Skip to main content

Problem with WSIT client to Geneva Service using token from Geneva STS

46 replies [Last post]
Anonymous

Hi,

My scenario is this:

1) Geneva STS running user name authentication. The STS basically just echoes the user name used to authenticate in an attribute in the 1.1 assertion

2) Geneva Web Service trusting the STS. The WS also just echoes whatever was in the user's assertion.

3) .NET WCF client submitting user name and password to the STS and authenticating to the service with the assertion

4) Java WSIT web service client that has trouble calling the WS

The STS, WS and .NET client work fine. WSDL files for the service and the STS are attached.

I've already taken steps to make the WS and STS Java-interoperable, namely disabling negotiateServiceCredential on the service to remove the SslContextToken from the WSDL for the service. Netbeans now accepts my WSDL file for the service just fine.

In netbeans 6.5.1 (Metro 1.5) I basically create a new web app and I add a new web service client to that app. The Web Service client I point to the web service's WSDL file which it appears to load fine. I then go in and edit the service client properties and add a static user name and password.

When running the sample I get the attached error from Netbeans.

I'm a bit confused if I'm even attacking this correctly. I've been doing some searching and some people are saying that I should add both the web service WSDL AND the STS WSDL and with that have two web service clients. If that's the case which do I call? Right now I've not added the STS WSDL file for two reasons 1) The web service WSDL already points to the STS and 2) Netbeans throws stackoverflow exceptions when I try to do it :)

I know this can be done since I've found found several posts about it name with Jiangdong and Clems Wasters participating.

Rgds.
Jesper Hvid
[att1.html]
[WS_WSDL.XML]
[STS_WSDL.XML]
[NetbeansError.txt]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Attachment not added (too many attachments): "NetbeansError.txt"

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
suresh

Jesper Hvid wrote:
>
> Just for good measure I’ll add both scenarios again:
>
>
>
> No line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> u:Id="_0"> > xmlns="http://tempuri.org/">Hello
>

>
> FINEST: Digest verification of Body was successful
>
>
>
> Line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›
>
> FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> u:Id="_0"> > xmlns="http://tempuri.org/">Hello
>
> HELLO

>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
Hi, Jesper,
in my case there is no such errror
see this log message:

without line break:
Buffering Payload from incomming message
WSS1763: Actual digest value is:v>����p����ζ�w�,A
WSS1762: Calculated digest value is:v>����p����ζ�w�,A
WSS1764: Canonicalized PayLoad is: xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="_5006"> xmlns:ns2="http://suresh/">*SunMicrosystems*
Digest verification of Body was successful

with linebreak:
Buffering Payload from incomming message
WSS1763: Actual digest value is:�yj���F]�焞N]��M_
WSS1762: Calculated digest value is:�yj���F]�焞N]��M_
WSS1764: Canonicalized PayLoad is: xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="_5006">*Sun*
*Microsystems*

Digest verification of Body was successful

can you tell how to reproduce your exception or send a sample
client/service which gives such exception?
Thanks
Suresh
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 26. juni 2009 23:15
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi,
>
>
>
> I put Metro 2.0 EA on my glassfish server a few hours ago and started
> testing. Unfortunately, there is no change in behavior. Digest
> verification of the body still fails when there are line breaks in the
> response string.
>
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 14:25
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Hi,
>
>
>
> I’m using Metro 1.5.
>
>
>
> If possible please try with Metro 2.0 once and let me know. It would
> be very useful help for us.
>
> regards,
> kumar
>
>
>

[att1.html]

Jesper Hvid

Hi,

I put Metro 2.0 EA on my glassfish server a few hours ago and started testing. Unfortunately, there is no change in behavior. Digest verification of the body still fails when there are line breaks in the response string.

Rgds.
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 14:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I’m using Metro 1.5.

If possible please try with Metro 2.0 once and let me know. It would be very useful help for us.

regards,
kumar

[att1.html]

Jesper Hvid

Just for good measure I’ll add both scenarios again:

No line break:

FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?
î(Ê›®P„
FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?
î(Ê›®P„
FINEST: WSS1764: Canonicalized PayLoad is: Hello
FINEST: Digest verification of Body was successful

Line break:

FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›
FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs
FINEST: WSS1764: Canonicalized PayLoad is: Hello
HELLO

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 26. juni 2009 23:15
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi,

I put Metro 2.0 EA on my glassfish server a few hours ago and started testing. Unfortunately, there is no change in behavior. Digest verification of the body still fails when there are line breaks in the response string.

Rgds.
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 14:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I’m using Metro 1.5.

If possible please try with Metro 2.0 once and let me know. It would be very useful help for us.

regards,
kumar

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> Just for good measure I’ll add both scenarios again:
>
>
>
> No line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> u:Id="_0"> > xmlns="http://tempuri.org/">Hello
>

>
> FINEST: Digest verification of Body was successful
>
>
>
> Line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›
>
> FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> u:Id="_0"> > xmlns="http://tempuri.org/">Hello
>
> HELLO

>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
Thanks it is likely a Bug, we will try to fix this soon.

regards,
kumar
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 26. juni 2009 23:15
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi,
>
>
>
> I put Metro 2.0 EA on my glassfish server a few hours ago and started
> testing. Unfortunately, there is no change in behavior. Digest
> verification of the body still fails when there are line breaks in the
> response string.
>
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 14:25
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Hi,
>
>
>
> I’m using Metro 1.5.
>
>
>
> If possible please try with Metro 2.0 once and let me know. It would
> be very useful help for us.
>
> regards,
> kumar
>
>
>

[att1.html]

Jesper Hvid

Hi,

Cool! Is there any hint of a “when”? Or at least somewhere I can see the status of the bug?

Thanks,
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 29. juni 2009 08:28
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Just for good measure I’ll add both scenarios again:

No line break:

FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?
î(Ê›®P„
FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?
î(Ê›®P„
FINEST: WSS1764: Canonicalized PayLoad is: xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_0">>Hello
FINEST: Digest verification of Body was successful

Line break:

FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›
FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs
FINEST: WSS1764: Canonicalized PayLoad is: xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_0">>Hello
HELLO

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload
Thanks it is likely a Bug, we will try to fix this soon.

regards,
kumar

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 26. juni 2009 23:15
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi,

I put Metro 2.0 EA on my glassfish server a few hours ago and started testing. Unfortunately, there is no change in behavior. Digest verification of the body still fails when there are line breaks in the response string.

Rgds.
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 14:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I’m using Metro 1.5.

If possible please try with Metro 2.0 once and let me know. It would be very useful help for us.

regards,
kumar

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> Hi,
>
>
>
> Cool! Is there any hint of a “when”? Or at least somewhere I can see
> the status of the bug?
>
>
>
Thanks for you help and you can file a bug so that you get notified as
soon as we fix.

regards,
kumar

> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 29. juni 2009 08:28
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Just for good measure I’ll add both scenarios again:
>
>
>
> No line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?
>
> î(Ê›®P„
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>
> u:Id="_0"> > >Hello
>

>
> FINEST: Digest verification of Body was successful
>
>
>
> Line break:
>
>
>
> FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›
>
> FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs
>
> FINEST: WSS1764: Canonicalized PayLoad is: > xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>
> u:Id="_0"> > >Hello
>
> HELLO

>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
> Thanks it is likely a Bug, we will try to fix this soon.
>
> regards,
> kumar
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 26. juni 2009 23:15
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi,
>
>
>
> I put Metro 2.0 EA on my glassfish server a few hours ago and started
> testing. Unfortunately, there is no change in behavior. Digest
> verification of the body still fails when there are line breaks in the
> response string.
>
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 14:25
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Hi,
>
>
>
> I’m using Metro 1.5.
>
>
>
> If possible please try with Metro 2.0 once and let me know. It would
> be very useful help for us
>
>
> regards,
> kumar
>
>
>
>
>

[att1.html]

Jesper Hvid

Done:
https://wsit.dev.java.net/issues/show_bug.cgi?id=1163

Thanks,
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 29. juni 2009 10:39
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

Cool! Is there any hint of a “when”? Or at least somewhere I can see the status of the bug?

Thanks for you help and you can file a bug so that you get notified as soon as we fix.

regards,
kumar

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 29. juni 2009 08:28
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Just for good measure I’ll add both scenarios again:

No line break:

FINEST: WSS1763: Actual digest value is:Òoîj*°Cxl ?

î(Ê›®P„

FINEST: WSS1762: Calculated digest value is:Òoîj*°Cxl ?

î(Ê›®P„

FINEST: WSS1764: Canonicalized PayLoad is: xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_0">>Hello

FINEST: Digest verification of Body was successful

Line break:

FINEST: WSS1763: Actual digest value is:hˆ0wS&vÎW?®-YþX?Qã›

FINEST: WSS1762: Calculated digest value is:Êp7•kÈ$"W}2WÐc¥}W…Ïs

FINEST: WSS1764: Canonicalized PayLoad is: xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_0">>Hello

HELLO

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

Thanks it is likely a Bug, we will try to fix this soon.

regards,
kumar

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 26. juni 2009 23:15
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi,

I put Metro 2.0 EA on my glassfish server a few hours ago and started testing. Unfortunately, there is no change in behavior. Digest verification of the body still fails when there are line breaks in the response string.

Rgds.

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 14:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I’m using Metro 1.5.

If possible please try with Metro 2.0 once and let me know. It would be very useful help for us

regards,
kumar

[att1.html]

Jesper Hvid

Sorry, forgot your question..

Yes, both the STS and the WS are Geneva framework (.NET)

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

________________________________

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Jesper Hvid

Hi again,

I managed to get it to work now. My WS returns a string basically and that string contains line breaks. When the string contains line breaks the validation fails on the client side. I changed my WS to just return a single string without line breaks and it now works.

Is this a bug in the client? Or somewhere else?

Thanks,
Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 17:57
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Sorry, forgot your question..

Yes, both the STS and the WS are Geneva framework (.NET)

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

________________________________

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]
[WSIT Client log NO LINE BREAKS.txt]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Jesper Hvid

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?
The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,
Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Yes, I do that after every change I’m doing atm.
looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?
Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]
[WS Response.xml]
[Client request.xml]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Jesper Hvid

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached ☺

Rgds.
Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?
The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,
Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Yes, I do that after every change I’m doing atm.
looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?
Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]
[WSIT Client log.txt]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Kumar Jayanti

Jesper Hvid wrote:
>
> Now I managed to get the WSIT client to log as well.. it’s a big one
> and it’s attached J
>
>
>
so who is the Service, is it .NET ?. We are printing the canonicalized
payload towards the end of the log, we need to now see if there is
something wrong there or compare it with what the server side did
calculate the canonicalized payload as. Can you get us the server side
canonicalized payload.

regards,
kumar

> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 16:33
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I’ve managed to get some message logging up and running on the Geneva
> side. Attached are the client’s request to the WS after getting a
> token and the WS’ response to that.
>
>
>
> Hope this helps…
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 16:17
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
> The CosoleHandler has the default level of INFO so you would have to
> change that as well before you can see the FINE Logs.
>
> But looks like somehow the message got modified since it was singed.
> It seems like you had a some other problems earlier and you cleaned up
> your whole setup and are trying to setup everything again ?.
>
> Maybe Jiandong can help since i am off for the rest of the day today.
> But send out the details like the message recieved by the client which
> is causing the problem.
>
> regards,
> kumar
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> generating code...
>
> com\microsoft\schemas\message\MessageBody.java
> com\microsoft\schemas\message\ObjectFactory.java
> com\microsoft\schemas\message\package-info.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java
> Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws
> BUILD SUCCESSFUL (total time: 2 seconds)
>
>
>
> So I believe you still use earlier version of Metro.
>
> You need to download Metro 1.5 jars from here:
> https://metro.dev.java.net/1.5/
>
> Then install it to the Glassfish 2.1 instance.
>
> When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.
> [Message sent by forum member 'jdg6688' (jdg6688)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Jesper Hvid

What exactly is that? Is it the entire Response soap body encoded or what is it?

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

________________________________

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> What exactly is that? Is it the entire Response soap body encoded or
> what is it?
>
If you see the client log you sent (towards the end) you will see :
FINEST: WSS1764: Canonicalized PayLoad is:

So i am looking for that on the server side.

regards,
kumar

>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 17:09
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Now I managed to get the WSIT client to log as well.. it’s a big one
> and it’s attached J
>
>
>
> so who is the Service, is it .NET ?. We are printing the
> canonicalized payload towards the end of the log, we need to now see
> if there is something wrong there or compare it with what the server
> side did calculate the canonicalized payload as. Can you get us the
> server side canonicalized payload.
>
> regards,
> kumar
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 16:33
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I’ve managed to get some message logging up and running on the Geneva
> side. Attached are the client’s request to the WS after getting a
> token and the WS’ response to that.
>
>
>
> Hope this helps…
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 16:17
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
> The CosoleHandler has the default level of INFO so you would have to
> change that as well before you can see the FINE Logs.
>
> But looks like somehow the message got modified since it was singed.
> It seems like you had a some other problems earlier and you cleaned up
> your whole setup and are trying to setup everything again ?.
>
> Maybe Jiandong can help since i am off for the rest of the day today.
> But send out the details like the message recieved by the client which
> is causing the problem.
>
> regards,
> kumar
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using

[att1.html]

Jesper Hvid

Hi,

I don’t know if you’ve seen my latest message? The WS client only complains when the service returns line breaks.. it sounds like a bug somewhere in the client?

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 11:21
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
What exactly is that? Is it the entire Response soap body encoded or what is it?
If you see the client log you sent (towards the end) you will see :
FINEST: WSS1764: Canonicalized PayLoad is:

So i am looking for that on the server side.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> Hi,
>
>
>
> I don’t know if you’ve seen my latest message? The WS client only
> complains when the service returns line breaks.. it sounds like a bug
> somewhere in the client?
>
>
>
I somehow missed your latest message. So it could be a bug, it appears
the server is not using Metro ?. Would it be possible to get the
canonicalized output on the server side so we can see what is wrong.

regards,
kumar

> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 11:21
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> What exactly is that? Is it the entire Response soap body encoded or
> what is it?
>
> If you see the client log you sent (towards the end) you will see :
> FINEST: WSS1764: Canonicalized PayLoad is:
>
> So i am looking for that on the server side.
>
> regards,
> kumar
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 17:09
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Now I managed to get the WSIT client to log as well.. it’s a big one
> and it’s attached J
>
>
>
> so who is the Service, is it .NET ?. We are printing the
> canonicalized payload towards the end of the log, we need to now see
> if there is something wrong there or compare it with what the server
> side did calculate the canonicalized payload as. Can you get us the
> server side canonicalized payload.
>
> regards,
> kumar
>
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 16:33
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I’ve managed to get some message logging up and running on the Geneva
> side. Attached are the client’s request to the WS after getting a
> token and the WS’ response to that.
>
>
>
> Hope this helps…
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 16:17
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
> The CosoleHandler has the default level of INFO so you would have to
> change that as well before you can see the FINE Logs.
>
> But looks like somehow the message got modified since it was singed.
> It seems like you had a some other problems earlier and you cleaned up
> your whole setup and are trying to setup everything again ?.
>
> Maybe Jiandong can help since i am off for the rest of the day today.
> But send out the details like the message recieved by the client which
> is causing the problem.
>
> regards,
> kumar
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using
>
>
>

[att1.html]

Jesper Hvid

Here it is again:

Hi again,

I managed to get it to work now. My WS returns a string basically and that string contains line breaks. When the string contains line breaks the validation fails on the client side. I changed my WS to just return a single string without line breaks and it now works.

Is this a bug in the client? Or somewhere else?

There is no way to get the canonicalized message on the Geneva side (Server and STS arerunning .NET Geneva remember?). I can do a packet trace, but that’ll take some time since I have to decrypt the traffic etc.

As I said I really think this is a bug since I know .NET clients are working and so is the Java client. Logically, it doesn’t make sense that the digest verification fails when I add line breaks. It’s 100% reproducible. I’ve tried small messages and also very large messages. It always fails when I add one or more line breaks to the response.

Thanks,
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 12:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I don’t know if you’ve seen my latest message? The WS client only complains when the service returns line breaks.. it sounds like a bug somewhere in the client?

I somehow missed your latest message. So it could be a bug, it appears the server is not using Metro ?. Would it be possible to get the canonicalized output on the server side so we can see what is wrong.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 11:21
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

What exactly is that? Is it the entire Response soap body encoded or what is it?

If you see the client log you sent (towards the end) you will see :
FINEST: WSS1764: Canonicalized PayLoad is:

So i am looking for that on the server side.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using

[att1.html]
[WSIT Client log NO LINE BREAKS.TXT]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Kumar Jayanti

Jesper Hvid wrote:
>
> Here it is again:
>
>
>
> Hi again,
>
>
>
> I managed to get it to work now. My WS returns a string basically and
> that string contains line breaks. When the string contains line breaks
> the validation fails on the client side. I changed my WS to just
> return a single string without line breaks and it now works.
>
>
>
> Is this a bug in the client? Or somewhere else?
>
>
>
Thanks for your investigations. Yes it could be a bug in our
canonicalizer. Are you using Metro 2.0 or are you using 1.5 ?. I know we
had made some fix sometime ago.

regards,
kumar

> There is no way to get the canonicalized message on the Geneva side
> (Server and STS arerunning .NET Geneva remember?). I can do a packet
> trace, but that’ll take some time since I have to decrypt the traffic
> etc.
>
>
>
> As I said I really think this is a bug since I know .NET clients are
> working and so is the Java client. Logically, it doesn’t make sense
> that the digest verification fails when I add line breaks. It’s 100%
> reproducible. I’ve tried small messages and also very large messages.
> It always fails when I add one or more line breaks to the response.
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 12:25
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Hi,
>
>
>
> I don’t know if you’ve seen my latest message? The WS client only
> complains when the service returns line breaks.. it sounds like a bug
> somewhere in the client?
>
>
>
> I somehow missed your latest message. So it could be a bug, it appears
> the server is not using Metro ?. Would it be possible to get the
> canonicalized output on the server side so we can see what is wrong.
>
> regards,
> kumar
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 11:21
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> What exactly is that? Is it the entire Response soap body encoded or
> what is it?
>
> If you see the client log you sent (towards the end) you will see :
> FINEST: WSS1764: Canonicalized PayLoad is:
>
> So i am looking for that on the server side.
>
> regards,
> kumar
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 17:09
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Now I managed to get the WSIT client to log as well.. it’s a big one
> and it’s attached J
>
>
>
> so who is the Service, is it .NET ?. We are printing the
> canonicalized payload towards the end of the log, we need to now see
> if there is something wrong there or compare it with what the server
> side did calculate the canonicalized payload as. Can you get us the
> server side canonicalized payload.
>
> regards,
> kumar
>
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 16:33
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I’ve managed to get some message logging up and running on the Geneva
> side. Attached are the client’s request to the WS after getting a
> token and the WS’ response to that.
>
>
>
> Hope this helps…
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 16:17
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
> The CosoleHandler has the default level of INFO so you would have to
> change that as well before you can see the FINE Logs.
>
> But looks like somehow the message got modified since it was singed.
> It seems like you had a some other problems earlier and you cleaned up
> your whole setup and are trying to setup everything again ?.
>
> Maybe Jiandong can help since i am off for the rest of the day today.
> But send out the details like the message recieved by the client which
> is causing the problem.
>
> regards,
> kumar
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Jesper Hvid

Hi,

I’m using Metro 1.5.

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 13:57
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Here it is again:

Hi again,

I managed to get it to work now. My WS returns a string basically and that string contains line breaks. When the string contains line breaks the validation fails on the client side. I changed my WS to just return a single string without line breaks and it now works.

Is this a bug in the client? Or somewhere else?

Thanks for your investigations. Yes it could be a bug in our canonicalizer. Are you using Metro 2.0 or are you using 1.5 ?. I know we had made some fix sometime ago.

regards,
kumar

There is no way to get the canonicalized message on the Geneva side (Server and STS arerunning .NET Geneva remember?). I can do a packet trace, but that’ll take some time since I have to decrypt the traffic etc.

As I said I really think this is a bug since I know .NET clients are working and so is the Java client. Logically, it doesn’t make sense that the digest verification fails when I add line breaks. It’s 100% reproducible. I’ve tried small messages and also very large messages. It always fails when I add one or more line breaks to the response.

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 12:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I don’t know if you’ve seen my latest message? The WS client only complains when the service returns line breaks.. it sounds like a bug somewhere in the client?

I somehow missed your latest message. So it could be a bug, it appears the server is not using Metro ?. Would it be possible to get the canonicalized output on the server side so we can see what is wrong.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 11:21
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

What exactly is that? Is it the entire Response soap body encoded or what is it?

If you see the client log you sent (towards the end) you will see :
FINEST: WSS1764: Canonicalized PayLoad is:

So i am looking for that on the server side.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using

________________________________

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> Hi,
>
>
>
> I’m using Metro 1.5.
>
>
>
If possible please try with Metro 2.0 once and let me know. It would be
very useful help for us.

regards,
kumar

> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 13:57
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Here it is again:
>
>
>
> Hi again,
>
>
>
> I managed to get it to work now. My WS returns a string basically and
> that string contains line breaks. When the string contains line breaks
> the validation fails on the client side. I changed my WS to just
> return a single string without line breaks and it now works.
>
>
>
> Is this a bug in the client? Or somewhere else?
>
>
>
> Thanks for your investigations. Yes it could be a bug in our
> canonicalizer. Are you using Metro 2.0 or are you using 1.5 ?. I know
> we had made some fix sometime ago.
>
> regards,
> kumar
>
>
> There is no way to get the canonicalized message on the Geneva side
> (Server and STS arerunning .NET Geneva remember?). I can do a packet
> trace, but that’ll take some time since I have to decrypt the traffic
> etc.
>
>
>
> As I said I really think this is a bug since I know .NET clients are
> working and so is the Java client. Logically, it doesn’t make sense
> that the digest verification fails when I add line breaks. It’s 100%
> reproducible. I’ve tried small messages and also very large messages.
> It always fails when I add one or more line breaks to the response.
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 12:25
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Hi,
>
>
>
> I don’t know if you’ve seen my latest message? The WS client only
> complains when the service returns line breaks.. it sounds like a bug
> somewhere in the client?
>
>
>
> I somehow missed your latest message. So it could be a bug, it appears
> the server is not using Metro ?. Would it be possible to get the
> canonicalized output on the server side so we can see what is wrong.
>
> regards,
> kumar
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 26. juni 2009 11:21
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> What exactly is that? Is it the entire Response soap body encoded or
> what is it?
>
> If you see the client log you sent (towards the end) you will see :
> FINEST: WSS1764: Canonicalized PayLoad is:
>
> So i am looking for that on the server side.
>
> regards,
> kumar
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 17:09
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Now I managed to get the WSIT client to log as well.. it’s a big one
> and it’s attached J
>
>
>
> so who is the Service, is it .NET ?. We are printing the
> canonicalized payload towards the end of the log, we need to now see
> if there is something wrong there or compare it with what the server
> side did calculate the canonicalized payload as. Can you get us the
> server side canonicalized payload.
>
> regards,
> kumar
>
> Rgds.
>
> Jesper Hvid
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 16:33
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I’ve managed to get some message logging up and running on the Geneva
> side. Attached are the client’s request to the WS after getting a
> token and the WS’ response to that.
>
>
>
> Hope this helps…
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 16:17
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
> The CosoleHandler has the default level of INFO so you would have to
> change that as well before you can see the FINE Logs.
>
> But looks like somehow the message got modified since it was singed.
> It seems like you had a some other problems earlier and you cleaned up
> your whole setup and are trying to setup everything again ?.
>
> Maybe Jiandong can help since i am off for the rest of the day today.
> But send out the details like the message recieved by the client which
> is causing the problem.
>
> regards,
> kumar
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>

[att1.html]

Jesper Hvid

10-4, I’ll give it a whirl!

Rgds.
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 14:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I’m using Metro 1.5.

If possible please try with Metro 2.0 once and let me know. It would be very useful help for us.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 13:57
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Here it is again:

Hi again,

I managed to get it to work now. My WS returns a string basically and that string contains line breaks. When the string contains line breaks the validation fails on the client side. I changed my WS to just return a single string without line breaks and it now works.

Is this a bug in the client? Or somewhere else?

Thanks for your investigations. Yes it could be a bug in our canonicalizer. Are you using Metro 2.0 or are you using 1.5 ?. I know we had made some fix sometime ago.

regards,
kumar

There is no way to get the canonicalized message on the Geneva side (Server and STS arerunning .NET Geneva remember?). I can do a packet trace, but that’ll take some time since I have to decrypt the traffic etc.

As I said I really think this is a bug since I know .NET clients are working and so is the Java client. Logically, it doesn’t make sense that the digest verification fails when I add line breaks. It’s 100% reproducible. I’ve tried small messages and also very large messages. It always fails when I add one or more line breaks to the response.

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 12:25
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Hi,

I don’t know if you’ve seen my latest message? The WS client only complains when the service returns line breaks.. it sounds like a bug somewhere in the client?

I somehow missed your latest message. So it could be a bug, it appears the server is not using Metro ?. Would it be possible to get the canonicalized output on the server side so we can see what is wrong.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 26. juni 2009 11:21
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

What exactly is that? Is it the entire Response soap body encoded or what is it?

If you see the client log you sent (towards the end) you will see :
FINEST: WSS1764: Canonicalized PayLoad is:

So i am looking for that on the server side.

regards,
kumar

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 17:09
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Now I managed to get the WSIT client to log as well.. it’s a big one and it’s attached J

so who is the Service, is it .NET ?. We are printing the canonicalized payload towards the end of the log, we need to now see if there is something wrong there or compare it with what the server side did calculate the canonicalized payload as. Can you get us the server side canonicalized payload.

regards,
kumar

Rgds.

Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 16:33
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I’ve managed to get some message logging up and running on the Geneva side. Attached are the client’s request to the WS after getting a token and the WS’ response to that.

Hope this helps…

Thanks,

Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,

Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Yes, I do that after every change I’m doing atm.

looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> I'm a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There's no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST
com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
com.sun.xml.wss.logging.impl.opt.token.level = FINEST

> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don't see gisit-sts on any of my WSDL's? I've attached them again.
> (attachment 1,2 and 3)
>
>
>
> It's true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I've gone in and...:
>
> Configured the trust store for the WS to point to the public key for
> the WS's service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I've attached the output from Glassfish (attachment 8),
> but it only tells me that it's trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won't rule out that I'm screwing something up in
> Netbeans.. I'm no professional in that area J Anyway, I've deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I'm not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> generating code...
>
> com\microsoft\schemas\message\MessageBody.java
> com\microsoft\schemas\message\ObjectFactory.java
> com\microsoft\schemas\message\package-info.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java
> Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws
> BUILD SUCCESSFUL (total time: 2 seconds)
>
>
>
> So I believe you still use earlier version of Metro.
>
> You need to download Metro 1.5 jars from here:
> https://metro.dev.java.net/1.5/
>
> Then install it to the Glassfish 2.1 instance.
>
> When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.
> [Message sent by forum member 'jdg6688' (jdg6688)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
>
>
>
>
>
>

[att1.html]

Jesper Hvid

Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I'm a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There's no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don't see gisit-sts on any of my WSDL's? I've attached them again. (attachment 1,2 and 3)

It's true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I've gone in and...:

Configured the trust store for the WS to point to the public key for the WS's service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I've attached the output from Glassfish (attachment 8), but it only tells me that it's trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won't rule out that I'm screwing something up in Netbeans.. I'm no professional in that area J Anyway, I've deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I'm not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]

suresh

Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
Did you restart your Glassfish before retesting ?
Thanks
Suresh
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> generating code...
>
> com\microsoft\schemas\message\MessageBody.java
> com\microsoft\schemas\message\ObjectFactory.java
> com\microsoft\schemas\message\package-info.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java
> Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws
> BUILD SUCCESSFUL (total time: 2 seconds)
>
>
>
> So I believe you still use earlier version of Metro.
>
> You need to download Metro 1.5 jars from here:
> https://metro.dev.java.net/1.5/
>
> Then install it to the Glassfish 2.1 instance.
>
> When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.
> [Message sent by forum member 'jdg6688' (jdg6688)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
>
>
>
>
>
>
>
>

[att1.html]

Jesper Hvid

Yes, I do that after every change I’m doing atm.

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?
Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]

suresh

Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
looks like some bug in in xwss..
we will look into that
Thanks
Suresh

>
>
> *From:* Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> generating code...
>
> com\microsoft\schemas\message\MessageBody.java
> com\microsoft\schemas\message\ObjectFactory.java
> com\microsoft\schemas\message\package-info.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java
> Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws
> BUILD SUCCESSFUL (total time: 2 seconds)
>
>
>
> So I believe you still use earlier version of Metro.
>
> You need to download Metro 1.5 jars from here:
> https://metro.dev.java.net/1.5/
>
> Then install it to the Glassfish 2.1 instance.
>
> When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.
> [Message sent by forum member 'jdg6688' (jdg6688)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
>
>
>
>
>
>
>
>
>
>

[att1.html]

Jesper Hvid

There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?

Thanks,
Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Yes, I do that after every change I’m doing atm.
looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?
Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]

Kumar Jayanti

Jesper Hvid wrote:
>
> There isn’t anything else I can do on my end to help the process along?
>
>
>
> Could it be something with the service’s certificate? Does the entire
> chain have to be trusted? Must every cert in the chain be in the
> cacerts.jks?
>
The CosoleHandler has the default level of INFO so you would have to
change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It
seems like you had a some other problems earlier and you cleaned up your
whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today.
But send out the details like the message recieved by the client which
is causing the problem.

regards,
kumar

>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 15:03
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Yes, I do that after every change I’m doing atm.
>
> looks like some bug in in xwss..
> we will look into that
> Thanks
> Suresh
>
>
>
>
> *From:* Suresh.Mandalapu@Sun.COM
> [mailto:Suresh.Mandalapu@Sun.COM]
> *Sent:* 25. juni 2009 14:49
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> Done, and retested.
>
>
>
> Nothing in the Glassfish output window.. is it logged elsewhere?
>
> Did you restart your Glassfish before retesting ?
> Thanks
> Suresh
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 14:35
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Jesper Hvid wrote:
>
> I’m a bit further in the process now. I got past the error with
> saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.
>
>
>
> My next step was to get the unlimited strength jurisdiction files
> since the client starting arguing with me about key sizes. Now I get
> the following error on the client:
>
>
>
> SEVERE: WSS1717: Error occurred while doing digest verification of
> body/payload
>
>
>
> There’s no stacktrace.. is there any way for me to enable more logging
> on the client?
>
>
>
> ... Try putting the following in logging.properties of your JRE.
>
>
>
> com.sun.xml.wss.logging.impl.opt.level = FINEST
> com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
> com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
> com.sun.xml.wss.logging.impl.opt.token.level = FINEST
>
>
>
>
>
>
> *From:* Vbkumar.Jayanti@Sun.COM
> [mailto:Vbkumar.Jayanti@Sun.COM]
> *Sent:* 25. juni 2009 12:05
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This one most likely because you are using JDK6 and somehow
> webservices-api.jar from metro version you are using is not in the
> endorsed dir of JDK6/jre/lib/endorsed
>
> regards,
> kumar
>
> Jesper Hvid wrote:
>
> Right.. got past the StackOverflowException.
>
>
>
> I had to disable secure conversation on the STS, but that took care of
> the error.
>
>
>
> Next up though, is this which happens when I try to run it:
>
>
>
> java.lang.ExceptionInInitializerError
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
>
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
> at java.lang.Class.newInstance0(Class.java:355)
>
> at java.lang.Class.newInstance(Class.java:308)
>
> at
> javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)
>
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)
>
> at
> javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)
>
> at
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)
>
> at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)
>
> at com.sun.xml.ws.api.BindingID.(BindingID.java:321)
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)
>
>
> at
> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)
>
>
> at
> com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)
>
>
> at
> com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
>
>
> at javax.xml.ws.Service.(Service.java:56)
>
> at org.tempuri.Service.(Service.java:45)
>
> at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
>
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
>
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)
>
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)
>
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
>
> at
> com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
>
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)
>
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)
>
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)
>
>
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
>
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
>
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)
>
>
> at
> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)
>
>
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>
>
> at
> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)
>
>
> at
> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)
>
> Caused by: java.lang.IllegalArgumentException:
> com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
> com.sun.xml.messaging.saaj.soap.LocalStrings
>
> at java.util.logging.Logger.getLogger(Logger.java:314)
>
> at
> com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)
>
>
> ... 63 more
>
>
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 25. juni 2009 10:48
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> Hi again,
>
>
>
> I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again.
> (attachment 1,2 and 3)
>
>
>
> It’s true that my first email had gisit-sts in them, but that was in a
> different environment. This is a local environment. Last night I tried
> deleting the project completely from the disk and I went in and
> created a new project along with new WS clients for both service and
> STS. This time it worked fine!
>
>
>
> Just now I’ve gone in and…:
>
> Configured the trust store for the WS to point to the public key for
> the WS’s service certificate (attachment 4)
>
> Configured the STS end point for the client to the WS (attachment 5)
>
> Configured the trust store and set the default user name and password
> for the client to the STS (attachment 6)
>
> Configured the user name and password for the WS client to the STS
> (attachment 7)
>
>
>
> Trouble is when I run it now I get a stackoverflow exception on the
> client side. I’ve attached the output from Glassfish (attachment 8),
> but it only tells me that it’s trying to load the wsit-client.xml-file
> (attachment 9) over and over again until it finally runs out of plates
> on the stack. Any help?
>
>
>
> Thanks!
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 24. juni 2009 21:50
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> This could be the problem:
>
> 1. You use wsimport against a local copy of the STS wsdl:
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl. Then it references another remote
> wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn
> references
>
> remote copy of the original copy of the wsdl ...
>
>
> Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?
>
>
>
>
> Jesper Hvid wrote:
>
> Hi agian,
>
>
>
> I just tried downloading metro 1.5 and running the wsitimport.bat
> utility directly from the Metro 1.5 directory. Command:
>
>
>
> c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated
> http://jehdb2.gen
>
> evadom.local/activests/active.svc?wsdl
>
>
>
> Result:
>
> [ERROR] duplicate "message" entity:
> "IWSTrust13Sync_Trust13Cancel_InputMessage"
>
> line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl
>
>
>
> *From:* Jesper Hvid [mailto:jh@globeteam.com]
> *Sent:* 24. juni 2009 09:55
> *To:* users@metro.dev.java.net
> *Subject:* RE: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> I certainly won’t rule out that I’m screwing something up in
> Netbeans.. I’m no professional in that area J Anyway, I’ve deployed
> Metro 1.5 to Glassfish using this guide:
>
> https://metro.dev.java.net/1.5/docs/install.html
>
>
>
> However, I noticed that in my web project it seems to reference 1.4?
> I’m not sure how to update that part (screenshot attached).
>
>
>
> Thanks,
>
> Jesper Hvid
>
>
>
> *From:* Jiandong.Guo@Sun.COM
> [mailto:Jiandong.Guo@Sun.COM]
> *Sent:* 23. juni 2009 23:56
> *To:* users@metro.dev.java.net
> *Subject:* Re: Problem with WSIT client to Geneva Service using token
> from Geneva STS
>
>
>
> http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...
>
> Jiandong Guo wrote:
>
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>
> Hi,
>
> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>
> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>
> -----Original Message-----
> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
> Sent: 22. juni 2009 21:04
> To: users@metro.dev.java.net
> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>
> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>
> http://131.107.153.205/trust?wsdl
>
> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
> parsing WSDL...
>
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>
> generating code...
>
> com\microsoft\schemas\message\MessageBody.java
> com\microsoft\schemas\message\ObjectFactory.java
> com\microsoft\schemas\message\package-info.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java
> org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java
> org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java
> com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java
> Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws
> BUILD SUCCESSFUL (total time: 2 seconds)
>
>
>
> So I believe you still use earlier version of Metro.
>
> You need to download Metro 1.5 jars from here:
> https://metro.dev.java.net/1.5/
>
> Then install it to the Glassfish 2.1 instance.
>
> When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.
> [Message sent by forum member 'jdg6688' (jdg6688)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[att1.html]

Jesper Hvid

Hi,

I’ll look into changing the level for the console.

I had problems reading the WSDL file for the STS earlier, but deleting the client project and creating it again resolved that issue. The .NET Geneva STS and the .NET Geneva WS remain unchanged. As I mentioned earlier I can see that 1) the STS is issuing a token and 2) the WS receives and validates it to be authentic. I can trace the .NET side right up to the WS sending a response to the client.

