On Mar 12, 2009, at 5:25 AM, Karan Malhi wrote:
Regardless, that won't stop us from implementing it :) I suspect
if we do
it and other vendors follow suit, it'll pretty much have to make it
into the
spec next time around.
Nice! . Is this on the top of your priority list? I have an area in
struts2
integration which could use this funcionality.
Not the top, but very high. Top priority in my mind right now is
getting our JNDI awkwardness straightened out.
The easiest way to implement this would be to scan at deployment like
everything else perhaps by adding an
"@org.apache.openejb.annotations.Injectable" annotation or something.
Would be great if we didn't have to do even that, but certainly would
be the easiest first step. Could probably get that in in a day or two
and wouldn't at all limit our ability to do it without the annotation
later. With the annotation, the user would get the same deploy time
checks as other EE components and without it'd be all runtime checks.
So both seem like a pretty ideal solution.
3) if more than one EJBContainer is active and the most recently
created
one is closed, do you return the current closed container, the most
recent
open container, null, or throw an exception.
This is tricky.Does that mean that per JVM there could be multiple
EJBContainer's? If thats the case then this method could throw an
exception.
Not a requirement which is good, but some thought it might imply that.
In our impl, the number of container systems you can put in your VM
depends on the number of classloaders that have loaded the openejb-
loader and openejb-core jars. In most cases that's going to be
exactly one as people load those jars right in the system classpath.
Basically, it boils down to the statics. If you have five sibling
classloaders and each of them have their own openejb-loader and
openejb-container jars and the parent classloader has neither of those
jars, you could have five container systems, one in each classloader.
-David
