You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/08/24 14:12:34 UTC
BlockContext & Merlin.
Folks,
http://jakarta.apache.org/avalon/phoenix/api/org/apache/avalon/phoenix/BlockContext.html
It appears that Merlin has a problem with mounting blocks. The problem
principally is that though a Context interface is handed in, blocks are
in the habit of casting them to BlockContext. Apart from making all
Avalon-Framework using containers need different specializations of
Context, it causes Merlin problems with hosting blocks.
This has been discussed over the past year or so, but perhaps now there
is need for a solution. So lets mull over some ideas, and find one that
is workable and that everying is happy with.
1) Merlin includes phoenix-client.jar and provides alternate
implemetations of the BlockContext interface.
(variations are - make phoenix-client.jar smaller by splitting out
stuff specific to the Phoenix kernel).
2) Change cornerstone comps to use Context as is, and access things via
'Object get(Object)'
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/context/Context.html
3) Create a new interface in A-F called say DirectoryNamedContext. It
has the two methods in BlockContext and extends Context. BlockContext
extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is
able to trade without reference to Phoenix. Adding an interface in this
way, as we all know is a backwards compatible thing.
Thoughts? ( Concise please )
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> 1) Merlin includes phoenix-client.jar and provides alternate
>> implemetations of the BlockContext interface.
>>
>> (variations are - make phoenix-client.jar smaller by splitting
>> out stuff specific to the Phoenix kernel).
>
> This is what I'm basically doing at the moment - the Phonix client in
> the excalibur/assembly/lib is a the regular phix-client.jar plus the
> GenericBlockContext implememtation. I don't like the solution but it
> works in terms of the work I'm doing with James and Cornerstone
> components.
With respect you are missing my point. I believe it is possible to
provide an alternative implementation of BlockContext. Although not
stated in my original poting, I that GenericBlockContext (impl) is not
required in Phoenix CVS.
Is it possible for you to merely include the phoenix-client.jar in your
Merlin's distribution. That is, the non-fork Phoenix client jar?
Specifically a solution, that after some rework, will not require your
forked Phoenix.
>> 2) Change cornerstone comps to use Context as is, and access things
>> via 'Object get(Object)'
>
> A more concrete solution would be for the establishment of a common
> attribute for the working directory context key.
> In the documentation under the excalibur/container project there is a
> page proposing a set of common context keys and meta info attributes.
> Phoenix currently provides the "apps.home" key - if this were expanded
> to include the same value under the "avalon:home" key then we would
> have a good solution for undating Cornerstone with minimal impact on
> Phoenix.
Yup, it is related to attributes. Thought on that in other emails.
>> http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/context/Context.html
>>
>>
>> 3) Create a new interface in A-F called say DirectoryNamedContext.
>
> I think it would be more appropriate to include such an interface
> under the excalibur/container package. This is where all of the
> common content between Merlin and Fortress resides.
But not for Phoenix. A-F seems to be where our interface art goes.
>> It has the two methods in BlockContext and extends Context.
>> BlockContext extends it. Cornerstone comps drop to
>> DirectoryNamedContext. Merlin is able to trade without reference to
>> Phoenix. Adding an interface in this way, as we all know is a
>> backwards compatible thing.
>>
>> Thoughts? ( Concise please )
>
> (a) To avoid multiple micro-forks of phoenix-client, it would be
> preferable that a generic block context solution be provided under the
> Phoinix CVS. This deals with the issue of managing existing
> non-Avalon CVS block implementations that reference BlockContext.
I do not believe the case for (I infer) GenericBlockContext has been
made, over the simple scenario of including the as-is phoenix-client.jar
with Merlin.
> (b) Usage of a common context key such as "avalon:home" resolves
> immediate concerns at the Cornerstone level and provides a model for
> consitency between Phoenix and Merlin.
This is going to happen anyway?
> (c) Defintion of a common context interface for access to a directory
> would make sense within the context of the excalibur/container
> package. I dont think this sort of thing should go into framework
> before a more comlete container spec/utility-package is in place.
org.apache.excalibur.container.* is not used by Phoenix..... How about
it goes in containerkit? But then that's not used by Phoenix.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Folks,
>
>
> http://jakarta.apache.org/avalon/phoenix/api/org/apache/avalon/phoenix/BlockContext.html
>
>
> It appears that Merlin has a problem with mounting blocks. The
> problem principally is that though a Context interface is handed in,
> blocks are in the habit of casting them to BlockContext. Apart from
> making all Avalon-Framework using containers need different
> specializations of Context, it causes Merlin problems with hosting
> blocks.
>
> This has been discussed over the past year or so, but perhaps now
> there is need for a solution. So lets mull over some ideas, and find
> one that is workable and that everying is happy with.
>
> 1) Merlin includes phoenix-client.jar and provides alternate
> implemetations of the BlockContext interface.
>
> (variations are - make phoenix-client.jar smaller by splitting
> out stuff specific to the Phoenix kernel).
This is what I'm basically doing at the moment - the Phonix client in
the excalibur/assembly/lib is a the regular phix-client.jar plus the
GenericBlockContext implememtation. I don't like the solution but it
works in terms of the work I'm doing with James and Cornerstone components.
>
>
> 2) Change cornerstone comps to use Context as is, and access things
> via 'Object get(Object)'
A more concrete solution would be for the establishment of a common
attribute for the working directory context key.
In the documentation under the excalibur/container project there is a
page proposing a set of common context keys and meta info attributes.
Phoenix currently provides the "apps.home" key - if this were expanded
to include the same value under the "avalon:home" key then we would have
a good solution for undating Cornerstone with minimal impact on Phoenix.
>
>
> http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/context/Context.html
>
>
> 3) Create a new interface in A-F called say DirectoryNamedContext.
I think it would be more appropriate to include such an interface under
the excalibur/container package. This is where all of the common
content between Merlin and Fortress resides.
> It has the two methods in BlockContext and extends Context.
> BlockContext extends it. Cornerstone comps drop to
> DirectoryNamedContext. Merlin is able to trade without reference to
> Phoenix. Adding an interface in this way, as we all know is a
> backwards compatible thing.
>
> Thoughts? ( Concise please )
(a) To avoid multiple micro-forks of phoenix-client, it would be
preferable that a generic block context solution be provided under the
Phoinix CVS. This deals with the issue of managing existing non-Avalon
CVS block implementations that reference BlockContext.
(b) Usage of a common context key such as "avalon:home" resolves
immediate concerns at the Cornerstone level and provides a model for
consitency between Phoenix and Merlin.
(c) Defintion of a common context interface for access to a directory
would make sense within the context of the excalibur/container package.
I dont think this sort of thing should go into framework before a more
comlete container spec/utility-package is in place.
Cheers, Steve.
>
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: BlockContext & Merlin.
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Aug 2002 20:24, Paul Hammant wrote:
> Nobody (you or Peter) has explained to me yet why phoenix-client.jar
> as-is cannot be imported into your CVS, in the same way that it is
> imported into thord-party component writer's CVS depots.
There is no technical reason.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
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>
Container nesting, common attributes and startup layer: Solution?
(was Re: BlockContext & Merlin.)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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: BlockContext & Merlin.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>> 1) Merlin includes phoenix-client.jar and provides alternate
>>> implemetations of the BlockContext interface.
>>>
>>
>> Thats the only real solution at this stage.
>>
>
> If this is the only real solution - would it not make more sense for
> this to be included as part of the Phoenix CVS?
Which bit are you agreeing to? 1) Merlin includes phoenix-client.jar
as-is for Phoenix compatability. Or are you asserting that 1.1)
Alternate implementations of BlockContext need to be in Phoenix CVS?
> Given that there is a possibly of Phoenix changing keys (as per your
> note below), at least all of the sources impacted by such a change
> would be under the scope of the team dealing with the change. This
> would at least eliminate the obligation of other container authors to
> track and maintain micro-forks of phoenix-client.jar.
But it would not eliminate the obligation of other container authors to
track changes, with a view to updating their CVS instance of
phoenix-client.jar. I don't buy the argument that the
GenericBlockContext changes need to be in Phoenix CVS. Other container
authors are going to have to conceptually subscribe to something, unless
their whole container is in Phoenix CVS and build from the same script.
Stephen, using phoenix-client.jar as-is is a good solution.
> The alternative is micro-management of phoenix-client.jar variations
> by other container project interested in maintaining compatibility
> with the Phoenix environment. I'm interested in knowing what Phoneix
> committers this about this. Is this is a good thing given the
> probable/inevitable de-synchronization of multiple phoenix-client.jar
> files?
The de-sync of jars covers multiple things for multiple projects. Why
is phoenix-client.jar a special case?
Nobody (you or Peter) has explained to me yet why phoenix-client.jar
as-is cannot be imported into your CVS, in the same way that it is
imported into thord-party component writer's CVS depots.
>>> ) Change cornerstone comps to use Context as is, and access things via
>>> 'Object get(Object)'
>>>
>>
>> This may work for somethings but the key will change in the future.
>> This wont work for somethings - especially once interceptors are
>> integrated properly.
>>
>
> Presumably the key values that Phoenix publishes in its API will be
> maintained in order to guarantee consistency with existing
> applications. For example, James has recently dropped direct
> references to the Phoenix BlockContext interface in favour of the
> reference to the published Phoenix key value.
I'm not 100% sure why theu did that.... It seems to have lead a
recommendation from the Avalon list, and also be in adnavce of any known
problem with Phoenix....
> Should James committers (and other external projects) be concerned
> about incompatible key changes in the near/medium-term future? I'm
> confident that the Phoenix team will ensure compatibility - which
> suggests that perhaps this solution "would work".
I think we are anal about backards compatibility in Avalon yes?
Remember the discussion over ComponentManager and ServiceManager?
> Given that there is work ongoing concerning a common set of attributes
> and keys, is it likely that the changes in Phoenix will be
> synchronized with other Avalon projects? In particular, could someone
> involved in Phoenix comment on the proposed attribute and context key
> values published under the excalibur/container package?
Phoenix does not use excalibur/conainer, how can it's work be described
as definative for Phoenix? Peter has container kit as a dependant
package for Phoenix. You know that Stephen. "Could anyone involved
with Phoenix....excalibur/container" is an unhelpful comment.
> I'm very interested in moving this forward with the objective of
> getting in place at a small but concrete set of cross-container solutions.
>
>>> 3) Create a new interface in A-F called say DirectoryNamedContext. It
>>> has the two methods in BlockContext and extends Context. BlockContext
>>> extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is
>>> able to trade without reference to Phoenix. Adding an interface in this
>>> way, as we all know is a backwards compatible thing.
>>>
>>
>> Fails to add value.
>>
>
> I would agree that this is a zero value proposition if we look from
> the internal perspective of the Phoenix project in isolation from the
> numerous other container activities related to Avalon. Things become
> more interesting when we take a more holistic view of the world, in
> particular, the existence of other projects dealing with similar
> concerns. Perhaps the added-value is something we can provide to our
> users - user's interested in consistency between different containers,
> consistency in semantics, and comfort in the knowledge that multiple
> projects are working together in the ultimate objective of delivering
> the best value proposition possible. I should point out that I don't
> think a common interface is terribly high on the agenda when compared
> to things like common context key, meta-data attributes, common DTDs
> for meta-info. At least the feeback I'm getting is that the
> user-community wants to see interoperability and consistency.
>
> I do you think that someone writing code against a container neutral
> interface would feel that they are getting value from cross-project
> collaborative initiatives.
Stephen dude, that sentence does not parse..
> 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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: common attributes revisited (Re: BlockContext & Merlin.)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>>>Given that there is work ongoing concerning a common set of attributes
>>>and keys, is it likely that the changes in Phoenix will be synchronized
>>>with other Avalon projects? In particular, could someone involved in
>>>Phoenix comment on the proposed attribute and context key values
>>>published under the excalibur/container package?
>>>
>>>
>>They are different from the ones I am working on. I will publish the
>>attributes/key names that Phoenix will use when they are closer to being
>>complete.
>>
>>
>
>I'd suggest against such a process flow. Since I am sure I will be using
>my components in different containers in the future, I want these key
>names to be the same, especially since I can see no reason not to make
>them the same. I urge you to consolidate efforts now.
>
>Discussion may be tiring, but with issues like this, it is important we
>figure things out sooner rather than later (when it is all in a released
>product and impossible to change).
>
>
+1
Leo:
I've put together documentation concerning all of the keys and type level
attributes that I consider to be cross-container related. The documentation
has been put under the excalibur/container package in the xdocs directory.
The documentation is intended to provide information/proposals about common
container keys, attributes, services, etc. and is not intended to be
specific
to any particular container.
To build the docs just use the "ant xdocs" target then checkout the
generated
html in build/docs.
Cheers, Steve.
>
>cheers,
>
>Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
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>
common attributes revisited (Re: BlockContext & Merlin.)
Posted by Leo Simons <le...@apache.org>.
> > Given that there is work ongoing concerning a common set of attributes
> > and keys, is it likely that the changes in Phoenix will be synchronized
> > with other Avalon projects? In particular, could someone involved in
> > Phoenix comment on the proposed attribute and context key values
> > published under the excalibur/container package?
>
> They are different from the ones I am working on. I will publish the
> attributes/key names that Phoenix will use when they are closer to being
> complete.
I'd suggest against such a process flow. Since I am sure I will be using
my components in different containers in the future, I want these key
names to be the same, especially since I can see no reason not to make
them the same. I urge you to consolidate efforts now.
Discussion may be tiring, but with issues like this, it is important we
figure things out sooner rather than later (when it is all in a released
product and impossible to change).
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Aug 2002 05:29, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Sat, 24 Aug 2002 22:12, Paul Hammant wrote:
> >>1) Merlin includes phoenix-client.jar and provides alternate
> >>implemetations of the BlockContext interface.
> >
> >Thats the only real solution at this stage.
>
> If this is the only real solution - would it not make more sense for
> this to be included as part of the Phoenix CVS?
The same reason I told you the last time, and the time before that, and the
time before that and ...
ie It will not be possible to implement it in the future if all the features
planned for BlockContext get implemented.
> Given that there is work ongoing concerning a common set of attributes
> and keys, is it likely that the changes in Phoenix will be synchronized
> with other Avalon projects? In particular, could someone involved in
> Phoenix comment on the proposed attribute and context key values
> published under the excalibur/container package?
They are different from the ones I am working on. I will publish the
attributes/key names that Phoenix will use when they are closer to being
complete.
> I should point out that I don't
> think a common interface is terribly high on the agenda when compared to
> things like common context key, meta-data attributes, common DTDs for
> meta-info. At least the feeback I'm getting is that the user-community
> wants to see interoperability and consistency.
Heh. Remember that you are the person who choose to fork that work. As a
result there is unlikely to be any commonality unless you decide to track CK
stuff.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sat, 24 Aug 2002 22:12, Paul Hammant wrote:
>
>>1) Merlin includes phoenix-client.jar and provides alternate
>>implemetations of the BlockContext interface.
>>
>
>Thats the only real solution at this stage.
>
If this is the only real solution - would it not make more sense for
this to be included as part of the Phoenix CVS?
Given that there is a possibly of Phoenix changing keys (as per your
note below), at least all of the sources impacted by such a change would
be under the scope of the team dealing with the change. This would at
least eliminate the obligation of other container authors to track and
maintain micro-forks of phoenix-client.jar.
The alternative is micro-management of phoenix-client.jar variations by
other container project interested in maintaining compatibility with the
Phoenix environment. I'm interested in knowing what Phoneix committers
this about this. Is this is a good thing given the probable/inevitable
de-synchronization of multiple phoenix-client.jar files?
>
>>2) Change cornerstone comps to use Context as is, and access things via
>>'Object get(Object)'
>>
>
>This may work for somethings but the key will change in the future. This wont
>work for somethings - especially once interceptors are integrated properly.
>
Presumably the key values that Phoenix publishes in its API will be
maintained in order to guarantee consistency with existing
applications. For example, James has recently dropped direct references
to the Phoenix BlockContext interface in favour of the reference to the
published Phoenix key value. Should James committers (and other
external projects) be concerned about incompatible key changes in the
near/medium-term future? I'm confident that the Phoenix team will
ensure compatibility - which suggests that perhaps this solution "would
work".
Given that there is work ongoing concerning a common set of attributes
and keys, is it likely that the changes in Phoenix will be synchronized
with other Avalon projects? In particular, could someone involved in
Phoenix comment on the proposed attribute and context key values
published under the excalibur/container package? I'm very interested in
moving this forward with the objective of getting in place at a small
but concrete set of cross-container solutions.
>>3) Create a new interface in A-F called say DirectoryNamedContext. It
>>has the two methods in BlockContext and extends Context. BlockContext
>>extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is
>>able to trade without reference to Phoenix. Adding an interface in this
>>way, as we all know is a backwards compatible thing.
>>
>
>Fails to add value.
>
I would agree that this is a zero value proposition if we look from the
internal perspective of the Phoenix project in isolation from the
numerous other container activities related to Avalon. Things become
more interesting when we take a more holistic view of the world, in
particular, the existence of other projects dealing with similar
concerns. Perhaps the added-value is something we can provide to our
users - user's interested in consistency between different containers,
consistency in semantics, and comfort in the knowledge that multiple
projects are working together in the ultimate objective of delivering
the best value proposition possible. I should point out that I don't
think a common interface is terribly high on the agenda when compared to
things like common context key, meta-data attributes, common DTDs for
meta-info. At least the feeback I'm getting is that the user-community
wants to see interoperability and consistency.
I do you think that someone writing code against a container neutral
interface would feel that they are getting value from cross-project
collaborative initiatives. 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?
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: Attribute DD and Model DD
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Sun, 25 Aug 2002 23:31, Nicola Ken Barozzi wrote:
>
>>Article on JMI
>>http://developer.java.sun.com/developer/technicalArticles/J2EE/JMI/
>>
>>XMI spec
>>http://cgi.omg.org/docs/formal/00-11-02.pdf
>>
>>JMI spec
>>http://www.jcp.org/jsr/detail/40.jsp
>>
>>
>>>Anyone familiar with any object metadata frameworks in opensource land?
>>
>>http://mdr.netbeans.org/
>>http://mdr.netbeans.org/architecture.html
>>
>>http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
>>
>>http://nsuml.sourceforge.net/
>>http://argouml.tigris.org/documentation/defaulthtml/cookbook/ch03s05.html
>>http://argouml.tigris.org/
>
>
> Thanks!
:-D
I'm glad I was of some help :-)
--
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: Attribute DD and Model DD
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Aug 2002 23:31, Nicola Ken Barozzi wrote:
> Article on JMI
> http://developer.java.sun.com/developer/technicalArticles/J2EE/JMI/
>
> XMI spec
> http://cgi.omg.org/docs/formal/00-11-02.pdf
>
> JMI spec
> http://www.jcp.org/jsr/detail/40.jsp
>
> > Anyone familiar with any object metadata frameworks in opensource land?
>
> http://mdr.netbeans.org/
> http://mdr.netbeans.org/architecture.html
>
> http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
>
> http://nsuml.sourceforge.net/
> http://argouml.tigris.org/documentation/defaulthtml/cookbook/ch03s05.html
> http://argouml.tigris.org/
Thanks!
--
Cheers,
Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute DD and Model DD
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Sun, 25 Aug 2002 22:18, Paul Hammant wrote:
>
>>>Have a look at Microsofts "attribute-driven" programming style that is
>>>part of dot net. I have not looked at implementation details mainly just
>>>research+white papers about it. Thats where I want a lot of avalon stuff
>>>to go in the future. It is a brilliant concept when used appropriately.
>>
>>That's what everyone is saying. Expect .Net inspired atributes to
>>arrive in Java3.
>
>
> JSR 175 (???) is doing them and it is led by a fairly smart guy so hopefully
> they will be kool. I hope they don't try to over define it though as that
> will screw it up but if they don't it could be sweet. JSR 175 is why I have
> been so insistent on keeping only type information in the
> BlockInfo/ComponentInfo as it will give us a clean migration path to JDK1.5s
> features.
>
>
>>>Can you imagine the ease of this if we ever achieved it?
>>>* Service Orientated Programming + Attribute driven framework
>>>* Model Driven development + Attribute driven framework
>>>
>>>I think the above is largely achievable (even if not in a a completely
>>>generic fashion for MDD).
>>>
>>>If someone was to come up with a decent process/workflow system (I haven't
>>>ever seen anything that is vaguely close to being viable) then it would
>>>make development soooooooooo much easier - essentially just coding in
>>>buisness rules and maybe engines to interpret the model.
>>>
>>>Anyways I believe I be gushing ;)
>>
>>Sigh, will this commercial effort ever be open-sourced?
>
>
> No idea. Parts of it definetly could be. The end client is telstra (a local
> telco) who does not give a doodie about the code IP and my indirect employer
> already intends to keep 90% of the infrastructure code as part of the deal.
> So it may be possible. Though it is rather ugly code ;)
>
> If there was an opensource implementation of the MetaData JSR then I would
> definetly do it properly. I have already rewritten the basic plumbing about 5
> times because it is easier to do that than do it properly. Going via
> something like the MetaData API would make it worth the effort.
Article on JMI
http://developer.java.sun.com/developer/technicalArticles/J2EE/JMI/
XMI spec
http://cgi.omg.org/docs/formal/00-11-02.pdf
JMI spec
http://www.jcp.org/jsr/detail/40.jsp
> Anyone familiar with any object metadata frameworks in opensource land?
>
http://mdr.netbeans.org/
http://mdr.netbeans.org/architecture.html
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
http://nsuml.sourceforge.net/
http://argouml.tigris.org/documentation/defaulthtml/cookbook/ch03s05.html
http://argouml.tigris.org/
--
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>
Attribute DD and Model DD
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Aug 2002 22:18, Paul Hammant wrote:
> >Have a look at Microsofts "attribute-driven" programming style that is
> > part of dot net. I have not looked at implementation details mainly just
> >research+white papers about it. Thats where I want a lot of avalon stuff
> > to go in the future. It is a brilliant concept when used appropriately.
>
> That's what everyone is saying. Expect .Net inspired atributes to
> arrive in Java3.
JSR 175 (???) is doing them and it is led by a fairly smart guy so hopefully
they will be kool. I hope they don't try to over define it though as that
will screw it up but if they don't it could be sweet. JSR 175 is why I have
been so insistent on keeping only type information in the
BlockInfo/ComponentInfo as it will give us a clean migration path to JDK1.5s
features.
> >Can you imagine the ease of this if we ever achieved it?
> >* Service Orientated Programming + Attribute driven framework
> >* Model Driven development + Attribute driven framework
> >
> >I think the above is largely achievable (even if not in a a completely
> > generic fashion for MDD).
> >
> >If someone was to come up with a decent process/workflow system (I haven't
> >ever seen anything that is vaguely close to being viable) then it would
> > make development soooooooooo much easier - essentially just coding in
> > buisness rules and maybe engines to interpret the model.
> >
> >Anyways I believe I be gushing ;)
>
> Sigh, will this commercial effort ever be open-sourced?
No idea. Parts of it definetly could be. The end client is telstra (a local
telco) who does not give a doodie about the code IP and my indirect employer
already intends to keep 90% of the infrastructure code as part of the deal.
So it may be possible. Though it is rather ugly code ;)
If there was an opensource implementation of the MetaData JSR then I would
definetly do it properly. I have already rewritten the basic plumbing about 5
times because it is easier to do that than do it properly. Going via
something like the MetaData API would make it worth the effort.
Anyone familiar with any object metadata frameworks in opensource land?
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Royal wrote:
> On Monday 26 August 2002 07:37 am, Paul Hammant wrote:
>
>>(*) The Avalon team recommends that Phoenix compatile container include
>>phoenix-client.jar in their distribution and make it visible to hosted
>>components at runtime. The Avalon team recommends that Phoenix
>>compatible containers hide their implementations of BlockContext in the
>>kernel's classloader and further hide the impl via use of a
>>Refelection's dynamic proxy.
-1
Containers should not be dependent from one another, because it creates
nasty dependencies that can become very difficult to track down, and
overall creates major confusion for the users.
They should only depend on Avalon Framework, which is the contract.
All other dependencies shall be internal, and not exposed.
Separation of Concerns: Any container shall only define contracts that
pertain to his capabilities.
Any use by a containers of components of another container must be
hidden by encapsulation of the latter, or by the use of defined
avalon-framework contracts.
The bottom line: if I want to use Phoenix-aware Components I put Phoenix
in my Container hierarchy.
If the Components do not necessarily depend on Phoenix, they must be
written to be Container indipendent.
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Royal <pr...@apache.org>.
On Monday 26 August 2002 07:37 am, Paul Hammant wrote:
> (*) The Avalon team recommends that Phoenix compatile container include
> phoenix-client.jar in their distribution and make it visible to hosted
> components at runtime. The Avalon team recommends that Phoenix
> compatible containers hide their implementations of BlockContext in the
> kernel's classloader and further hide the impl via use of a
> Refelection's dynamic proxy.
+1
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Aug 2002 21:37, Paul Hammant wrote:
> (*) The Avalon team recommends that Phoenix compatile container include
> phoenix-client.jar in their distribution and make it visible to hosted
> components at runtime. The Avalon team recommends that Phoenix
> compatible containers hide their implementations of BlockContext in the
> kernel's classloader and further hide the impl via use of a
> Refelection's dynamic proxy.
+1
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 27 Aug 2002 08:46, Stephen McConnell wrote:
>
>>Peter Donald wrote:
>>
>>>>Lets get a collaborative solution on meta-info that we are all
>>>>comfortable with first?
>>>
>>>If you are comfortable with what you have done then go with it. I am
>>>comfortable with what I have done so I am going with it.
>>
>>So in other words - forget about collaboration.
>
> No - as long as you want to cooperate then you are welcome to join in the CK
> stuff.
Same for you Peter, don't try to piss people off.
> If you want I can separate out the info stuff to a proposal directory.
Ok.
> However I don't think it is wise to bind to specific implementation strategies
> and nor do I think it is wise to support N different component models when 1
> is enough.
I agree.
Let's get the *one* componentmodel we all use and keep experimental
stuff as extensions container-specific for now.
But then, this is what Stephen wants too.
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Tue, 27 Aug 2002 08:46, Stephen McConnell wrote:
>>
>>
>>> Peter Donald wrote:
>>>
>>>
>>>>> Lets get a collaborative solution on meta-info that we are all
>>>>> comfortable with first?
>>>>>
>>>>
>>>> If you are comfortable with what you have done then go with it. I am
>>>> comfortable with what I have done so I am going with it.
>>>>
>>>
>>> So in other words - forget about collaboration.
>>>
>>
>>
>> No - as long as you want to cooperate then you are welcome to join in
>> the CK stuff. If you want I can separate out the info stuff to a
>> proposal directory
>>
>> However I don't think it is wise to bind to specific implementation
>> strategies and nor do I think it is wise to support N different
>> component models when 1 is enough.
>>
>
> Are you willing to accept a majority decision on this?
>
> If we go done this path lets do it properly. We setup a seperate
> project specifically to converge
> containerkit meta-info with excalibur/meta meta-info - the first thing
> we post is the pitch documents - you prepare "why containerkit
> meta-info is the best thing since sliced bread" and you also write up
> "why excalibur/meta is the wrong thing" (short-term, long-term,
> whatever). We go through a debate - one counter email from you, one
> counter email from me.
> We put it to a vote. You and I are excluded from the vote - we leave
> it up to the community.
>
> * if there is a majority off non-abstaining votes
Correction - a majority of abstaining votes (meaning +0 or -0)
>
>
> - we undertake to support each other's work - i.e. mutual DTD
> recognition
> and management
>
> - we mutually undertake to address concensus raised by the other
> people here
>
> - we mutually agree that vetos cannot be applied by you or I during
> the
> decision process
>
> - we update, we recall a vote
>
> * if there is a majority of +1 (over abstain) for a particular solution
>
> - if it containerkit you undertake to move the meta-info content into
> a seperate module from containerkit and I will undertake to
> synchronize
> Merlin to that module and dispose of excalibur/meta
>
> - if it is excalibur/meta you undertake to move the containerkit
> solution
> above it and dispose of cotainerkit's meta-info
>
> * if there is a discussion process arrising from the process, you and
> I both
> agree that they are right and our options may influence the process
> but we
> update the common project even if you and I don't like it - we go
> out of
> out way to compromise - the winner is the one who sucks-up the best
> to the
> future users
>
> Are your ready?
>
> 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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Tue, 27 Aug 2002 08:46, Stephen McConnell wrote:
>>
>>
>>> Peter Donald wrote:
>>>
>>>
>>>>> Lets get a collaborative solution on meta-info that we are all
>>>>> comfortable with first?
>>>>>
>>>>
>>>> If you are comfortable with what you have done then go with it. I am
>>>> comfortable with what I have done so I am going with it.
>>>>
>>>
>>> So in other words - forget about collaboration.
>>>
>>
>>
>> No - as long as you want to cooperate then you are welcome to join in
>> the CK stuff. If you want I can separate out the info stuff to a
>> proposal directory
>>
>> However I don't think it is wise to bind to specific implementation
>> strategies and nor do I think it is wise to support N different
>> component models when 1 is enough.
>>
>
> Are you willing to accept a majority decision on this?
>
> If we go done this path lets do it properly. We setup a seperate
> project specifically to converge
> containerkit meta-info with excalibur/meta meta-info - the first thing
> we post is the pitch documents - you prepare "why containerkit meta-info
> is the best thing since sliced bread" and you also write up "why
> excalibur/meta is the wrong thing" (short-term, long-term, whatever). We
> go through a debate - one counter email from you, one counter email from
> me.
And the others? ;-)
Let's not bing discussion to a head2head here with one email only.
Let's say one initial email.
> We put it to a vote. You and I are excluded from the vote - we leave it
> up to the community.
>
> * if there is a majority off non-abstaining votes
>
> - we undertake to support each other's work - i.e. mutual DTD
> recognition
> and management
>
> - we mutually undertake to address concensus raised by the other
> people here
>
> - we mutually agree that vetos cannot be applied by you or I during the
> decision process
>
> - we update, we recall a vote
>
> * if there is a majority of +1 (over abstain) for a particular solution
>
> - if it containerkit you undertake to move the meta-info content into
> a seperate module from containerkit and I will undertake to
> synchronize
> Merlin to that module and dispose of excalibur/meta
>
> - if it is excalibur/meta you undertake to move the containerkit
> solution above it and dispose of cotainerkit's meta-info
>
> * if there is a discussion process arrising from the process, you and I
> both agree that they are right and our options may influence the process
> but we update the common project even if you and I don't like it - we go out of
> out way to compromise - the winner is the one who sucks-up the best to
> the future users
Ok, a bit bizantine, but I get the message: write a mail with pros and
cons, let us ask questions, see how the efforts are able to evolve and
make them converge upon community suggestions and finally vote for the
result.
Please, Peter, do it.
I also add that it's *compulsory* that any extra feature that has not
been yet published and is experimental, like container extensions, be
addresses as a Container-specific issue.
It must also be addressed how to make Components with specific stuff
interoperate with other containers via a common descriptor definition of
the requirements (*not* the solutions) and Container nesting.
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 27 Aug 2002 08:46, Stephen McConnell wrote:
>
>
>>Peter Donald wrote:
>>
>>
>>>>Lets get a collaborative solution on meta-info that we are all
>>>>comfortable with first?
>>>>
>>>>
>>>If you are comfortable with what you have done then go with it. I am
>>>comfortable with what I have done so I am going with it.
>>>
>>>
>>So in other words - forget about collaboration.
>>
>>
>
>No - as long as you want to cooperate then you are welcome to join in the CK
>stuff. If you want I can separate out the info stuff to a proposal directory
>
>However I don't think it is wise to bind to specific implementation strategies
>and nor do I think it is wise to support N different component models when 1
>is enough.
>
Are you willing to accept a majority decision on this?
If we go done this path lets do it properly. We setup a seperate
project specifically to converge
containerkit meta-info with excalibur/meta meta-info - the first thing
we post is the pitch documents - you prepare "why containerkit meta-info
is the best thing since sliced bread" and you also write up "why
excalibur/meta is the wrong thing" (short-term, long-term, whatever).
We go through a debate - one counter email from you, one counter email
from me.
We put it to a vote.
You and I are excluded from the vote - we leave it up to the community.
* if there is a majority off non-abstaining votes
- we undertake to support each other's work - i.e. mutual DTD
recognition
and management
- we mutually undertake to address concensus raised by the other
people here
- we mutually agree that vetos cannot be applied by you or I during the
decision process
- we update, we recall a vote
* if there is a majority of +1 (over abstain) for a particular solution
- if it containerkit you undertake to move the meta-info content into
a seperate module from containerkit and I will undertake to
synchronize
Merlin to that module and dispose of excalibur/meta
- if it is excalibur/meta you undertake to move the containerkit
solution
above it and dispose of cotainerkit's meta-info
* if there is a discussion process arrising from the process, you and I
both
agree that they are right and our options may influence the process
but we
update the common project even if you and I don't like it - we go out of
out way to compromise - the winner is the one who sucks-up the best
to the
future users
Are your ready?
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
On Tue, 27 Aug 2002 08:46, Stephen McConnell wrote:
> Peter Donald wrote:
> >>Lets get a collaborative solution on meta-info that we are all
> >>comfortable with first?
> >
> >If you are comfortable with what you have done then go with it. I am
> >comfortable with what I have done so I am going with it.
>
> So in other words - forget about collaboration.
No - as long as you want to cooperate then you are welcome to join in the CK
stuff. If you want I can separate out the info stuff to a proposal directory.
However I don't think it is wise to bind to specific implementation strategies
and nor do I think it is wise to support N different component models when 1
is enough.
> >Time will tell who was right and who was wrong.
>
> Don't worry Pete - I am confident - totally and blindly confident - that
> you will be right and I will be wrong. It actually makes me feel all
> warn and fluffy knowing that we have someone here with such vision, such
> engagement, such intelligence, such integrity - the oracle - god's right
> hand little boy. It humbles me to know that in the fullness of time you
> will be there to explain to me the errors of my ways, to point to what
> it could have been if only I listened, if I only I had accepted the
> perls of wisdom - blindly, without question, without justification,
> without rationale - if only I had ignored the others - forgotten about
> those almost hidden voices - you know, the users - those little insecure
> voices that say they want different things - things to solve what they
> believe are real problems. You will show me the light - I'll recognize
> the error of my ways - and I'll thank you.
and you wonder why people would not want to work with you? hmmmm.
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>>Lets get a collaborative solution on meta-info that we are all
>>comfortable with first?
>>
>
>If you are comfortable with what you have done then go with it. I am
>comfortable with what I have done so I am going with it.
>
So in other words - forget about collaboration.
>Time will tell who was right and who was wrong.
>
Don't worry Pete - I am confident - totally and blindly confident - that
you will be right and I will be wrong. It actually makes me feel all
warn and fluffy knowing that we have someone here with such vision, such
engagement, such intelligence, such integrity - the oracle - god's right
hand little boy. It humbles me to know that in the fullness of time you
will be there to explain to me the errors of my ways, to point to what
it could have been if only I listened, if I only I had accepted the
perls of wisdom - blindly, without question, without justification,
without rationale - if only I had ignored the others - forgotten about
those almost hidden voices - you know, the users - those little insecure
voices that say they want different things - things to solve what they
believe are real problems. You will show me the light - I'll recognize
the error of my ways - and I'll thank you.
But for now your just going to have to put up with me.
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 27 Aug 2002 04:03, Stephen McConnell wrote:
>
>>>>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/
>>
>>Just for everyone's reference - the piece of containerkit that Pete is
>>refering to is the equivalent of the excalibur/meta package. The
>>containerkit package - which is much more of a container architecture,
>>could very easily build above the excalibur/meta package. If fact there
>>are no technical obsticales whatsoever.
>
>
> Hmmm. You mean when I indicate that it is premature to adopt a convention that
> specifies container architecture for extensions and that is not a technical
> obstacle? Hmmmm.
I think that adopting a convention that specifies container architecture
for extensions *is* a technical obstacle.
But the extension stuff started *after* this all started, and should be
kept specific to Merlin, as it has been quite agreed.
What we *must* adopt, and you said it too, is a convention for declaring
that there is something else that the Container must supply, then it's
up to the specific container understand how; with Merlin it would be
extensions.
>>>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
>>
>>This is something I've been meaning to ask concerning sar deployment and
>>the assumptions being made about manifest extension jar depedecies in
>>the SAR-INF/lib?
>
> what about it.
>
>>>* standard mechanism for defining components (ie
>>>META-INF/avalon/components.xml)
>>
>>As in meta-data directives?
>
> as in a way of indicating the components stored in a jar.
>
>>Lets get a collaborative solution on meta-info that we are all
>>comfortable with first?
>
> If you are comfortable with what you have done then go with it. I am
> comfortable with what I have done so I am going with it. Time will tell who
> was right and who was wrong.
I don't care who is right and who is wrong.
Ego ego ego egoooooooooo
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
On Tue, 27 Aug 2002 04:03, Stephen McConnell wrote:
> >>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/
>
> Just for everyone's reference - the piece of containerkit that Pete is
> refering to is the equivalent of the excalibur/meta package. The
> containerkit package - which is much more of a container architecture,
> could very easily build above the excalibur/meta package. If fact there
> are no technical obsticales whatsoever.
Hmmm. You mean when I indicate that it is premature to adopt a convention that
specifies container architecture for extensions and that is not a technical
obstacle? Hmmmm.
> >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
>
> This is something I've been meaning to ask concerning sar deployment and
> the assumptions being made about manifest extension jar depedecies in
> the SAR-INF/lib?
what about it.
> >* standard mechanism for defining components (ie
> >META-INF/avalon/components.xml)
>
> As in meta-data directives?
as in a way of indicating the components stored in a jar.
> Lets get a collaborative solution on meta-info that we are all
> comfortable with first?
If you are comfortable with what you have done then go with it. I am
comfortable with what I have done so I am going with it. Time will tell who
was right and who was wrong.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
On Tue, 27 Aug 2002 08:00, Paul Hammant wrote:
> Peter,
>
> >CK will soon adopt notion of Partitions (in progress), dynamic assembly
> >(mostly done) and separate containers per partition (not really started
> > yet). At that stage there will only be minor differences between the
> > containers feature sets and Phoenix will thus inherit these features.
>
> Please try to keep us included in designs. Partitions++, dynamic
> assembly we all buy.
They are not new designs, they are pretty much the same things that I was
saying when I started CK.
Partitions/scopes/hierarchies are needed in myrmidon and hence why I am
working towards them.
Dynamic assembly is needed to maintain compatability with existing config
files (like kernel.xml in Phoenix or services.xml in Myrmidon).
> Separate containers per partition is something I'd
> like to understand before it arrives....
Essentially it is similar to how most "enterprise" containers operate. The
granularity will be configurable but the idea is same. In Fortress and
friends there is the notion of lifestyle "handlers" which is also similar.
For example - lets say I deploy 3 components (A, B and C) into a partition.
Each component may be "handled/owned" by different container.
In Phoenix A, may be a BlockListener and would be handled by the "Listener"
container while B and C would be blocks and handled by the "Block" container.
In Fortress there is the notion of thread safe, poolable, etc components. Each
component lifestyle could have a separate container.
In many EJB servers there is notion of CMPEntityContainer or
StatelessSessionContainer (or whatever). Each different class of component is
allocated to a different container. In some EJB containers there will be
separate containers for each bean.
Anyways that is the general idea. Each Partition (be it application in Phoenix
terms, ejb-jar in EJB terms or config file in fortress times) shares a
component namespace but the components contained within the namespace may be
handled differently.
I have tried to do this several times before in the past. However this ended
up being less than successful because of code duplication across containers.
Wiht CK gradually cleaning it up, it may be a little more successful this
time (or may not).
--
Cheers,
Peter Donald
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 26 Aug 2002 23:14, Nicola Ken Barozzi wrote:
>
>>IMHO the next evolution stage is near, hence my "proactive" thinking ;-)
>
> 6 months maybe.
Definately less if you and Stephen stop fighting.
>>Ah, ok.
>>I still don't understand well why you and Stephan say the same things
>>but have two different Containers...
>
> Stephen forked CK, so it is not surprising that they are similar.
Get real, Peter.
You kept -1ing his work in a not very nice way, we have all seen it, and
you know it.
He never wanted to fork out of CK, I can tell from all the private
letters we had, but felt he got basically pushed into it by you.
Others had this feeling too.
Now, if you would just stop blocking the work of others without a
sensible alternative, and stop saying that "it will be done when it will
be done when I will do it right"...
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Peter,
>
>> CK will soon adopt notion of Partitions (in progress), dynamic
>> assembly (mostly done) and separate containers per partition (not
>> really started yet). At that stage there will only be minor
>> differences between the containers feature sets and Phoenix will thus
>> inherit these features.
>>
> Please try to keep us included in designs. Partitions++, dynamic
> assembly we all buy. Separate containers per partition is something I'd
> like to understand before it arrives....
Do you start to understand why someone felt pissed off?
This you were doing Partitions++, he -1ed your work, and said that he
will come around to eventually doing it right... just think about it.
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>CK will soon adopt notion of Partitions (in progress), dynamic assembly
>(mostly done) and separate containers per partition (not really started yet).
>At that stage there will only be minor differences between the containers
>feature sets and Phoenix will thus inherit these features.
>
Please try to keep us included in designs. Partitions++, dynamic
assembly we all buy. Separate containers per partition is something I'd
like to understand before it arrives....
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
On Mon, 26 Aug 2002 23:14, Nicola Ken Barozzi wrote:
> IMHO the next evolution stage is near, hence my "proactive" thinking ;-)
6 months maybe.
> Ah, ok.
> I still don't understand well why you and Stephan say the same things
> but have two different Containers...
Stephen forked CK, so it is not surprising that they are similar. If a new
idea comes out of Merlin that is useful then it will be cloned in CK but at
this stage the ideas are things already planned a long time (mainly derived
from CSF or early CK discussions).
However while the fork exists there is not alot of motivation to try to reuse
anything so the chips lie where they lay and progress continues.
CK will soon adopt notion of Partitions (in progress), dynamic assembly
(mostly done) and separate containers per partition (not really started yet).
At that stage there will only be minor differences between the containers
feature sets and Phoenix will thus inherit these features.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
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.
>
>
>
>>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.
>
>Stephen has been suggesting that Phoenix should be maintaining a compatability
>layer for Merlin because Phoenix is legacy, badly written etc.
>
Pete - please can we try and stick with the facts!
Just because we disagree does not mean you need to make stuff up.
The term "legacy" does not mean badly written.
The term "legacy" means something you need to deal with that you inherit
from somewhere else. Cornerstone is legacy for any new container due to
the depedencies it contains towards the Phoenix container. I have
pointed out that much of cornestone can be made Phienix indepedent and
that cornerstone content can be enhanced to take advantage of recent
work in meta-info beyond block context.
>
>>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/
>
>
Just for everyone's reference - the piece of containerkit that Pete is
refering to is the equivalent of the excalibur/meta package. The
containerkit package - which is much more of a container architecture,
could very easily build above the excalibur/meta package. If fact there
are no technical obsticales whatsoever.
>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.
>
The equivalent excalibur/meta package also includes the ability for a
component to declare any extension ability or extension depedencies. It
does not require a container to provide support this functionality and
is completely seperate from extension implementation. In additon, the
excalibur/meta package incorporates ideas and suggestions introduced on
this list concerning teminology, firendliness of the API, and backward
compatibility with the blockinfo specifciation in Phoneix.
>
>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.
>
>
On this I disagee.
There are some attributes that can be resolved relatively easily and can
enable the elimination of issues currently facing us.
>
>
>>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.
>
Lets assume that Block dissapears in the stage of evolution - and that
there is just the defintion of a component type along the lines of
containerkit ComponentInfo or the excalibur/meta Type class. Lets
assume that this something worth discussing and reaching agreement on.
Refusal to even consider what others have being doing is really
difficult to work with.
>
>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
>
This is something I've been meaning to ask concerning sar deployment and
the assumptions being made about manifest extension jar depedecies in
the SAR-INF/lib?
>* standard mechanism for defining components (ie
>META-INF/avalon/components.xml)
>
As in meta-data directives?
Lets get a collaborative solution on meta-info that we are all
comfortable with first?
Cheers, Steve.
>* 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.
>
>
>
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> 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?
Containerkit is too much and not enough.
The containerkit package is a overall container architecture that goes
from the lowest levels such as xinfo DTDs, through meta-info (the
defintion of an object model describing a type of component), up through
meta-data (information describing component deployment) and the way in
which this information is managed by a kernel.
While working on containerkit I came experienced:
* functional limitations at the meta-info and meta-data levels
* architecture too closely following Phoenix static assembly model
* architecture not sufficient abstract to support the Merlin dynamic
approach
* unnecesasary implemetation complexities when attemting to use the model
* extreme difficulties in collaboration on the activity (too many -1s)
* major loss of time attempting to communicate requirements
This resulted in the fork of a small part of containerkit dealing with
the xinfo and meta-info model (no container in the excalibur/meta
package). Since the fork, excalibur/meta has grown substantiallly in
terms of documentation, has evolved to refelect suggestions and
concensus on terminology discussed on this list, and has incorporated
the hooks necessary to allow Fortress and Merlin specific management of
extensions.
>
>
>>> 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.
It is important to note that the excalibur/meta meta-info model does not
oblige a container to implement lifecycle extensions. It simply
provides the hooks against which contains can provide solutions. Work on
excalibur/meta is much more a case of the minimal meta model package -
the meta-model that does not tell you how to build a container but
provides the foundations. Incorporation of excalibur/meta into
containerkit is totally possible.
Cheers, Steve.
>
>
> 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
>
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>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.
>>
>>
>
>Regarding this subject, my thinking on the subject is this:
>
>1) Containers need to declare if they support extentions or not.
> If they do not, then any components requiring extensions are
> not compatible with your container and the container must
> refuse to load and use the components.
>
+1
>
>2) Containers that DO declare that they support extensions must
> support the common meta-model, and common interfaces. That supports
> write-once, use many on the containers that do support extensions.
>
+1
>
>3) Extensions must be verifyable--i.e. the handler must exist,
> and the contracts must be obeyed. If not, then the container
> throws an error message and the component cannot be used.
>
+1
>
>Thoughts?
>
>
We agree.
Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Paul Hammant wrote:
>
>> Berin,
>>
>> Agree, but can we pend this discussion until we finalise the
>> GenericBlockConext one...
>
>
> No.
>
> GenericBlockContext is part of the attributes issue, because it's part
> of the problem in defining what a Container supports and what a
> Component needs.
>
> Once you solve that, the Context problem will go away magically...
+1
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Berin,
>
> Agree, but can we pend this discussion until we finalise the
> GenericBlockConext one...
No.
GenericBlockContext is part of the attributes issue, because it's part
of the problem in defining what a Container supports and what a
Component needs.
Once you solve that, the Context problem will go away magically...
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
Agree, but can we pend this discussion until we finalise the
GenericBlockConext one...
- Paul
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>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.
>>
>>
>
>Regarding this subject, my thinking on the subject is this:
>
>1) Containers need to declare if they support extentions or not.
> If they do not, then any components requiring extensions are
> not compatible with your container and the container must
> refuse to load and use the components.
>
>2) Containers that DO declare that they support extensions must
> support the common meta-model, and common interfaces. That supports
> write-once, use many on the containers that do support extensions.
>
>3) Extensions must be verifyable--i.e. the handler must exist,
> and the contracts must be obeyed. If not, then the container
> throws an error message and the component cannot be used.
>
>Thoughts?
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> 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.
Regarding this subject, my thinking on the subject is this:
1) Containers need to declare if they support extentions or not.
If they do not, then any components requiring extensions are
not compatible with your container and the container must
refuse to load and use the components.
2) Containers that DO declare that they support extensions must
support the common meta-model, and common interfaces. That supports
write-once, use many on the containers that do support extensions.
3) Extensions must be verifyable--i.e. the handler must exist,
and the contracts must be obeyed. If not, then the container
throws an error message and the component cannot be used.
Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Peter Donald <pe...@apache.org>.
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.
> 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.
Stephen has been suggesting that Phoenix should be maintaining a compatability
layer for Merlin because Phoenix is legacy, badly written etc.
> 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.
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.
> 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.
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.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Leo Simons <le...@apache.org>.
> *** Vote ***
> As such, can we vote on the recommendation :
>
> (*) The Avalon team recommends that Phoenix compatile container include
> phoenix-client.jar in their distribution and make it visible to hosted
> components at runtime. The Avalon team recommends that Phoenix
> compatible containers hide their implementations of BlockContext in the
> kernel's classloader and further hide the impl via use of a
> Refelection's dynamic proxy.
considering that
- phoenix is in beta
- its API should remain stable
- I want a release sooner than later
- it should not be tremendously difficult to support phoenix-client at
some level in a new container, though it might be suboptimal
I am +1
I'd like to add explicitly though that the recommended way to write
components is not to depend on phoenix-client or any of the additional
constraints/features phoenix offers. However, for components
specifically targetted at phoenix, the proposed path is the best way to
ensure the above goals (ie get a phoenix release).
I agree with Stephen that he is right wrt to architectural discussion
(there should be a GenericBlockContext rather than a
MerlinBlockContextProxy), optimal implementation, etc. Thing is, avalon
is not as perfect as we'd like it to be and this is a sort-of workable
workaround.
Finally, I like the phrase "recommends". We do not want to require this
strategy for all containers in avalon CVS, as there are some definite
disadvantages to it.
that's the best I can make of it.
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
> Paul Hammant wrote:
>
>> Stephen,
>>
>>>>>>>>>> 1) Merlin includes phoenix-client.jar and provides alternate
>>>>>>>>>> implemetations of the BlockContext interface.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thats the only real solution at this stage.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> There could be some reason why that is not possible.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It will become a lot more difficult in the future when
>>>>>>> classLoader and
>>>>>>> interceptor stuff get integrated but it should be possible to
>>>>>>> no-op those
>>>>>>> features - not sure.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well let's tackle future features in the future. For now though
>>>>>> I think
>>>>>> that useing a Phoenix jar to be Phoenix compatible is perfectly
>>>>>> possible.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I am not sure what you are saying. If you want to implement
>>>>> BlockContext then that is fine but the implementation is
>>>>> inherently container specific. The implementation should not even
>>>>> be in the same classloader as the interface.
>>>>
>>>>
>>>>
>>>>
>>>
>>> The GenericBlockContext provides a solution for any Avalon container
>>> to workaround the Phoenix BlockContext dependency issue. It deals
>>> with the very situation you mention below - the inclusion of
>>> container specific APIs - in this case a Phoenix specific APIs. What
>>> GenericBlockContext does is to provide a mechanism for any container
>>> to be able to deal with the legacy of Phoenix dependent components
>>> that include references to the BlockContext interface. The
>>> implementation solves the problem by allowing a container to handle
>>> the association of keys and values using java.util.Map and the
>>> Context class. Boyond this it has to implement the BlockContext
>>> interface in order to solve the issue of Phoenix API exposure
>>> towards components. Relative to a container, the GenericBlockContext
>>> depedencies are on Map, Context, String and a client supplied
>>> classpath. Relative to the component the dependency is on Phoneix
>>> and the A-F. GenericBlockContext provides the bridge between the two.
>>
>>
>>
>>> Everything about this is solving a Phoneix issue. But, yes - the
>>> solution can be included inside Merlin. Yes we can create
>>> artificial depedencies between the Merlin Project and the Phoenix
>>> Project. Yes we can oblige Merlin installations to include APIs to
>>> another container for those occasions where the client is dealing
>>> with Phoenix legacy and already have phoenix-client.jar in place.
>>> Yes, we could write this up in the FAQ and explain why its a good
>>> thing - but I may need some help on that!
>>
>>
>>
>> Refering to "..artificial dependencies between the Merlin Project and
>> the Pheonix Project" and "..Phoenix legacy..":- Phoenix compatability
>> is what we are talking about here unless I am wrong. It could be we
>> are talking about Phoenix obsolesence (I am not).
>
>
> I am *definately* not either.
>
> Phoenix has his very important space, Merlin/Fortress will have his.
> The more they can work together and in *synergy* the better.
>
>> We have an agreement a way forward for on the BlockContext issue. It
>> is simply to include the BlockContext class (via phoenix-client.jar)
>> in second and subsequent Phoenix compatible containers. Given
>> K/HC/CAPI conversation of the past, and the need for separation of
>> CAPI and K, GenericBlockContext in Phoenix CVS is the wrong solution,
>> I think we all agree that. Given also that the home for
>> GenericBlockContext is not certain (A-F is mooted above, but Phoenix
>> is where it was added). Given also that the content of
>> GenericBlockContext was nothing special - nothing that could not be
>> added to another kernel's CVS tree.
>>
>> My feeling is that this single issue is nothing to do with the
>> attributes thread. That attributes need to be handled correctly
>> designed properly and due consideration given to backards
>> compatability is paramount. Can multiple containers handle attribute
>> changes (well additions reeally) as they are rolled out? Yes, in my
>> opinion. Should attribute strings be added to BlockContext, yes in
>> my opinion.
>>
>> *** Vote ***
>> As such, can we vote on the recommendation :
>>
>> (*) The Avalon team recommends that Phoenix compatile container
>> include phoenix-client.jar in their distribution and make it visible
>> to hosted components at runtime. The Avalon team recommends that
>> Phoenix compatible containers hide their implementations of
>> BlockContext in the kernel's classloader and further hide the impl
>> via use of a Refelection's dynamic proxy.
>
>
> You are saying that a container that wants to use Phoenix-compatible
> Components use BlockContext?
>
> Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must
> use other Phoenix stuff too?
>
> Now, since Cornerstone is about Phoenix blocks IIUC, does this mean
> that the Phoenix blocks are the standard Avalon Components?
>
> If yes, they should be in framework IMNSHO.
> If no, it should be clearly stated that they are Phoenix-only compatible.
>
> And compatibility should not be attained by wrapping Phoenix stuff
> artificially, but by hierarchically containing Phoenix, which is a
> much cleaner solution.
>
> I don't like your proposal.
>
>>>>> Look at the Servlet/EJB/other APIs. They all follow this pattern
>>>>> and I believe some (servlet API 2.1+) actually mandates that no
>>>>> container specific classes can be in same classloader.
>>>>
>>>>
>>>
>>> Such a policy concerning Avalon containers is also appropriate. In
>>> general we should not be exposing container specific APIs to
>>> components. It locks the component to a particular container and
>>> introduces the problems we are currently dealing with.
>>
>>
>> For Phoenix, given its separation of interface and impl, it is only
>> the word phoenix that is objectionable in the phoenix-client.jar and
>> its attendant package names. If we had our time over we could have
>> moved these classes to another tree/package. Like with othr packages
>> in Avalon, we are keeping there where they are for compatability
>> reasons. This line of discussion deviates from (*) above and its
>> central discussion point alternatives for GenericBlockContext (being
>> added to Phoenix CVS).
>
>
> So you are saying that the Phoenix BlockContext has to be regarded as
> the standard Container Context?
>
> This I understand, and I would like to see it become part of the
> containerkit somehow or of the framework if this is the case.
>
> Don't ask me why, it's obvious.
>
>>>>> And we don't want to limit our evolution in future for so little a
>>>>> gain as having a generic implementation. It is rare that the
>>>>> implementations are more than 20-30 lines of code, so I am not
>>>>> sure what the great technical difficulty is.
>>>>>
>>>> Err I agree with you Peter. The interface remains in
>>>> phoenix-client.jar and the impl is left to the container in
>>>> question. I think Stephen is coming round to the possibility of
>>>> that fact.
>>>
>>>
>>>
>>> I'm comming around to the conclusion that :
>>>
>>> 1. the first step is to resolve the context key issue
>>>
>>> - context keys are part of the Avalon component contract
>>> - contract are intended to be maintained
>>> - solving this issue has to be addressed as a higher
>>> priority than convinience interfaces, Phoenix fixes,
>>> or other actions such as defining additional
>>> interfaces
>>
>>
>>
>> I completely disagree. We have got so far on the GenericBlockContext
>> (the need for it in Phoenix CVS) issue. Please don't switch
>> conversational threads when we are on the cusp of an agreement.
>> Please let me tackle these issues one by one. I'll move on to
>> attributes, meta info and other issues in time. It is important for a
>> sense of progress during mediation to resolve an issue. Please try
>> to meet me on this simple goal Stephen. Just because this is against
>> you original posting of GenericBlockContext does not mean all things
>> in this process are going to fall against you. Besides, you see the
>> logic of the BlockContext argument don't you :-))
>
>
> I completely disagree.
>
> *If* I understand what you are saying that is...
>
> To be more clear, *what* are we discussing about?
>
> A temporary solution for interoperability between Phoenix and
> Merlin/Fortress or standard way of defining the Context?
>
> If it's the first case, I agree; this is the easiest solution ATM and
> the best given that Phoenix is mature while Merlin is still growing.
>
> If it's the second case, I really fail to understand how you think
> that all Containers must adopt Phoenix inventions.
>
> I thought they had to adopt the framework.
>
> IMHO this has come out from the fact that Phoenix has been defining
> (in a concerted effort) and bringing forward the concept of Blocks and
> SARs.
>
> These are becoming important concepts for Component reuse, and Peter
> is correctly working with ContainerKit for better reusability.
>
> Can we make this "spec" become more clearly defined and part of
> framework somehow?
This is primary purpose of establishing the excalibur/container package.
To iniate actions focussed on clearly defining the spec for container
to component contracts. Much of this is framework independent - you
think of the framework as the client side of the container/component
architecture. We don't have the container side of the Avalon
architecture. I would like that architecture to arrise as a result of
progressive solutions build through collaboration across different
containers. I don't want to see one view of a container architecture
(such as conterkit) being forced upon us. Instead, I want to see
inovation, well-defined contracts, documented semantics, .etc.
>
> Do I understand correctly that ContainerKit is Peter's tentative in
> that direction, and that Merlin is Stephen's?
More correctly ....
* containerkit is Pete's iniative to define a container architecture
* excalibur/meta is a small package that defines a meta-info model as
a seperate concern from a container architecture
* escalibur/container is the result of work between Fortress and
Merlin that has led to the establishment of a set of container
indepedent interfaces (currently the lifecycle extension interfaces),
together with documentation on specific issues and proposal dealing with
component portability (context keys, meta-info attributes, etc.).
* excalibur/assembly is the Merlin 2 container that uses the
excalibur/meta and excalibur/container resorouces
Cheers, Steve.
>
>
> 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.
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>> Refering to "..artificial dependencies between the Merlin Project
>>> and the Pheonix Project" and "..Phoenix legacy..":- Phoenix
>>> compatability is what we are talking about here unless I am wrong.
>>> It could be we are talking about Phoenix obsolesence (I am not).
>>
>>
>>
>> I am *definately* not either.
>
>
> Kewl, it looks we're all on the same page then.
>
>> Phoenix has his very important space, Merlin/Fortress will have his.
>> The more they can work together and in *synergy* the better.
>
>
> I agree.
>
>>> We have an agreement a way forward for on the BlockContext issue.
>>> It is simply to include the BlockContext class (via
>>> phoenix-client.jar) in second and subsequent Phoenix compatible
>>> containers. Given K/HC/CAPI conversation of the past, and the need
>>> for separation of CAPI and K, GenericBlockContext in Phoenix CVS is
>>> the wrong solution, I think we all agree that. Given also that the
>>> home for GenericBlockContext is not certain (A-F is mooted above,
>>> but Phoenix is where it was added). Given also that the content of
>>> GenericBlockContext was nothing special - nothing that could not be
>>> added to another kernel's CVS tree.
>>>
>>> My feeling is that this single issue is nothing to do with the
>>> attributes thread. That attributes need to be handled correctly
>>> designed properly and due consideration given to backards
>>> compatability is paramount. Can multiple containers handle
>>> attribute changes (well additions reeally) as they are rolled out?
>>> Yes, in my opinion. Should attribute strings be added to
>>> BlockContext, yes in my opinion.
>>>
>>> *** Vote ***
>>> As such, can we vote on the recommendation :
>>>
>>> (*) The Avalon team recommends that Phoenix compatile container
>>> include phoenix-client.jar in their distribution and make it visible
>>> to hosted components at runtime. The Avalon team recommends that
>>> Phoenix compatible containers hide their implementations of
>>> BlockContext in the kernel's classloader and further hide the impl
>>> via use of a Refelection's dynamic proxy.
>>
>>
>>
>> You are saying that a container that wants to use Phoenix-compatible
>> Components use BlockContext?
>>
>> Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must
>> use other Phoenix stuff too?
>
>
> I'm uncomfortable with the word stuff Nicola. BlockContext for one,
> other classes from phoenix-client.jar too. I've suggested before that
> phoenix-client can be paired down a little further and think we should
> revisit that in a later discussion.
>
>> Now, since Cornerstone is about Phoenix blocks IIUC, does this mean
>> that the Phoenix blocks are the standard Avalon Components?
>
>
> People in this list for a while know I sway away from the use the of
> the word Avalon in anything other than a 'project' sense. Avalon is
> not a product it has not components. Avalon-Framework is a set of of
> interfaces (++) that define the way that a nomber of containers
> interoperate with lifecycle things. Some things in excalibur are
> simple A-F aware components that can be used like normal libraries
> jars by Java classes. Something are containers for special situations
> - ECM for Servlets (not exclusive). Tweety for play, Phoenix for
> enterprise. Some of these containers have different rules as the
> lacing together of components. Phoenix separates lacing-together into
> assembly.xml and configuration into config.xml. Others are less
> strict. A less strict one is EOB, which affords its components the
> runtime binding that Phoenix itself does not.
>
>> If yes, they should be in framework IMNSHO.
>
>
> I might agree that, given our time over that would be a better place.
> However that is off-topic. We are principally addressing one element
> of the recent disagreement. Namely the adding of GenericBlockContext
> to Phoenix CVS. Its author did so because he felt it was the only
> choice. Between us we have come up with an alternate solution that
> seems to be more inline with the original design of Phoenix. Nicola,
> please take a look at the contents of phoenix-client.jar - it is quite
> benign.
>
>> If no, it should be clearly stated that they are Phoenix-only
>> compatible.
>
>
>> And compatibility should not be attained by wrapping Phoenix stuff
>> artificially, but by hierarchically containing Phoenix, which is a
>> much cleaner solution.
>>
>> I don't like your proposal.
>
>
> Well that is a shame, but you are admitting that is a possible
> solution to the central issue of this thread which was the adding of
> GenericBlockContext tp Phoenix by Stephen.
>
> I do intend to adress the enhanced featuresof Merlin later. I also
> intend to be favourable to the concept of value-added. One issue at a
> time please.
>
>>>>>> Look at the Servlet/EJB/other APIs. They all follow this pattern
>>>>>> and I believe some (servlet API 2.1+) actually mandates that no
>>>>>> container specific classes can be in same classloader.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Such a policy concerning Avalon containers is also appropriate. In
>>>> general we should not be exposing container specific APIs to
>>>> components. It locks the component to a particular container and
>>>> introduces the problems we are currently dealing with.
>>>
>>>
>>>
>>> For Phoenix, given its separation of interface and impl, it is only
>>> the word phoenix that is objectionable in the phoenix-client.jar and
>>> its attendant package names. If we had our time over we could have
>>> moved these classes to another tree/package. Like with othr
>>> packages in Avalon, we are keeping there where they are for
>>> compatability reasons. This line of discussion deviates from (*)
>>> above and its central discussion point alternatives for
>>> GenericBlockContext (being added to Phoenix CVS).
>>
>>
>>
>> So you are saying that the Phoenix BlockContext has to be regarded as
>> the standard Container Context?
>
>
> Yup, it seems that the multi-year-old BlockContext is part of a
> defacto API. If you look at phoenix-client.jar you'll see that it is
> quite small and given amazing accident or far-sighted design by
> Stefano/Fede and others marks a good division between interface and
> impl of Phoenix from the component writers point of view.
Strong disagreement!
This is the wrong approach. We have the framework and the framework we
have Context and Context defines a named value pair scheme.
Irrespective of what you change about BlocContext - that fact is that
it is a Context object and as such the keys that are used and the types
of objects retured are part of the contract. Resolving the question of
keys in the context of a common container-component contract is a
precusor to any convinience interface - and BlockContext is just a
convinience interface.
>
>
> Yes, it has the word phoenix in it, but as I have pointed out before
> does not mean that all of Phoenix has to be included. It is already a
> better interface/impl separation than Sun's JMX or Servlet APIs are
> which require forking by alternative container developers.
>
>> This I understand, and I would like to see it become part of the
>> containerkit somehow or of the framework if this is the case.
>>
>> Don't ask me why, it's obvious.
>
>
> Apart from backards compatability. Yes, I might agree to a move to
> A-F. No, I might agree that it we had our design time again, we'd have
> a hierarchy (or not) of Context in A-F. A move to containerkit is not
> going to please the Merlin folks as they are based on
> excalibur/container.
Minor note - the Merlin folks ;-) use the excalibur/meta pacikage for
the meta-info layer (whicbis what your referencing here).
> However the central point of this thread is to adress the need for
> GenericBlockContext in Phoenix CVS. Perhaps my suggested vote topic
> was wrong. It should have been "[Vote] GenericBlockContext in Phoenix
> CVS is the wrong solution +1"
>
>>>>>> And we don't want to limit our evolution in future for so little
>>>>>> a gain as having a generic implementation. It is rare that the
>>>>>> implementations are more than 20-30 lines of code, so I am not
>>>>>> sure what the great technical difficulty is.
>>>>>>
>>>>> Err I agree with you Peter. The interface remains in
>>>>> phoenix-client.jar and the impl is left to the container in
>>>>> question. I think Stephen is coming round to the possibility of
>>>>> that fact.
>>>>
>>>>
>>>>
>>>>
>>>> I'm comming around to the conclusion that :
>>>>
>>>> 1. the first step is to resolve the context key issue
>>>>
>>>> - context keys are part of the Avalon component contract
>>>> - contract are intended to be maintained
>>>> - solving this issue has to be addressed as a higher
>>>> priority than convinience interfaces, Phoenix fixes,
>>>> or other actions such as defining additional
>>>> interfaces
>>>
>>>
>>>
>>>
>>> I completely disagree. We have got so far on the
>>> GenericBlockContext (the need for it in Phoenix CVS) issue. Please
>>> don't switch conversational threads when we are on the cusp of an
>>> agreement. Please let me tackle these issues one by one. I'll move
>>> on to attributes, meta info and other issues in time. It is
>>> important for a sense of progress during mediation to resolve an
>>> issue. Please try to meet me on this simple goal Stephen. Just
>>> because this is against you original posting of GenericBlockContext
>>> does not mean all things in this process are going to fall against
>>> you. Besides, you see the logic of the BlockContext argument don't
>>> you :-))
>>
>>
>>
>> I completely disagree.
>>
>> *If* I understand what you are saying that is...
>>
>> To be more clear, *what* are we discussing about?
>>
>> A temporary solution for interoperability between Phoenix and
>> Merlin/Fortress or standard way of defining the Context?
>>
>> If it's the first case, I agree; this is the easiest solution ATM and
>> the best given that Phoenix is mature while Merlin is still growing.
>>
>> If it's the second case, I really fail to understand how you think
>> that all Containers must adopt Phoenix inventions.
>
>
> I did not say that. Do not put words in my mouth. I am suggesting
> that all 'enterprise' containers that look to support blocks should be
> compatible with phoenix. I'm not covering ECM here. I'm not covering
> Servlet containers etc. I am covering containers who's stated aim is
> some level of interoperability with Pheonix. Could we try to keep
> discussion on the topic of GenericBlockContext.
But lets keep in mind that GenericBlockContext was introduced within the
scope of component portability.
:-)
>
>> I thought they had to adopt the framework.
>
>
> As well yes. That /is/ a prerequisite for all Lifecycle aware
> containers. Again though, that does not cover Servlet containers, or
> EJB containers. It also does not cover Applets (given they too are
> mounted in a container).
>
>> IMHO this has come out from the fact that Phoenix has been defining
>> (in a concerted effort) and bringing forward the concept of Blocks
>> and SARs.
>>
>> These are becoming important concepts for Component reuse, and Peter
>> is correctly working with ContainerKit for better reusability.
>
>
> With all due respect to Peter's effort there, Merlin is not using it.
> You will have a diffucult time convincing Stephen to move Merlin to
> containerkit. At a certain 'personal choice' level he should not have
> to.
Steve is really keen to see a comon solution - but he doesn't want the
containerkit architecture - it does not fit Merlin's requirements. The
excalibur/meta package represents an extended sub-set of containerkit
that addressed a more general requirement. The containerkit
architecture could very easily adapt to the meta-info model defined in
excalibur/meta. But that's not a real issue - the excalibur/meta
package can deal with containerkit based solutions just as containerkit
could easily deal with excalibur/meta solutions.
Cheers, Steve.
>
>
>> Can we make this "spec" become more clearly defined and part of
>> framework somehow?
>> Do I understand correctly that ContainerKit is Peter's tentative in
>> that direction, and that Merlin is Stephen's?
>
>
> No Merlin is a container that cn do the lot. Container kit is a
> reusable kit that a container writer may use as a part of a larger
> development which is a container.
>
>> 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.
>
>
> Could we try to keep discussion on the topic of GenericBlockContext.
>
> SAR, Block, Assembly, .xinfo later please.
>
> - Paul
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> Yup, it seems that the multi-year-old BlockContext is part of a
>> defacto API.
>
>
> Aha! :-))
>
> Finally you say it. You keep going in circles around it, and finally I
> make you say it.
>
> *This* is the whole point in this contention.
>
> So, you see that for you Phoenix is the Avalon RI!
Sigh. Avalon is a project. It's principal art is a couple of patterns
(not invented here) that are expressed in the lifecyle interfaces from
Avalon-Framework.
I never have and never will call Phoenix the RI for Avalon. The term
has no meaning to me. Avalon is a project with sub projects.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Nicola,
...
>> So you are saying that the Phoenix BlockContext has to be regarded as
>> the standard Container Context?
>
> Yup, it seems that the multi-year-old BlockContext is part of a defacto
> API.
Aha! :-))
Finally you say it. You keep going in circles around it, and finally I
make you say it.
*This* is the whole point in this contention.
So, you see that for you Phoenix is the Avalon RI!
> If you look at phoenix-client.jar you'll see that it is quite
> small and given amazing accident or far-sighted design by Stefano/Fede
> and others marks a good division between interface and impl of Phoenix
> from the component writers point of view.
>
> Yes, it has the word phoenix in it, but as I have pointed out before
> does not mean that all of Phoenix has to be included. It is already a
> better interface/impl separation than Sun's JMX or Servlet APIs are
> which require forking by alternative container developers.
Good, then let's define it standard, and move it to Excalibur, with a
*combined* effort, not a silent "let's dump it there and others adopt
the de-facto standard"!
It's the *same* thing Stephen is saying, man, why the heck do you think
he put the work "Generic" in his version?
Container must only depend on framework, not on other Containers.
Containers can be used hierarchically during runtime, but not depend on
parts of other containers.
I'm against de-facto standards becoming *silently* standards.
This way of declaring Phoenix features "standard" without discussion has
upset some developers, and has created FUD.
You see, you couldn't even say it clearly yourself!
>> This I understand, and I would like to see it become part of the
>> containerkit somehow or of the framework if this is the case.
>>
>> Don't ask me why, it's obvious.
>
>
> Apart from backards compatability. Yes, I might agree to a move to A-F.
> No, I might agree that it we had our design time again, we'd have a
> hierarchy (or not) of Context in A-F. A move to containerkit is not
> going to please the Merlin folks as they are based on
> excalibur/container.
Excalibur/container and ContainerKit are efforts to redefine in a more
generic solution.
It's design time, man.
...
--
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: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> Refering to "..artificial dependencies between the Merlin Project and
>> the Pheonix Project" and "..Phoenix legacy..":- Phoenix compatability
>> is what we are talking about here unless I am wrong. It could be we
>> are talking about Phoenix obsolesence (I am not).
>
>
> I am *definately* not either.
Kewl, it looks we're all on the same page then.
> Phoenix has his very important space, Merlin/Fortress will have his.
> The more they can work together and in *synergy* the better.
I agree.
>> We have an agreement a way forward for on the BlockContext issue. It
>> is simply to include the BlockContext class (via phoenix-client.jar)
>> in second and subsequent Phoenix compatible containers. Given
>> K/HC/CAPI conversation of the past, and the need for separation of
>> CAPI and K, GenericBlockContext in Phoenix CVS is the wrong solution,
>> I think we all agree that. Given also that the home for
>> GenericBlockContext is not certain (A-F is mooted above, but Phoenix
>> is where it was added). Given also that the content of
>> GenericBlockContext was nothing special - nothing that could not be
>> added to another kernel's CVS tree.
>>
>> My feeling is that this single issue is nothing to do with the
>> attributes thread. That attributes need to be handled correctly
>> designed properly and due consideration given to backards
>> compatability is paramount. Can multiple containers handle attribute
>> changes (well additions reeally) as they are rolled out? Yes, in my
>> opinion. Should attribute strings be added to BlockContext, yes in
>> my opinion.
>>
>> *** Vote ***
>> As such, can we vote on the recommendation :
>>
>> (*) The Avalon team recommends that Phoenix compatile container
>> include phoenix-client.jar in their distribution and make it visible
>> to hosted components at runtime. The Avalon team recommends that
>> Phoenix compatible containers hide their implementations of
>> BlockContext in the kernel's classloader and further hide the impl
>> via use of a Refelection's dynamic proxy.
>
>
> You are saying that a container that wants to use Phoenix-compatible
> Components use BlockContext?
>
> Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must
> use other Phoenix stuff too?
I'm uncomfortable with the word stuff Nicola. BlockContext for one,
other classes from phoenix-client.jar too. I've suggested before that
phoenix-client can be paired down a little further and think we should
revisit that in a later discussion.
> Now, since Cornerstone is about Phoenix blocks IIUC, does this mean
> that the Phoenix blocks are the standard Avalon Components?
People in this list for a while know I sway away from the use the of the
word Avalon in anything other than a 'project' sense. Avalon is not a
product it has not components. Avalon-Framework is a set of of
interfaces (++) that define the way that a nomber of containers
interoperate with lifecycle things. Some things in excalibur are simple
A-F aware components that can be used like normal libraries jars by Java
classes. Something are containers for special situations - ECM for
Servlets (not exclusive). Tweety for play, Phoenix for enterprise. Some
of these containers have different rules as the lacing together of
components. Phoenix separates lacing-together into assembly.xml and
configuration into config.xml. Others are less strict. A less strict
one is EOB, which affords its components the runtime binding that
Phoenix itself does not.
> If yes, they should be in framework IMNSHO.
I might agree that, given our time over that would be a better place.
However that is off-topic. We are principally addressing one element
of the recent disagreement. Namely the adding of GenericBlockContext to
Phoenix CVS. Its author did so because he felt it was the only choice.
Between us we have come up with an alternate solution that seems to be
more inline with the original design of Phoenix. Nicola, please take a
look at the contents of phoenix-client.jar - it is quite benign.
> If no, it should be clearly stated that they are Phoenix-only compatible.
> And compatibility should not be attained by wrapping Phoenix stuff
> artificially, but by hierarchically containing Phoenix, which is a
> much cleaner solution.
>
> I don't like your proposal.
Well that is a shame, but you are admitting that is a possible solution
to the central issue of this thread which was the adding of
GenericBlockContext tp Phoenix by Stephen.
I do intend to adress the enhanced featuresof Merlin later. I also
intend to be favourable to the concept of value-added. One issue at a
time please.
>>>>> Look at the Servlet/EJB/other APIs. They all follow this pattern
>>>>> and I believe some (servlet API 2.1+) actually mandates that no
>>>>> container specific classes can be in same classloader.
>>>>
>>>>
>>>
>>> Such a policy concerning Avalon containers is also appropriate. In
>>> general we should not be exposing container specific APIs to
>>> components. It locks the component to a particular container and
>>> introduces the problems we are currently dealing with.
>>
>>
>> For Phoenix, given its separation of interface and impl, it is only
>> the word phoenix that is objectionable in the phoenix-client.jar and
>> its attendant package names. If we had our time over we could have
>> moved these classes to another tree/package. Like with othr packages
>> in Avalon, we are keeping there where they are for compatability
>> reasons. This line of discussion deviates from (*) above and its
>> central discussion point alternatives for GenericBlockContext (being
>> added to Phoenix CVS).
>
>
> So you are saying that the Phoenix BlockContext has to be regarded as
> the standard Container Context?
Yup, it seems that the multi-year-old BlockContext is part of a defacto
API. If you look at phoenix-client.jar you'll see that it is quite
small and given amazing accident or far-sighted design by Stefano/Fede
and others marks a good division between interface and impl of Phoenix
from the component writers point of view.
Yes, it has the word phoenix in it, but as I have pointed out before
does not mean that all of Phoenix has to be included. It is already a
better interface/impl separation than Sun's JMX or Servlet APIs are
which require forking by alternative container developers.
> This I understand, and I would like to see it become part of the
> containerkit somehow or of the framework if this is the case.
>
> Don't ask me why, it's obvious.
Apart from backards compatability. Yes, I might agree to a move to A-F.
No, I might agree that it we had our design time again, we'd have a
hierarchy (or not) of Context in A-F. A move to containerkit is not
going to please the Merlin folks as they are based on
excalibur/container. However the central point of this thread is to
adress the need for GenericBlockContext in Phoenix CVS. Perhaps my
suggested vote topic was wrong. It should have been "[Vote]
GenericBlockContext in Phoenix CVS is the wrong solution +1"
>>>>> And we don't want to limit our evolution in future for so little a
>>>>> gain as having a generic implementation. It is rare that the
>>>>> implementations are more than 20-30 lines of code, so I am not
>>>>> sure what the great technical difficulty is.
>>>>>
>>>> Err I agree with you Peter. The interface remains in
>>>> phoenix-client.jar and the impl is left to the container in
>>>> question. I think Stephen is coming round to the possibility of
>>>> that fact.
>>>
>>>
>>>
>>> I'm comming around to the conclusion that :
>>>
>>> 1. the first step is to resolve the context key issue
>>>
>>> - context keys are part of the Avalon component contract
>>> - contract are intended to be maintained
>>> - solving this issue has to be addressed as a higher
>>> priority than convinience interfaces, Phoenix fixes,
>>> or other actions such as defining additional
>>> interfaces
>>
>>
>>
>> I completely disagree. We have got so far on the GenericBlockContext
>> (the need for it in Phoenix CVS) issue. Please don't switch
>> conversational threads when we are on the cusp of an agreement.
>> Please let me tackle these issues one by one. I'll move on to
>> attributes, meta info and other issues in time. It is important for a
>> sense of progress during mediation to resolve an issue. Please try
>> to meet me on this simple goal Stephen. Just because this is against
>> you original posting of GenericBlockContext does not mean all things
>> in this process are going to fall against you. Besides, you see the
>> logic of the BlockContext argument don't you :-))
>
>
> I completely disagree.
>
> *If* I understand what you are saying that is...
>
> To be more clear, *what* are we discussing about?
>
> A temporary solution for interoperability between Phoenix and
> Merlin/Fortress or standard way of defining the Context?
>
> If it's the first case, I agree; this is the easiest solution ATM and
> the best given that Phoenix is mature while Merlin is still growing.
>
> If it's the second case, I really fail to understand how you think
> that all Containers must adopt Phoenix inventions.
I did not say that. Do not put words in my mouth. I am suggesting that
all 'enterprise' containers that look to support blocks should be
compatible with phoenix. I'm not covering ECM here. I'm not covering
Servlet containers etc. I am covering containers who's stated aim is
some level of interoperability with Pheonix. Could we try to keep
discussion on the topic of GenericBlockContext.
> I thought they had to adopt the framework.
As well yes. That /is/ a prerequisite for all Lifecycle aware
containers. Again though, that does not cover Servlet containers, or
EJB containers. It also does not cover Applets (given they too are
mounted in a container).
> IMHO this has come out from the fact that Phoenix has been defining
> (in a concerted effort) and bringing forward the concept of Blocks and
> SARs.
>
> These are becoming important concepts for Component reuse, and Peter
> is correctly working with ContainerKit for better reusability.
With all due respect to Peter's effort there, Merlin is not using it.
You will have a diffucult time convincing Stephen to move Merlin to
containerkit. At a certain 'personal choice' level he should not have to.
> Can we make this "spec" become more clearly defined and part of
> framework somehow?
> Do I understand correctly that ContainerKit is Peter's tentative in
> that direction, and that Merlin is Stephen's?
No Merlin is a container that cn do the lot. Container kit is a
reusable kit that a container writer may use as a part of a larger
development which is a container.
> 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.
Could we try to keep discussion on the topic of GenericBlockContext.
SAR, Block, Assembly, .xinfo later please.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>>>>>>>> 1) Merlin includes phoenix-client.jar and provides alternate
>>>>>>>>> implemetations of the BlockContext interface.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thats the only real solution at this stage.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There could be some reason why that is not possible.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It will become a lot more difficult in the future when classLoader
>>>>>> and
>>>>>> interceptor stuff get integrated but it should be possible to
>>>>>> no-op those
>>>>>> features - not sure.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well let's tackle future features in the future. For now though I
>>>>> think
>>>>> that useing a Phoenix jar to be Phoenix compatible is perfectly
>>>>> possible.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I am not sure what you are saying. If you want to implement
>>>> BlockContext then that is fine but the implementation is inherently
>>>> container specific. The implementation should not even be in the
>>>> same classloader as the interface.
>>>
>>>
>>>
>>
>> The GenericBlockContext provides a solution for any Avalon container
>> to workaround the Phoenix BlockContext dependency issue. It deals
>> with the very situation you mention below - the inclusion of container
>> specific APIs - in this case a Phoenix specific APIs. What
>> GenericBlockContext does is to provide a mechanism for any container
>> to be able to deal with the legacy of Phoenix dependent components
>> that include references to the BlockContext interface. The
>> implementation solves the problem by allowing a container to handle
>> the association of keys and values using java.util.Map and the Context
>> class. Boyond this it has to implement the BlockContext interface in
>> order to solve the issue of Phoenix API exposure towards components.
>> Relative to a container, the GenericBlockContext depedencies are on
>> Map, Context, String and a client supplied classpath. Relative to the
>> component the dependency is on Phoneix and the A-F.
>> GenericBlockContext provides the bridge between the two.
>
>
>> Everything about this is solving a Phoneix issue. But, yes - the
>> solution can be included inside Merlin. Yes we can create artificial
>> depedencies between the Merlin Project and the Phoenix Project. Yes
>> we can oblige Merlin installations to include APIs to another
>> container for those occasions where the client is dealing with Phoenix
>> legacy and already have phoenix-client.jar in place. Yes, we could
>> write this up in the FAQ and explain why its a good thing - but I may
>> need some help on that!
>
>
> Refering to "..artificial dependencies between the Merlin Project and
> the Pheonix Project" and "..Phoenix legacy..":- Phoenix compatability is
> what we are talking about here unless I am wrong. It could be we are
> talking about Phoenix obsolesence (I am not).
I am *definately* not either.
Phoenix has his very important space, Merlin/Fortress will have his.
The more they can work together and in *synergy* the better.
> We have an agreement a way forward for on the BlockContext issue. It is
> simply to include the BlockContext class (via phoenix-client.jar) in
> second and subsequent Phoenix compatible containers. Given K/HC/CAPI
> conversation of the past, and the need for separation of CAPI and K,
> GenericBlockContext in Phoenix CVS is the wrong solution, I think we all
> agree that. Given also that the home for GenericBlockContext is not
> certain (A-F is mooted above, but Phoenix is where it was added). Given
> also that the content of GenericBlockContext was nothing special -
> nothing that could not be added to another kernel's CVS tree.
>
> My feeling is that this single issue is nothing to do with the
> attributes thread. That attributes need to be handled correctly
> designed properly and due consideration given to backards compatability
> is paramount. Can multiple containers handle attribute changes (well
> additions reeally) as they are rolled out? Yes, in my opinion. Should
> attribute strings be added to BlockContext, yes in my opinion.
>
> *** Vote ***
> As such, can we vote on the recommendation :
>
> (*) The Avalon team recommends that Phoenix compatile container include
> phoenix-client.jar in their distribution and make it visible to hosted
> components at runtime. The Avalon team recommends that Phoenix
> compatible containers hide their implementations of BlockContext in the
> kernel's classloader and further hide the impl via use of a
> Refelection's dynamic proxy.
You are saying that a container that wants to use Phoenix-compatible
Components use BlockContext?
Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must
use other Phoenix stuff too?
Now, since Cornerstone is about Phoenix blocks IIUC, does this mean that
the Phoenix blocks are the standard Avalon Components?
If yes, they should be in framework IMNSHO.
If no, it should be clearly stated that they are Phoenix-only compatible.
And compatibility should not be attained by wrapping Phoenix stuff
artificially, but by hierarchically containing Phoenix, which is a much
cleaner solution.
I don't like your proposal.
>>>> Look at the Servlet/EJB/other APIs. They all follow this pattern and
>>>> I believe some (servlet API 2.1+) actually mandates that no
>>>> container specific classes can be in same classloader.
>>>
>>
>> Such a policy concerning Avalon containers is also appropriate. In
>> general we should not be exposing container specific APIs to
>> components. It locks the component to a particular container and
>> introduces the problems we are currently dealing with.
>
> For Phoenix, given its separation of interface and impl, it is only the
> word phoenix that is objectionable in the phoenix-client.jar and its
> attendant package names. If we had our time over we could have moved
> these classes to another tree/package. Like with othr packages in
> Avalon, we are keeping there where they are for compatability reasons.
> This line of discussion deviates from (*) above and its central
> discussion point alternatives for GenericBlockContext (being added to
> Phoenix CVS).
So you are saying that the Phoenix BlockContext has to be regarded as
the standard Container Context?
This I understand, and I would like to see it become part of the
containerkit somehow or of the framework if this is the case.
Don't ask me why, it's obvious.
>>>> And we don't want to limit our evolution in future for so little a
>>>> gain as having a generic implementation. It is rare that the
>>>> implementations are more than 20-30 lines of code, so I am not sure
>>>> what the great technical difficulty is.
>>>>
>>> Err I agree with you Peter. The interface remains in
>>> phoenix-client.jar and the impl is left to the container in
>>> question. I think Stephen is coming round to the possibility of that
>>> fact.
>>
>>
>> I'm comming around to the conclusion that :
>>
>> 1. the first step is to resolve the context key issue
>>
>> - context keys are part of the Avalon component contract
>> - contract are intended to be maintained
>> - solving this issue has to be addressed as a higher
>> priority than convinience interfaces, Phoenix fixes,
>> or other actions such as defining additional
>> interfaces
>
>
> I completely disagree. We have got so far on the GenericBlockContext
> (the need for it in Phoenix CVS) issue. Please don't switch
> conversational threads when we are on the cusp of an agreement. Please
> let me tackle these issues one by one. I'll move on to attributes, meta
> info and other issues in time. It is important for a sense of progress
> during mediation to resolve an issue. Please try to meet me on this
> simple goal Stephen. Just because this is against you original posting
> of GenericBlockContext does not mean all things in this process are
> going to fall against you. Besides, you see the logic of the
> BlockContext argument don't you :-))
I completely disagree.
*If* I understand what you are saying that is...
To be more clear, *what* are we discussing about?
A temporary solution for interoperability between Phoenix and
Merlin/Fortress or standard way of defining the Context?
If it's the first case, I agree; this is the easiest solution ATM and
the best given that Phoenix is mature while Merlin is still growing.
If it's the second case, I really fail to understand how you think that
all Containers must adopt Phoenix inventions.
I thought they had to adopt the framework.
IMHO this has come out from the fact that Phoenix has been defining (in
a concerted effort) and bringing forward the concept of Blocks and SARs.
These are becoming important concepts for Component reuse, and Peter is
correctly working with ContainerKit for better reusability.
Can we make this "spec" become more clearly defined and part of
framework somehow?
Do I understand correctly that ContainerKit is Peter's tentative in that
direction, and that Merlin is Stephen's?
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.
--
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>
It's not the technology - it's the process
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Leo Sutic wrote:
>>
>>
>>
>>>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>>>
>>>>Avalon Committers : I'd like a vote of confidence please.
>>>>
>>>>
>>>>
>>>+100 for trying, mate.
>>>
>>>+1 for keeping on trying, but
>>>
>>>+0 for your chances of success.
>>>
>>>Mediation is only useful if the two sides want to get along.
>>>So far it seems like Peter and Stephen are fine with making any
>>>compromise and that they are happy to include any Merlin/Phoenix
>>>feature - as long as the end result is *exactly* like they
>>>intended it all along.
>>>
>>>
>>>
>>Leo:
>>
>>Let me point out to you a two or three facts of life:
>>
>>
>
>...
>
>
>
>>This isn't what I indended - it's better - a lot better!
>>
>>
>
>Stephen,
>
>I'm not about to get into an argument with you on this. This thread
>(and its predecessors) has been a time-sink since it started. The
>issue is not your achievements, Merlin speaks for itself, it is the
>mailing-list/CVS/code-war that you and Peter have been at for a while
>now.
>
>So let me just sum it up: Both you and Peter are convinced that you
>are right. You are both willing to compromise. But not enough for
>any type of mediation, because you would have to give up some central
>notion of your design. Thus deadlock. Thus any type of mediation is a
>total and utter waste of time for everyone involved.
>
I don't want an argument either ... so there's two things we agree on ;-)
I work with a lot of code and that code is very dependent on Avalon
Framework - and like you I don't want the framework to change. Its been
a year or two that I've been doing things here in Avalon and during that
time Pete's been the most active contributor of code - really good code.
Problem is that we have been very comfortable with Pete doing
everything. I know I have been really comfortable sitting back and
watching Phoenix evolve. New features, new benefits - and all of this
for free!
But there is a dark side - Pete's not ok with the process of dealing
with alternative opinions - and I'm not just talking about mine - I'm
talking about this is a general sense. We have already some significant
fractures in Avalon (e.g. interpretation of lookup semantics in ECM and
Phoenix are totally different - Merlin/Containerkit going in divergent
directions). We can continue to build are own playgrounds or we can act
with responsibility concerning the evolution of a complete solution - a
solution without fractures. To achieve this we need much better Avalon
level process to control product and service evolution.
For example, I watch commits of containerkit dependencies into Phoenix
without a single word of discussion - not even a comment. One more
fracture in the Avalon technology offer. This typifies my objection and
my basic concern. We - you - me - and the other committers here at
Avalon have to take much more responsibility for the direction and
integrity of this project.
Avalon cannot grow without engagement and responsibility.
This isn't about the technology.
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: [Vote] Mediation or not.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Leo Sutic wrote:
>
> >
> >>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> >>
> >>Avalon Committers : I'd like a vote of confidence please.
> >>
> >
> >+100 for trying, mate.
> >
> >+1 for keeping on trying, but
> >
> >+0 for your chances of success.
> >
> >Mediation is only useful if the two sides want to get along.
> So far it
> >seems like Peter and Stephen are fine with making any compromise and
> >that they are happy to include any Merlin/Phoenix feature -
> as long as
> >the end result is *exactly* like they intended it all along.
> >
>
> Leo:
>
> Let me point out to you a two or three facts of life:
...
> This isn't what I indended - it's better - a lot better!
Stephen,
I'm not about to get into an argument with you on this. This thread (and
its
predecessors) has been a time-sink since it started. The issue is not
your
achievements, Merlin speaks for itself, it is the
mailing-list/CVS/code-war
that you and Peter have been at for a while now.
So let me just sum it up: Both you and Peter are convinced that you are
right. You are both willing to compromise. But not enough for any type
of mediation, because you would have to give up some central notion
of your design. Thus deadlock. Thus any type of mediation is a total
and utter waste of time for everyone involved.
That is why I'm advocating an approach that does not require you and
Peter
to get along. It's not the most technically beautiful solution, but
given
the Jakarta we have, given the Avalon-dev we have, it may be the best
way.
It's an 80% solution that can be 100% implemented, as opposed to the
100%
solution that you will only ever be able to implement to 80% due to
friction between you and Peter.
> >All I want is no changes to Framework. As long as Avalon/Framework
> >has all contracts and all classes needed to write a container or a
> >component, I'm fine.
> >
>
> +1
I guess we agree on something, then.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] Mediation or not.
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>
>>Avalon Committers : I'd like a vote of confidence please.
>>
>
>+100 for trying, mate.
>
>+1 for keeping on trying, but
>
>+0 for your chances of success.
>
>Mediation is only useful if the two sides want to get along. So far
>it seems like Peter and Stephen are fine with making any compromise
>and that they are happy to include any Merlin/Phoenix feature - as
>long as the end result is *exactly* like they intended it all along.
>
Leo:
Let me point out to you a two or three facts of life:
1. forking occured due to an impossible situation
2. since the fork, the work on excalibur/meta has evolved to
include:
- Leo's (the other Leo) suggestions concerning API improvement
- Berin and Pete's position on terminology re stage/phase
- General concensus on terminology appliced to classes
- Fortress requirements on of lifecycle extension (subsequently
incorporated in Merlin)
- changes to the API based on trials focussing on Coocoon
requirements introduced by Nicola
- numerouse documentation enhancements and improvements
3. lots of trials across different applications
- James, raises issue with Cornerstone and Phoneix on
component portability (resolved)
- EOB, raised isssues on component protability (pending)
- Cornerstone, raises issue on component portability
(unresolved - Pete's -1s)
- OSM commercal apps - raised issues concerning component
protability (resolved), massive simplification in
deployment model is in progress and resulting in delivery
of remotetly accessible containers
- actions between Fortress and Merlin leading to establishment
of a common lifestyle managemnt solution based on collaboration
and contributions from Berin and Marcus
The excalibur/meta package is not what I intended it to me. In fact I
never intended excalibur/meta to even exist. I was necessity brought
about by Pete's abuse of -1 semantics. With the establishment of
excalibur/meta as a stucture enabling actions to proceed, the package
hase evolved substantially based on feedback and constructive input from
this forum.
I have to disagree with you.
This isn't what I indended - it's better - a lot better!
>
>
>The man with the plan, and Heaven help anything that the straight line
>from either of them to their goal intersects. I don't mind that - with
>an exception I'll get back to below - design by Guru is a remarkably
>fast way of getting good stuff done fast fast fast, because you don't
>have to spend time explaining the vision or plan and align everyone.
>I'm not the slightest surprised at Peter's two-week attribute-driven
>blitzkrieg - if anything it is that the business logic wasn't finished
>after 2w, but I guess management takes time.
>
>I'm not sure that the Phoenix way is the way to go - too static. I'm not
>sure the Merlin way is the way to go - too much magic.
>
Read the documentation - no magic - just practical solutions to
requirements.
http://jakarta.apache.org/avalon/merlin
http://jakarta.apache.org/avalon/meta
http://jakarta.apache.org/avalon/container
>All I want is no changes to Framework. As long as Avalon/Framework
>has all contracts and all classes needed to write a container or a
>component, I'm fine.
>
+1
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: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 27 Aug 2002 17:28, Nicola Ken Barozzi wrote:
> ... On The need for Context subclasses ...
>
>>I don't understand, sorry.
>>As I said above, any cast to a context is a big mistake IMO.
>>Please explain why you nead methods.
>
> The explanation to this is no different from the last two times I have
> explained this exact same point to you. I thought you conceded it was
> necessary last time? Or have you come up with a solution for the problem?
I don't remember this at all.
What I do remember instead, is that I tried argumenting that the Context
itsef could be avoided in many cases, not about the need of Context
*subclasses*.
I have also looked in the mail archives, reread threads like
http://marc.theaimsgroup.com/?t=102558313100001&r=1&w=2
and found no mail where doing
public void contextualize(Context context){
MyContext mycontext = (MyContext) context;
}
is better than
public void contextualize(Context context){
MyContext mycontext = (MyContext) context.get(MyContext.KEY);
}
Do others remember what Peter is talking about? :-?
--
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: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Tue, 27 Aug 2002 17:28, Nicola Ken Barozzi wrote:
>> ... On The need for Context subclasses ...
>>
>>> I don't understand, sorry.
>>> As I said above, any cast to a context is a big mistake IMO.
>>> Please explain why you nead methods.
>>
>>
>>
>> The explanation to this is no different from the last two times I have
>> explained this exact same point to you. I thought you conceded it was
>> necessary last time? Or have you come up with a solution for the problem?
>
>
> Oh, I forgot this.
> http://marc.theaimsgroup.com/?l=avalon-dev&m=102559159916800&w=2
>
> It seems to indicate that there is no real need for initial cast from
> the Context acquired.
...
from the example in containerkit:
"
<context type="MyContextInterface">
<!--
Declaration of an entry in a context object, the "key" is
the key used by a component to locate the context entry,
the "type" is the classname of value (typically an interface)
or primative type. The default value is java.lang.String.
The "optional" attribute is a boolean value derived from the
TRUE or FALSE that indicates if the context value must be
provided or not (default is FALSE).
-->
<entry key="base" type="java.io.File"/>
<entry key="mode" type="java.lang.Object" optional="TRUE"/>
</context>
"
I think we agree then.
--
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: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 27 Aug 2002 17:28, Nicola Ken Barozzi wrote:
> ... On The need for Context subclasses ...
>
>>I don't understand, sorry.
>>As I said above, any cast to a context is a big mistake IMO.
>>Please explain why you nead methods.
>
>
> The explanation to this is no different from the last two times I have
> explained this exact same point to you. I thought you conceded it was
> necessary last time? Or have you come up with a solution for the problem?
Oh, I forgot this.
http://marc.theaimsgroup.com/?l=avalon-dev&m=102559159916800&w=2
It seems to indicate that there is no real need for initial cast from
the Context acquired.
"
From: Peter Donald <pe...@apache.org>
At 08:04 AM 7/2/2002 +0200, you wrote:
>ie is it good practice to do in contextualize(Context context)
>
> MYContext mc = (MYContext) context;
I prefer this option - for no real good reason except that I find it
easier to use.
>?
>
>Or to do
>
> MYContext mc = context.get(MY_CONTEXT);
Another option.
"
--
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: [Vote] Mediation or not.
Posted by Peter Donald <pe...@apache.org>.
On Tue, 27 Aug 2002 17:28, Nicola Ken Barozzi wrote:
... On The need for Context subclasses ...
> I don't understand, sorry.
> As I said above, any cast to a context is a big mistake IMO.
> Please explain why you nead methods.
The explanation to this is no different from the last two times I have
explained this exact same point to you. I thought you conceded it was
necessary last time? Or have you come up with a solution for the problem?
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 27 Aug 2002 07:13, Nicola Ken Barozzi wrote:
>
>>This is IMNSHO a wrong way of using a context.
>>context has been casted to BlockContext, a thing that should be done
>>only on objects given by a ServiceManager.
>>
>>In fact, a service is gotten by role, a Context is given as-is.
>>
>>It's plain wrong that a Context be cast, it should be used only via keys.
>>
>>Seeing all the commented out methods of Blockcontext, I think Phoenix
>>developers agree.
>
>
> Actually - no ;)
>
> The commented out methods are there to indicate future evolution
paths. ie
> When we integrate the interceptors we will need the proxy methods.
When we
> integrate "protected" blocks we will need some way to get at MBean
server
> (though I don't think it will be via that method). etc.
I don't understand, sorry.
As I said above, any cast to a context is a big mistake IMO.
Please explain why you nead methods.
Are interceptors things that act when a method is called?
Then you can intercept the get and dispatch using the attribute.
>> > The attribute documentation over
>> > on excalibur/container/src/xdocs/attributes.xml provides a good
>> > picture of what's needed on common context keys.
>>
>>Let's standardize on these.
>>
>>Like lifecycle interfaces get a stamp of approval when there is a valid
>>use-case for them, so we should do with Context attributes.
>>
>>Proposals?
>
> Wait a while and I will commit the ones that are going to be
integrated into
> Phoenix.
Ha.
--
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: [Vote] Mediation or not.
Posted by Peter Donald <pe...@apache.org>.
On Tue, 27 Aug 2002 07:13, Nicola Ken Barozzi wrote:
> This is IMNSHO a wrong way of using a context.
> context has been casted to BlockContext, a thing that should be done
> only on objects given by a ServiceManager.
>
> In fact, a service is gotten by role, a Context is given as-is.
>
> It's plain wrong that a Context be cast, it should be used only via keys.
>
> Seeing all the commented out methods of Blockcontext, I think Phoenix
> developers agree.
Actually - no ;)
The commented out methods are there to indicate future evolution paths. ie
When we integrate the interceptors we will need the proxy methods. When we
integrate "protected" blocks we will need some way to get at MBean server
(though I don't think it will be via that method). etc.
> > The attribute documentation over
> > on excalibur/container/src/xdocs/attributes.xml provides a good
> > picture of what's needed on common context keys.
>
> Let's standardize on these.
>
> Like lifecycle interfaces get a stamp of approval when there is a valid
> use-case for them, so we should do with Context attributes.
>
> Proposals?
Wait a while and I will commit the ones that are going to be integrated into
Phoenix.
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Nicola
>
>> Proposals?
>
>
> Could you vote on a simple suggestion of issue-by-issue mediation? I
> know Phoenix and Cornerstone are not normally your areas Nicola, but you
> still get a vote.
I did vote, a -1.
> And by the way, I was tackling GenericBlockContext being added to
> Phoenix CVS. Stephen may be suggesting different things now, but I am
> tackling that item. Yopu have mistakenly called it PhoenixBlockContext
> (which does not exist, now or ever).
Gee man, how pricky!
It was intended!
> I'm quite prepared for things to move on to better ways of abstracting
> the differences, but I'd like to formally settle the GenericBlockContext
> issue first. By suggesting many great ideas you splinter the thread,
> and avoid the possibility of chalking up achievements (i.e.
> GenericBlockContext being not being added to Phoenix CVS).
+1 for not adding it
-1 for making it a dependency for other containers.
> So, in summary - could *you* ->
> 1) vote on a mandate for issue-by-issue resultion.
I did.
> 2) Avoid great ideas and splintering threads until voting.
I already voted, and simply gave a possible alternative suggestion.
> 3) Take some care to get naming right - GenericBlockContext in this
> instance (and 'Avalon RI' in previous threads, though I think I might
> have an understanding from you there).
You *are* pricky ;-P
--
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: [Vote] Mediation or not.
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola
> Proposals?
Could you vote on a simple suggestion of issue-by-issue mediation? I
know Phoenix and Cornerstone are not normally your areas Nicola, but you
still get a vote.
And by the way, I was tackling GenericBlockContext being added to
Phoenix CVS. Stephen may be suggesting different things now, but I am
tackling that item. Yopu have mistakenly called it PhoenixBlockContext
(which does not exist, now or ever).
I'm quite prepared for things to move on to better ways of abstracting
the differences, but I'd like to formally settle the GenericBlockContext
issue first. By suggesting many great ideas you splinter the thread,
and avoid the possibility of chalking up achievements (i.e.
GenericBlockContext being not being added to Phoenix CVS).
So, in summary - could *you* ->
1) vote on a mandate for issue-by-issue resultion.
2) Avoid great ideas and splintering threads until voting.
3) Take some care to get naming right - GenericBlockContext in this
instance (and 'Avalon RI' in previous threads, though I think I might
have an understanding from you there).
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] Mediation or not.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>
>>Avalon Committers : I'd like a vote of confidence please.
>
>
> +100 for trying, mate.
>
> +1 for keeping on trying, but
>
> +0 for your chances of success.
*sigh* *nod* *sigh*
> Mediation is only useful if the two sides want to get along. So far
> it seems like Peter and Stephen are fine with making any compromise and
> that
> they are happy to include any Merlin/Phoenix feature - as long as the
> end result
> is *exactly* like they intended it all along.
>
> The man with the plan, and Heaven help anything that the straight line
> from either of them to their goal intersects. I don't mind that - with
> an exception I'll get back to below - design by Guru is a remarkably
> fast way of getting good stuff done fast fast fast, because you don't
> have to spend time explaining the vision or plan and align everyone.
> I'm not the slightest surprised at Peter's two-week attribute-driven
> blitzkrieg - if anything it is that the business logic wasn't finished
> after 2w, but I guess management takes time.
Yup.
> I'm not sure that the Phoenix way is the way to go - too static. I'm not
> sure the Merlin way is the way to go - too much magic.
Good summary, I agree.
> All I want
> is no changes to Framework. As long as Avalon/Framework has all
> contracts
> and all classes needed to write a container or a component, I'm fine.
+1000
Some are more involved in containers here, some in components, I'm
surely with Leo on the framework :-D
> ------------
>
> Nicola's proposition of containers within containers seems like a
> worthwhile
> solution for now - only problem being how you handle lookups:
Yup, you said it ;-)
> Container X hosts component A. It also hosts container Y, which hosts
> component B:
>
> X -----+----- A
> |
> +----- Y ----- B
>
> Now when A does lookup(B.ROLE) (to use ECM notation, you know what I
> mean),
> X must not only check
>
> + itself (does X contain a B?)
> + it's parent CM (does the parent CM have a B?)
>
> as is done currently in the ECM, but also
>
> + all its embedded containers (does Y have a B?)
>
> Meaning that Y must somehow expose a Container interface (I guess
> similar to the ServiceManager interface).
Yes. A Container is a Component, and as such should have his interface.
> If we can have this, then
>
> + Phoenix can evolve in any way Peter sees fit.
>
> + Merlin can evolve in any way Stephen sees fit.
>
> + <insert name of next great container> can evolve
> in any way <author> sees fit.
Yes.
And eventually converge when they see the advantages of the other stuff.
Peter said it right: we are not ready yet to do a uber-all container,
and probably never will because we will *always* come to some point that
new Containers will come onto the scene, with new functionality.
Let's not get buried into something we're not ready yet to do, but let's
also manage multiple Containers effectively.
> I also think this will have the least impact on Merlin/Phoenix.
> Phoenix is already embeddable (I think), and Merlin surely is.
Yup.
Also, if we could decouple the base frontends from Phoenix, as I already
hinted to Paul, we could have a very neat thing.
Not compulsory, but nice IMHO.
> And the problem of trying to come up with the one true container pretty
> much disappears. Best of all: Avalon/Framework is unchanged.
[snipped subtle Leo-Rant ;-)]
-oOo-
With regards to the PhoenixBlockContext...
I don't like the solution Paul stated as a definitive solution to the
problem.
As I already said, I don't even like the idea that Cornerstone
components need to be bound necessarily to Phoenix.
I understand that Peter is addressing these issues, and I feel confident
he will.
BTW, I have taken time to look what usage there is in Cornerstone about
BlockContext.
There are only 4 classes, and this is part of AbstractFileRepository,
written by... you go and see, get ready for a surprise :-)
public void contextualize( final Context context )
{
final BlockContext blockContext = (BlockContext)context;
m_baseDirectory = blockContext.getBaseDirectory();
}
Now, this can be easily done like Stephen says:
> I really think that resolution of the attribute issue is the issue
> that needs to be dealt with in the short term.
>
> Consider the following:
>
> // Phoenix dependent version
> File file = context.getWorkingDirectory();
>
> // portable component version
> File file = (File) context.get("avalon:home");
This is IMNSHO a wrong way of using a context.
context has been casted to BlockContext, a thing that should be done
only on objects given by a ServiceManager.
In fact, a service is gotten by role, a Context is given as-is.
It's plain wrong that a Context be cast, it should be used only via keys.
Seeing all the commented out methods of Blockcontext, I think Phoenix
developers agree.
> The attribute documentation over
> on excalibur/container/src/xdocs/attributes.xml provides a good
> picture of what's needed on common context keys.
Let's standardize on these.
Like lifecycle interfaces get a stamp of approval when there is a valid
use-case for them, so we should do with Context attributes.
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: [Vote] Mediation or not.
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-08-26 at 22:38, Leo Sutic wrote:
>
>
> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> >
> > Avalon Committers : I'd like a vote of confidence please.
>
> +100 for trying, mate.
>
> +1 for keeping on trying, but
>
> +0 for your chances of success.
+1 to those, except I think +1 from all of the committers on this one
will improve that +0 to at least +.5 (which is probably why Paul asks
for it)
<snip>
> design by Guru is a remarkably
> fast way of getting good stuff done fast fast fast, because you don't
> have to spend time explaining the vision or plan and align everyone.
+1. However, I don't care that much about "fast fast fast" with regards
to avalon in general. If it takes 6 months to get a cross-container,
extensible, dynamic, well-designed meta system as opposed to 2 weeks for
a phoenix-only system, I say take 8 months and include docs ;)
I recognize everyone has different needs and agendas though...
<snip>
> (Alternatively we could just dump all this component portability
> thing and get on with everything like we did before.)
-1. That sounds like a stop on improvement ;)
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Vote] Mediation or not.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>
> Avalon Committers : I'd like a vote of confidence please.
+100 for trying, mate.
+1 for keeping on trying, but
+0 for your chances of success.
Mediation is only useful if the two sides want to get along. So far
it seems like Peter and Stephen are fine with making any compromise and
that
they are happy to include any Merlin/Phoenix feature - as long as the
end result
is *exactly* like they intended it all along.
The man with the plan, and Heaven help anything that the straight line
from either of them to their goal intersects. I don't mind that - with
an exception I'll get back to below - design by Guru is a remarkably
fast way of getting good stuff done fast fast fast, because you don't
have to spend time explaining the vision or plan and align everyone.
I'm not the slightest surprised at Peter's two-week attribute-driven
blitzkrieg - if anything it is that the business logic wasn't finished
after 2w, but I guess management takes time.
I'm not sure that the Phoenix way is the way to go - too static. I'm not
sure the Merlin way is the way to go - too much magic. All I want
is no changes to Framework. As long as Avalon/Framework has all
contracts
and all classes needed to write a container or a component, I'm fine.
------------
Nicola's proposition of containers within containers seems like a
worthwhile
solution for now - only problem being how you handle lookups:
Container X hosts component A. It also hosts container Y, which hosts
component B:
X -----+----- A
|
+----- Y ----- B
Now when A does lookup(B.ROLE) (to use ECM notation, you know what I
mean),
X must not only check
+ itself (does X contain a B?)
+ it's parent CM (does the parent CM have a B?)
as is done currently in the ECM, but also
+ all its embedded containers (does Y have a B?)
Meaning that Y must somehow expose a Container interface (I guess
similar to the ServiceManager interface).
If we can have this, then
+ Phoenix can evolve in any way Peter sees fit.
+ Merlin can evolve in any way Stephen sees fit.
+ <insert name of next great container> can evolve
in any way <author> sees fit.
I also think this will have the least impact on Merlin/Phoenix.
Phoenix is already embeddable (I think), and Merlin surely is.
And the problem of trying to come up with the one true container pretty
much disappears. Best of all: Avalon/Framework is unchanged.
/LS
(Alternatively we could just dump all this component portability
thing and get on with everything like we did before.)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Vote] Mediation or not.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> > Refering to "..artificial dependencies between the Merlin Project and
> > the Pheonix Project" and "..Phoenix legacy..":- Phoenix
> > compatability is what we are talking about here unless I am wrong.
>
>
> I believe it is the wrong focus.
I do not. I was merely trying to get the topic back to
GenericBlockContext being added to Phoenix CVS or not.
----
Avalon Committers : I'd like a vote of confidence please.
I, Paul Hammant, would like to be empowered by the committers of Avalon
to persue a plan of issue-by-issue resolution of things that Peter and
Stephen disagreed over. A sensible starting point wast the adding of
GenericBlockContext by Stephen *to* *Phoenix* *CVS* and its remove three
times by Peter. Without going back and looking to see who did or did
not garner a vote and/or provide an explanation on any event and/or have
kudos in the packages in question. I was trying to expore the options
and had several days worth of constructive discussion leading towards a
conclusion, before the waters were muddied. If I do not get majority
approval, I will just go back to commits on those areas I am disrectly
concerned with. I won't vote on this issue myself as it would be
incorrect to do so.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>>>>>>>> 1) Merlin includes phoenix-client.jar and provides
>>>>>>>>> alternate implemetations of the BlockContext
>>>>>>>>> interface.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thats the only real solution at this stage.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There could be some reason why that is not possible.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It will become a lot more difficult in the future when
>>>>>> classLoader and interceptor stuff get integrated but it
>>>>>> should be possible to no-op those features - not sure.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well let's tackle future features in the future. For now
>>>>> though I think that useing a Phoenix jar to be Phoenix
>>>>> compatible is perfectly possible.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I am not sure what you are saying. If you want to implement
>>>> BlockContext then that is fine but the implementation is
>>>> inherently container specific. The implementation should not
>>>> even be in the same classloader as the interface.
>>>
>>>
>>>
>>
>> The GenericBlockContext provides a solution for any Avalon
>> container to workaround the Phoenix BlockContext dependency issue.
>> It deals with the very situation you mention below - the inclusion
>> of container specific APIs - in this case a Phoenix specific APIs.
>> What GenericBlockContext does is to provide a mechanism for any
>> container to be able to deal with the legacy of Phoenix dependent
>> components that include references to the BlockContext interface.
>> The implementation solves the problem by allowing a container to
>> handle the association of keys and values using java.util.Map and
>> the Context class. Boyond this it has to implement the
>> BlockContext interface in order to solve the issue of Phoenix API
>> exposure towards components. Relative to a container, the
>> GenericBlockContext depedencies are on Map, Context, String and a
>> client supplied classpath. Relative to the component the
>> dependency is on Phoneix and the A-F. GenericBlockContext provides
>> the bridge between the two.
>
>
>> Everything about this is solving a Phoneix issue. But, yes - the
>> solution can be included inside Merlin. Yes we can create
>> artificial depedencies between the Merlin Project and the Phoenix
>> Project. Yes we can oblige Merlin installations to include APIs to
>> another container for those occasions where the client is dealing
>> with Phoenix legacy and already have phoenix-client.jar in place.
>> Yes, we could write this up in the FAQ and explain why its a good
>> thing - but I may need some help on that!
>
>
> Refering to "..artificial dependencies between the Merlin Project and
> the Pheonix Project" and "..Phoenix legacy..":- Phoenix
> compatability is what we are talking about here unless I am wrong.
I believe it is the wrong focus.
The problem space concerns the use and deployment of Avalon components
arcross different containers. We are dealing with a "legacy of
components that have been build on the assumption of one container
called Phoenix". These components (such as Cornerstone and any other
component including Phoneix specific APIs - such as EOB) have to be
managed in a special way - in effect to take from Phoneix dependent to
being container independent via utilities. Within this scenario Merlin
is simply the container that is pushing the envelope - its raising the
issues of non-component portability. This isn't a Merlin thing - this is
a component-to-container contract thing. GenericBlockContext is utility
that addressed this isssue as it relates to legacy Phoenix components.
> It could be we are talking about Phoenix obsolesence (I am not).
Nobody is talking about Phoniex obsolesence. Pheonix is great - it
is a way cool product and the source for much of the design of Merlin.
Phoneix has features that may never exist in Merlin. Merlin has
features that may never exist in Phoniex. Please undertand that the
term "legacy" is complete appropriate when discussing the issue of
portable components relative to the component that exist today.
>
>
> We have an agreement a way forward for on the BlockContext issue. It
> is simply to include the BlockContext class (via phoenix-client.jar)
> in second and subsequent Phoenix compatible containers. Given
> K/HC/CAPI conversation of the past, and the need for separation of
> CAPI and K, GenericBlockContext in Phoenix CVS is the wrong solution,
> I think we all agree that. Given also that the home for
> GenericBlockContext is not certain (A-F is mooted above, but Phoenix
> is where it was added). Given also that the content of
> GenericBlockContext was nothing special - nothing that could not be
> added to another kernel's CVS tree.
I don't see how you reach the conclusion the GenericBlockContext could
live anywhere. It is completely related to Phoneix components - it is
unrelated to any other container. I know your thinking to yourself -
but Merlin is pushing it - and I'll re-state that this is only because
Merlin is iniative that is dealing with the portability issue - dealing
with territory that has not been tackled before within the Avalon community.
>
>
> My feeling is that this single issue is nothing to do with the
> attributes thread.
It has everything to do with the attribute thread.
With resolution of the attribute thread subject - component authors can
choose between a Phoenix dedicated component approach or a portable
component approach. You own work in EOB is currently depedent on
Phoenix as a container - you can choose to move to a container neutral
approach providing the attribute question is resolved. Resolving the
attributes issue immediately lowers the priority on something like
GenericBlockContext (GBC) because we could rapidly update cornerstone
and the need for GBC within Avalon becomes debatable. In the absence of
common attribute naming and semantics GBC is a necessity.
> That attributes need to be handled correctly designed properly and
> due consideration given to backards compatability is paramount. Can
> multiple containers handle attribute changes (well additions reeally)
> as they are rolled out? Yes, in my opinion. Should attribute
> strings be added to BlockContext, yes in my opinion.
>
> *** Vote *** As such, can we vote on the recommendation :
>
> (*) The Avalon team recommends that Phoenix compatile container
> include phoenix-client.jar in their distribution and make it visible
> to hosted components at runtime. The Avalon team recommends that
> Phoenix compatible containers hide their implementations of
> BlockContext in the kernel's classloader and further hide the impl
> via use of a Refelection's dynamic proxy.
>
>>>> Look at the Servlet/EJB/other APIs. They all follow this
>>>> pattern and I believe some (servlet API 2.1+) actually mandates
>>>> that no container specific classes can be in same classloader.
>>>
>>>
>>>
>>
>> Such a policy concerning Avalon containers is also appropriate. In
>> general we should not be exposing container specific APIs to
>> components. It locks the component to a particular container and
>> introduces the problems we are currently dealing with.
>
>
> For Phoenix, given its separation of interface and impl, it is only
> the word phoenix that is objectionable in the phoenix-client.jar and
> its attendant package names. If we had our time over we could have
> moved these classes to another tree/package. Like with othr packages
> in Avalon, we are keeping there where they are for compatability
> reasons. This line of discussion deviates from (*) above and its
> central discussion point alternatives for GenericBlockContext (being
> added to Phoenix CVS).
I disagree - the Framework is the source of the defintion of what a
component is. The Context class provides a container neural mechanism
to the values that are needed. This issue concerns the management of
components that are using the BlockContext interface in the absence of a
context management solution in Phoenix today.
* This has nothing to do with the framework
* This has nothing to do with Fortress
* This has nothing to do with Tweety
* This has nothing to do with Merlin
* This is related to Phoenix
* This has everything to do with components that tied to Phoneix
by the org.apache.avalon.phoniex.BlockContext interface
>
>
>>>> And we don't want to limit our evolution in future for so
>>>> little a gain as having a generic implementation. It is rare
>>>> that the implementations are more than 20-30 lines of code, so
>>>> I am not sure what the great technical difficulty is.
>>>>
>>> Err I agree with you Peter. The interface remains in
>>> phoenix-client.jar and the impl is left to the container in
>>> question. I think Stephen is coming round to the possibility of
>>> that fact.
>>
>>
>>
>>
>> I'm comming around to the conclusion that :
>>
>> 1. the first step is to resolve the context key issue
>>
>> - context keys are part of the Avalon component contract - contract
>> are intended to be maintained - solving this issue has to be
>> addressed as a higher priority than convinience interfaces, Phoenix
>> fixes, or other actions such as defining additional interfaces
>
>
> I completely disagree. We have got so far on the GenericBlockContext
> (the need for it in Phoenix CVS) issue. Please don't switch
> conversational threads when we are on the cusp of an agreement.
I don't think we are on a cusp of an agreement. GBC is a workaround.
Reoslution of the attributes issue elininates 95% of the need for the
workaround.
> Please let me tackle these issues one by one. I'll move on to
> attributes, meta info and other issues in time. It is important for a
> sense of progress during mediation to resolve an issue. Please try
> to meet me on this simple goal Stephen. Just because this is against
> you original posting of GenericBlockContext does not mean all things
> in this process are going to fall against you. Besides, you see the
> logic of the BlockContext argument don't you :-))
Any container with a half-reasonable context management solution will
need something like GBC to deal with components like the cornerstone
suite, unitil the attributes issue is resolved and the common model is
(a) implemented in Phoneix, and (b) Conerstone component's are
neutralized with respect to Phoneix as container.
I really think that resolution of the attribute issue is the issue that
needs to be dealt with in the short term.
Consider the following:
// Phoneix dependent version
File file = context.getWorkingDirectory();
// portable component version
File file = (File) context.get("avalon:home");
The attribute documentation over on
excalibur/container/src/xdocs/attributes.xml provides a good picture of
what's needed on common context keys.
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>
[Vote] GenericblockContext (was Re: BlockContext & Merlin).
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>>>>>>> 1) Merlin includes phoenix-client.jar and provides alternate
>>>>>>>> implemetations of the BlockContext interface.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thats the only real solution at this stage.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> There could be some reason why that is not possible.
>>>>>>
>>>>>
>>>>>
>>>>> It will become a lot more difficult in the future when classLoader and
>>>>> interceptor stuff get integrated but it should be possible to
>>>>> no-op those
>>>>> features - not sure.
>>>>>
>>>>
>>>>
>>>> Well let's tackle future features in the future. For now though I
>>>> think
>>>> that useing a Phoenix jar to be Phoenix compatible is perfectly
>>>> possible.
>>>>
>>>
>>>
>>>
>>> I am not sure what you are saying. If you want to implement
>>> BlockContext then that is fine but the implementation is inherently
>>> container specific. The implementation should not even be in the
>>> same classloader as the interface.
>>
>>
>
> The GenericBlockContext provides a solution for any Avalon container
> to workaround the Phoenix BlockContext dependency issue. It deals
> with the very situation you mention below - the inclusion of container
> specific APIs - in this case a Phoenix specific APIs.
> What GenericBlockContext does is to provide a mechanism for any
> container to be able to deal with the legacy of Phoenix dependent
> components that include references to the BlockContext interface. The
> implementation solves the problem by allowing a container to handle
> the association of keys and values using java.util.Map and the Context
> class. Boyond this it has to implement the BlockContext interface in
> order to solve the issue of Phoenix API exposure towards components.
> Relative to a container, the GenericBlockContext depedencies are on
> Map, Context, String and a client supplied classpath. Relative to the
> component the dependency is on Phoneix and the A-F.
> GenericBlockContext provides the bridge between the two.
> Everything about this is solving a Phoneix issue. But, yes - the
> solution can be included inside Merlin. Yes we can create artificial
> depedencies between the Merlin Project and the Phoenix Project. Yes
> we can oblige Merlin installations to include APIs to another
> container for those occasions where the client is dealing with Phoenix
> legacy and already have phoenix-client.jar in place. Yes, we could
> write this up in the FAQ and explain why its a good thing - but I may
> need some help on that!
Refering to "..artificial dependencies between the Merlin Project and
the Pheonix Project" and "..Phoenix legacy..":- Phoenix compatability is
what we are talking about here unless I am wrong. It could be we are
talking about Phoenix obsolesence (I am not).
We have an agreement a way forward for on the BlockContext issue. It is
simply to include the BlockContext class (via phoenix-client.jar) in
second and subsequent Phoenix compatible containers. Given K/HC/CAPI
conversation of the past, and the need for separation of CAPI and K,
GenericBlockContext in Phoenix CVS is the wrong solution, I think we all
agree that. Given also that the home for GenericBlockContext is not
certain (A-F is mooted above, but Phoenix is where it was added). Given
also that the content of GenericBlockContext was nothing special -
nothing that could not be added to another kernel's CVS tree.
My feeling is that this single issue is nothing to do with the
attributes thread. That attributes need to be handled correctly
designed properly and due consideration given to backards compatability
is paramount. Can multiple containers handle attribute changes (well
additions reeally) as they are rolled out? Yes, in my opinion. Should
attribute strings be added to BlockContext, yes in my opinion.
*** Vote ***
As such, can we vote on the recommendation :
(*) The Avalon team recommends that Phoenix compatile container include
phoenix-client.jar in their distribution and make it visible to hosted
components at runtime. The Avalon team recommends that Phoenix
compatible containers hide their implementations of BlockContext in the
kernel's classloader and further hide the impl via use of a
Refelection's dynamic proxy.
>>> Look at the Servlet/EJB/other APIs. They all follow this pattern and
>>> I believe some (servlet API 2.1+) actually mandates that no
>>> container specific classes can be in same classloader.
>>
>>
>
> Such a policy concerning Avalon containers is also appropriate. In
> general we should not be exposing container specific APIs to
> components. It locks the component to a particular container and
> introduces the problems we are currently dealing with.
For Phoenix, given its separation of interface and impl, it is only the
word phoenix that is objectionable in the phoenix-client.jar and its
attendant package names. If we had our time over we could have moved
these classes to another tree/package. Like with othr packages in
Avalon, we are keeping there where they are for compatability reasons.
This line of discussion deviates from (*) above and its central
discussion point alternatives for GenericBlockContext (being added to
Phoenix CVS).
>>> And we don't want to limit our evolution in future for so little a
>>> gain as having a generic implementation. It is rare that the
>>> implementations are more than 20-30 lines of code, so I am not sure
>>> what the great technical difficulty is.
>>>
>> Err I agree with you Peter. The interface remains in
>> phoenix-client.jar and the impl is left to the container in
>> question. I think Stephen is coming round to the possibility of that
>> fact.
>
>
>
> I'm comming around to the conclusion that :
>
> 1. the first step is to resolve the context key issue
>
> - context keys are part of the Avalon component contract
> - contract are intended to be maintained
> - solving this issue has to be addressed as a higher
> priority than convinience interfaces, Phoenix fixes,
> or other actions such as defining additional
> interfaces
I completely disagree. We have got so far on the GenericBlockContext
(the need for it in Phoenix CVS) issue. Please don't switch
conversational threads when we are on the cusp of an agreement. Please
let me tackle these issues one by one. I'll move on to attributes, meta
info and other issues in time. It is important for a sense of progress
during mediation to resolve an issue. Please try to meet me on this
simple goal Stephen. Just because this is against you original posting
of GenericBlockContext does not mean all things in this process are
going to fall against you. Besides, you see the logic of the
BlockContext argument don't you :-))
- Pau
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Peter,
>
>>>>>>> 1) Merlin includes phoenix-client.jar and provides alternate
>>>>>>> implemetations of the BlockContext interface.
>>>>>>>
>>>>>>
>>>>>> Thats the only real solution at this stage.
>>>>>>
>>>>>
>>>>> There could be some reason why that is not possible.
>>>>>
>>>>
>>>> It will become a lot more difficult in the future when classLoader and
>>>> interceptor stuff get integrated but it should be possible to no-op
>>>> those
>>>> features - not sure.
>>>>
>>>
>>> Well let's tackle future features in the future. For now though I
>>> think
>>> that useing a Phoenix jar to be Phoenix compatible is perfectly
>>> possible.
>>>
>>
>>
>> I am not sure what you are saying. If you want to implement
>> BlockContext then that is fine but the implementation is inherently
>> container specific. The implementation should not even be in the same
>> classloader as the interface.
>
The GenericBlockContext provides a solution for any Avalon container to
workaround the Phoenix BlockContext dependency issue. It deals with the
very situation you mention below - the inclusion of container specific
APIs - in this case a Phoenix specific APIs.
What GenericBlockContext does is to provide a mechanism for any
container to be able to deal with the legacy of Phoenix dependent
components that include references to the BlockContext interface. The
implementation solves the problem by allowing a container to handle the
association of keys and values using java.util.Map and the Context
class. Boyond this it has to implement the BlockContext interface in
order to solve the issue of Phoenix API exposure towards components.
Relative to a container, the GenericBlockContext depedencies are on Map,
Context, String and a client supplied classpath. Relative to the
component the dependency is on Phoneix and the A-F. GenericBlockContext
provides the bridge between the two.
Everything about this is solving a Phoneix issue. But, yes - the
solution can be included inside Merlin. Yes we can create artificial
depedencies between the Merlin Project and the Phoenix Project. Yes we
can oblige Merlin installations to include APIs to another container for
those occasions where the client is dealing with Phoenix legacy and
already have phoenix-client.jar in place. Yes, we could write this up
in the FAQ and explain why its a good thing - but I may need some help
on that!
>>
>> Look at the Servlet/EJB/other APIs. They all follow this pattern and
>> I believe some (servlet API 2.1+) actually mandates that no container
>> specific classes can be in same classloader.
>
Such a policy concerning Avalon containers is also appropriate. In
general we should not be exposing container specific APIs to components.
It locks the component to a particular container and introduces the
problems we are currently dealing with.
>>
>> And we don't want to limit our evolution in future for so little a
>> gain as having a generic implementation. It is rare that the
>> implementations are more than 20-30 lines of code, so I am not sure
>> what the great technical difficulty is.
>>
> Err I agree with you Peter. The interface iremains in
> phoenix-client.jar and the impl is left to the container in question.
> I think Stephen is comping round to the possibility of that fact.
I'm comming around to the conclusion that :
1. the first step is to resolve the context key issue
- context keys are part of the Avalon component contract
- contract are intended to be maintained
- solving this issue has to be addressed as a higher
priority than convinience interfaces, Phoenix fixes,
or other actions such as defining additional
interfaces
2. and that we should recognize that these issues are directly
attributed to the exposure of container specific APIs
- this can be addressed within Phoenix
- this can be corrected within Cornerstone
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: BlockContext & Merlin.
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>>>>1) Merlin includes phoenix-client.jar and provides alternate
>>>>>>implemetations of the BlockContext interface.
>>>>>>
>>>>>>
>>>>>Thats the only real solution at this stage.
>>>>>
>>>>>
>>>>There could be some reason why that is not possible.
>>>>
>>>>
>>>It will become a lot more difficult in the future when classLoader and
>>>interceptor stuff get integrated but it should be possible to no-op those
>>>features - not sure.
>>>
>>>
>>Well let's tackle future features in the future. For now though I think
>>that useing a Phoenix jar to be Phoenix compatible is perfectly possible.
>>
>>
>
>I am not sure what you are saying. If you want to implement BlockContext then
>that is fine but the implementation is inherently container specific. The
>implementation should not even be in the same classloader as the interface.
>
>Look at the Servlet/EJB/other APIs. They all follow this pattern and I believe
>some (servlet API 2.1+) actually mandates that no container specific classes
>can be in same classloader.
>
>And we don't want to limit our evolution in future for so little a gain as
>having a generic implementation. It is rare that the implementations are more
>than 20-30 lines of code, so I am not sure what the great technical
>difficulty is.
>
Err I agree with you Peter. The interface iremains in
phoenix-client.jar and the impl is left to the container in question. I
think Stephen is comping round to the possibility of that fact.
>>>>Personally I like this solution best. Why? I have beans with EOB, and if
>>>>I get back to it Jesktop-applets that could also be contextualizable.
>>>>JAMES has maillets and one day newslets. FtpServer might one day have
>>>>FtpLets. If all these were Contextualizable woulldn't it be nice is one
>>>>Component could run in multiple containers, and adapt its duties to that
>>>>container. For example a single comp that was both a Mailet and a
>>>>EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
>>>>need.
>>>>
>>>>
>>>It is a goal and thats what I am moving towards with the ContainerKit
>>>stuff.
>>>
>>>
>>Bllimey, I thought'd you'd shoot that down as inpossible dream ;-)
>>
>>
>
>Naah :)
>
>Have a look at Microsofts "attribute-driven" programming style that is part of
>dot net. I have not looked at implementation details mainly just
>research+white papers about it. Thats where I want a lot of avalon stuff to
>go in the future. It is a brilliant concept when used appropriately.
>
>
That's what everyone is saying. Expect .Net inspired atributes to
arrive in Java3.
>Essentially every component/service/object is handled identically. The magic
>comes from the metadata that is stored along with the object.
>
>In avalon terms this means marking each method/class with xdoclet attributes.
>We could mark a method with "avalon.remote=true".
>
Same as .Net. Cool. For us it is xdoclet today with a concrete impl
for Java3.
>This would indicate to the
>container that it is capable of being remoted via altrmi, soap, rmi or
>whatever. We could also look for other attributes like "avalon.stateless",
>"avalon.multiclient" and "avalon.threadsafe". Depending on the values of
>these attributes, the component could be equivelent to stateless session
>bean, or stateful session bean, a remoted singleton or whatever.
>
>The way the object is treated is essentially a combination of;
>* the extra metadata it encodes
>* the metadata that the container supports
>
>So you could add transaction, persistence, security, remoting, replication,
>pooling, <insert favourite aspect here> etc with a few metadata entries.
>
>While the above is largely talking about "service" orientated attributes, it
>can also be used in Model Driven development. For example, my latest contract
>is basically a frontend to a non-j2ee distributed management system (jsp,
>struts, taglibs, sitemesh, etc). In it, each buisness object is represented
>on multiple layers;
>* as a struts form object
>* as a commons/struts DynaBean (mainly for auxilliary tag libraries)
>* as a client-server Data Transfer Object (DTO)
>* as a DAO
>* as a inter-server DTO
>* as XML readers/writers
>etc.
>
>Each BusObj also has a whole host of UI arterfacts and screens (table views,
>editing forms, version history etc).
>
>Trying to develope all this code using traditional processes was scheduled at
>about 8 months work. We had just under 2 months :)
>
>So what I did was essentially describe the object model in xml like
>
><object name="nzUser"
> display-name="User"
> validator="com.biz.UserValidator"
> view-rank="3">
> <property name="username"
> type="String"
> key-part="true"/>
> <property name="pent_id"
> type="Integer"
> immutable="true"
> dto="none"
> hidden="true"/>
> <property name="password"
> type="Password"/>
> ...
> etc
> ...
> <relationship to="Role" via="username"/>
></object>
>
>So each object contains
>* a set of object attributes
>* a set of propertys
>* a set of relationships
>
>Each property contains
>* a name
>* a type
>* a set of property attributes
>
>Each relationship contains
>* a destination schema
>* optionally a via and multiplicity
>* a set of property attributes
>
>In each case the attributes are the magic interpted by an appropriate
>"engine". ie I end up having only about 18 jsps (thank god!), rather than
>120+. Which attributes are editable, immutable, displayed and so forth is all
>defined by their metadata rather than by any harcoding.
>
>The struts/taglib portion only deals with attributes it knows about, while the
>DTO builders only deal with attributes they know about, while the database
>layer only deals with attributes it knows about.
>
>Anyways it has made it possible for us to get the majority of GUI,
>persistence, distribution and all the rest of the "grunt" programming out of
>the way in 2 weeks! Now all we have to do is the actual buisness logic, 8
>months be damned ;)
>
>You will notice that this is the same approach that a lot of new toolkits are
>heading. Especially a lot of new toolkits that describe the model in UML +
>magic attributes (are they called tags in UML?) and allow you to generate a
>whole application setup (though most use icky code generation). This is a
>partially a result of the difficulty of J2EE and the need to move between 2
>tier and multi-tier dev platforms.
>
>Anyways thats my latest kick. If you are familiar with torque, it sort of does
>the model driven approach for one aspect of program (persistence and data
>migration). It uses code generation because it only covers once aspect but it
>is still great.
>
>Anyways thats one of the very very attractive ideas I want to explore in the
>next year or two with avalon stuff. (Or at least the service side of
>attribute driven dev).
>
>Can you imagine the ease of this if we ever achieved it?
>* Service Orientated Programming + Attribute driven framework
>* Model Driven development + Attribute driven framework
>
>I think the above is largely achievable (even if not in a a completely generic
>fashion for MDD).
>
>If someone was to come up with a decent process/workflow system (I haven't
>ever seen anything that is vaguely close to being viable) then it would make
>development soooooooooo much easier - essentially just coding in buisness
>rules and maybe engines to interpret the model.
>
>Anyways I believe I be gushing ;)
>
>
Sigh, will this commercial effort ever be open-sourced?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Attribute-oriented Programming (Re: BlockContext & Merlin.)
Posted by Leo Simons <le...@apache.org>.
> > >>Personally I like this solution best. Why? I have beans with EOB, and if
> > >>I get back to it Jesktop-applets that could also be contextualizable.
> > >> JAMES has maillets and one day newslets. FtpServer might one day have
> > >>FtpLets. If all these were Contextualizable woulldn't it be nice is one
> > >>Component could run in multiple containers, and adapt its duties to that
> > >>container. For example a single comp that was both a Mailet and a
> > >>EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
> > >>need.
> > >
> > >It is a goal and thats what I am moving towards with the ContainerKit
> > > stuff.
> >
> > Bllimey, I thought'd you'd shoot that down as inpossible dream ;-)
>
> Naah :)
>
> Have a look at Microsofts "attribute-driven" programming style that is part of
> dot net. I have not looked at implementation details mainly just
> research+white papers about it.
me too (still waiting on books...damned amazon ;)
> Thats where I want a lot of avalon stuff to
> go in the future. It is a brilliant concept when used appropriately.
definately. The single good bit of VB (as in Visual Basic, not Victoria
Bitter...I miss Oz :) extracted out ;)
> In avalon terms this means marking each method/class with xdoclet attributes.
> We could mark a method with "avalon.remote=true". This would indicate to the
> container that it is capable of being remoted via altrmi, soap, rmi or
> whatever. We could also look for other attributes like "avalon.stateless",
> "avalon.multiclient" and "avalon.threadsafe". Depending on the values of
> these attributes, the component could be equivelent to stateless session
> bean, or stateful session bean, a remoted singleton or whatever.
hmm. This is implementation stuff, I guess, but I like using XML for
metadata. It fits well.
> While the above is largely talking about "service" orientated attributes, it
> can also be used in Model Driven development.
you know what I'd like to see? One of the avalon architecture gurus (you
know who you are) writing a paper on how avalon relates to/facilitates
MDD...
> Anyways thats one of the very very attractive ideas I want to explore in the
> next year or two with avalon stuff. (Or at least the service side of
> attribute driven dev).
I'd like to see all that...but I'm also considering the fact that we
might end up coding to .net...so am looking at ways to steal ideas from
that rather than doing it ourselves...but I guess that's the attitude of
most people around here?
> If someone was to come up with a decent process/workflow system (I haven't
> ever seen anything that is vaguely close to being viable) then it would make
> development soooooooooo much easier - essentially just coding in buisness
> rules and maybe engines to interpret the model.
maybe in 20 years or so....imagine the terribly high programmer
unemployment rate that results though ;)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Sun, 25 Aug 2002 19:01, Paul Hammant wrote:
> >>>>1) Merlin includes phoenix-client.jar and provides alternate
> >>>>implemetations of the BlockContext interface.
> >>>
> >>>Thats the only real solution at this stage.
> >>
> >>There could be some reason why that is not possible.
> >
> >It will become a lot more difficult in the future when classLoader and
> >interceptor stuff get integrated but it should be possible to no-op those
> >features - not sure.
>
> Well let's tackle future features in the future. For now though I think
> that useing a Phoenix jar to be Phoenix compatible is perfectly possible.
I am not sure what you are saying. If you want to implement BlockContext then
that is fine but the implementation is inherently container specific. The
implementation should not even be in the same classloader as the interface.
Look at the Servlet/EJB/other APIs. They all follow this pattern and I believe
some (servlet API 2.1+) actually mandates that no container specific classes
can be in same classloader.
And we don't want to limit our evolution in future for so little a gain as
having a generic implementation. It is rare that the implementations are more
than 20-30 lines of code, so I am not sure what the great technical
difficulty is.
> >>Personally I like this solution best. Why? I have beans with EOB, and if
> >>I get back to it Jesktop-applets that could also be contextualizable.
> >> JAMES has maillets and one day newslets. FtpServer might one day have
> >>FtpLets. If all these were Contextualizable woulldn't it be nice is one
> >>Component could run in multiple containers, and adapt its duties to that
> >>container. For example a single comp that was both a Mailet and a
> >>EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
> >>need.
> >
> >It is a goal and thats what I am moving towards with the ContainerKit
> > stuff.
>
> Bllimey, I thought'd you'd shoot that down as inpossible dream ;-)
Naah :)
Have a look at Microsofts "attribute-driven" programming style that is part of
dot net. I have not looked at implementation details mainly just
research+white papers about it. Thats where I want a lot of avalon stuff to
go in the future. It is a brilliant concept when used appropriately.
Essentially every component/service/object is handled identically. The magic
comes from the metadata that is stored along with the object.
In avalon terms this means marking each method/class with xdoclet attributes.
We could mark a method with "avalon.remote=true". This would indicate to the
container that it is capable of being remoted via altrmi, soap, rmi or
whatever. We could also look for other attributes like "avalon.stateless",
"avalon.multiclient" and "avalon.threadsafe". Depending on the values of
these attributes, the component could be equivelent to stateless session
bean, or stateful session bean, a remoted singleton or whatever.
The way the object is treated is essentially a combination of;
* the extra metadata it encodes
* the metadata that the container supports
So you could add transaction, persistence, security, remoting, replication,
pooling, <insert favourite aspect here> etc with a few metadata entries.
While the above is largely talking about "service" orientated attributes, it
can also be used in Model Driven development. For example, my latest contract
is basically a frontend to a non-j2ee distributed management system (jsp,
struts, taglibs, sitemesh, etc). In it, each buisness object is represented
on multiple layers;
* as a struts form object
* as a commons/struts DynaBean (mainly for auxilliary tag libraries)
* as a client-server Data Transfer Object (DTO)
* as a DAO
* as a inter-server DTO
* as XML readers/writers
etc.
Each BusObj also has a whole host of UI arterfacts and screens (table views,
editing forms, version history etc).
Trying to develope all this code using traditional processes was scheduled at
about 8 months work. We had just under 2 months :)
So what I did was essentially describe the object model in xml like
<object name="nzUser"
display-name="User"
validator="com.biz.UserValidator"
view-rank="3">
<property name="username"
type="String"
key-part="true"/>
<property name="pent_id"
type="Integer"
immutable="true"
dto="none"
hidden="true"/>
<property name="password"
type="Password"/>
...
etc
...
<relationship to="Role" via="username"/>
</object>
So each object contains
* a set of object attributes
* a set of propertys
* a set of relationships
Each property contains
* a name
* a type
* a set of property attributes
Each relationship contains
* a destination schema
* optionally a via and multiplicity
* a set of property attributes
In each case the attributes are the magic interpted by an appropriate
"engine". ie I end up having only about 18 jsps (thank god!), rather than
120+. Which attributes are editable, immutable, displayed and so forth is all
defined by their metadata rather than by any harcoding.
The struts/taglib portion only deals with attributes it knows about, while the
DTO builders only deal with attributes they know about, while the database
layer only deals with attributes it knows about.
Anyways it has made it possible for us to get the majority of GUI,
persistence, distribution and all the rest of the "grunt" programming out of
the way in 2 weeks! Now all we have to do is the actual buisness logic, 8
months be damned ;)
You will notice that this is the same approach that a lot of new toolkits are
heading. Especially a lot of new toolkits that describe the model in UML +
magic attributes (are they called tags in UML?) and allow you to generate a
whole application setup (though most use icky code generation). This is a
partially a result of the difficulty of J2EE and the need to move between 2
tier and multi-tier dev platforms.
Anyways thats my latest kick. If you are familiar with torque, it sort of does
the model driven approach for one aspect of program (persistence and data
migration). It uses code generation because it only covers once aspect but it
is still great.
Anyways thats one of the very very attractive ideas I want to explore in the
next year or two with avalon stuff. (Or at least the service side of
attribute driven dev).
Can you imagine the ease of this if we ever achieved it?
* Service Orientated Programming + Attribute driven framework
* Model Driven development + Attribute driven framework
I think the above is largely achievable (even if not in a a completely generic
fashion for MDD).
If someone was to come up with a decent process/workflow system (I haven't
ever seen anything that is vaguely close to being viable) then it would make
development soooooooooo much easier - essentially just coding in buisness
rules and maybe engines to interpret the model.
Anyways I believe I be gushing ;)
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>>1) Merlin includes phoenix-client.jar and provides alternate
>>>>implemetations of the BlockContext interface.
>>>>
>>>>
>>>Thats the only real solution at this stage.
>>>
>>>
>>There could be some reason why that is not possible.
>>
>>
>
>It will become a lot more difficult in the future when classLoader and
>interceptor stuff get integrated but it should be possible to no-op those
>features - not sure.
>
Well let's tackle future features in the future. For now though I think
that useing a Phoenix jar to be Phoenix compatible is perfectly possible.
>>>>2) Change cornerstone comps to use Context as is, and access things via
>>>>'Object get(Object)'
>>>>
>>>>
>>>This may work for somethings but the key will change in the future. This
>>>wont work for somethings - especially once interceptors are integrated
>>>properly.
>>>
>>>
>>The key will change one the Attribute thread/discussion is completed?
>> If yes, then that is not too far away right?
>>
>>
>
>It will happen when I integrate containerkit into Phoenix. That will happen
>when it is ready. There is still a bit of work to do before that happens
>(mainly experimentation). I want to get at least the skeleton of HPs CSF
>structure in place and tested (mainly hierarchial Partiions and associated
>execution contexts).
>
>
OK, We'll look forward to the attribute designs..
>>Personally I like this solution best. Why? I have beans with EOB, and if
>>I get back to it Jesktop-applets that could also be contextualizable.
>> JAMES has maillets and one day newslets. FtpServer might one day have
>>FtpLets. If all these were Contextualizable woulldn't it be nice is one
>>Component could run in multiple containers, and adapt its duties to that
>>container. For example a single comp that was both a Mailet and a
>>EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
>>need.
>>
>>
>
>It is a goal and thats what I am moving towards with the ContainerKit stuff.
>
>
Bllimey, I thought'd you'd shoot that down as inpossible dream ;-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Peter Donald <pe...@apache.org>.
On Sun, 25 Aug 2002 05:20, Paul Hammant wrote:
> >>1) Merlin includes phoenix-client.jar and provides alternate
> >>implemetations of the BlockContext interface.
> >
> >Thats the only real solution at this stage.
>
> There could be some reason why that is not possible.
It will become a lot more difficult in the future when classLoader and
interceptor stuff get integrated but it should be possible to no-op those
features - not sure.
> >>2) Change cornerstone comps to use Context as is, and access things via
> >>'Object get(Object)'
> >
> >This may work for somethings but the key will change in the future. This
> > wont work for somethings - especially once interceptors are integrated
> > properly.
>
> The key will change one the Attribute thread/discussion is completed?
> If yes, then that is not too far away right?
It will happen when I integrate containerkit into Phoenix. That will happen
when it is ready. There is still a bit of work to do before that happens
(mainly experimentation). I want to get at least the skeleton of HPs CSF
structure in place and tested (mainly hierarchial Partiions and associated
execution contexts).
> Personally I like this solution best. Why? I have beans with EOB, and if
> I get back to it Jesktop-applets that could also be contextualizable.
> JAMES has maillets and one day newslets. FtpServer might one day have
> FtpLets. If all these were Contextualizable woulldn't it be nice is one
> Component could run in multiple containers, and adapt its duties to that
> container. For example a single comp that was both a Mailet and a
> EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
> need.
It is a goal and thats what I am moving towards with the ContainerKit stuff.
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>1) Merlin includes phoenix-client.jar and provides alternate
>>implemetations of the BlockContext interface.
>>
>>
>
>Thats the only real solution at this stage.
>
There could be some reason why that is not possible.
>>2) Change cornerstone comps to use Context as is, and access things via
>>'Object get(Object)'
>>
>>
>
>This may work for somethings but the key will change in the future. This wont
>work for somethings - especially once interceptors are integrated properly.
>
The key will change one the Attribute thread/discussion is completed?
If yes, then that is not too far away right?
Personally I like this solution best. Why? I have beans with EOB, and if
I get back to it Jesktop-applets that could also be contextualizable.
JAMES has maillets and one day newslets. FtpServer might one day have
FtpLets. If all these were Contextualizable woulldn't it be nice is one
Component could run in multiple containers, and adapt its duties to that
container. For example a single comp that was both a Mailet and a
EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven
need.
>>3) Create a new interface in A-F called say DirectoryNamedContext. It
>>has the two methods in BlockContext and extends Context. BlockContext
>>extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is
>>able to trade without reference to Phoenix. Adding an interface in this
>>way, as we all know is a backwards compatible thing.
>>
>>
>
>Fails to add value.
>
package org.apache.avalon.framework.context;
public interface Context {
Object get( Object key ) throws ContextException;
}
package org.apache.avalon.framework.context;
public interface DirectoryNamedContext extends Context {
String APP_NAME = "app.name";
String APP_HOME_DIR = "app.home";
String NAME = "block.name";
File getBaseDirectory();
String getName();
}
package org.apache.avalon.phoenix;
public interface BlockContext extends DirectoryNamedContext {
}
I'm not so sure. As a place for a strong interface solution to
Stephen's needs, that negates the need for him to include the (albeit
small) phoenix-client.jar in Merlin's distro.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext & Merlin.
Posted by Peter Donald <pe...@apache.org>.
On Sat, 24 Aug 2002 22:12, Paul Hammant wrote:
> 1) Merlin includes phoenix-client.jar and provides alternate
> implemetations of the BlockContext interface.
Thats the only real solution at this stage.
> 2) Change cornerstone comps to use Context as is, and access things via
> 'Object get(Object)'
This may work for somethings but the key will change in the future. This wont
work for somethings - especially once interceptors are integrated properly.
> 3) Create a new interface in A-F called say DirectoryNamedContext. It
> has the two methods in BlockContext and extends Context. BlockContext
> extends it. Cornerstone comps drop to DirectoryNamedContext. Merlin is
> able to trade without reference to Phoenix. Adding an interface in this
> way, as we all know is a backwards compatible thing.
Fails to add value.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>