avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [ISSUE] containerkit
Date Thu, 04 Jul 2002 04:41:01 GMT

Peter Donald wrote:

> At 04:26 AM 7/4/2002 +0200, you wrote:
>>> I have no problem with that - it can't hurt me if it is container 
>>> specific. Stephen however wants to force everyone else to adopt his 
>>> model.
>> No I don't - all I'm asking for is the hook.
>> What I want is that you add the following operation to 
>> ComponentMetaData:
>>     /**
>>      * Returns the context object for the component.
>>      * @param parent the parent context
>>      * @return the context object to be supplied
>>      */
>>      public Context getContext( Context parent )
>>     {
>>          return context;
>>     }
> * which of course will only be used by Merlin. 

No Pete - think about it.  CompontMetaData is holding the state 
information for parameters and configuration. Different contains can use 
services that prepare CompontMetaData and if they access this via 
CompontMetaData, then at least we have a common mechanisms for extension 
without having different contains narrowing to some specific service 
just to get a compliant context.

> * which also changes a passive object into an active object 

You have repeatedly said that CompontMetaData is extendable.  You have 
lots of emails on this subject - the reason why, potential approaches, 
impact of failing to address this, etc.  Could you try to be a little 
more constructive - if you don't like it then propose something else 
that address the issue. If you don't feel included to put in the time 
and effort in that then leave it to others.  After all - this is a 
collaborative process .... isn't it?

> * which could be implemented in Merlin without effecting any of the 
> other containers 

Pete - for the last time will you please go back and read the email on 
this topic.  Yes is can be implemented by Merlin.  You know very well it 
is already implemented by Merlin.  Why is it implemented by Merlin - 
because Merlin is concerned with generic component deployment - not just 
Pete's personal portfolio of interest.  I want Cocoon components to run 
in Merlin, I want Merlin components to in Phoenix - your position will 
ensure that this never happens without the existence of container 
adapters in every container - which will not happen - which means no 

>>> The problem is Stephen wants add it to ComponentMetaData and thus 
>>> force all containers to use a single method for constructing context 
>>> - despite the fact that this wont work in any existing container 
>>> except Merlin .... hmmm.
>> NO NO NO &%#####**!£$%^&
>> I would like to see different containers using containerkit.  I would 
>> prefer that the center of interoperability is based on containerkit. 
>> I've provided several examples of why containerkit breaks this for 
>> existing components and goes against the general component model as 
>> documeted.  I've provided info on how an implementation can address 
>> this in response to your claims that it is impossible.  I've put up 
>> with being accused of of having an IQ in the single digit range, 
>> accused of strange and amazing anti-component practices, I'm now 
>> accused of attempting to force a solution!  Please keep in mind that 
>> your objection to the original proposal of a accessor to context was 
>> on the grounds that (a) it was exclusively a container concern, 
>> following which you raised the assertion was made that it was 
>> impossible anyway (leading to a lot of explanitory emails explaining 
>> how it is possible).
> Containerkit is about consolidating practices in containerkit. What 
> you propose is not common through containers, and can be implemented 
> fine in any particular container. You notice there is also no 
> ConfigurationSchema/ParametersSchema or LoggerMetaData or anything 
> like that. 

Come on - try a little harder.  Configuration and Parameters don't have 
an explicit ContextDescriptor that declares constraints.  Please - if 
you going to be difficult then at least put the time and effort into 
addressing the issue. You are sating that as far a potable container is 
concerned - context is out of bounds. and yet you include a context 
constraint criteria.  You then argue that the context constraint 
criteria is great (because you are the author) - and then you object to 
any possibility of a container neutral approach to a mechanisms to meet 
that criteria. 

You justify this bizarre idea on the grounds of personal attacks, 
technical impossibilities, false assertions of forced conditions on 
implementation, and now it gets even worse - your proposing that 
containerkit is reflecting a recommended practice of neglecting existing 
implementations and users and ignoring what exists in the framework 
today.  I really don't want bother with it any more - you have decided 
that this is not an issue and it does not matter when anyone says.  You 
will not even bother to even try to understand the issue -- all it means 
is that containerkit is NOT a portability platform - its Pete's 
architectural masturbation which at the end of the day may be the 
abstract foundation to something else that delivers the real solution.



Stephen J. McConnell

digital products for a global economy

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

View raw message