You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/25 13:38:28 UTC
Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Paul Hammant wrote:
> Stephen,
...
>> I do not see how this would fail to add value towards the Avalon
>> user. Perhaps you could provide your recommendations for the best
>> approach for users who are considering the development of new
>> components that they indented to be container neutral? A Phoenix
>> wrapper hides the problem, but I don't think this is the best approach
>> given the different features and benefits presented some of the more
>> recent generation containers?
>
>
> Now mate, I'm getting worse again. I'll reread later and see if it
> makes any sense! It looks at first glance like sales blurb for Merlin
Paul, now it's you who is being blind.
The above paragraph says nothing about Merlin.
It says that we should strive to make the same Components workable in
all containers, even the more recent ones.
"given the different features and benefits" only hints that other
containers like Merlin have *different* features and benefits, not better.
But if it were a sales blurb for Merlin?
Does it annoy you?
Given your previous conciliatory mails, I hope not.
Let's get the best of both worlds instead of fighting.
<> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
I see three issues to tacle ATM:
1) define a simple and workable set of rules to make container nesting
seamless. Peter has already said that it can be done, and it would make
it possible to embed seamlessly Merlin in Phoenix, or viceversa, or any
other, as I proposed in previous mail as a workable cooperation solution.
2) define a set of common attributes. Some attributes are like
interfaces, and must be discussed on and standardized on (see the
common-attributes-revisited thread).
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.
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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> 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.
Just a note
excalibur/container
* the common resources shared by Fortress and Merlin on
lifecycle extensions
* documentation about keys and attrbutes the impact
cross-container deployment
excalibur/meta
* the meta info model that is compatible with
both Merlin and Phoenix
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
EOB
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>>>
>>> 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 :-)
>
>
>
> EOB includes BlockContext which means that additional meta-info is
> required for these components to run inside Merlin. The solution to
> this involves the following:
>
> * add .xtype descriptors to the EOB distribution (these contain the
> information describing the depedencies that the EOB blocks have -
> including the dependency on the Phoenix BlockContext interface and
> Phoneix conterxt keys)
> * use the patched version of cornerstone that I'm maintaining (the
> patched version also includes the .xtype declarations in order to
> solve the same issues and provide convinient deployment profiles for
> some of the conterstone components)
One point I forgot to mention is that EOB does not publish the
components it provides under its manifest
If you include a .xtype (i.e. additional info to handle context
information) then you could declare this as follows:
Name: net/sourceforge/eob/core/DefaultApplicationRepository
Avalon: Type
If your using blockinfo declarations Merlin will recognize the Phoenix
pattern (but this will only work if you component does not reference
Phoniex APIs).
Name: net/sourceforge/eob/core/DefaultApplicationRepository
Avalon-Block: true
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> 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.
>
>
> +1
>
>>>> 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 :-)
EOB includes BlockContext which means that additional meta-info is
required for these components to run inside Merlin.
The solution to this involves the following:
* add .xtype descriptors to the EOB distribution (these contain the
information describing the depedencies that the EOB blocks have -
including the dependency on the Phoenix BlockContext interface and
Phoneix conterxt keys)
* use the patched version of cornerstone that I'm maintaining (the
patched version also includes the .xtype declarations in order to solve
the same issues and provide convinient deployment profiles for some of
the conterstone components)
Cheers, Steve.
>
>
>>> *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.
What about adding the deprication of BlockContext to the list?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Paul Hammant <Pa...@yahoo.com>.
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.
+1
>>> 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.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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?
> *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.]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>>> I do not see how this would fail to add value towards the Avalon
>>> user. Perhaps you could provide your recommendations for the best
>>> approach for users who are considering the development of new
>>> components that they indented to be container neutral? A Phoenix
>>> wrapper hides the problem, but I don't think this is the best
>>> approach given the different features and benefits presented some of
>>> the more recent generation containers?
>>
>>
>>
>> Now mate, I'm getting worse again. I'll reread later and see if it
>> makes any sense! It looks at first glance like sales blurb for Merlin
>
>
> Paul, now it's you who is being blind.
>
> The above paragraph says nothing about Merlin.
I inferred it, in a tongue-in-cheek way from 'more recent generation'.
> It says that we should strive to make the same Components workable in
> all containers, even the more recent ones.
> "given the different features and benefits" only hints that other
> containers like Merlin have *different* features and benefits, not better.
>
> But if it were a sales blurb for Merlin?
> Does it annoy you?
>
> Given your previous conciliatory mails, I hope not.
> Let's get the best of both worlds instead of fighting.
If you read my single line again, you'll note that it is concilliatory
(the word 'mate'). Indicates I am going to comback with something of
acomment that is less throw away.
I really don't want to be pointed at as part of the problem. I really
do not want that.
I am going to ask you to not question my impartiality again. There are
risks inherent in that that make me shrink from my mediation path.
> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
>
> I see three issues to tacle ATM:
>
> 1) define a simple and workable set of rules to make container nesting
> seamless. Peter has already said that it can be done, and it would
> make it possible to embed seamlessly Merlin in Phoenix, or viceversa,
> or any other, as I proposed in previous mail as a workable cooperation
> solution.
Which is sort of what we are doing. I'm choosing to tackle an issue at
a time. Currently I am dwelling on phoenix-client.jar the previous
required class GenericBlockContext.
> 2) define a set of common attributes. Some attributes are like
> interfaces, and must be discussed on and standardized on (see the
> common-attributes-revisited thread).
Attributes is in process as a discussion. I see no need to interfere
with the lengthy discussion on that at the present moment. All parties
moved on the naming of attributes as the discussion progressed. There
is no need to mediate.
> 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.
> 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.
*Please* let me continue with my slow programme of issue-by-issue
conflict resolution.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>