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/26 13:37:10 UTC
[Vote] GenericblockContext (was Re: BlockContext & Merlin).
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: [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 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 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>.
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 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 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>.
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 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 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>