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
