[jira] Created: (CXF-3327) PhaseInterceptorChain should warn user if the interceptor phase can't be found
PhaseInterceptorChain should warn user if the interceptor phase can't be found -- Key: CXF-3327 URL: https://issues.apache.org/jira/browse/CXF-3327 Project: CXF Issue Type: Improvement Components: Core Reporter: Willem Jiang Assignee: Willem Jiang Priority: Minor Fix For: 2.2.13, 2.4, 2.3.3 When the user set a wrong phase string, he should be warned otherwise it will take a long time to figure out why the interceptor is not working. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CXF-3328) Improve WS-I Basic Profile conformance
Improve WS-I Basic Profile conformance -- Key: CXF-3328 URL: https://issues.apache.org/jira/browse/CXF-3328 Project: CXF Issue Type: Improvement Components: Soap Binding Affects Versions: 2.3.1 Reporter: Dennis Kieselhorst The auto-generated wsdls currently violate the following WS-I Basic Profile requirements: * BP2012: R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its wsoap11:body element(s), only to wsdl:part element(s) that have been defined using the element attribute (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2012). * BP2101: R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2101). * BP2119: R2210 If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a wsoap11:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl:parts (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2119). * BP2120a: R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2120a). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3327) PhaseInterceptorChain should warn user if the interceptor phase can't be found
[ https://issues.apache.org/jira/browse/CXF-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-3327. --- Resolution: Fixed > PhaseInterceptorChain should warn user if the interceptor phase can't be found > -- > > Key: CXF-3327 > URL: https://issues.apache.org/jira/browse/CXF-3327 > Project: CXF > Issue Type: Improvement > Components: Core >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.2.13, 2.4, 2.3.3 > > > When the user set a wrong phase string, he should be warned otherwise it will > take a long time to figure out why the interceptor is not working. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CXF-3329) idl2wsdl: attributes of structs with the same name as a type do not show up in XSD
idl2wsdl: attributes of structs with the same name as a type do not show up in
XSD
--
Key: CXF-3329
URL: https://issues.apache.org/jira/browse/CXF-3329
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.3.2, 2.3.3
Reporter: Arnoud Glimmerveen
I am using idl2wsdl to generate a XML schema from a set of type definitions in
IDL using the cxf-corbatools-maven-plugin. If the IDL has structures containing
attributes with the same name as a type in the same IDL, that attribute does
not show up in the generated XSD.
For example, the following IDL definition:
{code}
module myModule
{
struct myStruct
{
long myStruct;
long otherField;
};
};
{code}
results in the XSD below:
{code:xml}
http://my.company.com"; xmlns:tns="http://my.company.com";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
{code}
The attribute myStruct from the IDL is not present in the XSD.
The output of idl2wsdl is as follows:
{noformat}
idl2wsdl -o path/to/output -x http://my.company.com -T types.xsd -verbose
path/to/types.idl
idl2wsdl - Apache CXF 2.3.3-SNAPSHOT
( module myModule ( struct myStruct long myStruct long otherField ) )
{noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CXF-3330) URITemplate does not escape literal '+' characters
URITemplate does not escape literal '+' characters -- Key: CXF-3330 URL: https://issues.apache.org/jira/browse/CXF-3330 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 2.3.2 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.4, 2.3.3 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3330) URITemplate does not escape literal '+' characters
[ https://issues.apache.org/jira/browse/CXF-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3330. --- Resolution: Fixed https://issues.apache.org/jira/browse/CXF-3330 > URITemplate does not escape literal '+' characters > -- > > Key: CXF-3330 > URL: https://issues.apache.org/jira/browse/CXF-3330 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.3.2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4, 2.3.3 > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CXF-3330) URITemplate does not escape literal '+' characters
[ https://issues.apache.org/jira/browse/CXF-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-3330: -- Comment: was deleted (was: https://issues.apache.org/jira/browse/CXF-3330) > URITemplate does not escape literal '+' characters > -- > > Key: CXF-3330 > URL: https://issues.apache.org/jira/browse/CXF-3330 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.3.2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4, 2.3.3 > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
wsdl2java client generation error with WS-Trust
Hi!
I hope i'm writing to the right mailing list. I want to use OpenAm, and it
has a few webservices. When i tried to generate a client to one of them, i
got the following error message (i'm using SpringSource Tool Suitewith CXF
2.3.1):
WSDLToJava Error:
Summary: Failures: 2, Warnings: 0
<<< ERROR!
Part in Message
<{http://localhost:8080/openfm/SecurityTokenService/}ISecurityTokenService_IssueToken_InputMessage>
referenced Type
<{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken> can
not be found in the schemas
Part in Message
<{http://localhost:8080/openfm/SecurityTokenService/}ISecurityTokenService_IssueToken_OutputMessage>
referenced Type
<{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse>
can not be found in the schemas
A document-literal binding in a DESCRIPTION MUST refer, in each of its
soapbind:body element(s),only to wsdl:part element(s) that have been defined
using the element attribute.
org.apache.cxf.tools.common.ToolException:
Summary: Failures: 2, Warnings: 0
<<< ERROR!
Part in Message
<{http://localhost:8080/openfm/SecurityTokenService/}ISecurityTokenService_IssueToken_InputMessage>
referenced Type
<{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken> can
not be found in the schemas
Part in Message
<{http://localhost:8080/openfm/SecurityTokenService/}ISecurityTokenService_IssueToken_OutputMessage>
referenced Type
<{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse>
can not be found in the schemas
A document-literal binding in a DESCRIPTION MUST refer, in each of its
soapbind:body element(s),only to wsdl:part element(s) that have been defined
using the element attribute.
at
org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:141)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:201)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:61)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:167)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:128)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:271)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:184)
The wsdl to the webservice i'm trying to use is the following:
http://schemas.xmlsoap.org/wsdl/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:wsap10="http://www.w3.org/2006/05/addressing/wsdl";
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing";
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/09/policy/addressing";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract";
xmlns:tns="http://localhost:8080/openfm/SecurityTokenService/";
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex";
xmlns:wsa10="http://www.w3.org/2005/08/addressing";
name="SecurityTokenService"
targetNamespace="http://localhost:8080/openfm/SecurityTokenService/";>
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";>
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always";>
[jira] Commented: (CXF-3328) Improve WS-I Basic Profile conformance
[ https://issues.apache.org/jira/browse/CXF-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993543#comment-12993543 ] Glen Mazza commented on CXF-3328: - The JAX-WS specification (here, the Java-to-WSDL mapping) is what CXF must implement, even if it allows users to violate the WS-I Basic Profile requirements. For example R2710 violations are going to happen if the developer chooses construct his Java class to create those situations, same with many other of the Basic Profile rules. Choosing to follow the WS-I Basic Profile is the prerogative of the developer, JAX-WS does not require you to follow WS-I Basic Profile. In other words, what you're asking us to do is akin to asking Microsoft Word developers to prohibit typing of double negatives or split infinitives. The WS-I maintains tools to make sure your WSDLs are "legit" w.r.t. the Basic Profiles, tools that can be used regardless of web service stack (CXF or Metro or other) you're using, so I don't see a need for CXF to duplicate this effort. However, if there are specific Java-to-WSDL changes CXF can make that don't violate the JAX-WS spec and would remove a WS-I basic profile violation, that would be a good idea for us to consider. > Improve WS-I Basic Profile conformance > -- > > Key: CXF-3328 > URL: https://issues.apache.org/jira/browse/CXF-3328 > Project: CXF > Issue Type: Improvement > Components: Soap Binding >Affects Versions: 2.3.1 >Reporter: Dennis Kieselhorst > > The auto-generated wsdls currently violate the following WS-I Basic Profile > requirements: > * BP2012: R2204 A document-literal binding in a DESCRIPTION MUST refer, in > each of its wsoap11:body element(s), only to wsdl:part element(s) that have > been defined using the element attribute > (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2012). > * BP2101: R2001 A DESCRIPTION MUST only use the WSDL "import" statement to > import another WSDL description > (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2101). > * BP2119: R2210 If a document-literal binding in a DESCRIPTION does not > specify the parts attribute on a wsoap11:body element, the corresponding > abstract wsdl:message MUST define zero or one wsdl:parts > (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2119). > * BP2120a: R2710 The operations in a wsdl:binding in a DESCRIPTION MUST > result in operation signatures that are different from one another > (http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#BP2120a). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3322) Introduce the extended SecurityContext interface
[ https://issues.apache.org/jira/browse/CXF-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3322. --- Resolution: Fixed Assignee: Sergey Beryozkin We will update this interface if it proves to be incomplete > Introduce the extended SecurityContext interface > > > Key: CXF-3322 > URL: https://issues.apache.org/jira/browse/CXF-3322 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.3.2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4, 2.3.3 > > > As discussed with Christian, it would be handy to have an access to the list > of roles and possibly Subject representing a current authenticated Principal. > That will be useful for the advanced context propagation cases work better. > CXF SecurityContexts can optionally implement it and then CXF interceptors > sitting after JAASLoginInterceptor or WS-Security related authorization > interceptors can get the list of roles or the Subject and wrap into Spring > Security contexts, etc, etc -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3329) idl2wsdl: attributes of structs with the same name as a type do not show up in XSD
[
https://issues.apache.org/jira/browse/CXF-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993572#comment-12993572
]
Ulhas Bhole commented on CXF-3329:
--
Can you attach a sample idl file? I wouldn't mind having a quick look into it
since I recently fixed similar duplicate attributes issue.
> idl2wsdl: attributes of structs with the same name as a type do not show up
> in XSD
> --
>
> Key: CXF-3329
> URL: https://issues.apache.org/jira/browse/CXF-3329
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.3.2, 2.3.3
>Reporter: Arnoud Glimmerveen
> Labels: idl2wsdl
>
> I am using idl2wsdl to generate a XML schema from a set of type definitions
> in IDL using the cxf-corbatools-maven-plugin. If the IDL has structures
> containing attributes with the same name as a type in the same IDL, that
> attribute does not show up in the generated XSD.
> For example, the following IDL definition:
> {code}
> module myModule
> {
> struct myStruct
> {
> long myStruct;
> long otherField;
> };
> };
> {code}
> results in the XSD below:
> {code:xml}
>
> elementFormDefault="unqualified" targetNamespace="http://my.company.com";
> xmlns:tns="http://my.company.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
> {code}
> The attribute myStruct from the IDL is not present in the XSD.
> The output of idl2wsdl is as follows:
> {noformat}
> idl2wsdl -o path/to/output -x http://my.company.com -T types.xsd -verbose
> path/to/types.idl
> idl2wsdl - Apache CXF 2.3.3-SNAPSHOT
> ( module myModule ( struct myStruct long myStruct long otherField ) )
> {noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CXF-3329) idl2wsdl: attributes of structs with the same name as a type do not show up in XSD
[
https://issues.apache.org/jira/browse/CXF-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnoud Glimmerveen updated CXF-3329:
Attachment: sample.idl
Sample IDL file, where attribute myStruct does not appear in the generated XSD.
> idl2wsdl: attributes of structs with the same name as a type do not show up
> in XSD
> --
>
> Key: CXF-3329
> URL: https://issues.apache.org/jira/browse/CXF-3329
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.3.2, 2.3.3
>Reporter: Arnoud Glimmerveen
> Labels: idl2wsdl
> Attachments: sample.idl
>
>
> I am using idl2wsdl to generate a XML schema from a set of type definitions
> in IDL using the cxf-corbatools-maven-plugin. If the IDL has structures
> containing attributes with the same name as a type in the same IDL, that
> attribute does not show up in the generated XSD.
> For example, the following IDL definition:
> {code}
> module myModule
> {
> struct myStruct
> {
> long myStruct;
> long otherField;
> };
> };
> {code}
> results in the XSD below:
> {code:xml}
>
> elementFormDefault="unqualified" targetNamespace="http://my.company.com";
> xmlns:tns="http://my.company.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
> {code}
> The attribute myStruct from the IDL is not present in the XSD.
> The output of idl2wsdl is as follows:
> {noformat}
> idl2wsdl -o path/to/output -x http://my.company.com -T types.xsd -verbose
> path/to/types.idl
> idl2wsdl - Apache CXF 2.3.3-SNAPSHOT
> ( module myModule ( struct myStruct long myStruct long otherField ) )
> {noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CXF-3329) idl2wsdl: attributes of structs with the same name as a type do not show up in XSD
[
https://issues.apache.org/jira/browse/CXF-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993596#comment-12993596
]
Arnoud Glimmerveen edited comment on CXF-3329 at 2/11/11 5:24 PM:
--
I attached the sample as IDL file. The attribute myStruct does not appear in
the generated XSD.
was (Author: arnoud):
Sample IDL file, where attribute myStruct does not appear in the generated
XSD.
> idl2wsdl: attributes of structs with the same name as a type do not show up
> in XSD
> --
>
> Key: CXF-3329
> URL: https://issues.apache.org/jira/browse/CXF-3329
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.3.2, 2.3.3
>Reporter: Arnoud Glimmerveen
> Labels: idl2wsdl
> Attachments: sample.idl
>
>
> I am using idl2wsdl to generate a XML schema from a set of type definitions
> in IDL using the cxf-corbatools-maven-plugin. If the IDL has structures
> containing attributes with the same name as a type in the same IDL, that
> attribute does not show up in the generated XSD.
> For example, the following IDL definition:
> {code}
> module myModule
> {
> struct myStruct
> {
> long myStruct;
> long otherField;
> };
> };
> {code}
> results in the XSD below:
> {code:xml}
>
> elementFormDefault="unqualified" targetNamespace="http://my.company.com";
> xmlns:tns="http://my.company.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
> {code}
> The attribute myStruct from the IDL is not present in the XSD.
> The output of idl2wsdl is as follows:
> {noformat}
> idl2wsdl -o path/to/output -x http://my.company.com -T types.xsd -verbose
> path/to/types.idl
> idl2wsdl - Apache CXF 2.3.3-SNAPSHOT
> ( module myModule ( struct myStruct long myStruct long otherField ) )
> {noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CXF-3331) Schema validation breaks with multiple Instances of Java first JAX-WS service
[ https://issues.apache.org/jira/browse/CXF-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Turkel updated CXF-3331: - Attachment: HelloWorldTest.java HelloWorldImpl.java > Schema validation breaks with multiple Instances of Java first JAX-WS service > - > > Key: CXF-3331 > URL: https://issues.apache.org/jira/browse/CXF-3331 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3.2 >Reporter: Joel Turkel > Attachments: HelloWorld.java, HelloWorldImpl.java, HelloWorldTest.java > > > When publishing two instances of a Java first JAX-WS service, valid messages > sent to the second service always fail schema validation. With the attached > test case, the call to the second service fails with the following stack > trace: > org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find > the declaration of element 'ns2:sayHi'. > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:791) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:632) > at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:133) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:311) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:280) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:931) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:868) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) > at org.eclipse.jetty.server.Server.handle(Server.java:352) > at > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:596) > at > org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1068) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:805) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218) > at > org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:508) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:451) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.xml.bind.UnmarshalException > - with linked exception: > [org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of > element 'ns2:sayHi'.] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:768) > ... 24 more > Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the > declaration of element 'ns2:sayHi'. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1916) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705) > at > com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(Validator
[jira] Created: (CXF-3331) Schema validation breaks with multiple Instances of Java first JAX-WS service
Schema validation breaks with multiple Instances of Java first JAX-WS service - Key: CXF-3331 URL: https://issues.apache.org/jira/browse/CXF-3331 Project: CXF Issue Type: Bug Affects Versions: 2.3.2 Reporter: Joel Turkel Attachments: HelloWorld.java, HelloWorldImpl.java, HelloWorldTest.java When publishing two instances of a Java first JAX-WS service, valid messages sent to the second service always fail schema validation. With the attached test case, the call to the second service fails with the following stack trace: org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element 'ns2:sayHi'. at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:791) at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:632) at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:133) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:311) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:280) at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:931) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:868) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) at org.eclipse.jetty.server.Server.handle(Server.java:352) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:596) at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1068) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:805) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:508) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:451) at java.lang.Thread.run(Thread.java:662) Caused by: javax.xml.bind.UnmarshalException - with linked exception: [org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ns2:sayHi'.] at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:768) ... 24 more Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ns2:sayHi'. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1916) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705) at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:549) at com.sun.xml.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.startElement(ValidatingUnmarshaller.java:96) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:242) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnec
[jira] Updated: (CXF-3331) Schema validation breaks with multiple Instances of Java first JAX-WS service
[ https://issues.apache.org/jira/browse/CXF-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Turkel updated CXF-3331: - Attachment: HelloWorld.java > Schema validation breaks with multiple Instances of Java first JAX-WS service > - > > Key: CXF-3331 > URL: https://issues.apache.org/jira/browse/CXF-3331 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3.2 >Reporter: Joel Turkel > Attachments: HelloWorld.java, HelloWorldImpl.java, HelloWorldTest.java > > > When publishing two instances of a Java first JAX-WS service, valid messages > sent to the second service always fail schema validation. With the attached > test case, the call to the second service fails with the following stack > trace: > org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find > the declaration of element 'ns2:sayHi'. > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:791) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:632) > at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:133) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:311) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:280) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:931) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:868) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) > at org.eclipse.jetty.server.Server.handle(Server.java:352) > at > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:596) > at > org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1068) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:805) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218) > at > org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:508) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:451) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.xml.bind.UnmarshalException > - with linked exception: > [org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of > element 'ns2:sayHi'.] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:768) > ... 24 more > Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the > declaration of element 'ns2:sayHi'. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1916) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705) > at > com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:549) > at > com.
[jira] Assigned: (CXF-3308) WS-RM change to use long instead of BigInteger for sequence numbers
[ https://issues.apache.org/jira/browse/CXF-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3308: Assignee: Daniel Kulp > WS-RM change to use long instead of BigInteger for sequence numbers > --- > > Key: CXF-3308 > URL: https://issues.apache.org/jira/browse/CXF-3308 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Dennis Sosnoski >Assignee: Daniel Kulp > Attachments: distribution-long.diff, final-long.diff > > > The current WS-RM code uses BigInteger for all sequence numbers, making the > code to compare and work with sequence numbers very cumbersome. Changing to > long values would still allow for over 291,271 years of continuous operation > at 1 million operations per second, so is probably sufficient. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CXF-3332) SourceDataBinding doesn't create a thread safe DataReader
SourceDataBinding doesn't create a thread safe DataReader
--
Key: CXF-3332
URL: https://issues.apache.org/jira/browse/CXF-3332
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.3.2, 2.3.1, 2.2.12, 2.2.11, 2.3.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.2.13, 2.4, 2.3.3
If there are multi-client send the dispatch request to server , the provider
server will send a fault message to client randomly.
This issue is caused by SourceDataBinding doesn't create a thread safe
DataReader.
The server code:
{code}
import javax.xml.transform.Source;
import javax.xml.ws.Endpoint;
import javax.xml.ws.Provider;
import javax.xml.ws.Service;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;
import javax.xml.ws.http.HTTPBinding;
public class Starter
{
@WebServiceProvider
@ServiceMode(value = Service.Mode.MESSAGE)
static class SimplePOXEchoProvider implements Provider {
public Source invoke(Source request) {
return request;
}
}
public static void main(String[] args) throws InterruptedException
{
Endpoint ep = Endpoint.create(HTTPBinding.HTTP_BINDING, new
SimplePOXEchoProvider());
ep.publish("http://localhost:9001/test";);
while (true)
{
Thread.sleep(10);
}
}
}
{code}
The client code
{code}
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import java.io.IOException;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import javax.xml.namespace.QName;
import javax.xml.transform.stream.StreamSource;
import javax.xml.ws.Dispatch;
import javax.xml.ws.Service;
import javax.xml.ws.http.HTTPBinding;
import org.apache.commons.io.IOUtils;
import org.apache.cxf.jaxws.DispatchImpl;
import org.apache.log4j.Logger;
import org.junit.Test;
public class ServiceTests {
private final static Logger log = Logger.getLogger(ServiceTests.class);
private boolean failed = false;
public static final String POX_REQUEST =
"http://service.sandbox.paxtests.example.com/\";>" +
"Hello";
@Test
public void concurrentPositiveTest() throws InterruptedException {
int requestsCount = 20;
final CountDownLatch latch = new CountDownLatch(requestsCount);
Runnable task = new Runnable() {
public void run() {
try {
testPoxPositive();
} catch (Throwable t) {
log.error("FAILED", t);
failed = true;
} finally {
latch.countDown();
}
}
};
ExecutorService threadPool = Executors.newFixedThreadPool(10);
for(int i=0; ihttp://localhost:9001/test";);
Dispatch disp = service.createDispatch(portName,
StreamSource.class, Service.Mode.MESSAGE);
StreamSource response = disp.invoke(new
StreamSource(IOUtils.toInputStream(POX_REQUEST)));
String text = IOUtils.toString(response.getInputStream());
assertEquals(POX_REQUEST, text);
((DispatchImpl)disp).getClient().destroy();
}
{code}
When send the request with thread pool size 20, you will get the below stack
trace.
{code}
[pool-1-thread-2] 2011-02-10 15:25:39,089 ERROR [com.example.test.ServiceTests]
- FAILED
javax.xml.ws.http.HTTPException
at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:248)
at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:339)
at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:218)
at com.example.test.ServiceTests.testPoxPositive(ServiceTests.java:66)
at com.example.test.ServiceTests$1.run(ServiceTests.java:40)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.cxf.binding.xml.XMLFault: Message part
{http://service.sandbox.paxtests.gateway.sabre.com/}sendIt was not recognized.
(Does it exist in service WSDL?)
at
org.apache.cxf.binding.xml.interceptor.XMLFaultInInterceptor.handleMessage(XMLFaultInInterceptor.java:63)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)
at
org.apache.cxf.binding.xml.interceptor.XMLMessageInInterceptor.handleMessage(XMLMessageInInterceptor.java:81)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInte
[jira] Resolved: (CXF-3332) SourceDataBinding doesn't create a thread safe DataReader
[
https://issues.apache.org/jira/browse/CXF-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-3332.
---
Resolution: Fixed
Applied patch into trunk, 2.3.x-fixing and 2.2.x-fixing branch.
> SourceDataBinding doesn't create a thread safe DataReader
> --
>
> Key: CXF-3332
> URL: https://issues.apache.org/jira/browse/CXF-3332
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0, 2.2.11, 2.2.12, 2.3.1, 2.3.2
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.2.13, 2.4, 2.3.3
>
>
> If there are multi-client send the dispatch request to server , the provider
> server will send a fault message to client randomly.
> This issue is caused by SourceDataBinding doesn't create a thread safe
> DataReader.
> The server code:
> {code}
> import javax.xml.transform.Source;
> import javax.xml.ws.Endpoint;
> import javax.xml.ws.Provider;
> import javax.xml.ws.Service;
> import javax.xml.ws.ServiceMode;
> import javax.xml.ws.WebServiceProvider;
> import javax.xml.ws.http.HTTPBinding;
> public class Starter
> {
> @WebServiceProvider
> @ServiceMode(value = Service.Mode.MESSAGE)
> static class SimplePOXEchoProvider implements Provider {
> public Source invoke(Source request) {
> return request;
> }
> }
>
>public static void main(String[] args) throws InterruptedException
>{
> Endpoint ep = Endpoint.create(HTTPBinding.HTTP_BINDING, new
> SimplePOXEchoProvider());
> ep.publish("http://localhost:9001/test";);
> while (true)
> {
> Thread.sleep(10);
> }
>}
> }
> {code}
> The client code
> {code}
> import static org.junit.Assert.assertEquals;
> import static org.junit.Assert.assertFalse;
> import static org.junit.Assert.assertTrue;
> import java.io.IOException;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.TimeUnit;
> import javax.xml.namespace.QName;
> import javax.xml.transform.stream.StreamSource;
> import javax.xml.ws.Dispatch;
> import javax.xml.ws.Service;
> import javax.xml.ws.http.HTTPBinding;
> import org.apache.commons.io.IOUtils;
> import org.apache.cxf.jaxws.DispatchImpl;
> import org.apache.log4j.Logger;
> import org.junit.Test;
> public class ServiceTests {
> private final static Logger log = Logger.getLogger(ServiceTests.class);
> private boolean failed = false;
>
> public static final String POX_REQUEST =
> " xmlns:ns2=\"http://service.sandbox.paxtests.example.com/\";>" +
> "Hello";
>
> @Test
> public void concurrentPositiveTest() throws InterruptedException {
> int requestsCount = 20;
> final CountDownLatch latch = new CountDownLatch(requestsCount);
> Runnable task = new Runnable() {
> public void run() {
> try {
> testPoxPositive();
> } catch (Throwable t) {
> log.error("FAILED", t);
> failed = true;
> } finally {
> latch.countDown();
> }
>
> }
> };
> ExecutorService threadPool = Executors.newFixedThreadPool(10);
> for(int i=0; i threadPool.execute(task);
> }
> assertTrue(latch.await(10, TimeUnit.SECONDS));
> assertFalse(failed);
> }
>
> //@Test
> public void testPoxPositive() throws IOException {
> QName portName = new QName("dummy", "dummy");
> Service service = Service.create(null);
> service.addPort(portName, HTTPBinding.HTTP_BINDING,
> "http://localhost:9001/test";);
> Dispatch disp = service.createDispatch(portName,
> StreamSource.class, Service.Mode.MESSAGE);
> StreamSource response = disp.invoke(new
> StreamSource(IOUtils.toInputStream(POX_REQUEST)));
> String text = IOUtils.toString(response.getInputStream());
> assertEquals(POX_REQUEST, text);
> ((DispatchImpl)disp).getClient().destroy();
> }
> {code}
> When send the request with thread pool size 20, you will get the below stack
> trace.
> {code}
> [pool-1-thread-2] 2011-02-10 15:25:39,089 ERROR
> [com.example.test.ServiceTests] - FAILED
> javax.xml.ws.http.HTTPException
> at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:248)
> at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:339)
> at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:218)
> at com.example.test.ServiceTests.testPoxPositive(ServiceTests.java:66)
> at com.example.test.ServiceTests$1.run(ServiceTests.java:40)
> at
> java.util.concurre
