2013-06-20 3 views
0

Apache CXF (2.7.5)를 기반으로하는 웹 서비스 응용 프로그램을 Glassfish 3.0.1에 배포했으며 WS-Sec 지원을 사용할 때까지 제대로 작동합니다. 나는 웹 서비스 요청을 할 때 그 때 나는 다음과 같은 예외가 :GlassFish의 Apache CXF 문제

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 클래스를 호출하는 것을 (그것은 xmlsec에 있어요 .jar 파일). 모든 CXF 파일은 내 war 파일에 압축되어 있으며 <class-loader delegate="false" />이 sun-web.xml에 설정되어 있습니다. 글래스 피어 클래스 로더가 이런 식으로 작동하는 이유를 누군가 도와 줄 수 있습니까? 어떻게 해결할 수 있습니까?

답변

0

글래스 피쉬 (적어도 3.0.1 버전)는 classpath에있는 일부 패키지 (주로 javax 패키지)를 "보호"하기 위해 기본 클래스 로딩 동작을 수정한다는 것을 알아 냈습니다. 그것이 왜 내 클래스의 lib 디렉토리가 아닌 modules 디렉토리에있는 클래스를 찾아서 사용하는 이유입니다. 이 JVM이 옵션은 domain.xml의에 추가해야 해결하려면

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

을이 글래스 피시와 함께 전쟁 파일에 libs와 사용할 수 있습니다. 그러나이 설정으로도 Metro와 함께 WS-Securityy에서 CXF를 사용하는 것은 문제가됩니다. 더 나은 해결 방법은 Metro가 포함되지 않은 Web Profile만으로 Full Profile이 아닌 Web Profile 만 사용하는 Glassfish를 사용하는 것입니다.