Fyi, for the ability to dynamically load new implementations of an existing service without bringing down the application/class loader, see the Lutris EAS J2EE application server. There's an article on the subject in the Lutris journal from last July. I doubt changing application servers is an option for you, but the approach is interesting in its own right.
Wes (seems to require netscape to display the graphics? and to subscribe to the newsletter...) http://www.lutris.com/journal/July2001/articles/ClassloaderArticle_files/classLoader.html > -----Original Message----- > From: Shone Sadler [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 13, 2002 8:34 AM > To: [EMAIL PROTECTED] > Subject: EJB & ClassLoading > > > Hello everyone, > > We have recently converted our app to take full advantage of > J2EE1.3. There > is one part of our application that relies heavily on classloading. In > particular, We load up a component (which is written to our > specification) > from the database. The component contains an xml descriptor > and may contain > external libraries as well. Unfortunately, the J2EE > specification still > prohibits classloading. Has anyone done anything similar? The three > approaches we are looking at doing include: > > 1. Simply leave the classloading in the EJB Bean (Stateless > Session Bean). > And test on various AppServers. > 2. Implement an RMI server that does the class loading and > call it from our > Bean. > 3. Implement our components as Stateless Session Beans, so > that the EJB > Container handles the class loading. > > To us option 3 seems the most appealing, but there some issues with > deployment. It is a requirement for our application to be able to > dynamically add new components and redeploy existing one > without bringing > the system down. Furthermore, our components include more > than the execution > service they also include a Dialog, etc.. used by other parts of the > application. We currently have a UI for deploying our > components, the system > would need to deploy a component to any Application Server > when a deployment > is made to the database through the UI. This requires the > Application Server > to support Hot Deployment and preferably provide a Deployment API. > > Any feedback about a better alternative would be appreciated! > > Thanks, > > Shone > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > of the message "signoff EJB-INTEREST". For general help, > send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
