avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Container nesting, common attributes and startup layer: Solution? (was Re: BlockContext & Merlin.)
Date Sun, 25 Aug 2002 13:00:08 GMT
Nicola Ken Barozzi wrote:

> Paul Hammant wrote:
> [snipped many things that don't reall make much sense to me, but that 
> I won't question for the respect I have of you; go along, I will follow]
>> Nicola,
> ...
>>> 3) define a common startup layer for the Avalon Containers, so that 
>>> it can be used with all containers. I imagine a single set of shell 
>>> scripts, a single servlet container, a single class container, which 
>>> can use inside any other container.
>>> This would make it possible to run Phoenix or Merlin or whatever as 
>>> standalone, or in a servlet, or in another program... and also nested.
>> I don't think you can count servlet.  Why?  It is not an Lifecycle 
>> using API.
> Concrete example: Cocoon is an Avalon Container. I want to be able to 
> run it standalone (CLI), in a Servlet (as now) or directly as a .SAR 
> in Phoenix. 


>>> This would eliminate the problems we are having now, by making 
>>> components usable in all containers by nesting containers, and 
>>> making any container easily embedded in other apps.
>> With respect, I have written two containers that sit on top of the 
>> default container Phoenix.  They are Jesktop and EOB.  Both of them 
>> handle classloading of their separate componets well enough.  It 
>> would be nice for me to use ContainerKit or Excalibur/Container to 
>> save lines of code, but I have not done so yet.  Anyway, the point is 
>> that container-in-container is possible already.
> I can easily make plain components work in Phoenix, but as you have 
> seen with Merlin, viceversa is not painless.
> Can Merlin use EOB?

I dunno, I suggestd to Stephen that he tried it a couple of week ago :-)

>> *Please* let me continue with my slow programme of issue-by-issue 
>> conflict resolution.
> [I still don't see how your mail about the blurb is an issue-by-issue 
> conflict resolution; please remain concrete on the proposals.]
I am, We started with four choices for BlockContext 
compatability/resolution and we are working towards an agreement.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message