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
