Jacek -
The situation I deal alot with is a hosting environment, in which we have one or more instances of Tomcat running behind an Apache web server. Since only a minority of applications actually use EJBs, we run OpenEJB separately via "openejb.sh start". This means that Tomcat applications must define their EJB resources within the appropriate <Context> block and that the EJB jars must be available in Tomcat's common/lib.
The problem with this configuration is that we'll have to restart both Tomcat and OpenEJB in order to load up new EJBs. While I can afford to restart OpenEJB, with our heavy load I don't want to always restart Tomcat. Hence I am keenly interested in doing some work to eliminate that problem.
Unless I misunderstand you, what you describe below refers to the situation where OpenEJB is run as an embedded service within Tomcat, correct?
Regarding OpenEJB 2, it would really be nice to be able to enjoy the new features in a standalone mode. I'm presuming that it is the JMS dependencies that will cause a problem? I'm not adverse to running Geronimo, I just like a clean, smaller footprint for everything ...
Regards,
Lajos
Jacek Laskowski wrote:
Lajos wrote:
Hi Jacek -
Hi Lajos,
Thanks for the reply. Glad to hear about the OpenEJB 2 plans. One question: with that release, can we still run OpenEJB in standalone mode? I ask because that is the typical configuration I use OpenEJB in: running it in a separate JVM from Tomcat.
And, I guess, that's the configuration what most people use.
Looking at the changes to OpenEJB2 to comply with the 2.1 spec I don't think the standalone (remote) mode is possible yet unless it's embedded in Apache Geronimo.
If you want to use OpenEJB in the standalone mode, I'd strongly advise you to use it in Apache Geronimo so besides EJBs you'll also be able to leverage the whole J2EE stack of services Apache Geronimo provides which aren't available in Apache Tomcat. I think using Apache Geronimo in your configuration will let you change your architecture and functionality in ways you haven't thought of before. Think of using Geronimo (with OpenEJB) as the feature you can use at no charge :)
Which brings me to my proposal. So far, I've been looking at this from a Tomcat perspective: I'd like to move the EJB definitions and class loading down to the application (context) level and be able to restart a context in order to make it 'aware' of newly defined EJBs. For this, I have some ideas since I am fairly familiar with the Tomcat source code. However, you are right, it would be also necessary to have that dynamic loading capability in OpenEJB. While I only just now started looking at that source code, I would be willing to have a go at it if you think it would be possible. Would you have any suggestions on where to start?
I think it's possible *now*. Just ask Tomcat for restarting the WebAppLoader that loaded your EJBs and the next time the webapp will be started up, OpenEJB shall load the newly added EJBs. No code changes required.
Should you want it in OpenEJB, you'd have to create a resource watchdog that would monitor EJBs repositories, if it encountered any new/modified EJBs it'd load them *all* again.
Since, the webapp loaded in Tomcat uses classes that may have been changed the class loader would have to restart itself as well.
It seems it's a matter of recognizing the changes in EJBs. I can think of a bunch of if's where you would need to analyse the changes and decide whether or not Tomcat WebAppLoader (WAL) needs to be restarted as well. Some changes don't incur Tomcat WAL restarting, like changing the method body of a method. Unless, the changes don't influence the contract (the EJB interfaces) it's not necessary to restart Tomcat WAL.
Hope it helps.
Regards,
Lajos
-Jacek
--
Lajos Moczar
----------------------------------------
Open Source Support, Consulting and Training
----------------------------------------
Tomcat Unleashed
(www.amazon.com/exec/obidos/tg/detail/-/0672326361)Cocoon Developer's Handbook (www.amazon.com/exec/obidos/tg/detail/-/0672322579)
_ _____
/ \ /
/___\ /
/ \ /____http://www.galatea.com -- powered by AzSSL