I’ll see if I can find a way of getting the WS’ response to the client out.

Thanks for all your help today.. We’re close now so it can’t be long ☺

Rgds.
Jesper Hvid

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 16:17
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
There isn’t anything else I can do on my end to help the process along?

Could it be something with the service’s certificate? Does the entire chain have to be trusted? Must every cert in the chain be in the cacerts.jks?
The CosoleHandler has the default level of INFO so you would have to change that as well before you can see the FINE Logs.

But looks like somehow the message got modified since it was singed. It seems like you had a some other problems earlier and you cleaned up your whole setup and are trying to setup everything again ?.

Maybe Jiandong can help since i am off for the rest of the day today. But send out the details like the message recieved by the client which is causing the problem.

regards,
kumar

Thanks,
Jesper Hvid

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 15:03
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Yes, I do that after every change I’m doing atm.
looks like some bug in in xwss..
we will look into that
Thanks
Suresh

From: Suresh.Mandalapu@Sun.COM [mailto:Suresh.Mandalapu@Sun.COM]
Sent: 25. juni 2009 14:49
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:
Done, and retested.

Nothing in the Glassfish output window.. is it logged elsewhere?
Did you restart your Glassfish before retesting ?
Thanks
Suresh

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 14:35
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

Jesper Hvid wrote:

