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".
