Skip to main content

Can't reach STS Endpoint with WebStart Client

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
medivan
Offline
Joined: 2010-09-19

Hey all,
first a little overview of what we're trying to do: we got a bunch of WebServices which are secured by an STS and everything works fine as long as we run our Client via the IDE.
So we thought everything is fine and made a WebStart package for the Client, deployed it and now it seems the Client is unable to find the exact same STS Endpoint, which he can access while running within the IDE.
I already checked if there could be any connection problem and even ran it all on localhost, still everythings the same:
Start the client from the IDE: everything works fine.
Start the client from the WebStart App we get the following Exception:
WSSTUBE0035: Recieved Exception during IssuedToken Creation.
com.sun.xml.ws.api.security.trust.WSTrustException: WST0042:No matching service with endpoint http://localhost:8484/IdentityProvider/IdentityProviderService?wsdl found in the Meatadata.
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.doMexRequest(TrustPluginImpl.java:621)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.invokeRST(TrustPluginImpl.java:480)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.process(TrustPluginImpl.java:163)
at com.sun.xml.ws.security.trust.impl.client.STSIssuedTokenProviderImpl.issue(STSIssuedTokenProviderImpl.java:53)
at com.sun.xml.ws.api.security.trust.client.IssuedTokenManager.getIssuedToken(IssuedTokenManager.java:79)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.invokeTrustPlugin(SecurityClientTube.java:568)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:200)
at com.sun.xml.ws.security.secconv.WSSCPlugin.sendRequest(WSSCPlugin.java:397)
at com.sun.xml.ws.security.secconv.WSSCPlugin.process(WSSCPlugin.java:260)
at com.sun.xml.ws.security.secconv.impl.client.SCTokenProviderImpl.issue(SCTokenProviderImpl.java:129)
at com.sun.xml.ws.api.security.trust.client.IssuedTokenManager.getIssuedToken(IssuedTokenManager.java:79)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.invokeSCPlugin(SecurityClientTube.java:391)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:196)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:167)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
at com.sun.xml.ws.client.Stub.process(Stub.java:222)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:135)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy44.getIdentity(Unknown Source)
at de.client.controller.WSController.<init>(WSController.java:113)
at de.client.controller.WSController.getInstance(WSController.java:135)
at de.client.gui.SingleFrameApplication.initWSController(SingleFrameApplication.java:147)
at de..client.gui.SingleFrameApplication.startup(SingleFrameApplication.java:109)
at org.jdesktop.application.Application$1.run(Application.java:171)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

When i have a look at the Metadata information given under the /mex Address i can clearly see the Endpoint with that URL though:

Endpoint
Information

Service Name:

Port Name:

Address:
http://localhost:8484/IdentityProvider/IdentityProviderService/mex

WSDL:
http://localhost:8484/IdentityProvider/IdentityProviderService/mex?wsdl

Implementation class:
com.sun.xml.ws.mex.server.MEXEndpoint

Service Name:
{http://sts.security.service.de/}IdentityProviderService

Port Name:
{http://sts.security.service.de/}IIdentityProviderService_Port

Address:
http://localhost:8484/IdentityProvider/IdentityProviderService

WSDL:
http://localhost:8484/IdentityProvider/IdentityProviderService?wsdl

Implementation class:
de.service.security.sts.IdentityProvider

I'm really out of ideas why the Endpoint can be found with a "regular" Client and can't be found while running inside WebStart. Am I missing some special configuration that is needed with GlassFish v3 and Metro 2.0 (since we did a similiar scenario with GlassFish v2 and Metro 1.x and it worked fine)?
I'd be really thankfull for any advice.

Thanks in advance and best regards,

Medivan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
medivan
Offline
Joined: 2010-09-19

Okay we solved that mysterie now. In the WebStart project some of the webservice libraries weren't up to date (still the metro 1.x libs) and that caused this error...
Happy to finally found the error we updated those libraries with the Metro 2.0 ones but now we got the next Problem:
#### Java Web Start Error:
#### com.sun.xml.ws.policy.PolicyException: JAX-WS 2.1 API is loaded from file:/C:/Program%20Files/Java/jre6/lib/rt.jar, But JAX-WS runtime requires JAX-WS 2.2 API. Use the endorsed standards override mechanism to load JAX-WS 2.2 API

Okay, right, the JRE ships with Jax-WS 2.1 but we're using Metro 2.0 so we kinda need Jax-WS 2.2, shouldn't be that a big problem with the endorsed property we thought. But it looks like it really is a bigger Problem since it doesn't work with WebStart.
After some extensive searching it seems that there is no real fix for using endorsed directories with WebStart. Automatically copying the needed jars into the Java endorsed dir isn't really an option since that could influence other applications running on our Clients systems.
The JNLP Wrapper seemed promising but all links i could find ended up dead.
So does anyone know if there is another way to set the endorsed directory for a WebStart application or if there is an alternative to WebStart which lets us distribute and update our application.
Thanks in advance and best regards,

Medivan