avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Map and Array Dependencies
Date Tue, 01 Oct 2002 09:30:18 GMT


> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> On Tue, 2002-10-01 at 10:26, Peter Donald wrote:
> > Any other comments?
> 
> This adds additional semantic meaning to the lookup key, 
> modifying the sm contract.

No - see Peter's reply to me.

> This makes your components (atm) 
> phoenix-specific, it is also the way to a dll-like-hell if we 
> keep adding meaning to core contracts that wasn't there before.
> 
> What if I have an application deployed in phoenix 4.0 that 
> just happens to postfix about half of its components with 
> "#"? It will break in the next release. Granted, what are the 
> chances....but the thing with contracts is you should be 
> really strict about them.
> 
> We could do the whole yada-yada on this again....
> 
> I'm not going to throw a -1 at it because I don't really feel 
> like having to go over exactly the same discussions again. I 
> feel like doing so though.
> 
> Anyway, it makes me more sure that the only way to have 
> avalon survive is to define that the minimum contracts 
> defined in avalon framework are also the maximum ones........

Yes, but we repeatedly slam into discovering that the 
contracts we specify aren't enough.

Simply put - Avalon as it is is not mature enough to fulfill
its intended scope.

We can keep trying to come up with the ultimate container,
but since no one of us knows what that container would need
for a feature set, we keep having diverging implementations
as each developer tries to solve his own problems.

Good parts: It means that the framework is indeed evolving.

Bad parts: Avalon as a dependency is less attractive.

Again, I think the component portability has to be abandoned
in favor of a JNDI publishing solution with containers that can
export and import components from JNDI in a uniform way. That
would accommodate the current shear we have in interpreting the 
contracts.

/LS


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


Mime
View raw message