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 08:56:32 GMT
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
* 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

In the future (JDK1.5 time), most servers will need to be able handle 
Isolates and that will usually be managed by container etc.

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.

List of common data values;

* Container version/build number
* component name
* base directory
* common/shared ClassLoaders (at least common to 2 containers anyways).


>Context is a very delicate point in the context ;-) of component portability.

Mostly if you use it you become unportable ;)

>Personally I tend to think (sensation) that the whole concept of Context 
>is flawed, because it is usually used in the wrong way.

It is a bit icky which is why it is probably the most rarely used part of 
the framework. But is necessary at times - pretty much anytime the 
container is the only provider of service/data or that data is generated at 
runtime by container.

>What cases can *only* be /reasonably/ solved by a Context?
>
>How can we try to enforce good use of it?


Impossible ;)


Cheers,

Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
              - John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


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