[jira] Created: (CXF-1882) JAX-RS can't unmarshall request body if the corresponding parameter is annotated with non-JAX-RS annotation
JAX-RS can't unmarshall request body if the corresponding parameter is
annotated with non-JAX-RS annotation
---
Key: CXF-1882
URL: https://issues.apache.org/jira/browse/CXF-1882
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime, JAXB Databinding, REST
Affects Versions: 2.1.2
Environment: windows XP
apache-tomcat-6.0.13
jdk1.6.0_02
Reporter: Gabo Manuel
I have a java-first service. The goal is to have a single service
implementation that can be accessed via SOAP or as ReST service. I am using the
JAX-WS annotations to have a more descriptive WSDL. I am using the JAX-RS
annotations as defined in: http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html
. Below is a trimmed down version of the code:
//AccountService.java
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.ws.rs.ConsumeMime;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
@WebService(serviceName="AccountService")
@ConsumeMime("text/xml")
public class AccountService {
@PUT
@Path("/Account")
@WebMethod
public long insert(
@WebParam(name="account")
Account account
) {
logger.info("insert Received: " + account);
return 0;
}
}
//Account.java
import javax.ws.rs.Path;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
@XmlRootElement(name="Account")
@XmlType(name="Account")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Account {
private String accountID = "";
public String getAccountID() {
return accountID;
}
public void setAccountID(String accountID) {
this.accountID = accountID;
}
}
//beans.xml
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xmlns:soap="http://cxf.apache.org/bindings/soap";
xmlns:sec="http://cxf.apache.org/configuration/security";
xmlns:jaxrs="http://cxf.apache.org/jaxrs";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/bindings/soap
http://cxf.apache.org/schemas/configuration/soap.xsd
http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/jaxrs
http://cxf.apache.org/schemas/jaxrs.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd
">
I have already discussed this with Sergey of CXF support team
(http://www.nabble.com/-JAX-WS--JAX-RS--tt20007600.html). The issue seem to be
not present if the parameter is not annotated by JAX-WS. Below is a snippet of
his findings:
I think I might know what might be happening - JAXRS runtime does not recognize
the Account as being a standalone method parameter as it's annotated with a
JAXWS annotation. On other words, in JAX-RS, providers(by default) are used
only when unmarshalling parameters not annotated with JAX-RS annotations, for ex
void foo(@PathParam("id") String id, Account acc);
here the Account will be unmarshalled as expected but because you have
void foo(@WebParam(name="account") Account account);
the runtime mistakenly ignores it
Please advise if you need more information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1656) PolicyEngineImpl Memory Improvement
[ https://issues.apache.org/jira/browse/CXF-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1656. - > PolicyEngineImpl Memory Improvement > --- > > Key: CXF-1656 > URL: https://issues.apache.org/jira/browse/CXF-1656 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.1.1, 2.0.7 >Reporter: Bharath Ganesh >Assignee: Daniel Kulp > Fix For: 2.1.3 > > > PolicyEngineImpl maintains a clientEndpointInfos map to keep the > EndpointPolicies for client endpoints. An entry added to this map (while a > client comes in) is removed only when the server endpoint is stopped. This > leads to very high memory usage when there are frequent getPort() Calls. > This can be can be reduced by maintaining a weak reference to the client > EndpointInfo's. [Make clientEndpointInfoMap a weakhashmap] > This would mean that after the lifetime of a single client port, all its data > structures would be cleared. We need to explore more on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1654) Promote request/response contexts from JAX-WS up to ClientImpl base class
[ https://issues.apache.org/jira/browse/CXF-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1654. - > Promote request/response contexts from JAX-WS up to ClientImpl base class > -- > > Key: CXF-1654 > URL: https://issues.apache.org/jira/browse/CXF-1654 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.1 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.1.3 > > > By promoting them into the base class, the simple frontend and the > DynamicClient's can take advantage of them and set request params. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1732) RFSB NPE for some sort of confusion on a return type caused by Aegis, maybe
[ https://issues.apache.org/jira/browse/CXF-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1732. - > RFSB NPE for some sort of confusion on a return type caused by Aegis, maybe > --- > > Key: CXF-1732 > URL: https://issues.apache.org/jira/browse/CXF-1732 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.1 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.1.3 > > > Unignore the test in org.apache.cxf.aegis.client.HeaderTest, and observe the > resulting NPE fireworks. Feel free to throw back at me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1624) XmlSchemaException: Schema name conflict in collection.
[ https://issues.apache.org/jira/browse/CXF-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1624. - > XmlSchemaException: Schema name conflict in collection. > --- > > Key: CXF-1624 > URL: https://issues.apache.org/jira/browse/CXF-1624 > Project: CXF > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Richard Opalka >Assignee: Daniel Kulp > Fix For: 2.1.3 > > > 17:50:53,336 ERROR [[/jaxws-samples-logicalhandler-jaxb]] > StandardWrapper.Throwable > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'SOAPEndpoint': Invocation of init method failed; nested exception > is javax.xml.ws.WebServiceException: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection. Namespace: http://org.jboss.ws/jaxws/samples/logicalhandler > Caused by: > javax.xml.ws.WebServiceException: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection. Namespace: http://org.jboss.ws/jaxws/samples/logicalhandler > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:258) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:194) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:380) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1242) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1208) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1172) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:427) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:249) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:155) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:246) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:291) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352) > at > org.jboss.wsf.stack.cxf.CXFServletExt.loadAdditionalConfigExt(CXFServletExt.java:125) > at > org.jboss.wsf.stack.cxf.CXFServletExt.loadBus(CXFServletExt.java:102) > at > org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFServlet.java:86) > at org.jboss.wsf.stack.cxf.CXFServletExt.init(CXFServletExt.java:74) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161) > at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) > at > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.
[jira] Closed: (CXF-1745) idl2wsdl tool fails to add Any type to schema
[ https://issues.apache.org/jira/browse/CXF-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1745. - > idl2wsdl tool fails to add Any type to schema > - > > Key: CXF-1745 > URL: https://issues.apache.org/jira/browse/CXF-1745 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.1.3 >Reporter: Matteo Vescovi >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: add_any_type_to_schema.diff > > > idl2wsdl tool fails to add Any type to schema if the > http://www.w3.org/2001/XMLSchema schema is not the first schema returned by > getXmlSchemas(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1748) Add more tests to increase coverage of idl2wsdl and wsdl2idl tools
[ https://issues.apache.org/jira/browse/CXF-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1748. - > Add more tests to increase coverage of idl2wsdl and wsdl2idl tools > -- > > Key: CXF-1748 > URL: https://issues.apache.org/jira/browse/CXF-1748 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.1.2 >Reporter: Matteo Vescovi >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: corba_tools_tests.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1751) idl2wsdl fails to generate wsdl for IDL files with complex object reference usage
[ https://issues.apache.org/jira/browse/CXF-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1751. - > idl2wsdl fails to generate wsdl for IDL files with complex object reference > usage > - > > Key: CXF-1751 > URL: https://issues.apache.org/jira/browse/CXF-1751 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.1.2 >Reporter: Matteo Vescovi >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: complex_obj_ref_idl.diff > > > Here is the stack trace: > org.apache.cxf.tools.common.ToolException: > org.apache.cxf.tools.common.ToolException: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection > at > org.apache.cxf.tools.corba.processors.idl.IDLToWSDLProcessor.process(IDLToWSDLProcessor.java:88) > at > org.apache.cxf.tools.corba.processors.idl.IDLToWSDLProcessor.process(IDLToWSDLProcessor.java:79) > at > org.apache.cxf.tools.corba.processors.idl.AbstractIDLToWSDLModuleToNSTestCase.testModuleToNSWSDLGeneration(AbstractIDLToWSDLModuleToNSTestCase.java:147) > at > org.apache.cxf.tools.corba.processors.idl.AbstractIDLToWSDLModuleToNSTestCase.testModuleToNSWSDLGeneration(AbstractIDLToWSDLModuleToNSTestCase.java:89) > at > org.apache.cxf.tools.corba.processors.idl.AbstractIDLToWSDLModuleToNSTestCase.testModuleToNSWSDLGeneration(AbstractIDLToWSDLModuleToNSTestCase.java:76) > at > com.iona.soa.bindings.corba.tools.processors.idl.IDLToWSDLParlay50GenerationTest.testPolicyInterfaces(IDLToWSDLParlay50GenerationTest.java:496) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) > at org.apache.maven.surefire.Surefire.run(Surefire.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980) > Caused by: org.apache.cxf.tools.common.ToolException: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection > at > org.apache.cxf.tools.corba.processors.idl.IDLToWSDLProcessor.parseIDL(IDLToWSDLProcessor.java:219) > at > org.apache.cxf.tools.corba.processors.idl.IDLToWSDLProcessor.process(IDLToWSDLProcessor.java:86) > ... 28 more > Caused by: java.lang.RuntimeException: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection > at > org.apache.cxf.tools.corba.processors.idl.PortTypeVisitor.visitInterface(PortTypeVisitor.java:199) > at > org.apache.cxf.tools.corba.processors.idl.PortTypeVisitor.visit(PortTypeVisitor.java:91) > at > org.apache.cxf.tools.corba.processors.idl.DefinitionVisitor.visit(DefinitionVisitor.java:66) > at > org.apache.cxf.tools.corba.processors.idl.ModuleVisitor.visit(ModuleVisitor.java:53) > at > org.apache.cxf.tools.corba.processors.idl.DefinitionVisitor.visit(DefinitionVisitor.java:57) > at > org.apache.cxf.tools.corba.processors.idl.ModuleVisitor.visit(ModuleVisitor.java:53) > at > org.apache.cxf.tools.corba.processors.idl.DefinitionVisitor.visit(DefinitionVisitor
[jira] Closed: (CXF-1778) Memory leak occurs in specific cases when WS-Addressing feature is enabled
[ https://issues.apache.org/jira/browse/CXF-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1778. - > Memory leak occurs in specific cases when WS-Addressing feature is enabled > -- > > Key: CXF-1778 > URL: https://issues.apache.org/jira/browse/CXF-1778 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.1.2 >Reporter: Maciej Kwiecien >Assignee: Daniel Kulp >Priority: Critical > Fix For: 2.1.3 > > Attachments: cxf-ws-addr-memory-leak.zip, histoConnectionRefused.log, > histoEchoServerWithoutWsAddr.log > > > I observed memory leak (OOM thrown) in following situations: > 1.WS-Addressing enabled on client and server side. When server stops > responding (connection refused on client side) > client memory usage is increasing until OOM is thrown. > 2.WS-Addressing enabled only on client side, server provide service without > WS-Addressing feature (or WS-Addressing configuration is incorrect). Client > memory heap is building up even faster than in first case. > I will provide a sample application and more detailed description how to > reproduce bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1735) Invalid namespace qualification in Java to WSDL mapping
[
https://issues.apache.org/jira/browse/CXF-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1735.
-
> Invalid namespace qualification in Java to WSDL mapping
> ---
>
> Key: CXF-1735
> URL: https://issues.apache.org/jira/browse/CXF-1735
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.0.8
>Reporter: Jarek Gawor
>Assignee: Daniel Kulp
> Fix For: 2.1.3
>
>
> I have the following SEI:
> @WebService(name = "Greeter", targetNamespace =
> "http://apache.org/greeter_control";)
> public interface Greeter {
> @WebMethod
> @WebResult(name = "responseType", targetNamespace =
> "http://apache.org/greeter_control/types";)
> @RequestWrapper(localName = "greetMe", targetNamespace =
> "http://apache.org/greeter_control/types";, className =
> "org.apache.greeter_control.types.GreetMe")
> @ResponseWrapper(localName = "greetMeResponse", targetNamespace =
> "http://apache.org/greeter_control/types";, className =
> "org.apache.greeter_control.types.GreetMeResponse")
> public String greetMe(
> @WebParam(name = "requestType", targetNamespace =
> "http://apache.org/greeter_control/types";)
> String requestType);
> }
> ?wsdl request on a service that implements this SEI contains the following
> schema:
> elementFormDefault="unqualified"
> targetNamespace="http://apache.org/greeter_control/types";
> xmlns="http://apache.org/greeter_control/types";
> xmlns:tns="http://apache.org/greeter_control";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
> http://apache.org/greeter_control";
> xmlns="http://www.w3.org/2001/XMLSchema"; />
>
>
>
>
>
>
>
>
>
> />
>
>
>
> Notice, the elementFormDefault="unqualified" attribute on the schema. That
> means that the requestType and responseType elements are unqualified in the
> schema. However, the annotation defines explicit namespaces for these
> elements.
> When actaully invoking the service, the service will expect the requestType
> element to be unqualified. If the requestType element is qualified on the
> wire, the "requestType" parameter in Java code will be passed as null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1747) Adding WS-Addressing http://schemas.xmlsoap.org/ws/2004/03/addressing support to WS-* Component
[ https://issues.apache.org/jira/browse/CXF-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1747. - > Adding WS-Addressing http://schemas.xmlsoap.org/ws/2004/03/addressing support > to WS-* Component > --- > > Key: CXF-1747 > URL: https://issues.apache.org/jira/browse/CXF-1747 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Maciej Kwiecien >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.1.3 > > Attachments: ws_addr_200403.patch > > Original Estimate: 24h > Remaining Estimate: 24h > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-932) dynamic client needs to handle more complex wsdl
[
https://issues.apache.org/jira/browse/CXF-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-932.
> dynamic client needs to handle more complex wsdl
> -
>
> Key: CXF-932
> URL: https://issues.apache.org/jira/browse/CXF-932
> Project: CXF
> Issue Type: Improvement
> Components: Dynamic Languages
>Affects Versions: 2.0.1
> Environment: windows xp, jdk1.5
>Reporter: Marty Henderson
>Assignee: Daniel Kulp
>Priority: Minor
> Fix For: 2.1.3
>
> Attachments: BusinessProcessManager.wsdl,
> DynamicClientGenerationTest.java
>
>
> when pointing the dynamic client at a more complex wsdl, the error below is
> seen when trying to generate the jaxb classes.
> java.lang.RuntimeException: Error compiling schema from WSDL at {
> http://localhost:8080/donkey/services/service?wsdl}: Two declarations cause a
> collision in the ObjectFactory class.
> at
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory$InnerErrorListener.error(DynamicClientFactory.java:409)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:245)
> at
> com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:61)
> at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:66)
> at
> com.sun.tools.xjc.generator.bean.ObjectFactoryGeneratorImpl.populate(ObjectFactoryGeneratorImpl.java:150)
> at
> com.sun.tools.xjc.generator.bean.PublicObjectFactoryGenerator.populate(PublicObjectFactoryGenerator.java:19)
> at
> com.sun.tools.xjc.generator.bean.BeanGenerator.(BeanGenerator.java:210)
> at
> com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
> at com.sun.tools.xjc.model.Model.generateCode(Model.java:226)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:211)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:66)
> at
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:166)
> at
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:137)
> at
> com.donkey.donkey.scaffold.service.DynamicService.constructClient(Dynamicervice.java:92)
> at
> com.donkey.donkey.scaffold.service.DynamicService.(DynamicService.java:36)
> at
> com.donkey.donkey.scaffold.service.DynamicServiceTest.testInvoke(DynamicServiceTest.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> this seems to be a known issue in the jaxb component:
> https://jaxb.dev.java.net/guide/Dealing_with_errors.html
> whereby some form of configuration is needed to manage the collision.
> need to have a think about the best way to handle this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1792) JMX ONs for performance counters should not use qnames for port and operation
[
https://issues.apache.org/jira/browse/CXF-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1792.
-
> JMX ONs for performance counters should not use qnames for port and operation
> -
>
> Key: CXF-1792
> URL: https://issues.apache.org/jira/browse/CXF-1792
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.2
>Reporter: Hadrian Zbarcea
>Assignee: Daniel Kulp
> Fix For: 2.1.3, 2.2
>
> Attachments: cxf-1792.patch
>
>
> ObjectNames for counters look like that:
> org.apache.cxf:bus.id=cxf945122723,type=Performance.Counter.Server,service="{http://apache.org/hello_world_soap_http}SOAPService",port="{http://apache.org/hello_world_soap_http}SoapPort",operation="{http://apache.org/hello_world_soap_http}sayHi";
> Having them mapped to qnames is unnecessary and only makes ONs long and hard
> to read/manage and I think it would be better if they looked like this:
> org.apache.cxf:bus.id=cxf945122723,type=Performance.Counter.Server,service="{http://apache.org/hello_world_soap_http}SOAPService",port="SoapPort",operation="sayHi";
> I am proposing the attached patch to fix this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1788) Problem with Calendar
[ https://issues.apache.org/jira/browse/CXF-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1788. - > Problem with Calendar > - > > Key: CXF-1788 > URL: https://issues.apache.org/jira/browse/CXF-1788 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.1.2 > Environment: JDK 5, JDK 6, WIndows Vista. >Reporter: Alejandro > Fix For: 2.1.3 > > Attachments: XFireCustomMapping.java > > > Hi, I'm migrating a XFIRE ws application to CXF. Because I need to > keep alive the compatibility with XFIRE I use Aegis as DataBinding. > I've solve a problems but now I cna't solve the problem with the > Calendar datatype, some of my classes uses java.util.Date or > java.util.Calendar. When the binding tried to make the bindings I've > get this error: > javax.xml.ws.WebServiceException: java.lang.ClassCastException: > org.apache.cxf.aegis.type.basic.CalendarType cannot be cast to > org.apache.cxf.aegis.type.basic.BeanType >at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:267) > ... > Caused by: java.lang.ClassCastException: > org.apache.cxf.aegis.type.basic.CalendarType cannot be cast to > org.apache.cxf.aegis.type.basic.BeanType >at > org.apache.cxf.aegis.type.basic.BeanType.getSuperType(BeanType.java:670) >at > org.apache.cxf.aegis.type.basic.BeanType.writeSchema(BeanType.java:417) >at > org.apache.cxf.aegis.databinding.AegisDatabinding.createSchemas(AegisDatabinding.java:478) >at > org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:323) > In XFire I've create a CustomMapping to solve this problem, but in CXF > I don't find any example about that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1804) CorbaBindingFactory does not register with DestinationFactoryManager and ConduitIniatorManager
[ https://issues.apache.org/jira/browse/CXF-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1804. - > CorbaBindingFactory does not register with DestinationFactoryManager and > ConduitIniatorManager > -- > > Key: CXF-1804 > URL: https://issues.apache.org/jira/browse/CXF-1804 > Project: CXF > Issue Type: Bug > Components: CORBA Binding >Affects Versions: 2.1.2 >Reporter: Matteo Vescovi >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: register_fix.diff > > > CorbaBindingFactory does not register with DestinationFactoryManager and > ConduitIniatorManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1841) Some issues with outbound jca connector
[ https://issues.apache.org/jira/browse/CXF-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1841. - > Some issues with outbound jca connector > --- > > Key: CXF-1841 > URL: https://issues.apache.org/jira/browse/CXF-1841 > Project: CXF > Issue Type: Bug > Components: Integration >Reporter: William Tam >Assignee: Willem Jiang > Fix For: 2.0.9, 2.1.3, 2.2 > > Attachments: CXF-1841.patch > > > 1. The client proxy factory does not get configured by Configurer to inject > configurations. So, for example, the ws security cannot be enabled in JCA > connector. > 2. ManagedConnectionImpl should implement equals() ahd hashcode() based on > properties as required by JCA 1.5 > 3. A single bus is shared by multiple web applications. It is not possible > to have a per web application bus config. > 4. If a bean class is defined in a WAR and it is referenced by bus config, > the bus cannot be created when the JCA connector starts in WebSphere 6.1. > The reason is JCA connector classloader cannot load the class in belong in a > WAR. > 5. The outbound connector APIs should be moved to the api module so that > javadoc can be produced for them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1794) codegen plugin not merging autodetected options with the options in the poms correctly...
[ https://issues.apache.org/jira/browse/CXF-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1794. - > codegen plugin not merging autodetected options with the options in the poms > correctly... > - > > Key: CXF-1794 > URL: https://issues.apache.org/jira/browse/CXF-1794 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.0.8, 2.1.2 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.1.3 > > > Codegen plugin is not detecting constructing the file objects correctly so > the .equals(...) is always false so the options aren't getting merged. The > trick is that the auto loading is using a URI.toString() (so has file: > protocol), but just new File(o2.getWsdl()) which then doesn't parse the > protocol part. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1834) The corba prefix is not present in the physical part of the wsdl when a yoko corba namespace is used.
[ https://issues.apache.org/jira/browse/CXF-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1834. - > The corba prefix is not present in the physical part of the wsdl when a yoko > corba namespace is used. > - > > Key: CXF-1834 > URL: https://issues.apache.org/jira/browse/CXF-1834 > Project: CXF > Issue Type: Bug > Components: CORBA Binding, JAXB Databinding >Affects Versions: 2.1.2 >Reporter: Keith Halligan >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: corba_prefix_fix.diff > > > The corba prefix is not present in the physical part of the wsdl returned on > the wire, when the original wsdl used the old yoko corba namespace: > "http://schemas.apache.org/yoko/bindings/corba"; > eg. > > http://cxf.apache.org/bindings/corba"; bases="" > repositoryID="IDL:HelloWorld:1.0" /> > > http://cxf.apache.org/bindings/corba"; > name="greetMe"> > > > > > > > > > > > binding="tns:HelloWorldCORBABinding"> > http://cxf.apache.org/bindings/corba"; > location="corbaloc::localhost:40001/hw" /> > > > http://cxf.apache.org/bindings/corba"; > targetNamespace="http://schemas.apache.org/yoko/idl/HelloWorld/corba/typemap/"; > /> > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1780) float's and double's negative infinity is incorrectly marshalled/unmarshalled as positive infinity
[ https://issues.apache.org/jira/browse/CXF-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1780. - > float's and double's negative infinity is incorrectly marshalled/unmarshalled > as positive infinity > -- > > Key: CXF-1780 > URL: https://issues.apache.org/jira/browse/CXF-1780 > Project: CXF > Issue Type: Bug > Components: CORBA Binding >Affects Versions: 2.1.2 >Reporter: Matteo Vescovi >Assignee: Daniel Kulp > Fix For: 2.1.3 > > Attachments: infinity_patch.diff > > > Floats with value Float.NEGATIVE_INFINITY or doubles with value > Double.NEGATIVE_INFINITY are incorrectly marshalled/unmarshalled as positive > infinity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1860) JMS Transport - JMSDestination no room left on workqueue in JMSListenerThread
[ https://issues.apache.org/jira/browse/CXF-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1860. - > JMS Transport - JMSDestination no room left on workqueue in JMSListenerThread > - > > Key: CXF-1860 > URL: https://issues.apache.org/jira/browse/CXF-1860 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.1.2 >Reporter: Richard Holt >Assignee: Christian Schneider >Priority: Critical > Fix For: 2.1.3 > > Attachments: JMSDestination.java > > > when running a mass test against a CXF/JMS endpoint we discovered that our > solution was disposing of messages. On further investigation we discovered > that the code in the JMSListenerThread when it runs out of threads on the > workqueue doesn't loop like the comment suggests but rather disposes of the > message. > We altered the code to follow the comments advice (shown below) and now it > calls into the code held in the else statement (which just runs the message > in the listener thread, maybe not ideal from an architectural viewpoint but > we don't lose messages). > //FIXME - no room left on workqueue, what to do > //for now, loop until it WILL fit on the queue, > //although we could just dispatch on this thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1857) ServiceFactoryBean should not call createInvoker() twice if its invoker does not be set
[
https://issues.apache.org/jira/browse/CXF-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1857.
-
> ServiceFactoryBean should not call createInvoker() twice if its invoker does
> not be set
> ---
>
> Key: CXF-1857
> URL: https://issues.apache.org/jira/browse/CXF-1857
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 2.0.3, 2.0.4, 2.0.5, 2.1, 2.0.6, 2.1.1, 2.0.7, 2.0.8,
> 2.1.2
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.1.3, 2.2
>
>
> public Server create() {
> try {
> applyExtraClass();
> if (serviceBean != null && getServiceClass() == null) {
> setServiceClass(ClassHelper.getRealClass(serviceBean));
> }
> if (invoker != null) {
> getServiceFactory().setInvoker(invoker);
> } else if (serviceBean != null) {
> // we should set the invoker here
> getServiceFactory().setInvoker(createInvoker());
>
> }
> Endpoint ep = createEndpoint();
> server = new ServerImpl(getBus(),
> ep,
> getDestinationFactory(),
> getBindingFactory());
> if (ep.getService().getInvoker() == null) {
> if (invoker == null) {
> ep.getService().setInvoker(createInvoker());
> } else {
> ep.getService().setInvoker(invoker);
> }
> }
> if (start) {
> server.start();
> }
> } catch (EndpointException e) {
> throw new ServiceConstructionException(e);
> } catch (BusException e) {
> throw new ServiceConstructionException(e);
> } catch (IOException e) {
> throw new ServiceConstructionException(e);
> }
> if (serviceBean != null) {
> initializeAnnotationInterceptors(server.getEndpoint(),
>
> ClassHelper.getRealClass(getServiceBean()));
> } else if (getServiceClass() != null) {
> initializeAnnotationInterceptors(server.getEndpoint(),
> getServiceClass());
> }
> applyFeatures();
> return server;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1793) WSDL2Java reports Non unique body parts if first part in message are soap headers.
[
https://issues.apache.org/jira/browse/CXF-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1793.
-
> WSDL2Java reports Non unique body parts if first part in message are soap
> headers.
> --
>
> Key: CXF-1793
> URL: https://issues.apache.org/jira/browse/CXF-1793
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.1.2
> Environment: Windows XP, Java 1.5
>Reporter: Dag Framstad
>Assignee: Daniel Kulp
> Fix For: 2.1.3
>
> Attachments: cxf-1793.zip, cxf1793_works.wsdl
>
>
> In my WSDL I have 2 services that have similar names.
> If the first 14 characters in the message part name are identical WSDL2Java
> reports (from ant):
> generate:
> [java] Loading FrontEnd jaxws ...
> [java] Loading DataBinding jaxb ...
> [java] wsdl2java -b
> c:\ADN\adnfond/src/main/resources/com/edb/adnfond/transport/ws/calendar.xjb.w2j
> -impl -verbose -validate -c
> atalog c:\ADN\adnfond/src/main/resources/com/edb/adnfond/transport/ws/misc -d
> c:\ADN\adnfond/src/main/generated c:\ADN\adnfond/src/m
> ain/resources/com/edb/adnfond/transport/ws/misc/Misc_v10.wsdl
> [java] wsdl2java - Apache CXF 2.1.2
> [java]
> [java]
> [java] WSDLToJava Error: Non unique body parts, operation [
> getSalesOfficeId ] and operation [ getSalesPersonId ] have the sam
> e body block {http://edb.com/ws/WSCommon_v21}AutHeader
> [java]
> [java]
> [java]
> [java] org.apache.cxf.tools.common.ToolException: Non unique body parts,
> operation [ getSalesOfficeId ] and operation [ getSal
> esPersonId ] have the same body block
> {http://edb.com/ws/WSCommon_v21}AutHeader
> [java]
> [java]
> [java] at
> org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:128)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:200
> )
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:62)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:132)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:232)
> [java] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:173)
> Example WSDL:
>
>targetNamespace="http://www.edb.com/adnfond/transport/ws/misc/";
> xmlns:misc="http://www.edb.com/adnfond/transport/ws/misc/misc_v10";
> xmlns:m="http://www.edb.com/adnfond/transport/ws/misc/";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:edb="http://edb.com/ws/WSCommon_v21";>
>
>
> http://www.w3.org/2001/XMLSchema";>
> http://edb.com/ws/WSCommon_v21";
> schemaLocation="../WSCommon_v21.xsd"/>
>namespace="http://www.edb.com/adnfond/transport/ws/misc/misc_v10";
> schemaLocation="Misc_v10.xsd"/>
>
>
>
>
>
>element="misc:getSalesOfficeIdRequest"/>
>
>
>
>element="misc:getSalesOfficeIdResponse" />
>
>
>
>element="misc:getSalesOfficeId2Request"/>
>
>
>
>element="misc:getSalesOfficeId2Response"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>transport="http://schemas.xmlsoap.org/soap/http"/>
>
>style="document"/>
>
>part="salesOfficeIdHeader" use="literal"/>
>use="literal"/>
>
>
>
>
>
>
>style="document"/>
>
>part="salesOfficeId2Header" use="literal"/>
>use="literal"/>
>
>
>
>
>
>
>
>
[jira] Closed: (CXF-1849) PolicyVerificationOutInterceptor writes faults at wrong phase when processing response
[ https://issues.apache.org/jira/browse/CXF-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1849. - > PolicyVerificationOutInterceptor writes faults at wrong phase when processing > response > -- > > Key: CXF-1849 > URL: https://issues.apache.org/jira/browse/CXF-1849 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.1.2 >Reporter: Fred Dushin >Assignee: Daniel Kulp > Fix For: 2.1.3, 2.2 > > Attachments: CXF-1849-trunk-r703513.patch > > > When a CXF response is processed on an endpoint that contains policy > assertions (via spring, WSDL, etc), and the policy assertions are not marked > as asserted, the PolicyVerificationOutInterceptor properly raises a SOAP > fault. However, this interceptor is inserted into the "post-stream" phase, > and it seems as though the fault gets written to the SOAP body after the > business logic has been written. > So a response in this scenario will come out as follows: > http://schemas.xmlsoap.org/soap/envelope/";> > > >Bonjou > > >soap:Server >These policy alternatives can not be satisfied: > [snip] > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1756) wsdl2java @WebService annotation on Impl class should be on Interface class JSR181 3.1
[ https://issues.apache.org/jira/browse/CXF-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1756. - > wsdl2java @WebService annotation on Impl class should be on Interface class > JSR181 3.1 > -- > > Key: CXF-1756 > URL: https://issues.apache.org/jira/browse/CXF-1756 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.1.2 > Environment: CXF 2.1.2 and 2.0.8 >Reporter: Bob Fields >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.1.3 > > > Looks like XFIRE-496 (http://jira.codehaus.org/browse/XFIRE-496) was never > fixed or carried over to CXF. > I'm getting an error from my Eclipse Jax-ws validator for the code created by > wsdl2java: JSR-181 3.1: name element cannot be used with endpointInterface. > According to JSR181 section 3.1, if an Interface has an Impl, the @WebService > annotation on the Impl class must only have serviceName and endpointInterface > attributes. The other attributes (name, portName, targetNamespace, > wsdlLocation) must be on the Interface class @WebService annotation. > java2wsdl creates this on the Impl class (removed data between quotes) but > should only have serviceName and endpointImpl: > @javax.jws.WebService(name = "", > serviceName = "", > portName = "", > targetNamespace = "", > wsdlLocation = "", > endpointInterface = "") > and this on the Interface class (missing serviceName, portName, wsdlLocation): > @WebService(targetNamespace = "", name = "") > java2wsdl appears to work correctly with the annotations in the proper place > in the SEI and Impl classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1864) CXF client failes to parse SOAP 1.2 FaultCode
[ https://issues.apache.org/jira/browse/CXF-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang closed CXF-1864. - > CXF client failes to parse SOAP 1.2 FaultCode > - > > Key: CXF-1864 > URL: https://issues.apache.org/jira/browse/CXF-1864 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 2.1.2 > Environment: Windows XP 64-bit, Java JDK 1.5. update 14 (32-bit) >Reporter: Slobodan Marjanovic >Assignee: Daniel Kulp > Fix For: 2.1.3 > > > I'm using CXF as a WS client for WS which is running on JBoss 4.2.3 GA. Web > service is configured to use SOAP 1.2 protocol. > Here is the SOAP message that I get from server: > xmlns:env='http://www.w3.org/2003/05/soap-envelope'> xmlns:env='http://www.w3.org/2003/05/soap-envelope'> xmlns:env='http://www.w3.org/2003/05/soap-envelope'> xmlns:codeNS='http://www.w3.org/2003/05/soap-envelope' > xmlns:env='http://www.w3.org/2003/05/soap-envelope'>codeNS:Receiver xmlns:env='http://www.w3.org/2003/05/soap-envelope'> xml:lang='en-US' xmlns:env='http://www.w3.org/2003/05/soap-envelope'>Some > Reason xmlns:env='http://www.w3.org/2003/05/soap-envelope'>General201Person > with that pid already > exists!Create. > CXF stack trace: > INFO: Interceptor has thrown exception, unwinding now > java.lang.RuntimeException: Invalid QName in mapping: codeNS:Receiver > at org.apache.cxf.helpers.XMLUtils.getQName(XMLUtils.java:387) > at > org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:72) > at > org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96) > at > org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) > at > org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2029) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1865) > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47) > at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:170) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:593) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178) > at $Proxy39.create(Unknown Source) > at > com.prozone.poc.ejb.session.PersonWS_PersonWSPort_Client.main(PersonWS_PersonWSPort_Client.java:72) > Exception in thread "main" javax.xml.ws.WebServiceException: > java.lang.RuntimeException: Invalid QName in mapping: codeNS:Receiver > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:196) > at $Proxy39.create(Unknown Source) > at > com.prozone.poc.ejb.session.PersonWS_PersonWSPort_Client.main(PersonWS_PersonWSPort_Client.java:72) > Caused by: java.lang.RuntimeException: Invalid QName in mapping: > codeNS:Receiver > at org.apache.cxf.helpers.XMLUtils.getQName(XMLUtils.java:387) > at > org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:72) > at > org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96) > at > org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) > at > org.apache.
[jira] Closed: (CXF-1856) LoggingOutInterceptor has encoding problem and the solution
[
https://issues.apache.org/jira/browse/CXF-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1856.
-
> LoggingOutInterceptor has encoding problem and the solution
>
>
> Key: CXF-1856
> URL: https://issues.apache.org/jira/browse/CXF-1856
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.2
>Reporter: calvin xiu
>Assignee: Willem Jiang
> Fix For: 2.1.3, 2.2
>
>
> LoggingOutInterceptor use org.apache.cxf.io.CachedOutputStream to write the
> log.
> in CachedOutputStream public void writeCacheTo(StringBuilder out)
> out.append(((ByteArrayOutputStream)currentStream).toString();
> It use the platform default encoding to write the log
> in a chinese server, the default encoding is GBK, but the program is UTF-8,
> the clause should change to
>
> out.append(((ByteArrayOutputStream)currentStream).toString("UTF-8")
> should LoggingOutInterceptor pass LoggingMessage's encoding message to
> CachedOutputStream ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1821) UrlUtilities.getStem is parsing a decoded URL
[
https://issues.apache.org/jira/browse/CXF-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang closed CXF-1821.
-
> UrlUtilities.getStem is parsing a decoded URL
> -
>
> Key: CXF-1821
> URL: https://issues.apache.org/jira/browse/CXF-1821
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Will Gomes
>Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: patch.txt
>
>
> UrlUtilities.getStem method parses a decoded uri path using lastIndexOf('/').
> This returns an incorrect "stem" if the baseURI path contained an encoded
> forward slash. This in turn is results in the WSDLQueryHandler to not
> recognize a wsdl query. I've attached a patch to fix this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
