cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Helma van der Linden (JIRA)" <>
Subject [jira] Reopened: (COCOON-371) [PATCH] Replacement for AvalonToCocoonSource
Date Tue, 25 Oct 2005 13:41:55 GMT
     [ ]
Helma van der Linden reopened COCOON-371:

reopened just to set the resolution to fixed

> [PATCH] Replacement for AvalonToCocoonSource
> --------------------------------------------
>          Key: COCOON-371
>          URL:
>      Project: Cocoon
>         Type: Improvement
>   Components: * Cocoon Core
>     Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Jens Lorenz
>     Assignee: Cocoon Developers Team
>     Priority: Minor
>  Attachments:,
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message