You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Yonghe <ya...@gmail.com> on 2010/11/06 00:51:19 UTC
stack overflow while parsing SecurityTokenService from .Net 4.0
Hi,
I am trying to create a WS-Trust client for .net 4.0. However, CXF's
wsdl2java reports stack overflow while parsing the wsdl from .net's
SecurityTokenService. Here is the wsdl
http://cxf.547215.n5.nabble.com/file/n3252672/sts.zip sts.zip . I would like
to know what is wrong with the wsdl? or, it is a bug of wsdl2java?
Thanks,
Yonghe
--
View this message in context: http://cxf.547215.n5.nabble.com/stack-overflow-while-parsing-SecurityTokenService-from-Net-4-0-tp3252672p3252672.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: stack overflow while parsing SecurityTokenService from .Net 4.0
Posted by Yonghe <ya...@gmail.com>.
I double-checked it that i am using 2.3.0 and i am still getting
stackoverflow error while parsing the wsdl with wsdl2java. I am using
Eclipse Helios and have WTP 3.2.2 installed. WTP comes with a WS-I message
Validator. I have validated the wsdl with the validator without any
complains. Although i am not sure what the validator did, it should include
WS-I Basic Profile.
I am not sure what you mean "use the STSClient object that CXF already has
built in". Currently, I have a cxf.xml at the root of classpath. It looks
like these:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:http="http://cxf.apache.org/transports/http/configuration"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xmlns:cxf="http://cxf.apache.org/core"
xmlns:p="http://cxf.apache.org/policy"
xmlns:sec="http://cxf.apache.org/configuration/security"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/policy
http://cxf.apache.org/schemas/policy.xsd">
<cxf:bus>
<cxf:features>
<p:policies enabled="true" />
<cxf:logging />
</cxf:features>
</cxf:bus>
<jaxws:client
name="{http://tempuri.org/}WS2007FederationHttpBinding_IService1"
createdFromAPI="true">
<jaxws:properties>
<entry key="ws-security.encryption.properties"
value="etc/clientKeystore.properties" />
<entry key="ws-security.encryption.username" value="localhost" />
<entry key="ws-security.sts.client">
<bean class="org.apache.cxf.ws.security.trust.STSClient">
<constructor-arg ref="cxf" />
<property name="wsdlLocation" value="etc/sts.wsdl" />
<property name="serviceName"
value="{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}SecurityTokenService"
/>
<property name="endpointName"
value="{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}WS2007FederationHttpBinding_IWSTrust13Sync"
/>
<property name="properties">
<map>
<entry key="ws-security.username" value="cctest" />
<entry key="ws-security.password" value="password" />
<entry key="ws-security.signature.properties"
value="etc/yoyan.properties" />
<entry key="ws-security.encryption.properties"
value="etc/clientKeystore.properties" />
<entry key="ws-security.encryption.username" value="localhost" />
<entry key="ws-security.callback-handler"
value="com.microsoft.stc.client.KeystorCallback" />
</map>
</property>
<property name="features">
<list>
<cxf:logging />
</list>
</property>
</bean>
</entry>
</jaxws:properties>
</jaxws:client>
<bean
name="{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}WS2007FederationHttpBinding_IWSTrust13Sync.sct-client.sts-client"
class="org.apache.cxf.ws.security.trust.STSClient" abstract="true">
<property name="wsdlLocation" value="etc/sts.wsdl" />
<property name="serviceName"
value="{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}SecurityTokenService"
/>
<property name="endpointName"
value="{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}WS2007FederationHttpBinding_IWSTrust13Sync"
/>
<property name="properties">
<map>
<entry key="ws-security.username" value="cctest" />
<entry key="ws-security.password" value="password" />
<entry key="ws-security.signature.properties"
value="etc/yoyan.properties" />
<entry key="ws-security.encryption.properties"
value="etc/clientKeystore.properties" />
<entry key="ws-security.sts.token.properties"
value="etc/clientKeystore.properties" />
<entry key="ws-security.callback-handler"
value="com.microsoft.stc.client.KeystorCallback" />
</map>
</property>
<property name="features">
<list>
<cxf:logging />
</list>
</property>
</bean>
</beans>
Seems to me that I am using the STSClient object. This cxf.xml cause stack
overflow. By the way, my JDK is 1.6.0Update21 x64.
Yonghe
Daniel Kulp wrote:
>
> On Friday 05 November 2010 7:51:19 pm Yonghe wrote:
>> Hi,
>>
>> I am trying to create a WS-Trust client for .net 4.0. However, CXF's
>> wsdl2java reports stack overflow while parsing the wsdl from .net's
>> SecurityTokenService.
>
> What version of CXF? 2.3.0 seems to not stack trace, but doesn't
> actually
> work either:
>
>
> WSDLToJava Error: Non-unique body parts! In a port, operations must have
> unique operation signatures on the wire for successful dispatching. In
> port
> {http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}WS2007HttpBinding_IWSTrust13Sync,
> operations
> "{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}Trust13Cancel"
> and
> "{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}Trust13Renew"
> have the same request body block {http://docs.oasis-open.org/ws-sx/ws-
> trust/200512}RequestSecurityToken
>
>
> If you try the RI's wsimport, you get similar messgaes:
> [WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations
> must have unique operation signaure on the wire for successful dispatch.
> In
> port WS2007FederationHttpBinding_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 112 of file:/tmp/sts.wsdl
>
> although it does proceed to generate code that may or may not work.
>
>
>
>> Here is the wsdl
>> http://cxf.547215.n5.nabble.com/file/n3252672/sts.zip sts.zip . I would
>> like to know what is wrong with the wsdl? or, it is a bug of wsdl2java?
>
> Basically, the STS wsdl is not a WSI-Basic Profile compliant wsdl and thus
> doesn't map onto JAX-WS interfaces very well at all. My suggestion would
> be
> to use the STSClient object that CXF already has built in and seeing if
> that
> would work for you.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://cxf.547215.n5.nabble.com/Re-stack-overflow-while-parsing-SecurityTokenService-from-Net-4-0-tp3255867p3257533.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: stack overflow while parsing SecurityTokenService from .Net 4.0
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 05 November 2010 7:51:19 pm Yonghe wrote:
> Hi,
>
> I am trying to create a WS-Trust client for .net 4.0. However, CXF's
> wsdl2java reports stack overflow while parsing the wsdl from .net's
> SecurityTokenService.
What version of CXF? 2.3.0 seems to not stack trace, but doesn't actually
work either:
WSDLToJava Error: Non-unique body parts! In a port, operations must have
unique operation signatures on the wire for successful dispatching. In port
{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}WS2007HttpBinding_IWSTrust13Sync,
operations
"{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}Trust13Cancel"
and
"{http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice}Trust13Renew"
have the same request body block {http://docs.oasis-open.org/ws-sx/ws-
trust/200512}RequestSecurityToken
If you try the RI's wsimport, you get similar messgaes:
[WARNING] Non unique body parts! In a port, as per BP 1.1 R2710 operations
must have unique operation signaure on the wire for successful dispatch. In
port WS2007FederationHttpBinding_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 112 of file:/tmp/sts.wsdl
although it does proceed to generate code that may or may not work.
> Here is the wsdl
> http://cxf.547215.n5.nabble.com/file/n3252672/sts.zip sts.zip . I would
> like to know what is wrong with the wsdl? or, it is a bug of wsdl2java?
Basically, the STS wsdl is not a WSI-Basic Profile compliant wsdl and thus
doesn't map onto JAX-WS interfaces very well at all. My suggestion would be
to use the STSClient object that CXF already has built in and seeing if that
would work for you.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog