Thanks for the quick response. I am definitly interested in both JSR-77 and JSR-88 and will be looking at them, Thanks.
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 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. 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. Shone -----Original Message----- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 13, 2002 11:59 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: EJB & ClassLoading Shone, About which part of your system exactly do you speak? The client side or the server side? If this is about the server side (i.e. EJBs) and you want to stay compatible with the specification, you need to create your JAR containing your classes, libs, descriptors, ... and deploy this: you are not allowed to play with classloaders in your bean (even SLSB). If you have specific requirements, you will need to check with your particular app-server to see which schemes it may support. Then, for your other questions, it is really app-server-vendor dependent (deployement, ...). You may take a look at JSR-77 and JSR-88 for vendor-neutral J2EE management/deployement specs. Can you provide more details? Cheers, Sacha > -----Message d'origine----- > De : A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]De la part de Shone Sadler > Envoy� : dimanche, 13 janvier 2002 17:34 > � : [EMAIL PROTECTED] > Objet : 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. =========================================================================== 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".
