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.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
