I cant get the article (login required), but I thought that a classloader was not permitted to unload a class once it was loaded? hence the approach of dropping a classloader and starting again in this scenario...
I should say, that I've never actually implemented this myself, but from my readings, that was the deal... anyone enlighten me on this? cheers dim ----- Original Message ----- From: "Isberg, Wes <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 4:13 PM Subject: Re: EJB & ClassLoading > 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". > =========================================================================== 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".
