avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [proposal] Primitive and composite patterns
Date Tue, 27 Feb 2001 06:13:34 GMT
At 10:01  26/2/01 -0800, Federico Barbieri wrote:
>Peter Donald wrote:
>> 
>> At 05:23  26/2/01 -0800, Federico Barbieri wrote:
>> >It's a general rule it's better to have primitive than composite
>> >packages... because they don't have dependencies and they enforce SOC. I
>> >may like the avalon.pool interfaces but I don't want to inherit all
>> >component contracts. This make perfect sense.
>> 
>> The problem is that if you want to place anything in a CM then it needs to
>> implement Component - which is why some people I talked to said either
>> *everything* should implement component or *nothing* should implement
>> component and the CM should deal with objects. Thats the main reason why
>> Pool etal extend Component.
>
>not sure... being a Recyclabe doesn't imply being a component too... so
>I can have a pool being a Component and working with the CM but I can
>have a pool NOT implementing component as stand alone. 

you can but it is for all purposes practically unusable. Under Avalon
almost all components are shared via a ComponentManager. If we have to
extend components trivially to implement Component then it is a PITA to use
a CM. 

>The reason I want to clear this is simple... container is a desing
>pattern that is exteremly useful in many situation, including phoenix
>and its blocks, a servlet container and its servlet etc. If we can't
>decouple container from component then a SE can't benefit of the
>patterns since servlet ARE NOT components. This whould be a pity... 

I am not 100% clear what you are saying here but if it what I think you are
saying then I have a different opinion.

Whether something is a component or a container is completely a matter of
perspective. From one perspective a object may be a component while from
another it is a container. 

Take phoenix - It has a kernel (container) that hosts Applications
(component). These applications (now looks like a Container) are in turn
made of up of content-objects/Blocks (component). This Block (now a
container) can host other things like mailets/servlets/ejbs/other
(component again) etc.

>Then does it make sense to have a clean container package component
>unaware and a higher camelot package component aware? The container can
>be small but it's reusable by all container, camelot is for component
>oriented containers (phoenix etc.).

It does in the long run - but now is not the time to do it I don't think.
We haven't road tested camelot enough for it to be viable in alternate
contexts. Once we see it tested out in a few other places then it may be
something we could consider. We could break it down into
install/deploy/container/info/registry sections. Of course this will be
more further defined after use ;)


Cheers,

Pete

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


Mime
View raw message