avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 14:45:48 GMT


Stephen McConnell wrote:
...
>> Context is a very delicate point in the context ;-) of component 
>> portability.
>>
>> Personally I tend to think (sensation) that the whole concept of 
>> Context is flawed, because it is usually used in the wrong way.
>>
>> Services can be given by the ServiceManager. The container should 
>> *never* expose itself to the components it manages, it breaks SoC and 
>> IoC. This means that the abuve services you mention should not be 
>> given at all to the component, given as a service or given in a 
>> standard way that we should define. 
> 
> This is the issue - "given as a service or given in a standard way that 
> we should define" - we know how to create components - we have to define 
> the standard way of creating context.

+1


>> I think that Context is a hole in the whole architectire.
>>
>> What cases can *only* be /reasonably/ solved by a Context?
> 
>        String name = (String) context.get("name");
>        File rootDir = (File) context.get("root");
>        ClassLoader loader = (ClassLoader) context.get("classloader");

    String name = (String) servicemanager.get("name");
    File rootDir = (File) servicemanager.get("root");
    ClassLoader loader = (ClassLoader) servicemanager.get("classloader");

Go tell users the difference ;-)

>> How can we try to enforce good use of it?
> 
> By providing a specification of how context values can be created.  That 
> specification then defines the limitation a developer can work within to 
> ensure component context usage is not tied to a particular container.

+1

And keep kernel services out of there somehow.

Since Cocoon *will* have his context, if we put kernel access stuff in 
there too we will have a context with a double container dependency <ugh>

BTW, what the heck is Cocoon from an architectural POV?
A service? A container? Both?

I see two types of components in Cocoon: generic ones, that will be made 
as the new block specification, and Cocoon specific ones, the sitemap 
components.

The latter will need to rely on a CocoonContext, the others won't.

If Cocoon wants to access the kernel services IMO it should not go 
through CocoonContext, but via a KernelService or whatever.

I understand that exposing the kernel as a service has created problems, 
but can't we:

- take it away from context without putting it in service (ie new method)

or

- expose the kernel services as generic standard services based on the 
container profile (micro, std, ee)?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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