I’m a bit further in the process now. I got past the error with saaj-impl.jar by getting the newest version (1.3.3) and replacing mine.

My next step was to get the unlimited strength jurisdiction files since the client starting arguing with me about key sizes. Now I get the following error on the client:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload

There’s no stacktrace.. is there any way for me to enable more logging on the client?

... Try putting the following in logging.properties of your JRE.

com.sun.xml.wss.logging.impl.opt.level = FINEST

com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST

com.sun.xml.wss.logging.impl.opt.signature.level = FINEST

com.sun.xml.wss.logging.impl.opt.token.level = FINEST

From: Vbkumar.Jayanti@Sun.COM [mailto:Vbkumar.Jayanti@Sun.COM]
Sent: 25. juni 2009 12:05
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This one most likely because you are using JDK6 and somehow webservices-api.jar from metro version you are using is not in the endorsed dir of JDK6/jre/lib/endorsed

regards,
kumar

Jesper Hvid wrote:

Right.. got past the StackOverflowException.

I had to disable secure conversation on the STS, but that took care of the error.

Next up though, is this which happens when I try to run it:

java.lang.ExceptionInInitializerError

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:55)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:133)

at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:166)

at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:75)

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:144)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:178)

at com.sun.xml.ws.api.SOAPVersion.(SOAPVersion.java:83)

