Skip to main content

Including gf-client.jar on the classpath causes WS implementation incompatibilities

6 replies [Last post]
netmackan
Offline
Joined: 2005-06-26
Points: 0

I am trying to add GlassFish 3.1 support to SignServer [DSS-306] and have some trouble getting both WS and EJB calls to work using the same classpath.

This is the setup:

  • From my client application (JUnit test case) I am calling a few EJB session beans running in GlassFish and after that the JUnit tests calls my web services.
  • To make the EJB calls I included the gf-client.jar on the classpath.
  • To make the Web Services class the JAX-WS implementation available in the JDK should be enough, however as gf-client.jar has a lot of dependencies including the WS implementation in GlassFish there is an runtime error at the client side:
java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
at com.sun.xml.ws.model.RuntimeModeler.processExceptions(RuntimeModeler.java:1213)
at com.sun.xml.ws.model.RuntimeModeler.processDocWrappedMethod(RuntimeModeler.java:943)
at com.sun.xml.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:711)
at com.sun.xml.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:472)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:314)
at com.sun.xml.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:99)
at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:74)
at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:58)
at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:130)
at com.sun.xml.ws.client.WSServiceDelegate.buildRuntimeModel(WSServiceDelegate.java:782)
at com.sun.xml.ws.client.WSServiceDelegate.createSEIPortInfo(WSServiceDelegate.java:789)
at com.sun.xml.ws.client.WSServiceDelegate.addSEI(WSServiceDelegate.java:765)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:386)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:363)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:345)
at javax.xml.ws.Service.getPort(Service.java:92)
at org.signserver.protocol.ws.gen.SignServerWSService.getSignServerWSPort(SignServerWSService.java:56)
at org.signserver.client.api.SigningAndValidationWS.<init>(SigningAndValidationWS.java:148)
at org.signserver.client.cli.defaultimpl.WebServicesDocumentSigner.<init>(WebServicesDocumentSigner.java:51)
at org.signserver.client.cli.defaultimpl.SignDocumentCommand.createSigner(SignDocumentCommand.java:302)
at org.signserver.client.cli.defaultimpl.SignDocumentCommand.run(SignDocumentCommand.java:371)
at org.signserver.client.cli.defaultimpl.SignDocumentCommand.execute(SignDocumentCommand.java:417)
at org.signserver.client.cli.DocumentSignerTest.execute(DocumentSignerTest.java:300)
at org.signserver.client.cli.DocumentSignerTest.test04signPDFwithPasswordOverWebservices(DocumentSignerTest.java:163)

It turns out that WebFault.class is from JAX-WS in the JDK (rt.jar) while RuntimeModeler.class is from GlassFish (webservices-osgi.jar) and they are not compatible.

If I only would do web services I just remove gf-client.jar from the classpath and the WS calls works fine but then I can not use the EJBs.

Is there a smaller sets of JARs that I can use instead of gf-client.jar which only includes what is necessary to do JNDI and EJB calls and not brings in the WS stuff?

Best regards,
Markus

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jungicz
Offline
Joined: 2004-08-17
Points: 0

there's a mismatch between API available on the classpath/in JDK and API required by webservices-osgi.jar.

To fix it make sure that JAX-WS API 2.2 is available - either by running on JDK 7 or by using endorsed mechanism (you can find required APIs in $GF_HOME/glassfish/modules/endorsed folder)

--lukas

netmackan
Offline
Joined: 2005-06-26
Points: 0

Using JDK 7 instead gave a different error. It seems like the trust store setting is not working as I am now getting "java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty." even though the code does:

System.setProperty("javax.net.ssl.trustStore", "full-path-to-truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

(Edit: This might be more of an issue with JDK 7 rather then GlassFish)

jungicz
Offline
Joined: 2004-08-17
Points: 0

Sorry, I don't know what is exactly wrong here but google pointed me to stackoverflow.com. From that it looks more like OpenJDK (or linux) issue. HTH.

netmackan
Offline
Joined: 2005-06-26
Points: 0

jungicz wrote:
Sorry, I don't know what is exactly wrong here but google pointed me to stackoverflow.com. From that it looks more like OpenJDK (or linux) issue. HTH.

Thank you jungicz but that is a different sitation where the default trust store is not available. In my case I am providing the truststore.

It did point me in the right the direction though. I think I have now solved the GlassFish3/JDK7 truststore issue. It turns out that System.setProperty("javax.net.ssl.trustStore") does not take affect instead setting up a socket factory and using HttpsURLConnection.setDefaultSSLSocketFactory(factory) works also with GlassFish3/JDK7.

netmackan
Offline
Joined: 2005-06-26
Points: 0

Note that I only want to be able to access the EJB:s using the GlassFish API. I am not interested in using the GlassFish web services stack at all.

There should be a way that I can use only the EJB API:s without having to get the WS stack on the classpath or are they so mixed together that it is not possible to use one without the other?

Running on JDK 7 sounds like the best solution yet as it is time to do that anyway. But having to do that because of limitations in GlassFish doesn't feel optimal.

Thanks,
Markus

netmackan
Offline
Joined: 2005-06-26
Points: 0

No suggestions?