Jeff Turner wrote:
On Mon, Jan 27, 2003 at 07:19:05PM +0100, Ugo Cei wrote:
You should get back a JaxpParser instance, which is a Component, so the
cast is valid. I'd imagine the compiler doesn't realise this at
compile-time, and you'd get a ClassCastException if it wasn't a
Component.
Maybe I should have a look at the JLS, but since I'm lazy and my code
runs, I figure I'd better ask cocoon-dev ;-).
Is this the kosher way of obtaining an XML parser in Cocoon 2.1?
To further complicate things, Eclipse does not like my little class
which implements org.apache.avalon.framework.component.Component, since
it insists that the type Component is deprecated, along with
ComponentManager. In order to play by the rules, I've removed
"Component" from the interfaces my class implements, but Cocoon (or is
it Excalibur?) barfs with a "ClassCastException" when I try to put it in
cocoon.xconf. Well, I just put back the "implements Component"
declaration and live with Eclipse's warnings, but I cannot help feeling
a little disoriented about all this ;-).
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