at com.sun.xml.ws.api.BindingID.(BindingID.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:434)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:321)

at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:146)

at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:228)

at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:176)

at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)

at javax.xml.ws.Service.(Service.java:56)

at org.tempuri.Service.(Service.java:45)

at org.apache.jsp.index_jsp._jspService(index_jsp.java from :64)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:431)

at org.apache.catalina.core.StandardWrapperValve.preInvoke(StandardWrapperValve.java:462)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:139)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:186)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)

at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:142)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:719)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:657)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:651)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1030)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)

at com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:633)

at com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:570)

at com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:827)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)

at com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:71)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)

at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:325)

at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:184)

Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings

at java.util.logging.Logger.getLogger(Logger.java:314)

at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.(SAAJMetaFactoryImpl.java:71)

... 63 more

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 25. juni 2009 10:48
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

Hi again,

I don’t see gisit-sts on any of my WSDL’s? I’ve attached them again. (attachment 1,2 and 3)

It’s true that my first email had gisit-sts in them, but that was in a different environment. This is a local environment. Last night I tried deleting the project completely from the disk and I went in and created a new project along with new WS clients for both service and STS. This time it worked fine!

Just now I’ve gone in and…:

Configured the trust store for the WS to point to the public key for the WS’s service certificate (attachment 4)

