![]() |
![]() |
![]() |
![]() |
![]() |
||||
![]() |
Home | News | FAQ | Download | Lists | Issues | ![]() |
||||||
![]() |
![]() |
![]() |
![]() |
![]() |
||||
How XBean is used in OpenEJBBelow 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-reflectxbean-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. Some code refs:
xbean-finderxbean-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. 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: 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" 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. 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}. 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 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> You can override any server service property in the same way. Here are a bunch more examples: Option: -D<service>.bind=<address> Option: -D<service>.port=<port> Option: -D<service>.only_from=<addresses> Option: -D<service>.threads=<max> Option: -D<service>.disabled=<true/false> |
![]() |
|||||||
![]()
|
![]() |