YourNamespace . That is where the error is occurring. If you do not define a param-
eter map, that does not necessarily mean that one does not exist.
As we saw with result mapping, primitive values can only be used if they are
wrapped in another object (this assumes that you are not using Java 5, in which
case you can pass in primitive parameters anywhere you want to because of the
“autoboxing” feature). If you want to pass a primitive value into i BATIS , you can
do it by using a bean (see section 4.3.2) or by using one of the primitive wrapper
classes (i.e., Integer, Long, etc.).
Arrays of primitive types can be passed into i BATIS , but using arrays is
beyond the scope of this chapter. For information related to using arrays
with Dynamic SQL , see section 8.2.5.
OK, now let's move on and not be so primitive...
JavaBean and Map parameters
Although there is a difference between bean and Map parameters, the syntax is
identical when you are working with them. The difference lies in the behavior of
the two when the parameter maps are loading.
If you create a parameter map with a bean and attempt to refer to a property
that does not exist, you will get an immediate failure when the parameter map is
loaded. This is a good thing, because it helps you keep from letting users find the
bugs—you will find them yourself.
If you do the same thing with a Map, there is no way for i BATIS to know that the
property does not exist (because the Map is built at runtime instead of at compile
time), so there is no way for it to help you identify a potential failure.
This brings up an important point: early failure is a good thing. Every bug you
see and correct before releasing your application is a bug that does not impact
your users. Fewer bugs sent to your users means that your users are more produc-
tive, and the value of your software increases.
OK, so now that we have input values nailed down, let's move on to getting the
output values that you need.