Bug 39349

(In reply to comment #0)
> Hello,
> 
> I apologize, if this functionality is already implemented and I just fail
> to see it.
> 
> Using the JSR 105 API I see no way to set a javax.xml.transform.URIResolver for
> resolving URIs when performing an XSLT Transform. This means, that the default 
> URIResolver will be used, which is not always desirable.
> 
> Looking at the source code, I can see 2 ways of implementing this
> (I assume you do not want to change the API of XMLCryptoContext):
> 
> 1) explicitly setting a URIResolver property in the XMLCryptoContext,
> e.g. XMLCryptoContext.setProperty("javax.xml.transform.URIResolver",
myURIResolver)
> 
> 2) implementing a URIResolver that internally uses the URIDereferencer
> from the XMLCryptoContext
> 
> In both cases, the resulting URIResolver would have to be passed down to the 
> org.apache.xml.security.transforms.implementations.TransformXSLT that
> actually does the transform.
> 
> If you indicate which way you would prefer it, i would be willing to implement
> this functionality and provide a patch.

Solution 1 is technically an API change (since you propose defining a 
property starting with "javax"), so it would need to go through the Java
Community Process and a maintenance revision of the specification would need 
to be released. Since we have only just recently finalized JSR 105 and don't
have any immediate plans for a maintenance revision, this 
option would take a while. Alternatively, you could define an
implementation-specific property starting with org.apache (but it would 
be specific to the Apache implementation).

Solution 2 is probably better. However, I should note for a tighter JSR
105 integration, the Apache Transform implementations should be
changed to extend the JSR 105 javax.xml.crypto.dsig.TransformService class. 
Then the XMLCryptoContext would be passed to the 
transform method (inherited from TransformService) of the TransformXSLT 
impl, and from there you could get 
the URIDereferencer from the XMLCryptoContext. But that may be more of
a long-term (XMLSec 2.0?) change since it would require some fairly significant 
restructuring/modification of the classes.

--Sean

Sean,

Thank you for your informative reply. I understand, why (1) is not an option
at the moment. But from looking at the code, maybe you could reconsider (2).
I think there is a solution that does not require the kind of class 
restructuring that you suggest.

Currently, the org.jcp.xml.dsig.internal.dom.ApacheTransform class acts as
the glue between the JSR105 and the Apache implementation. In the 'transformIt'
method of this class, the respective Apache Transform is instantiated. It
is in this method, where both the XMLCryptoContext and the Apache Transform
Impl would be available at the same time. There it would be possible to set
a URIResolver (that is a wrapper over the URIDereferencer of the 
XMLCryptoContext) to the Apache Transform object - provided such a setter is 
added to the class, which shouldn't be a problem because it doesn't break
compatibility. In the Apache TransformXSLT 'enginePerformTransform' method
the URIResolver would be accessible via _transformObject.getURIResolver().

What do you think about that? 

regards,
Patrick

Hi Patrick,

Sorry for not getting back to you earlier. I think your proposed solution is
fine. Can you attach a patch (or code diffs) to this bug when you have it
ready?