avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 09:35:07 GMT
At 11:20 AM 7/2/2002 +0200, you wrote:
>>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?

Exposing Kernel services via Serviceable seems nice at first ... but soon 
becomes very ugly. You start having large special cases in your code and 
putting in lots of special cases that is very icky to say the very least.

ie When you are assembling you need to come up with a new notation that 
saids the container will supply service. ie Usually you say component X 
provides service P to Component Y. You have to also treat them specially 
all through the kernel and it ends up about doubling the container code. We 
experimented doing that with Phoenix for a it but eventually reverted.


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message