Exactly right Ted, you explained it much better than me. But that is exactly the functionality we are looking for. We need to explicitly manage the classloading and be able to associate a classloader with each component so they can each have their own namespace. Implementing each component as a SSB would work if we had the capability of managing the deployment ourselves, because there is more to our component than the business logic that would be implemented in the SSB (Dialog, meta-data, etc...). Furthermore we require that the deployment is dynamic and can be done without bringing the system down. Thanks to you and Sacha we have a few JSRs to look at.
I really liked your Idea about using a Servlet for doing the classloading. Yes, it is not pretty, but I believe it may help us in the short term in at least being portable. I was hoping someone may have tried writing a wrapper for deploying EJB s already for a similar solution. J2EE 1.3 has worked out very well for us. Almost all of our prior propriety architecture mapped over fairly cleanly. MDB's were a definite requirement for us. The only roadblock we have come up against has been the classloading. But, when there is a will there is a way! About the book, Its already in our library, and we definitely consider it a must read! Thanks for the help, Shone -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Ted Neward Sent: Sunday, January 13, 2002 6:01 PM To: [EMAIL PROTECTED] Subject: Re: EJB & ClassLoading > So, if I well understand you, you have your service implementation and a > tool that allow you to configure your services. > > Why not then, use your tool to write the deployement descriptor of your > beans? You will then be able to write, in the deployement descriptor, > configuration values your bean will then read from JNDI. > Because they want to manage the deployment and usage directly, rather than through the completely unspecified facilities of the EJB specification. (There is no portability here--the spec punts on this deliberately, to allow vendors to do what they wish. Hot reloading of EJBs isn't even required, IIRC.) > Why not simply put everything in the bean JAR? why is the classloading such > an issue in your case? > Because then you can't drop and reload new instances of the same object into the VM--only by explicitly managing ClassLoader relationships is this a feasible process. Shone, I'm afraid that the explicit component management that you're looking for isn't there in EJB. What you *really* wanted, rather than porting the app over to EJB, was to use something that conformed to JSR-111, the Services API JSR, which isn't even close to being finished yet. :/ Having said that, though.... Another approach you can think about is instead of using RMI, use HTTP and the Servlet portion of the J2EE container. Servlets are not forbidden to load & use ClassLoader management (so long as you remember to keep the ClassLoader delegation tree intact, anyway), and this would give you your component-management within the J2EE container. This sort of falls halfway in between your options 1 and 2--it's not ideal, in that you have to move to doing some of the proxying by hand (create the java.net.URL object, marshal up the parameters--you can just serialize them--and then send the request, where ther recipient servlet then has to unmarshal the parameters--again, just deserialize--and so on with the response), but it does logistically seem to fall halfway in between. Had I been around when you were considering the port, I'd have suggested you not do it; unfortunately, that's water under the bridgework. You might take a look at Apache Avalon (Berin Loritsch is on the JSR 111 Expert Group) as another Services Framework, you might take a look at JNLP as a deployment framework, and I humbly suggest you might find a few ideas in my "Server-Based Java Programming" book. Ted Neward {.NET || Java} Course Author & Instructor, DevelopMentor (http://www.develop.com) http://www.javageeks.com/tneward ----- Original Message ----- From: "Sacha Labourey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 13, 2002 9:36 AM Subject: Re: [EJB-INT] EJB & ClassLoading > Hello, > > > Actually our components are used on both the client and the server side. > > Among other things a component is > > made up of: > > 1. A service class , which contains business logic defined by the > > developer > > of the component > > 2. A dialog class that is used within our design tool to manage parameters > > needed in the service class. > > > > Loading the dialog class into the design tool is a no brainier. > > But loading > > the service class (and external libraries) > > into our ProcessEngine (Server) is a little more difficult with the > > restriction on class loading. > > > > We only recently changed our architecture over to J2EE (Proprietary before > > that). Everything mapped over fairly well, except for the pluggable > > component part of our architecture. > > So, if I well understand you, you have your service implementation and a > tool that allow you to configure your services. > > Why not then, use your tool to write the deployement descriptor of your > beans? You will then be able to write, in the deployement descriptor, > configuration values your bean will then read from JNDI. > > For your beans, you need to understand that they are somehow "passive" i.e. > they don't manage threading, classloading, ... and only receive requests > that have been addressed by the container. Consequently, if you want to > implement some specific behaviours such as implementing specific services > that don't fit in the J2EE world, you may want to implement them as JMX > services. > > > > So once again these are the only options I see, I was hoping there may be > > more. > > > > 1. Simply leave the classloading in the EJB Bean (Stateless > > Session Bean). > > And test on various AppServers. Of course this will be illegal. > > Why not simply put everything in the bean JAR? why is the classloading such > an issue in your case? > > > 2. Implement an RMI server that does the class loading and call > > it from our > > Bean. > > You cannot be sure that the bean will have access to the class loaded by the > RMI server: the classloading mechanism/structure is app server dependent. > > > 3. Implement our components as Stateless Session Beans, so that the EJB > > Container handles the class loading. > > this is the way to do it. Why do you think it is not the best solution for > you? What are your specific constraints? > > Cheers, > > > > Sacha > > =========================================================================== > 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".
