Vadim Gritsenko wrote:
Berin Loritsch wrote:Jeff Turner wrote:...Yes, those deprecation warnings are annoying and misleading, because Component is deprecated for Avalon, not Cocoon. Perhaps Cocoon should have a special avalon-framework-nodepr-4.1.3.jar , without the @deprecated?The current version of the ECM in CVS, as well as Fortress (the next generation Avalon container), and Merlin, and Phoenix all have the same solution to the problem. It involves the use of dynamic proxies to add the Component interface at runtime to components who do not have it. The Avalon team are in the process of creating a huge unified release so that all the latest versions of all the Avalon projects will work together. It is on the top of our priority list. One thing that the dynamic proxy (as it is implemented currently) requires is a minimum JDK version of 1.3. We can alter that with a BCEL enabled dynamic proxy generator if someone takes the time to donate the code. If Cocoon upgrades to the current CVS version of ECM, they can get rid of the artificial deprecation warnings by not having any of the role interfaces implement the Component interface.:-/That will remove any deprecation warnings for code that uses the Cocoon component interfaces. Does this seem like a viable solution? We are trying to get a feel for the best action from this point forward.
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.
(someone who belives that lockin is a bad thing)
Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
