-
1. Re: Using XMLSignatureFactory
grgrzybek Jun 5, 2014 6:03 AM (in response to rmrfchik)Hello Paul
Have a look at this project: https://github.com/grgrzybek/grgr-tests/tree/master/grgr-test-dsig.
With default fuse-6.1.redhat-379, I got this when starting this bundle:
Fabric8:karaf@root> install -s mvn:grgr.test/test-dsig/0.1.0.BUILD-SNAPSHOT Bundle ID: 158 Error executing command: Error installing bundles: Unable to start bundle mvn:grgr.test/test-dsig/0.1.0.BUILD-SNAPSHOT: Unresolved constraint in bundle grgr.test.dsig [158]: Unable to resolve 158.0: missing requirement [158.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.crypto.dsig)
But when I added this line:
javax.xml.crypto.dsig, \
To correct VM settings in FUSE_HOME/etc/jre.properties, I was able to start it succesfully:
Fabric8:karaf@root> install -s mvn:grgr.test/test-dsig/0.1.0.BUILD-SNAPSHOT org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory@4c0a4063 Bundle ID: 159
regards
Grzegorz Grzybek
-
-
3. Re: Using XMLSignatureFactory
grgrzybek Jun 10, 2014 3:09 PM (in response to rmrfchik)I've updated my example here: https://github.com/grgrzybek/grgr-tests/tree/master/grgr-test-dsig to make it work with Fuse 6.1.GA.
In Fuse, there is apache santuario xmlsec library available, so you have to make some additional steps:
Here's the working bundle activator:
org.apache.xml.security.Init.init(); Security.insertProviderAt(new org.apache.jcp.xml.dsig.internal.dom.XMLDSigRI(), 0); XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM", "ApacheXMLDSig"); System.out.println(fac.toString());
regards
Grzegorz Grzybek
-
4. Re: Using XMLSignatureFactory
kconner Jun 10, 2014 11:28 AM (in response to grgrzybek)Hiya Grzegorz
We have been hitting this recently within the Overlord projects and came up with another way to workaround the issue, this is related to Gary's question from earlier.
Our workaround was to have the javax.xml.crypto packages exposed through the system bundle, hence the question about jre.properties and child containers, and to modify the xmlsec.jar MANIFEST.MF so that it also Imported the packages, thereby allowing those in the jar to be rewired to the versions in the system bundle.
What are your thoughts on this?
Kev
-
5. Re: Re: Using XMLSignatureFactory
grgrzybek Jun 10, 2014 3:07 PM (in response to kconner)Hi Kevin
Modifying
etc/jre.properties
is one thing, but hacking in the contents ofxmlsec.jar
is a warning sign, that it should be done in other way...doesn't:
Security.insertProviderAt(new org.apache.jcp.xml.dsig.internal.dom.XMLDSigRI(), 0);
work for you?
Also the question is - do you want to use Apache Santuario version or the one provided with JDK (in the latter case - you should uninstall xmlsec bundle...
regards
Grzegorz Grzybek
-
6. Re: Re: Re: Using XMLSignatureFactory
kconner Jun 11, 2014 11:15 AM (in response to grgrzybek)Modifying
etc/jre.properties
is one thing, but hacking in the contents ofxmlsec.jar
is a warning sign, that it should be done in other way...I would prefer not to modify xmlsec.jar, that is definitely a warning as you say, but this seems to be the 'lesser evil' as it leads to a cleaner classloading hierarchy shared with the system classes.
doesn't:
- Security.insertProviderAt(new org.apache.jcp.xml.dsig.internal.dom.XMLDSigRI(), 0);
work for you?
If this was localised to certain hierarchies then I would be happier but having it registered through java.security.Security, especially if multiple bundles are having to do this, is likely to lead to problems when one of them is undeployed.
Also the question is - do you want to use Apache Santuario version or the one provided with JDK (in the latter case - you should uninstall xmlsec bundle...
We are not interested in the Santuario provider but rather some of the other packages being exported within xmlsec.
Thanks,
Kev
-
7. Re: Using XMLSignatureFactory
grgrzybek Jun 26, 2014 2:46 AM (in response to kconner)Hello Kevin
Can I provide some more help with this? Or have you found solution?
regards
Grzegorz