Configured the STS end point for the client to the WS (attachment 5)

Configured the trust store and set the default user name and password for the client to the STS (attachment 6)

Configured the user name and password for the WS client to the STS (attachment 7)

Trouble is when I run it now I get a stackoverflow exception on the client side. I’ve attached the output from Glassfish (attachment 8), but it only tells me that it’s trying to load the wsit-client.xml-file (attachment 9) over and over again until it finally runs out of plates on the stack. Any help?

Thanks!

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 24. juni 2009 21:50
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

This could be the problem:

1. You use wsimport against a local copy of the STS wsdl: http://jehdb2.gen

evadom.local/activests/active.svc?wsdl. Then it references another remote
wsdl http://gisit-sts/ActiveSTS/Active.svc?wsdl=wsdl0 whihc in turn references

remote copy of the original copy of the wsdl ...

Can you try directly with http://gisit-sts/ActiveSTS/Active.svc?wsdl ?

Jesper Hvid wrote:

Hi agian,

I just tried downloading metro 1.5 and running the wsitimport.bat utility directly from the Metro 1.5 directory. Command:

c:\Users\Administrator\Desktop\metro\bin\wsimport -d generated http://jehdb2.gen

evadom.local/activests/active.svc?wsdl

Result:

[ERROR] duplicate "message" entity: "IWSTrust13Sync_Trust13Cancel_InputMessage"

