cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: What is a Parser?
Date Wed, 29 Jan 2003 22:21:40 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message