Stephen McConnell wrote:
Vadim Gritsenko wrote:Stephen McConnell wrote:Vadim Gritsenko wrote:...Why deprecating this interface in the first place? I don't see how presence of (non-deprecated) Component interface may impose limitations on Avalon's future.
Its a massive obsticle.
Imagie you are dealing with code that has nothing to do with Avalon - your building real components - but the only difference is that they don't implement org.apache.avalon.framework.componet.Component (which contains no method declarations or static declarations - nothing). This means that any component developed outside of the Avalon sphere of influence is not a component. That is unreastic and irratrional. This means that the hunreds of standard compoents (refer OMG work) are nbot realy components. This means that unless I incorporatye this particular interface I cannot interoperate in a Avalon framework. That's what is wrong with Componet - it locks you into Avalon. The truth (and the reason for the Service4 package) is that you don't need lock in - you need liberty.
Cheers, Steve.
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.
For a library (like FOP, Batik) lock-in in some, say, specific logging package is a really bad thing - imaging if you have to have 5-6 different logging systems. But I don't think it is equally bad for the *framework*. Some parallels, if I may:
"Lock-in on HttpServlet and the related classes (HttpSerlvetRequest, HttpServletResponse, ServletContext, etc. is basically a bad thing."
"Lock-in on SessionBean and the related classes (SessionContext, EJBObject, EJBHome, etc. is basically a bad thing."
I can continue ;-)
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.
But that means lock-in into ServiceManager (or whatever) and friends - isn't it?
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.
If change is search/replace Component -> Service, then it's easy, no doubt.
As concerns justification - my background is strongly aligned with international standards - and guess what - they
"standards"... "they"... Uhm... Hint, please?
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.
So, can you now declare JDBC driver as ComponentSelector (or-how-it-is-called-now) and Connection as poolable resource? (iirc, here comes marker interfaces -> meta data migration?)
Over to you!
Thanks for the explanations :) Vadim
Cheers, Steve.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
