Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3D6A299D.30100@apache.org>
Date: Mon, 26 Aug 2002 15:14:05 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
References: <3D677832.20604@yahoo.com> <3D6A12E6.3070308@yahoo.com>
 <3D6A176B.50608@apache.org> <200208262241.08431.peter@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Peter Donald wrote:
> On Mon, 26 Aug 2002 21:56, Nicola Ken Barozzi wrote:
> 
>>If yes, they should be in framework IMNSHO.
>>If no, it should be clearly stated that they are Phoenix-only compatible.
> 
> Well given that cornerstone was designated a "Set of default services for 
> Avalon/Phoenix" I think it is a given that they are only considered to be 
> supported for Phoenix deployments. The link against Phoenix can be broken for 
> some of them after the next evolution stage and most of the components will 
> be migrated back into excalibur. 

Yes, ok. It's mainly a user-perception issue ATM.

IMHO the next evolution stage is near, hence my "proactive" thinking ;-)

>>So you are saying that the Phoenix BlockContext has to be regarded as
>>the standard Container Context?
> 
> 
> Nope. I don't think anyone one has suggested that. 
> 
> However if a container needs to run components that were written to a 
> particular containers API then they need to have a compatability layer. Much 
> like if you use a bunch of components in excalibur you are still largely 
> restricted to ECM/Fortress unless you want to extend your component or your 
> container.

Yes, I understand/agree.

> Stephen has been suggesting that Phoenix should be maintaining a compatability 
> layer for Merlin because Phoenix is legacy, badly written etc.

I didn't understand he meant that, and privately he has never said so.
He says that Phoenix is *different* from Merlin, and for some 
functionality, Merlin is better, that's all.

If he intended in any way discredit Phoenix, and I don't think he did, I 
would have backed your resentment from the start.

>>Can we make this "spec" become more clearly defined and part of
>>framework somehow?
> 
> This is where things are going. Just need more time to experiment with things 
> to make sure we are going in the right direction. The core ideas are 
> relatively stable and are mostly derived and enhanced Phoenix ideas.
> 
> See 
> 
> jakarta-avalon-excalibur/containerkit/src/java/org/apache/avalon/framework/info/
> 
> For the "code" view of Component info (descendents of BlockInfo). They 
> basically describe the requirements of a Component (ie what services it 
> needs, services it exports, context entrys it requires, loggers it uses etc.

Hey, this is what Merlin does... hmmm...

> Each aspect of component can be extended by "attributes". Attributes are 
> key=value pairs that store extra information about the aspect and allow you 
> to extend it in all sorts of ways. 
> 
> It is the attributes that are the things proving difficult to define as they 
> require all sorts of experimentation. It is these attributes that are the 
> causing the delay in it coming about.

Ah, ok.
I still don't understand well why you and Stephan say the same things 
but have two different Containers...

IIRC you and Stephen were working both on ContainerKit, why does Stephen 
(question for Stephen, and *please* be short) think that this approach 
is not enough?

>>I repeat myself, let's define the contracts and the boundaries well, and
>>I humbly suggest you to also tackle the block and SAR think, because I
>>think that they are valuable concepts that need to be integrated more at
>>a lower level.
> 
> 
> The notion of a Block disapears in next stage of evolution - there is just 
> Components and all of them are really super-charged Blocks in current 
> terminology.

Yes, I understood that and it's very nice :-)

> I don't think it is appropriate just yet to define the SAR deployment format 
> (which includes all the assembly/configuration/environment data) because 
> containers will definetly need different things in this area. It may be 
> possible to define a package (jar) format. Possibly something like
> 
> * standard naming convention for JDK1.3 Extensions in manifest
> * standard mechanism for defining components (ie 
> META-INF/avalon/components.xml)
> * standard mechanism for defining factorys, resources and possibly "roles"[1] 
> (ie META-INF/avalon/roles.xml, META-INF/avalon/resources.xml)
> 
> [1] Note that this is partially inheriting from work in myrmidon and may not 
> be so appropriate for phoenix and merlin. But it would be appropriate for 
> Cocoon and Myrmidon. However this will take longer to figure out if we can 
> figure it out at all.

Ok.
But again, it seems that you are not giving a look at what Merlin did 
about this IIUC it did some experimentation about it.

Why can't some of the more generic Merlin features on this part be used?

I understood that lifecycle extensions tend to ring alarm bell on you, 
and I have personally accepted that ATM it's better to relefate them to 
a Merlin/Fortress container specific thing.

Let my try to enucleate Merlin "features" and how they relate to current 
issues.
Please be patient, it's difficult for me because you are so quick and 
nimble on these things, I'm not so into them so deeply yet.

Merlin Kernel
--------------
A Merlin and a Phoenix abstraction for Container management.
IMHO there is no need to expose this out of the Merlin Container.
Maybe in the future Phoenix and Merlin Kernels will be interoperable, maybe.

Cascading containers
---------------------
No need to expose this outside of Merlin.

Exported services
------------------
If Merlin is run as a Phoenix block, it can expose services it Manages 
well, so this is a possibility of playing well with Phoenix.

Lifecycle Extensions
----------------------
Controversial, there is no immediate need to expose them to *all* 
containers.
We should though define that any Container that implements extensions is 
highly recommended to use the standard extension mechanism.

Deployment & Assembly
------------------------

Highly important that we get this to a common level.
If you regerd that having all components use a single Container model is 
too limiting ATM, and I respect that, we must achieve compatibility on 
the descriptors.

http://jakarta.apache.org/avalon/merlin/assembly.html
http://jakarta.apache.org/avalon/merlin/deployment.html

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