cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Configuration issues
Date Wed, 17 May 2006 22:00:33 GMT
Peter Hunsberger skrev:
> On 5/17/06, Daniel Fagerstrom <> wrote:
> <snip/>
>> > 2. This works only as long as the user wants to use the same
>> > implementation for a component. Switching to an own implementation with
>> > an own configuration is not possible.
>> >
>> > Any idea on how to solve this?
>> Here the IMO best and most natural solution is to have different blocks
>> for different implementations. Say we have two different components that
>> implements the XsltProcessor inteface, the Xalan and the Saxon
>> implementation. Then if you have a Xalan block with its own embedded
>> configuration and a Saxon block with its own embedded configuration. If
>> you want to use the Xalan implementation you deploy the Xalan block and
>> if you want the Saxon implementation you deply the Saxon block.
> Would this solution be able to deal with using both Saxon and Xalan or
> two different versions of Saxon at different points in the same
> pipeline?  In our case we have 1 critical XSLT that currently only
> runs under Saxon 6 (I've tried repeatedly to get it to Saxon 8, but so
> far no go).  Everything else exploits XSLT 2.0 and requires Saxon 8.
> We mix these XSLT in the same pipelines all the time...

No, XSLT processors was a rather bad example as they not are 
interchangeable even if they implement the same interface.

In OSGi service is registred with the interfaces that it implements and 
optionally with a map with properties. A service can be looked up based 
on its interfaces and optionally with an LDAP style filter on the 
property map.

So in the above example, both implementations would be registered as 
XsltProcessors, then could also have properties describing vendor name 
and version.

A component that can do with any XsltProcessor would just lookup the 
XSLT service based on the interface. While a component with special 
needs would use a filter that describe version range and/or vendor. I 
don't know if anything like this would be possible with Spring.


View raw message