Peter Hunsberger skrev:
On 5/17/06, Daniel Fagerstrom <[EMAIL PROTECTED]> 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.
/Daniel
