We had a discussion about making most of the extra parts of phoenix pluggable services (we used the term "facilities", talked about .far) and there was some code at some point that went this direction.
It all got hideously complex so Pete (rightly so) cleaned it up a lot and made the services we needed sort of directly called by the kernel (ie the manager). Maybe we will arrive at a point in time somewhere in the future where we have a better abstraction and the phoenix kernel becomes completely "servicable" itself. - Leo On Tue, 2002-07-02 at 11:20, Nicola Ken Barozzi wrote: > > Peter Donald wrote: > > At 10:30 AM 7/2/2002 +0200, you wrote: > > > >>> Example services that only container can provide; > >>> * Modification/Saving of Configuration object > >>> * Access to ClassLoader hierarchy of app > >>> * Access to ThreadGroup hierarchy of app > >>> * Access to various code-based Security policys > >>> * name of component > >>> etc > >> > >> > >> It seems that this is the issue. > >> If we want to be portable between containers, this just won't work. > >> > >> IMO *no* container should *ever* be the only one capable of giving > >> that service. > > > > > > Thats where individual containers differentiate. ie Some applications > > will require these extra services. > > > > Some real examples from Phoenix; > > * MBeanServer should be server wide and managed by kernel. Thus in some > > cases kernel needs to expose MBeanServer to components so they can do magic > > It's a service, so it can easily be given via Serviceable. > > The fact that it's tied to a specific container is not a problem, since > with the three container approach we are effectively making three > component profiles, ie with increasing demands on the container. > > MBeanServer service would simply require Phoenix. > > > * ClassLoader needs to be exposed to components like ServletEngines. ie > > You want to know exact hierarchy from Common to shared to other > > ClassLoaders. In some cases you want this to be pluggable. ie Embedding > > Tomcat/Jo/Jetty into an EJB server requires that the ClassLoader > > hierarchy be re-arranged but the different components still access > > ClassLoaders via symbolic names > > Still another possible service. > > > In the future (JDK1.5 time), most servers will need to be able handle > > Isolates and that will usually be managed by container etc. > > They are still exposable as services. > I understand your POV, but by making them services, we are being more > consistent (ie a service is a Service is a service) and paving the way > for a possible future indipendence from the container (ie the kernel > would expose itself as a service to these services). > > > There are some commonalities that could be homogenized. ie Phoenix, > > myrmidon (and cocoon?) all provide a base directory from which component > > can operate. Phoenix and myrmidon also provide the component with its > > own name. The keys for these values could definetly be standardized > > across the board. > > Yes, this is something that could/should? be done. > Context is something like XML: without a schema it's just making > documents unportable. > > > List of common data values; > > > > * Container version/build number > > * component name > > * base directory > > +1+1+1 > > > * common/shared ClassLoaders (at least common to 2 containers anyways). > > Not as a service? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
