Below is an explanation by David Blevins on the usage of xbean in OpenEJB. This text was taken from an email conversation. To view the full conversation, click here
xbean-reflect is a beefed up reflection library.
Earlier 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.
Assembler.java We also use it to construct Stateful and Stateless session bean instances.
xbean-finder is the second coolest library ever. It's a beefed up service finder for grabbing stuff in your classpath. We use it at a couple of places.
The available commands are in properties files in “META-INF/org.openejb.cli/{name}”, where {name} is the name of the command. See:
Earlier 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. See MainImpl.java
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. 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.
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}. See:
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:
You can override any server service property in the same way. Here are a bunch more examples:
Option: -D.bind= openejb start -Dejbd.bind=10.45.67.8 openejb start -Dejbd.bind=myhost.foo.com openejb start -Dtelnet.bind=myhost.foo.com
Option: -D.port= openejb start -Dejbd.port=8765 openejb start -Dhttpejbd.port=8888
Option: -D.only_from= openejb start -Dadmin.only_from=192.168.1.12 openejb start -Dadmin.only_from=192.168.1.12,joe.foo.com,robert
Option: -D.threads= openejb start -Dejbd.threads=200
Option: -D.disabled=<true/false> openejb start -Dtelnet.disabled=true