cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Component deprecation warnings (Re: What is a Parser?)
Date Thu, 30 Jan 2003 03:13:48 GMT
On Thu, Jan 30, 2003 at 03:22:50AM +0100, Stephen McConnell wrote:
> Vadim Gritsenko wrote:
> >I kind of understand this part about bringing non-avalon components 
> >into Avalon, and also I don't completely agree with this (without 
> >further thinking), my question was a bit about different thing. Your 
> >argumentation can justify redefenition of "Avalon Component" term to 
> >include all Objects. But why deprecate all existing Avalon Components 
> >(now you have to go and fix'em all and fix all your containers which 
> >expect Component - Cocoon's case) by deprecating Component interface? 
> >I mean, you can extend definition of component and include all this 
> >non-Avalon thingies out there (if you see that it's possible and adds 
> >value), but this by itself does not require deprecation of Component 
> >interface. Which means, there is something more to it... 
> Lock-in on Component and the related classes (ComponentManger, 
> ComponentException, ComponetSelector, etc. is basically a bad thing.  
> The service package provides a parallel solution that does not lock you 
> into Avalon.  All it requires in that someone takes care of the 
> transition.   ComponentXxxxxx gets relpleaces by ServiceXxxxx - and 
> Composable by Servicable. I did the transition on my own stuff (which is 
> bigger than Cocoon and it took me half a day - James took two hours).  
> Cocoon needs someone to do the job of transition.
> As concerns justification - my background is strongly aligned with 
> international standards - and guess what - they don't declare standard 
> components via org.apache.avalon.framework.component.Component.  This is 
> nothing more that an artificial limitation on your developers.  If you 
> want to introduce a JDBC driver as a component - you cannot because it 
> does not implement Component - there is something wrong in that equation 
> - Avalon is a framework - it is not the global definition of Component. 
> Avalon 4.1.3 is an open solution - all you need to do is choose between 
> liberty and proprietary.
> Over to you!

But this is arguing for the carrot when someone complains about the

Clearly there are advantages of Serviceable, but they seem totally
independent of whether Component has a @deprecated tag or not.  When I
boot my Win95 box, I don't get a popup warning me that it's obsolete.


 - cocoon-dev should call for volunteers to Serviceable'ize the codebase.
   If none come forward before beta, use a recompiled Framework without
   the @deprecated
 - avalon-dev should consider if the stick (@deprecated) is really
   necessary, if the carrot (eliminating the Component interface) is so


> Cheers, Steve.

To unsubscribe, e-mail:
For additional commands, email:

View raw message