You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2002/08/07 18:06:51 UTC
DO NOT REPLY [Bug 11533] New: - [PATCH] Replacement for AvalonToCocoonSource

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11533>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11533

[PATCH] Replacement for AvalonToCocoonSource

           Summary: [PATCH] Replacement for AvalonToCocoonSource
           Product: Cocoon 2
           Version: Current CVS
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: core
        AssignedTo: cocoon-dev@xml.apache.org
        ReportedBy: jens.lorenz@interface-business.de


The Source resolving invented for Cocoon was donated to Avalon-Excalibur. In 
order to maintain compatibility wrappers have been written. However this 
wrapping must fail as soon as there are some special Source Implementations 
which contain extended functionality.

For example think of an ExtendedSource which might be used by FileGenerator for 
ordinary generation, but might also be used by ExtendedFileGenerator for 
extended generation. Obviously ExtendedFileGenerator has to check if the Source 
is actually an ExtendedSource and then call extended methods on it.

The current AvalonToCocoonSource and CocoonToAvalonSource wrappers break this 
approach by not wrapping around the CocoonSource and then not allowing to 
access to wrapped source.

A nice way to accomplish the same is by creating dynamic proxies (which are 
available from JDK 1.3 onwards). This class can implement any interface and 
then route the method call to another class. It can also be assigned to any 
interface it implements.

The attachements contain a patched AbstractEnvironment (since it's there where 
the CocoonSources are wrapped) and an AvalonToCocoonSourceInvocationHandler 
which is needed for creating the proxy class and contains essentially the same 
logic as AvalonToCocoonSource.

It shouldn't be hard to create a CocoonToAvalonSourceInvocationHandler on this 
basis for the other way around.

The credits for creating this go to Stefan K�hler.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org