I went down the rabbit hole, feedback requested. Should we chase
this rabbit?
On Jul 15, 2006, at 3:16 PM, David Blevins wrote:
Ok, then I'm going to take a stab at updating the
ConfigurationFactory to use the new JEE pojo tree instead of our
old castor generated classes.
So I got the ConfigurationFactory rolled over to the JEE pojo tree
(i.e. the JAXB2 stuff i posted about). I split it up a bit further
so the same code can also be used with the xbean-spring assembler.
For an experiment, it's turning out kind of cool. It might end up as
something we'd want to support in addition to the standard
openejb.conf file.
Here is what a container looks like and a relevant deployments
section. Think of these both like the corresponding elements in an
openejb.conf file.
---snip---
...
<!--
# ==========================================================
# Default Stateless SessinBean Container
# ==========================================================
-->
<o:statelessContainer id="Default Stateless Container">
id Default Stateless Container
# Specifies the time to wait between invocations. This
# value is measured in milliseconds. A value of 5 would
# result in a time-out of 5 milliseconds between invocations.
# A value of zero would mean no timeout.
timeOut 0
# Specifies the size of the bean pools for this
# stateless SessionBean container.
poolSize 10
# StrictPooling tells the container what to do when the pool
# reaches it's maximum size and there are incoming requests
# that need instances.
#
# With strict pooling, requests will have to wait for instances
# to become available. The pool size will never grow beyond the
# the set PoolSize value.
#
# Without strict pooling, the container will create temporary
# instances to meet demand. The instances will last for just one
# method invocation and then are removed.
strictPooling true
transactionManager #transactionManager
securityService #securityService
<o:registry>
<o:addDeployments from="#deployments1" to="Default Stateless
Container"/>
</o:registry>
</o:statelessContainer>
<o:deployments id="deployments1" classpath="#classLoader"
transactionManager="#transactionManager" assembly="#assembly"/>
<o:assembly id="assembly"/>
...
---snip---
One thing to note is I added a "classpath" attribute to
<deployments>. This would work in addition to the existing "jar" and
"dir" options that give us "load this jar" and "load all jars in this
dir OR load this unpacked jar" respectively. The "classpath" option
would be "load all META-INF/ejb-jar.xml files in the specified
classloader." I.e. you can scrape the classpath of the specified
classloader and pull in any ejbs we find. We'd likely want to use
the same classloader to load those ejbs, but I didn't try that out.
We have a similar ability in 1.0 to scrape the classpath for ejbs via
setting an system property "openejb.deployments.classpath" to
"true". It's part of the magic that makes the Tomcat-webapp
integration work. There we just assume the classloader we should
look in is the current classloader. This is an extension of that
idea were the classloader can be constructed via some spring def and
then used as a source for deployments.
There are some ugly things which I threw in just to get things to
work via spring. I'd like to find a way to remove them, any ideas
welcome. Don't care for the "transactionManager" and the "assembly"
attributes of "<deployments...>. Needed these more or less just
because the way the code is organized. Kind of ugly.
What I dislike the most about the prototype is the complete and total
overuse of the container ID in several different places. It's not
just ugly, but easy to get wrong. I spent a whole day stepping
through code in a debugger just to realize I put the wrong ID in one
<addDeployments to="blah" ...>. The kicker is that it's an object
*inside* the <statelessContainer> (and other) element, so why should
I have to specify the name of the container I'm *in*.
There's likely a better way to do all this, but the good part is we
at least know it isn't a failed idea. We can probably hammer out
something better we think this is something people will like.
-David
