Outstanding. This is truly one of the gold standard examples for
technical explanations...
THANKS!
Regards,
Alan
David Blevins wrote:
On Aug 23, 2006, at 10:17 PM, Alan Cabrera wrote:
David,
This sounds really interesting. If you have the time, can you give a
brief explanation of what
xbean-reflect
xbean-reflect is the coolest library ever. It's basically a beefed up
reflection library.
Remember before how all pluggable components had an "init(Properties
props)" method? Same concept except now we throw the component class
and the properties into an "ObjectRecipe" and call create(). The
recipe will take the props out, convert them to the right data types,
and construct the object using the right constructor and setters.
So our Containers and stuff now use constructors and setters. Same
with anything in a service-jar.xml file.
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/resources/META-INF/org.openejb/service-jar.xml?r=2679
Some code refs:
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/assembler/classic/Assembler.java?r=2821#l254
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/assembler/classic/Assembler.java?r=2821#l264
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/assembler/classic/ContainerBuilder.java?r=2824#l98
We also use it to construct Stateful and Stateless session bean
instances.
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/core/stateful/StatefulInstanceManager.java?r=2835#l90
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/core/stateless/StatelessInstanceManager.java?r=2821#l71
xbean-finder
xbean-finder is the second coolest library ever. It's a beefed up
service finder for grabbing stuff in your classpath. We use it a
couple of places.
COMMAND LINE TOOL:
The available commands are in properties files in
"META-INF/org.openejb.cli/{name}", where {name} is the name of the
command. See:
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/resources/META-INF/org.openejb.cli
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/openejb-itests/src/main/resources/META-INF/org.openejb.cli
Remember before how it was sort of strange that we had the "test"
command hardcoded in a script, but the person may have uninstalled the
itests? Well now, if you have the itests jar, the "test" command will
be available. If you don't have the itests jar, the "test" command
won't be available. The "test" command itself is in the itests jar.
You can put any command in any jar and it will automatically become
available on the command line. Remove the jar and the command is gone.
When someone types "java -jar openejb.jar start" this guy will look
for "META-INF/org.openejb.cli/start". If he finds it, he'll create it
and execute it. If he doesn't find it, he'll list the available
commands by enumerating over all the files he see's in the classpath
under the "META-INF/org.openejb.cli/" directory.
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/openejb/cli/Main.java?r=2708
An extra cool thing is that each command has in it's properties a
"description" property. This is localized, so if the VM locale is
"pl" it will look for a "description.pl" property and use its value
when printing command line help. Hey Jacek, you want to make OpenEJB
the first open source container to have command line tools in Polish?
I'd like to give Jeremy Whitlock a big shout-out for doing such a bang
up job on this. He and I worked out the idea and white-boarded it in
the wiki, then Jeremy went off and coded up the whole thing! It was
fantastic.
SERVER SERVICES:
We also use the xbean-finder to create our Server Services (aka.
protocols). Our ServerService implementations are in properties files
under "META-INF/org.openejb.server.ServerService/{protocolName}"
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/server/openejb-server/src/main/resources/META-INF/org.openejb.server.ServerService/admin
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/server/openejb-ejbd/src/main/resources/META-INF/org.openejb.server.ServerService/ejbd
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/server/openejb-telnet/src/main/resources/META-INF/org.openejb.server.ServerService/telnet
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/server/openejb-http/src/main/resources/META-INF/org.openejb.server.ServerService/httpejbd
The very first time a ServerService is constructed, we squirt the
properties file into the openejb/conf/ directory so the user can edit
it. The properties files for ServerServices are very xinet.d like.
For example, here is the definition of the "admin" server service:
server = org.openejb.server.admin.AdminDaemon
bind = 127.0.0.1
port = 4200
disabled = false
threads = 1
only_from = localhost
You can reconfigure the "admin" server service, for example, via the
properties file in openejb/conf/admin.properties. Or you can do it on
the command line as such:
<in-a-shell>
$ ./bin/openejb start -Dadmin.bind=192.168.42.13
OPENEJB_HOME=/Users/dblevins/work/openejb1/target/openejb-1.1-SNAPSHOT
OpenEJB 1.1-SNAPSHOT build: 20060420-2356
http://www.openejb.org
resources 1
OpenEJB ready.
[init] OpenEJB Remote Server
** Starting Services **
NAME IP PORT
webadmin 127.0.0.1 4203
httpejbd 127.0.0.1 4204
telnet 127.0.0.1 4202
ejbd 127.0.0.1 4201
admin 192.168.42.13 4200
-------
Ready!
</in-a-shell>
You can override any server service property in the same way. Here
are a bunch more examples:
Option: -D<service>.bind=<address>
openejb start -Dejbd.bind=10.45.67.8
openejb start -Dejbd.bind=myhost.foo.com
openejb start -Dtelnet.bind=myhost.foo.com
Option: -D<service>.port=<port>
openejb start -Dejbd.port=8765
openejb start -Dhttpejbd.port=8888
Option: -D<service>.only_from=<addresses>
openejb start -Dadmin.only_from=192.168.1.12
openejb start -Dadmin.only_from=192.168.1.12,joe.foo.com,robert
Option: -D<service>.threads=<max>
openejb start -Dejbd.threads=200
Option: -D<service>.disabled=<true/false>
openejb start -Dtelnet.disabled=true
IN THE FUTURE:
I'd like to extend this overriding to *anything* in OpenEJB that uses
properties.
openejb start -Dcmp.PoolSize=200
On a similar note, I've posted in the past about using entirely
properties to configure the server and containers with no need for any
kind of xml config file. I'll dig that up and repost.
Anyway, I'm sure this is more than you asked for :)
I've pulled this information from various sources in email archives,
svn and some from my head. I spent a couple hours writing this email,
is there anyone who might be interested in putting this info in the
wiki and formatting it all nicely?
Thanks,
David
is and how they are used?
Regards,
Alan
David Blevins wrote:
On Aug 22, 2006, at 1:47 PM, Jacek Laskowski wrote:
Hi,
The subject says it all - where/how's XBean used in OpenEJB 3?
So far, I've worked in the xbean-reflect module (which I love) in a
few places, assembly and protocol creation IIRC. We use the
xbean-finder all over. And Dain did the xbean-spring work, which
gives us an alternate way to assemble OpenEJB. Definitely some work
that can be done there -- the xml format is still in prototype stage
and could be improved.
There are a couple modules of OpenEJB origin that were seeded when
XBean was at Codehaus, xbean-telnet and xbean-classpath. Both were
moved over so ActiveMQ, ServiceMix and others could use them. The
xbean-telnet module which is based on our telnet code and has since
been cleaned up a bit by Hiram for ActiveMQ -- he's pretty good at
making things look organized. The xbean-classpath module is based
on a chunk of our embedding cod; the part that can shove classes
into the classpath "forcefully" if needed. Always been meaning to
work those back in.
Is anyone working on using more features of XBean in OpenEJB3 (if
there's any left out ;-))?
I'm not currently working on anything, but I hope to start
prototyping an idea i had a couple weeks ago where we put ".xbean"
files in our server directories that say what they are (conf dir,
beans dir, logs dir, libs dir) and we wouldn't have to assume they
were named a specific thing or in a specific location anymore.
People could put the directories where ever they wanted, or in some
cases (libs and beans) have as many of them as they want. Still a
rough idea in my head and I have the urge to make it capable of
doing a lot more, such as a general-purpose metadata system. You
never really know till you start working on it.
Shall I
expect more to come or do I need to roll up my sleeves and do it
myself? ;-)
Both :) Overall, it's a "scratch your itch" based system. So if
you have an itch, you're encouraged to scratch it :)
As long as there are ideas, there'll be code to write and consume :)
-David
Jacek
--Jacek Laskowski
http://www.laskowski.net.pl
