Kurt and I have been doing a number of things to leverage the JBoss kernel for ESB and to clean up the overall distribution of JBoss ESB. A lot of sweeping changes have been done for deployment and testing. We've also drastically changed the distribution.
Here's what we've done so far:
* ESB Deployer: real packaging and hotdeployment for ESB
We've written a JBoss Deployer for ESB which allows you to create ESB jar archives or raw esb XML files and deploy them to a JBoss instance. In the old ESB jboss integration, you could only have one jbossesb.xml file. Now you can have multiple deployments. The two deployment options are:
- a .esb jar archive. This is a regular JAR file with a .esb suffix that has any number of user classes in it. A META-INF/jboss-esb.xml file in the .esb jar archive is required and this defines your providers and services in the current and past XML file format. You may also add a META-INF/classloader.xml file if you want to have classloader scoping for this .esb deployment. The syntax is exactly the same as other classloading configuration of other JBoss components.
- a xxx-esb.xml file. This is just a raw esb .xml file that defines
* New .sar files. jbossesb.sar and jbossesb-registry.sar. In the old distribution, everything was in one scoped .sar file. This was not feasible as it required user classes, actions, services, etc. that use ESB to be in the same scoped classloader domain as the esb files. Now, only the jbossesb-registry.sar is scoped for the JAXR and Scout snapshots.
* Everything is self contained in the .sar files now. There is no special installation step for installing into JBoss AS other than copying the .sar files into the deploy directory. All configuration files are now under jbossesb.sar. This includes juddi and esb property files, and datasource -ds.xml files for juddi and esb.
* jbossesb.sar now will initialize the juddi and message store database at boot time if they haven't already been initialized. Look in jbossesb.sar/META-INF/jboss-service.xml to see how this is done with a generic DatabaseInitializer service that we wrote.
* New distribution. JBoss ESB will now have a ESB Server distribution, and a SAR distribution. The ESB Server distribution is the raw JBoss 4.x Kernel configured with basic services that a full blown ESB needs like, database connection pooling, JNDI, juddi, JMS, transactions. FYI, this boots in 11 seconds. Most of the time is in initializing JMS and Tomcat. The SAR distribution is just the esb .sar files, without the server. The idea with the SAR distribution is if you want to deploy onto an existing JBoss AS distribution
* To build the distribution, I created a new ant file under product/build-distr.xml. After you do ant dist, do a ant -f build-distr.xml This will create a full server distribution under product/build/jbossesb-server-4.0.1.
* To run the distribution $ cd product/build/jbossesb-server-4.0.1/bin. run.bat or run.sh
* TESTING. I've incorporated the JBoss Test junit integration that we use in the appserver project. It is really good because it allows you to specify archives/files you want to deploy to a running server for the duration of the tests of that test class. Look at qa/junit/src/org/jboss/soa/esb/server/unit/SimpleDeployUnitTestCase.java.
* I added an ant target in qa/junit that allows you to run all the tests in a specific directory in the source tree. For example:
ant -Dtest=server one-test
will run the SimpleDeployUnitTestCase example I talk about above.
This target creates junit output into qa/build/reports which another ant target "tests-report-html" can transform into a nice HTML report of all the tests you ran. Eventually we should really port all the tests to this framework so that you can build and run all tests within ESB just by checking out and building ESB.
Well, I think that is about it. Hopefully I didn't miss anything. If I did, Kurt speak up!!!
Looks great Bill, just wanted to add that deployments to the standalone is kept inline with deploying to JBossAS, so it's easy to switch deployments between the two.
So far only the helloworld sample has been converted to the new deployment. The work to convert one is to rename the jbossesb.xml to jboss-esb.xml, then add that to the custom-code-jar in META-INF, and make sure the extention of the archive is '.esb'. This is your deployable package.
Nice. Good work all around guys.
Yes, great work.
This sounds great guys :-)
We should look at deploying the admin console with the server!
Quick one... can the deployments be deployed in exploded form, or must they be jar'd in a .esb archive?
should be explodable, but Kurt had some problems with that. We still have a few things to iron out by Friday.
It works either way, I just have problems with it being hot-deployable. Touching the META-INF/jboss-esb.xml should trigger a redeploy but that does not seem to work for me.
This is minor enough, but just wondering what's supposed to happen if 2 .esb deployments try to deploy the same mbean (e.g. for a JMS queue the both depend on)? This is the case for some of the quickstarts.
At the moment, it appears as though you get a deployment error on the second deployment.
Just wondering was there anything we could do.
If you want to be able to deploy the quickstarts together, then deploy differently named queues/topics. It is unexceptable, IMO, for a user to have to do any manual steps when running the demos other than running ant.
Nice, is this changes coming in next release ? and witch date is the next release coming ?
MP1 for 4.0 is due out at the end of this week.
I am running into an issue with classloading in the ActionProcessingPipeline. In particular, I have reusable action classes packaged into a sar separate from the jbossesb.sar. My standalone config (jboss-esb.xml) references an action class loaded in the other sar. When the config is loaded at startup (the pipeline eager-loads the action classes on initialization), the other sar has not been loaded, resulting in a ClassNotFoundException. If I move the jar with custom actions into jbossesb.sar, everything works fine. I am wondering if the ActionProcessingPipeline should lazy-load the action classes so that everything has a chance to load. This has the side-effect of not reporting classloading errors until the first time the action chain is used -- which may be a bad thing. Any ideas?
Are you running jbossesb.sar scoped or unscoped? In MP1 it no longer needs to be scoped. So that may solve your issues?
BTW you can add a sar (mbean) dependency in the jboss-service.xml, to make sure one loads before the other.
I am not sure if we are running scoped or unscoped. I noticed that the loader-repository was removed from jbossesb.sar/META-INF/jboss-service.xml, so we did the same for ours. I was thinking scoping was only at the deployment level and only valid for exploded or zipped deployments since it involves adding a file to meta-inf. Is there a default scoping setting somewhere?