Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <3.0.6.32.20010227171334.008d5d50@alphalink.com.au>
Date: Tue, 27 Feb 2001 17:13:34 +1100
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
From: Peter Donald <donaldp@apache.org>
Subject: Re: [proposal] Primitive and composite patterns
In-Reply-To: <3A9B42AB.5D69D680@betaversion.org>
References: <3.0.6.32.20010227003534.007c2a40@alphalink.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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