line 1 of http://jehdb2.genevadom.local/ActiveSTS/Active.svc?wsdl

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 24. juni 2009 09:55
To: users@metro.dev.java.net
Subject: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I certainly won’t rule out that I’m screwing something up in Netbeans.. I’m no professional in that area J Anyway, I’ve deployed Metro 1.5 to Glassfish using this guide:

https://metro.dev.java.net/1.5/docs/install.html

However, I noticed that in my web project it seems to reference 1.4? I’m not sure how to update that part (screenshot attached).

Thanks,

Jesper Hvid

From: Jiandong.Guo@Sun.COM [mailto:Jiandong.Guo@Sun.COM]
Sent: 23. juni 2009 23:56
To: users@metro.dev.java.net
Subject: Re: Problem with WSIT client to Geneva Service using token from Geneva STS

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:

The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
the setting up problem when you create client for your wsdl.

Thanks!

Jiandong

Jesper Hvid wrote:

Hi,

I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?

My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.

-----Original Message-----

From: metro@javadesktop.org [mailto:metro@javadesktop.org]

Sent: 22. juni 2009 21:04

To: users@metro.dev.java.net

Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS

I don't see this when I try a similar STS WSDL from WCF plugfest site:

http://131.107.153.205/trust?wsdl

command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl

parsing WSDL...

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync3, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync1": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync1, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "CustomBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync2": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync2, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] SOAP port "WSHttpBinding_IWSTrustFeb2005Sync3": uses a non-standard SOAP 1.2 binding.

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Issue" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Renew" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port WSHttpBinding_IWSTrustFeb2005Sync3, Operations "TrustFeb2005Validate" and "TrustFeb2005Cancel" have the same request body block {http://schemas.xmlsoap.org/ws/2005/02/trust}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction

line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl

generating code...

com\microsoft\schemas\message\MessageBody.java

com\microsoft\schemas\message\ObjectFactory.java

com\microsoft\schemas\message\package-info.java

org\xmlsoap\schemas\ws\_2005\_02\trust\ObjectFactory.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenResponseType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\RequestSecurityTokenType.java

org\xmlsoap\schemas\ws\_2005\_02\trust\package-info.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\ObjectFactory.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseCollectionType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenResponseType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\RequestSecurityTokenType.java

org\oasis_open\docs\ws_sx\ws_trust\_200512\package-info.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrust13Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\IWSTrustFeb2005Sync.java

com\microsoft\schemas\ws\_2008\_06\identity\securitytokenservice\SecurityTokenService.java

Copying 15 files to C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated-sources\jax-ws

BUILD SUCCESSFUL (total time: 2 seconds)

So I believe you still use earlier version of Metro.

You need to download Metro 1.5 jars from here:

https://metro.dev.java.net/1.5/

Then install it to the Glassfish 2.1 instance.

When you create the client, make sure it use the Glassfish with the Metro 1.5 installed.

[Message sent by forum member 'jdg6688' (jdg6688)]

http://forums.java.net/jive/thread.jspa?messageID=352398

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net

For additional commands, e-mail: users-help@metro.dev.java.net

This body part will be downloaded on demand.

[att1.html]

Jiandong Guo

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7974de06-3d9...

Jiandong Guo wrote:
> The plugfest wsdl contains bindings for both the Trust13 and TrustFeb2005.
> Your STS wsdl contains exact the TrustFeb2005 part. So it is very likely
> the setting up problem when you create client for your wsdl.
>
> Thanks!
>
> Jiandong
>
> Jesper Hvid wrote:
>> Hi,
>>
>> I have no problem loading the WSDL from this particular STS, but I'd very much like to see how it's configured. Do you have access to the Web.config-file for the plugfest STS?
>>
>> My original WSDL (attached again) still does not load, however. There are differences in the files also, which can be seen with the naked eye.
>>
>> -----Original Message-----
>> From: metro@javadesktop.org [mailto:metro@javadesktop.org]
>> Sent: 22. juni 2009 21:04
>> To: users@metro.dev.java.net
>> Subject: Re: RE: Problem with WSIT client to Geneva Service using token from Geneva STS
>>
>> I don't see this when I try a similar STS WSDL from WCF plugfest site:
>>
>> http://131.107.153.205/trust?wsdl
>>
>> command line: wsimport -d C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -extension -Xnocompile -keep -s C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\build\generated\jax-wsCache\trust -catalog C:\metro\WSIT\samples\wcf-sts\WCFSTSClient\catalog.xml -verbose C:\metro\WSIT\samples\wcf-sts\WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl -wsdllocation http://131.107.153.205/trust?wsdl
>> parsing WSDL...
>>
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync1, Operations "Trust13Validate" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Issue" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> line 1 of file:/C:/metro/WSIT/samples/wcf-sts/WCFSTSClient/src/conf/xml-resources/web-service-references/trust/wsdl/131.107.153.205/trust.wsdl
>>
>> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations must have unique operation signaure on the wire for successful dispatch. In port CustomBinding_IWSTrust13Sync2, Operations "Trust13Renew" and "Trust13Cancel" have the same request body block {http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken. Method dispatching may fail, runtime will try to dispatch using SOAPAction
>> li