2013-06-20 5 views
0

Я создал приложение для веб-сервисов на основе Apache CXF (2.7.5), развернуло его на Glassfish 3.0.1 и отлично работает, пока не включу поддержку WS-Sec. Тогда я получаю следующее исключение, когда я пытаюсь сделать запрос WebService:Проблема Apache CXF на Glassfish

Caused by: javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory(provider: ApacheXMLDSig)cannot be found. 

    at javax.xml.crypto.dsig.XMLDSigSecurity.doGetImpl(Unknown Source) ~[webservices-osgi.jar:1.0] 
    at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0] 
    at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0] 
    at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(Unknown Source) ~[webservices-osgi.jar:1.0] 
    at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(Unknown Source) ~[webservices-osgi.jar:1.0] 
    at org.apache.ws.security.message.WSSecSignature.init(WSSecSignature.java:127) ~[wss4j-1.6.10.jar:1.6.10] 
    at org.apache.ws.security.message.WSSecSignature.<init>(WSSecSignature.java:120) ~[wss4j-1.6.10.jar:1.6.10] 
    at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1730) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5] 
    at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:546) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5] 
    at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:147) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5] 
    ... 273 common frames omitted 
Caused by: java.lang.ClassNotFoundException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory 
    at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) ~[felix.jar:na] 
    at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) ~[felix.jar:na] 
    at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) ~[felix.jar:na] 
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_43] 

Кажется, что CXF вызывает класс XMLSignatureFactory, содержащийся реализацией по умолчанию поставщика вебсервис GlassFish вместо того, чтобы вызывать его собственные один (это в xmlsec .jar). Все файлы CXF упакованы в мой файл войны, а также установите <class-loader delegate="false" /> в sun-web.xml. Может кто-нибудь помочь мне, почему классный загрузчик Glassfish работает таким образом и как я могу это исправить?

ответ

0

Мне удалось выяснить, что Glassfish (по крайней мере версия 3.0.1) изменяет поведение загрузки класса по умолчанию для «защиты» некоторых пакетов (в основном пакетов javax.) В его пути к классам. Именно по этой причине он находит и использует классы в своей директории модулей, а не в библиотеке моей войны. Чтобы решить эту опцию JVM должна быть добавлена ​​к domain.xml:

<jvm-options>-Dcom.sun.enterprise.overrideablejavaxpackages=javax.xml.crypto,javax.xml.crypto.dsig</jvm-options> 

С этой Glassfish позволит использовать ваши LIBS в вашей войне файл. Но даже с этой настройкой проблематично использовать CXF с WS-Securityy вместе с Metro. Лучшим решением является использование Glassfish с единственным профилем веб-профиля без полного профиля, поскольку веб-профиль не имеет Metro.