On Jul 21, 2006, at 8:30 PM, David Blevins wrote:
I went down the rabbit hole, feedback requested. Should we chase
this rabbit?
And to make sure credit is dished out, Dain definitely dug the
hole :) I just followed with the ejb-jar deployment stuff.
Anyway, more just looking to get some feedback to see if we think
OpenEJB should go down this hole too. I.e. good idea? looks
promising? yes/no?
-David
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
