[jira] [Created] (CXF-6750) HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
Matko Šuflaj created CXF-6750:
-
Summary: HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string,
and possibly fault code, not set
Key: CXF-6750
URL: https://issues.apache.org/jira/browse/CXF-6750
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.7.11
Reporter: Matko Šuflaj
Hi,
I am having an issue when trying to create a client that communicates with the
service over https, following is the exception:
javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code,
not set
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11]
at com.sun.proxy.$Proxy232.invoke(Unknown Source) ~[na:na]
at
hr.pbz.core.dao.impl.RtdDaoImpl.invokeService(RtdDaoImpl.java:227)
[pbz-retail-dao-9.50.72-SNAPSHOT.jar:na]
at
hr.pbz.core.dao.impl.RtdDaoImpl.callNavigationService(RtdDaoImpl.java:378)
[pbz-retail-dao-9.50.72-SNAPSHOT.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.6.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
~[na:1.6.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source) ~[na:1.6.0_45]
at java.lang.reflect.Method.invoke(Unknown Source)
~[na:1.6.0_45]
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
[spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
[spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
[spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at
hr.pbz.core.logging.interceptor.PerformanceLoggingInterceptor.invoke(PerformanceLoggingInterceptor.java:87)
[pbz-common-utils-9.50.72-SNAPSHOT.jar:na]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
[spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
[spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at com.sun.proxy.$Proxy233.callNavigationService(Unknown
Source) [na:na]
Caused by: java.lang.NullPointerException: null
at
org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:197)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:186)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:177)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.phase.PhaseChainCache.getChain(PhaseChainCache.java:93)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.phase.PhaseChainCache.get(PhaseChainCache.java:77)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.endpoint.ClientImpl.setupInterceptorChain(ClientImpl.java:1007)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:538)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
~[cxf-api-2.7.11.jar:2.7.11]
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
~[cxf-rt-frontend-simple-2.7.11.jar:2.7.11]
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11]
Codebase for client:
private SDClientPortType getWebServiceClient() {
final JaxWsProxyFactoryBean factory = new
JaxWsProxyFactoryBean();
factory.setServiceClass(SDClientPortType.class);
factory.setAddress(getRtdWebServiceUrl());
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new
LoggingOutInterceptor());
factory.getOutInterceptors().add(m_sslOutInterceptor);
final SDClientPortType webServiceClient =
(SDClientPortType) factory.create();
final HTTPConduit http = (HTTPConduit)
ClientProxy.getClient(webServiceClient).getConduit();
final TLSClientParameters tlsParameters = new
TLSClientParameters
[jira] [Updated] (DOSGI-224) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/DOSGI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panu Hämäläinen updated DOSGI-224: -- Description: The package containing the interface org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) which makes it impossible to implement 3rd party discovery plugins. (was: The package containing the interface org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not export (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) which makes it impossible to implement 3rd party discovery plugins.) > DiscoveryPlugin interface not exported > -- > > Key: DOSGI-224 > URL: https://issues.apache.org/jira/browse/DOSGI-224 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOSGI-224) DiscoveryPlugin interface not exported
Panu Hämäläinen created DOSGI-224: - Summary: DiscoveryPlugin interface not exported Key: DOSGI-224 URL: https://issues.apache.org/jira/browse/DOSGI-224 Project: CXF Distributed OSGi Issue Type: Bug Components: Discovery Affects Versions: 1.7.0 Reporter: Panu Hämäläinen The package containing the interface org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not export (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
Thorsten Möller created CXF-6758:
Summary: DataReaderImpl.handleEvent is too strict in case of
XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
Key: CXF-6758
URL: https://issues.apache.org/jira/browse/CXF-6758
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.4
Environment: CXF 3.1.4 integrated into JBoss Wildly 10.0.0.CR5, java
version 1.8.0_71
Reporter: Thorsten Möller
The implementation of
{{org.apache.cxf.jaxb.io.DataReaderImpl.handleEvent(ValidationEvent event)}} is
too strict in comparison to
{{com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleEvent(ValidationEvent)}}
and returns {{false}} (cannot recover) if the ValidationEvent.severity equals
{{ValidationEvent.ERROR}}.
In the following, details from a real-world Web service where we have
encountered this issue.
The issue can be observed when invoking the method {{GetListModel}} of this
[Web service|http://webservices.eurotaxglass.com/wsdl/identification-v2.wsdl]
whose reply message contains elements of the complex type {{ETGdateType}} that
contains a field of type {{xsd:gMonth}} (and {{xsd:gMonth}}). The following is
an excerpt of the relevant part of a reply message:
{code:xml}
07
2010
{code}
If invoked by a service client class from within a Web application deployed to
Wildfly (which uses CXF), an unmarshalling error occurs and the following stack
trace is logged:
{noformat}
16:43:46,891 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default
task-113) Interceptor for
{http://www.eurotax.com/Webservices/Identification/}IdentificationStub#{http://www.eurotax.com/Webservices/Identification/}GetListModel
has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault:
Unmarshalling Error: 07
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:905)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
at
org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
at
ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:277)
at
ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
at
ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
[jira] [Updated] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Möller updated CXF-6758:
-
Description:
The implementation of
{{org.apache.cxf.jaxb.io.DataReaderImpl.handleEvent(ValidationEvent event)}} is
too strict in comparison to
{{com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleEvent(ValidationEvent)}}
and returns {{false}} (cannot recover) if the {{ValidationEvent.severity}}
equals {{ValidationEvent.ERROR}}.
In the following, details from a real-world Web service where we have
encountered this issue.
The issue can be observed when invoking the method {{GetListModel}} of this
[Web service|http://webservices.eurotaxglass.com/wsdl/identification-v2.wsdl]
whose reply message contains elements of the complex type {{ETGdateType}} that
contains a field of type {{xsd:gMonth}} (and {{xsd:gYear}}). The following is
an excerpt of the relevant part of a reply message:
{code:xml}
07
2010
{code}
If invoked by a service client class from within a Web application deployed to
Wildfly (which uses CXF), an unmarshalling error occurs and the following stack
trace is logged:
{noformat}
16:43:46,891 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default
task-113) Interceptor for
{http://www.eurotax.com/Webservices/Identification/}IdentificationStub#{http://www.eurotax.com/Webservices/Identification/}GetListModel
has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault:
Unmarshalling Error: 07
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:905)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
at
org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
at
ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:277)
at
ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
at
ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51
[jira] [Updated] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Möller updated CXF-6758:
-
Description:
The implementation of
{{org.apache.cxf.jaxb.io.DataReaderImpl.handleEvent(ValidationEvent event)}} is
too strict in comparison to
{{com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleEvent(ValidationEvent)}}
and returns {{false}} (cannot recover) if the {{ValidationEvent.severity}}
equals {{ValidationEvent.ERROR}}.
In the following, details from a real-world Web service where we have
encountered this issue.
The issue can be observed when invoking the method {{GetListModel}} of this
[Web service|http://webservices.eurotaxglass.com/wsdl/identification-v2.wsdl]
whose reply message contains elements of the complex type {{ETGdateType}} that
contains a field of type {{xsd:gMonth}} (and {{xsd:gYear}}). The following is
an excerpt of the relevant part of a reply message:
{code:xml}
07
2010
{code}
If invoked by a service client class from within a Web application deployed to
Wildfly (which uses CXF), an unmarshalling error occurs and the following stack
trace is logged:
{noformat}
16:43:46,891 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default
task-113) Interceptor for
{http://www.eurotax.com/Webservices/Identification/}IdentificationStub#{http://www.eurotax.com/Webservices/Identification/}GetListModel
has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault:
Unmarshalling Error: 07
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:905)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
at
org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
at
ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:277)
at
ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
at
ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51
[jira] [Commented] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119447#comment-15119447
]
Thorsten Möller commented on CXF-6758:
--
Having visited your link, I agree, the Web service reply is syntactically
incorrect.
Still, what about the different behavior of the reference implementation. I
just like to understand why the reference implementation considers validation
events other than FATAL_ERROR as recoverable and why CXF does not. Is it more a
matter of laziness or superficialness in the reference implementation or is
there a clear reason?
Btw, setting set-jaxb-validation-event-handler to false didn't help much. There
is a new exception now and I'm currently trying to figure out what might be the
reason this time. In case you have an idea, this is the stack trace that I'm
getting now:
{noformat}
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:161)
at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
at
ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:279)
at
ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
at
ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
ch.sbi.atlas.servlet.filter.ResponseHeaderFilter.doFilter(ResponseHeaderFilter.java:110)
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechan
[jira] [Created] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
Panu Hämäläinen created DOSGI-225: - Summary: Service publication with org.apache.cxf.ws.httpservice.context property does not work Key: DOSGI-225 URL: https://issues.apache.org/jira/browse/DOSGI-225 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.7.0 Reporter: Panu Hämäläinen For org.apache.cxf.ws.httpservice.context the page https://cxf.apache.org/distributed-osgi-reference.html says "When this property is specified, the OSGi HTTP Service is used to expose the service, rather than a dedicated Jetty HTTP Server. This property doesn't allow the specification of a port number, as this is provided by the HTTP Service." However, this does not work with DOSGi 1.7.0. Instead, the service gets exposed (by PojoConfigurationTypeHandler) at the default address http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOSGI-226) Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
Panu Hämäläinen created DOSGI-226: - Summary: Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall Key: DOSGI-226 URL: https://issues.apache.org/jira/browse/DOSGI-226 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.7.0 Reporter: Panu Hämäläinen I have tried to configure DSW in Karaf 4.0.3 via Felix fileinstall with a config file named "cxf-dsw.cfg". However, the framework never ends up calling the update method (ManagedService) of org.apache.cxf.dosgi.dsw.Activator. The problem probably is the syntax (against OSGi spec?) of the service PID (cxf-dsw). After updating the PID to "org.apache.cxf.dosgi.dsw" in org.apache.cxf.dosgi.dsw.Activator (and the cfg filename accordingly) things started to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6750) HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
[ https://issues.apache.org/jira/browse/CXF-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131026#comment-15131026 ] Matko Šuflaj commented on CXF-6750: --- Forgot to close this, some misconfiguration in client creation was at hand which I didn't have time to look into since i find a solution that worked.There was an issue with wiring the SSL interceptor which, despited the fact that it seemed initialized when set on the client stub, ended up as null in PhaseInterceptorChain. I have reconfigured from programatic to xml ()configuration and injected the client thus inside the component where I needed it and it worked. > HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault > code, not set > -- > > Key: CXF-6750 > URL: https://issues.apache.org/jira/browse/CXF-6750 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.11 >Reporter: Matko Šuflaj > > Hi, > > I am having an issue when trying to create a client that communicates with > the service over https, following is the exception: > > javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, > not set > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157) > ~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11] > at com.sun.proxy.$Proxy232.invoke(Unknown Source) ~[na:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.invokeService(RtdDaoImpl.java:227) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.callNavigationService(RtdDaoImpl.java:378) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[na:1.6.0_45] > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at java.lang.reflect.Method.invoke(Unknown Source) > ~[na:1.6.0_45] > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > hr.pbz.core.logging.interceptor.PerformanceLoggingInterceptor.invoke(PerformanceLoggingInterceptor.java:87) > [pbz-common-utils-9.50.72-SNAPSHOT.jar:na] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at com.sun.proxy.$Proxy233.callNavigationService(Unknown > Source) [na:na] > Caused by: java.lang.NullPointerException: null > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:197) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:186) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:177) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.getChain(PhaseChainCache.java:93) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.get(PhaseChainCache.java:77) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.setupInterceptorChain(ClientImpl.java:1007) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:538) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > ~[
[jira] [Comment Edited] (CXF-6750) HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
[ https://issues.apache.org/jira/browse/CXF-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131026#comment-15131026 ] Matko Šuflaj edited comment on CXF-6750 at 2/3/16 8:00 PM: --- Forgot to close this, some misconfiguration in client creation was at hand which I didn't have time to look into thoroughly after I found a solution that worked.There was an issue with wiring the SSL interceptor which, despited the fact that it seemed initialized when set on the client stub, ended up as null in PhaseInterceptorChain. I have reconfigured from programatic to xml ()configuration and injected the client thus inside the component where I needed it and it worked. was (Author: msuflaj): Forgot to close this, some misconfiguration in client creation was at hand which I didn't have time to look into since i find a solution that worked.There was an issue with wiring the SSL interceptor which, despited the fact that it seemed initialized when set on the client stub, ended up as null in PhaseInterceptorChain. I have reconfigured from programatic to xml ()configuration and injected the client thus inside the component where I needed it and it worked. > HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault > code, not set > -- > > Key: CXF-6750 > URL: https://issues.apache.org/jira/browse/CXF-6750 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.11 >Reporter: Matko Šuflaj > > Hi, > > I am having an issue when trying to create a client that communicates with > the service over https, following is the exception: > > javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, > not set > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157) > ~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11] > at com.sun.proxy.$Proxy232.invoke(Unknown Source) ~[na:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.invokeService(RtdDaoImpl.java:227) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.callNavigationService(RtdDaoImpl.java:378) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[na:1.6.0_45] > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at java.lang.reflect.Method.invoke(Unknown Source) > ~[na:1.6.0_45] > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > hr.pbz.core.logging.interceptor.PerformanceLoggingInterceptor.invoke(PerformanceLoggingInterceptor.java:87) > [pbz-common-utils-9.50.72-SNAPSHOT.jar:na] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at com.sun.proxy.$Proxy233.callNavigationService(Unknown > Source) [na:na] > Caused by: java.lang.NullPointerException: null > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:197) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:186) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:177) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.getChain(PhaseChainCache.java:93) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.get(PhaseChainCache.java:77) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cx
[jira] [Closed] (CXF-6750) HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
[
https://issues.apache.org/jira/browse/CXF-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matko Šuflaj closed CXF-6750.
-
> HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault
> code, not set
> --
>
> Key: CXF-6750
> URL: https://issues.apache.org/jira/browse/CXF-6750
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.11
>Reporter: Matko Šuflaj
>
> Hi,
>
> I am having an issue when trying to create a client that communicates with
> the service over https, following is the exception:
>
> javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code,
> not set
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
> ~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11]
> at com.sun.proxy.$Proxy232.invoke(Unknown Source) ~[na:na]
> at
> hr.pbz.core.dao.impl.RtdDaoImpl.invokeService(RtdDaoImpl.java:227)
> [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na]
> at
> hr.pbz.core.dao.impl.RtdDaoImpl.callNavigationService(RtdDaoImpl.java:378)
> [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[na:1.6.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source) ~[na:1.6.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source) ~[na:1.6.0_45]
> at java.lang.reflect.Method.invoke(Unknown Source)
> ~[na:1.6.0_45]
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
> [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
> at
> hr.pbz.core.logging.interceptor.PerformanceLoggingInterceptor.invoke(PerformanceLoggingInterceptor.java:87)
> [pbz-common-utils-9.50.72-SNAPSHOT.jar:na]
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
> [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE]
> at com.sun.proxy.$Proxy233.callNavigationService(Unknown
> Source) [na:na]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:197)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:186)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:177)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseChainCache.getChain(PhaseChainCache.java:93)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseChainCache.get(PhaseChainCache.java:77)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.endpoint.ClientImpl.setupInterceptorChain(ClientImpl.java:1007)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:538)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
> ~[cxf-api-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> ~[cxf-rt-frontend-simple-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> ~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11]
>
> Codebase for client:
>
> private SDClientPortType getWebServiceClient() {
>
> final JaxWsProxyFactoryBean factory = new
> JaxWsProxyFactoryBean();
>
[jira] [Resolved] (CXF-6750) HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
[ https://issues.apache.org/jira/browse/CXF-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matko Šuflaj resolved CXF-6750. --- Resolution: Not A Problem Misconfiguration in injecting the interceptor properties, after switching to XML configuration the thing worked, probably would have with programmatic too with a bit more research. > HTTPS javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault > code, not set > -- > > Key: CXF-6750 > URL: https://issues.apache.org/jira/browse/CXF-6750 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.11 >Reporter: Matko Šuflaj > > Hi, > > I am having an issue when trying to create a client that communicates with > the service over https, following is the exception: > > javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, > not set > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157) > ~[cxf-rt-frontend-jaxws-2.7.11.jar:2.7.11] > at com.sun.proxy.$Proxy232.invoke(Unknown Source) ~[na:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.invokeService(RtdDaoImpl.java:227) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at > hr.pbz.core.dao.impl.RtdDaoImpl.callNavigationService(RtdDaoImpl.java:378) > [pbz-retail-dao-9.50.72-SNAPSHOT.jar:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) ~[na:1.6.0_45] > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) ~[na:1.6.0_45] > at java.lang.reflect.Method.invoke(Unknown Source) > ~[na:1.6.0_45] > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > hr.pbz.core.logging.interceptor.PerformanceLoggingInterceptor.invoke(PerformanceLoggingInterceptor.java:87) > [pbz-common-utils-9.50.72-SNAPSHOT.jar:na] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) > [spring-aop-3.1.0.RELEASE.jar:3.1.0.RELEASE] > at com.sun.proxy.$Proxy233.callNavigationService(Unknown > Source) [na:na] > Caused by: java.lang.NullPointerException: null > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:197) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:186) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.add(PhaseInterceptorChain.java:177) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.getChain(PhaseChainCache.java:93) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseChainCache.get(PhaseChainCache.java:77) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.setupInterceptorChain(ClientImpl.java:1007) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:538) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > ~[cxf-api-2.7.11.jar:2.7.11] > at > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > ~[cxf-rt-frontend-simple-2.7.11.jar:2.7.11] > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) > ~[cxf-rt-fr
[jira] [Created] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
Torsten Römer created CXF-6769: -- Summary: Underscores in values of FIQL search expressions are incorrectly escaped Key: CXF-6769 URL: https://issues.apache.org/jira/browse/CXF-6769 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.2 Environment: Webapp deployed to WildFly 10 Reporter: Torsten Römer Priority: Minor We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL\_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Römer updated CXF-6769: --- Description: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL\\_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. was: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL\_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Priority: Minor > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL\\_UE' > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was escaped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Römer updated CXF-6769: --- Description: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. was: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL\\_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Priority: Minor > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was escaped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Römer updated CXF-6769: --- Description: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' (Note [backslash] is supposed to mean a literal "\" which is swallowed here) If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. was: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Priority: Minor > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > (Note [backslash] is supposed to mean a literal "\" which is swallowed here) > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was escaped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Römer updated CXF-6769: --- Description: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' (Note [backslash] is supposed to mean a literal "\" which is swallowed here) If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was preceded with a backslash. was: We are basically "just" using FIQLParser and SQLPrinterVisitor like this: final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); final SearchCondition searchCondition = fiqlParser.parse(search); final SQLPrinterVisitor visitor = new SQLPrinterVisitor(table); searchCondition.accept(visitor); final String sql = visitor.getQuery(); A search expression like this: text==VAL_UE yields an SQL query like this: SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' (Note [backslash] is supposed to mean a literal "\" which is swallowed here) If the table contains a row with text "VAL_UE", the query returns no results because the underscore in the value was escaped. > Underscores in values of FIQL search expressions are incorrectly escaped > ---- > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Priority: Minor > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > (Note [backslash] is supposed to mean a literal "\" which is swallowed here) > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was preceded with a backslash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150452#comment-15150452 ] Torsten Römer commented on CXF-6769: Great, I'll check this out as soon as the next release is available! > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > (Note [backslash] is supposed to mean a literal "\" which is swallowed here) > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was preceded with a backslash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6807) Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html
Tobias Schöneberg created CXF-6807: -- Summary: Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html Key: CXF-6807 URL: https://issues.apache.org/jira/browse/CXF-6807 Project: CXF Issue Type: Bug Components: Documentation Reporter: Tobias Schöneberg Priority: Minor In http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Client it somewhere sais "[...]please see this beans.xml" where "beans.xml" is a link to http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/jms_server_config.xml that link is broken, the correct URL would be http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/jms/jms_server_config.xml Regards, Tobi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6810) Oneway with jms-transport not working
Tobias Schöneberg created CXF-6810: -- Summary: Oneway with jms-transport not working Key: CXF-6810 URL: https://issues.apache.org/jira/browse/CXF-6810 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.0.8, 3.1.5, 3.1.4 Reporter: Tobias Schöneberg I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header plan a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayReques" not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Schöneberg updated CXF-6810: --- Attachment: cxf-jms-oneway-issue.zip the tests as announced in the issue description > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header plan a role. However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayReques" not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Schöneberg updated CXF-6810: --- Description: I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header play a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayRequest not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias was: I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header plan a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayReques" not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173415#comment-15173415 ] Tobias Schöneberg edited comment on CXF-6810 at 3/1/16 8:47 AM: adding the tests as announced in the issue description was (Author: t.schoeneberg): the tests as announced in the issue description > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6656) [Regression] Inheritance of exceptions produces marshalling problems
[
https://issues.apache.org/jira/browse/CXF-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Mähr updated CXF-6656:
---
Affects Version/s: 3.1.5
> [Regression] Inheritance of exceptions produces marshalling problems
>
>
> Key: CXF-6656
> URL: https://issues.apache.org/jira/browse/CXF-6656
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.3, 3.1.5
>Reporter: Bernhard Mähr
>
> We have services throwing exceptions inherited from super classes.
> For example:
> {code}
> public class MyException extends org.springframework.dao.DataAccessException
> { .. }
> {code}
> Throwing this exception leads to
> Caused by: javax.xml.bind.JAXBException: java.lang.Throwable is not known to
> this context
> at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:613)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getBeanInfo(UnmarshallerImpl.java:599)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:394)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallException(JAXBEncoderDecoder.java:582)
> The problem is the method getMostSpecificCause returning an object of type
> Throwable.
> In older versions (2.4.10) the superclasses of the exception were not
> processed by JAXBEncoderDecoder.marshallException, only the getters of the
> actual class.
> Now the method Utils.getGetters is used to get the list of getters and it
> returns also getters of superclasses.
> It is not possible to avoid marshalling of the method getMostSpecificCause
> with XmlTransient because even if it is overidden in the actual class,
> Utils.getGetters returns the method off the superclass. This is because only
> annotations of the method of the superclass are checked.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173694#comment-15173694 ] Tobias Schöneberg commented on CXF-6810: Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seem to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173694#comment-15173694 ] Tobias Schöneberg edited comment on CXF-6810 at 3/1/16 12:42 PM: - Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seems to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. was (Author: t.schoeneberg): Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seem to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6845) Some methods in MessageUtils prone to NPE
Francesco Chicchiriccò created CXF-6845:
---
Summary: Some methods in MessageUtils prone to NPE
Key: CXF-6845
URL: https://issues.apache.org/jira/browse/CXF-6845
Project: CXF
Issue Type: Bug
Affects Versions: 3.0.9
Reporter: Francesco Chicchiriccò
When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
due to some methods in {{MessageUtils}} - see for example
{code}
public static boolean getContextualBoolean(Message m, String key, boolean
defaultValue) {
Object o = m.getContextualProperty(key);
if (o != null) {
return PropertyUtils.isTrue(o);
}
return defaultValue;
}
{code}
As you can see, if {{m}} is NULL, NPE is thrown.
See for reference the same method from 3.1.6:
{code}
public static boolean getContextualBoolean(Message m, String key, boolean
defaultValue) {
if (m != null) {
Object o = m.getContextualProperty(key);
if (o != null) {
return PropertyUtils.isTrue(o);
}
}
return defaultValue;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6845) Some methods in MessageUtils prone to NPE
[
https://issues.apache.org/jira/browse/CXF-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6845:
Attachment: CXF-6845.diff
Being this a core class, I prefer to attach a patch instead of committing the
fix directly; please review.
> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6845) Some methods in MessageUtils prone to NPE
[
https://issues.apache.org/jira/browse/CXF-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned CXF-6845:
---
Assignee: Francesco Chicchiriccò
> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6845) Some methods in MessageUtils prone to NPE
[
https://issues.apache.org/jira/browse/CXF-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6845:
Fix Version/s: 3.2.0
3.1.7
3.0.10
> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6845) Some methods in MessageUtils prone to NPE
[
https://issues.apache.org/jira/browse/CXF-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved CXF-6845.
-
Resolution: Fixed
> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6845) Some methods in MessageUtils prone to NPE
[
https://issues.apache.org/jira/browse/CXF-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215820#comment-15215820
]
Francesco Chicchiriccò commented on CXF-6845:
-
Thanks [~sergey_beryozkin] for reviewing.
> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[
https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231929#comment-15231929
]
Torsten Römer commented on CXF-6769:
I've just tried this and while this would solve our problem, we unfortunately
can't use in our setup.
We are running in WildFly 8/10 which includes Apache CXF, but uses RESTEasy
instead of CXF's RS implementation. So we basically just include
cxf-rt-rs-extension-search in our WAR deployment and create our "own" instance
of FiqlParser (all we want to do is to convert an FIQL expression to an SQL
query):
{code}
final FiqlParser fiqlParser = new
FiqlParser<>(SearchBean.class);
final SearchCondition searchCondition =
fiqlParser.parse(search);
final SQLPrinterVisitor visitor = new
SQLPrinterVisitor(table);
searchCondition.accept(visitor);
final String sql = visitor.getQuery();
{code}
And like that we are not able to set the property.
Any suggestion?
> Underscores in values of FIQL search expressions are incorrectly escaped
>
>
> Key: CXF-6769
> URL: https://issues.apache.org/jira/browse/CXF-6769
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.2
> Environment: Webapp deployed to WildFly 10
>Reporter: Torsten Römer
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.6, 3.0.9, 3.2.0
>
>
> We are basically "just" using FIQLParser and SQLPrinterVisitor like this:
> final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class);
> final SearchCondition searchCondition = fiqlParser.parse(search);
> final SQLPrinterVisitor visitor = new
> SQLPrinterVisitor(table);
> searchCondition.accept(visitor);
> final String sql = visitor.getQuery();
> A search expression like this:
> text==VAL_UE
> yields an SQL query like this:
> SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE'
> (Note [backslash] is supposed to mean a literal "\" which is swallowed here)
> If the table contains a row with text "VAL_UE", the query returns no results
> because the underscore in the value was preceded with a backslash.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232047#comment-15232047 ] Torsten Römer commented on CXF-6769: Setting the property is fine, but since the Message given to MessageUtil.getContextualBoolean() is null in this case, the property is not considered and the defaultValue "true" is returned and the underscore is still escaped. Or am I missing something here? > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.1.6, 3.0.9, 3.2.0 > > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > (Note [backslash] is supposed to mean a literal "\" which is swallowed here) > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was preceded with a backslash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6769) Underscores in values of FIQL search expressions are incorrectly escaped
[ https://issues.apache.org/jira/browse/CXF-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232223#comment-15232223 ] Torsten Römer commented on CXF-6769: Fine, we'll either avoid underscores for now or implement the workaround. Thank you! > Underscores in values of FIQL search expressions are incorrectly escaped > > > Key: CXF-6769 > URL: https://issues.apache.org/jira/browse/CXF-6769 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.2 > Environment: Webapp deployed to WildFly 10 >Reporter: Torsten Römer >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.1.6, 3.0.9, 3.2.0 > > > We are basically "just" using FIQLParser and SQLPrinterVisitor like this: > final FiqlParser fiqlParser = new FiqlParser<>(SearchBean.class); > final SearchCondition searchCondition = fiqlParser.parse(search); > final SQLPrinterVisitor visitor = new > SQLPrinterVisitor(table); > searchCondition.accept(visitor); > final String sql = visitor.getQuery(); > A search expression like this: > text==VAL_UE > yields an SQL query like this: > SELECT * FROM some_table WHERE text = 'VAL[backslash]_UE' > (Note [backslash] is supposed to mean a literal "\" which is swallowed here) > If the table contains a row with text "VAL_UE", the query returns no results > because the underscore in the value was preceded with a backslash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6907) CXF-WSN improvment in onMessage listenner
Mançaux Pierre-Alexandre created CXF-6907:
-
Summary: CXF-WSN improvment in onMessage listenner
Key: CXF-6907
URL: https://issues.apache.org/jira/browse/CXF-6907
Project: CXF
Issue Type: Improvement
Components: JMS, Services
Affects Versions: 3.0.5
Environment: ServiceMix bundle
Reporter: Mançaux Pierre-Alexandre
Priority: Trivial
hello,
i m using servicemix with apache-cxf-wsn as a bundle and i see when i send a
jms message on activemq, my consumer take it and i pass 1 second in onMessage
method of org.apache.cxf.wsn.jms.JmsSubscription class.
500ms is pass into getEpr method.
I think we can declare a
private W3CEndpointReference epr;
in JmsSubscription and in constructor or in onMessage do :
if (epr == null) {
epr = getEpr();
}
with this i win 500ms per message!
in my opinion getEpr is returning always the same W3CEndpointReference value,
can you confirm it and i can propose a patch to correct this.
thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-226) Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
[
https://issues.apache.org/jira/browse/DOSGI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303505#comment-15303505
]
Panu Hämäläinen commented on DOSGI-226:
---
To be clear, the patch would be to change from
{code}
private static final String CONFIG_SERVICE_PID = "cxf-dsw";
{code}
to
{code}
private static final String CONFIG_SERVICE_PID = "org.apache.cxf.dosgi.dsw";
{code}
in org.apache.cxf.dosgi.dsw.Activator
> Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
> -
>
> Key: DOSGI-226
> URL: https://issues.apache.org/jira/browse/DOSGI-226
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.7.0
>Reporter: Panu Hämäläinen
>
> I have tried to configure DSW in Karaf 4.0.3 via Felix fileinstall with a
> config file named "cxf-dsw.cfg". However, the framework never ends up calling
> the update method (ManagedService) of org.apache.cxf.dosgi.dsw.Activator. The
> problem probably is the syntax (against OSGi spec?) of the service PID
> (cxf-dsw). After updating the PID to "org.apache.cxf.dosgi.dsw" in
> org.apache.cxf.dosgi.dsw.Activator (and the cfg filename accordingly) things
> started to work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[
https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303507#comment-15303507
]
Panu Hämäläinen commented on DOSGI-225:
---
To be clear, the patch would be to change from
{code}
!*
{code}
to
{code}
org.apache.cxf.dosgi.discovery.zookeeper.publish
{code}
in the pom of the artifact cxf-dosgi-ri-discovery-distributed.
> Service publication with org.apache.cxf.ws.httpservice.context property does
> not work
> -
>
> Key: DOSGI-225
> URL: https://issues.apache.org/jira/browse/DOSGI-225
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.7.0
>Reporter: Panu Hämäläinen
>
> For org.apache.cxf.ws.httpservice.context the page
> https://cxf.apache.org/distributed-osgi-reference.html says "When this
> property is specified, the OSGi HTTP Service is used to expose the service,
> rather than a dedicated Jetty HTTP Server. This property doesn't allow the
> specification of a port number, as this is provided by the HTTP Service."
> However, this does not work with DOSGi 1.7.0. Instead, the service gets
> exposed (by PojoConfigurationTypeHandler) at the default address
> http://localhost:9000. This used to work e.g. with 1.4.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[
https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303507#comment-15303507
]
Panu Hämäläinen edited comment on DOSGI-225 at 5/27/16 5:16 AM:
To be clear, the patch would be to change from
{code}
!*
{code}
to
{code}
org.apache.cxf.dosgi.discovery.zookeeper.publish
{code}
in the pom.xml of the artifact cxf-dosgi-ri-discovery-distributed.
was (Author: hamapa):
To be clear, the patch would be to change from
{code}
!*
{code}
to
{code}
org.apache.cxf.dosgi.discovery.zookeeper.publish
{code}
in the pom of the artifact cxf-dosgi-ri-discovery-distributed.
> Service publication with org.apache.cxf.ws.httpservice.context property does
> not work
> -
>
> Key: DOSGI-225
> URL: https://issues.apache.org/jira/browse/DOSGI-225
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.7.0
>Reporter: Panu Hämäläinen
>
> For org.apache.cxf.ws.httpservice.context the page
> https://cxf.apache.org/distributed-osgi-reference.html says "When this
> property is specified, the OSGi HTTP Service is used to expose the service,
> rather than a dedicated Jetty HTTP Server. This property doesn't allow the
> specification of a port number, as this is provided by the HTTP Service."
> However, this does not work with DOSGi 1.7.0. Instead, the service gets
> exposed (by PojoConfigurationTypeHandler) at the default address
> http://localhost:9000. This used to work e.g. with 1.4.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[
https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Panu Hämäläinen updated DOSGI-225:
--
Comment: was deleted
(was: To be clear, the patch would be to change from
{code}
!*
{code}
to
{code}
org.apache.cxf.dosgi.discovery.zookeeper.publish
{code}
in the pom.xml of the artifact cxf-dosgi-ri-discovery-distributed.)
> Service publication with org.apache.cxf.ws.httpservice.context property does
> not work
> -
>
> Key: DOSGI-225
> URL: https://issues.apache.org/jira/browse/DOSGI-225
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.7.0
>Reporter: Panu Hämäläinen
>
> For org.apache.cxf.ws.httpservice.context the page
> https://cxf.apache.org/distributed-osgi-reference.html says "When this
> property is specified, the OSGi HTTP Service is used to expose the service,
> rather than a dedicated Jetty HTTP Server. This property doesn't allow the
> specification of a port number, as this is provided by the HTTP Service."
> However, this does not work with DOSGi 1.7.0. Instead, the service gets
> exposed (by PojoConfigurationTypeHandler) at the default address
> http://localhost:9000. This used to work e.g. with 1.4.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-224) DiscoveryPlugin interface not exported
[
https://issues.apache.org/jira/browse/DOSGI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303512#comment-15303512
]
Panu Hämäläinen commented on DOSGI-224:
---
To be clear, the patch would be to change from
{code}
!*
{code}
to
{code}
org.apache.cxf.dosgi.discovery.zookeeper.publish
{code}
in the pom.xml of the artifact cxf-dosgi-ri-discovery-distributed.
> DiscoveryPlugin interface not exported
> --
>
> Key: DOSGI-224
> URL: https://issues.apache.org/jira/browse/DOSGI-224
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Discovery
>Affects Versions: 1.7.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0)
> which makes it impossible to implement 3rd party discovery plugins.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6298) Memory leak in tomcat webapp
[
https://issues.apache.org/jira/browse/CXF-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307847#comment-15307847
]
GELOT Cédric commented on CXF-6298:
---
I think the problem is not related to CXF but tomcat : [Bug
59138|https://bz.apache.org/bugzilla/show_bug.cgi?id=59138]
> Memory leak in tomcat webapp
>
>
> Key: CXF-6298
> URL: https://issues.apache.org/jira/browse/CXF-6298
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.4
> Environment: Tomcat 7.0.55
>Reporter: Alessandro Canevese
>
> I'm developing a J2EE webapp with Spring 4.1, Struts2, etc.. I'm not able to
> redeploy my app under development more than a couple of times before a
> permgen / out of memory error is fired.
> To see if it's my Spring configuration fault, I've got rid of the jaxws bean
> and I've put the following code directly in a method:
> ...
> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
> Client client = dcf.createClient(serviceUrl + "?wsdl");
> Object result = null;
> try
> {
> Object[] callResult = client.invoke(methodName, parameter);
> result = callResult[0];
> }
> catch (Exception ex)
> {
> log.error(ex);
> }
> ...use of result (without storing it anywhere)...
>
> Nothing has changed. Sooner or later, when I undeploy the webapp I get a
> couple of the following:
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [com.sun.xml.bind.v2.ClassFactory$1] (value
> [com.sun.xml.bind.v2.ClassFactory$1@2379cbe3]) and a value of type
> [java.util.WeakHashMap] (value [
> {class
> it.cai.auth.ws.core.service.UserGroup=java.lang.ref.WeakReference@1138b647,
> class
> it.cai.auth.ws.core.service.GetUserDataResponse=java.lang.ref.WeakReference@2246f826,
> class java.util.ArrayList=java.lang.ref.WeakReference@614d985e, class
> it.cai.auth.ws.core.service.User=java.lang.ref.WeakReference@2d4e753a, class
> it.cai.auth.ws.core.service.Authority=java.lang.ref.WeakReference@79f24a12}
> ]) but failed to remove it when the web application was stopped. Threads are
> going to be renewed over time to try and avoid a probable memory leak.
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@11dd224a]) and
> a value of type [org.apache.cxf.BusFactory.BusHolder] (value
> [org.apache.cxf.BusFactory$BusHolder@4cf6316f]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> Just to be clear, classes it.cai.auth.ws.core.service.* are those dynamically
> created by CXF accessing the ws pointed by the serviceUrl above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
Tobias Schöneberg created CXF-6930:
--
Summary: Race-Condition with JMS-transport, LoggingInInterceptor
spoils the payload while logging it
Key: CXF-6930
URL: https://issues.apache.org/jira/browse/CXF-6930
Project: CXF
Issue Type: Bug
Components: JMS
Affects Versions: 3.1.6
Reporter: Tobias Schöneberg
Hi,
I think we stumbled over a problem with cxf and the JMS-transport,
if the {{LoggingFeature}} is used to log incoming response messages.
The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
{{null}},
but from the logged message payload, it's clear that there is a not-null
response payload coming from the sever.
I believe, I just figured out that it is in fact the logging of that very
payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
How?
There is a race between the actual "client thread" which waited for the
server's response
(i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
until notified by the ActiveMQ Session Task thread
(i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
one one side and the ActiveMQ Session Task thread itself on the other side.
Once the client thread is notified, it goes on with {{preProcessResult(...)}}
and {{handleResponse(...)}} and somewhere in there the message's
{{ByteArrayStream}} is read and the return object is created.
However, at the same time, back in the ActiveMQ thread, the interceptor chain
is run.
In my case it contains the {{LoggingInInterceptor}} which accesses the
message's *same* {{ByteArrayInputStream}}, in the method
{{LoggingInInterceptor.logInputStream(...)}} ).
Now, in {{logInputStream(...)}}, we have
{code:java}
IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
bos.flush();
bis = new SequenceInputStream(bos.getInputStream(), bis);
// restore the delegating input stream or the input stream
if (is instanceof DelegatingInputStream) {
((DelegatingInputStream)is).setInputStream(bis);
} else {
message.setContent(InputStream.class, bis);
}
{code}
My problem happens if the client thread tries to read the message while
"{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is closed
for the in the client thread and it will skip over it (or throw an Exception,
based on its config).
My current best and maybe naive guess on how to solve this is to change the
method {{JMSConduit.processReplyMessage(...)}}
and execute the if-block around {{exchange.notifyAll();}} only after the
if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
WDYT?
Best reagards
Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6942) cxf-codegen-plugin wsdlArtifact
Torkel Røisli created CXF-6942: -- Summary: cxf-codegen-plugin wsdlArtifact Key: CXF-6942 URL: https://issues.apache.org/jira/browse/CXF-6942 Project: CXF Issue Type: Sub-task Components: Core Affects Versions: 3.1.6 Reporter: Torkel Røisli Fix For: 3.0.0-milestone1 Failed to resolve WSDL artifact no.xxx:artifactId-wsdl:master-SNAPSHOT. no.xxx artifactId-wsdl master-SNAPSHOT Verified to work ok with 3.0.0-milestone1, but failes with 3.1.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6942) cxf-codegen-plugin wsdlArtifact failed to resolve WSDL
[ https://issues.apache.org/jira/browse/CXF-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torkel Røisli updated CXF-6942: --- Summary: cxf-codegen-plugin wsdlArtifact failed to resolve WSDL (was: cxf-codegen-plugin wsdlArtifact) > cxf-codegen-plugin wsdlArtifact failed to resolve WSDL > -- > > Key: CXF-6942 > URL: https://issues.apache.org/jira/browse/CXF-6942 > Project: CXF > Issue Type: Sub-task > Components: Core >Affects Versions: 3.1.6 >Reporter: Torkel Røisli > Fix For: 3.0.0-milestone1 > > > Failed to resolve WSDL artifact no.xxx:artifactId-wsdl:master-SNAPSHOT. > > no.xxx > artifactId-wsdl > master-SNAPSHOT > > Verified to work ok with 3.0.0-milestone1, but failes with 3.1.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-6298) Memory leak in tomcat webapp
[
https://issues.apache.org/jira/browse/CXF-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
GELOT Cédric updated CXF-6298:
--
Comment: was deleted
(was: I think the problem is not related to CXF but tomcat : [Bug
59138|https://bz.apache.org/bugzilla/show_bug.cgi?id=59138])
> Memory leak in tomcat webapp
>
>
> Key: CXF-6298
> URL: https://issues.apache.org/jira/browse/CXF-6298
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.4
> Environment: Tomcat 7.0.55
>Reporter: Alessandro Canevese
>
> I'm developing a J2EE webapp with Spring 4.1, Struts2, etc.. I'm not able to
> redeploy my app under development more than a couple of times before a
> permgen / out of memory error is fired.
> To see if it's my Spring configuration fault, I've got rid of the jaxws bean
> and I've put the following code directly in a method:
> ...
> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
> Client client = dcf.createClient(serviceUrl + "?wsdl");
> Object result = null;
> try
> {
> Object[] callResult = client.invoke(methodName, parameter);
> result = callResult[0];
> }
> catch (Exception ex)
> {
> log.error(ex);
> }
> ...use of result (without storing it anywhere)...
>
> Nothing has changed. Sooner or later, when I undeploy the webapp I get a
> couple of the following:
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [com.sun.xml.bind.v2.ClassFactory$1] (value
> [com.sun.xml.bind.v2.ClassFactory$1@2379cbe3]) and a value of type
> [java.util.WeakHashMap] (value [
> {class
> it.cai.auth.ws.core.service.UserGroup=java.lang.ref.WeakReference@1138b647,
> class
> it.cai.auth.ws.core.service.GetUserDataResponse=java.lang.ref.WeakReference@2246f826,
> class java.util.ArrayList=java.lang.ref.WeakReference@614d985e, class
> it.cai.auth.ws.core.service.User=java.lang.ref.WeakReference@2d4e753a, class
> it.cai.auth.ws.core.service.Authority=java.lang.ref.WeakReference@79f24a12}
> ]) but failed to remove it when the web application was stopped. Threads are
> going to be renewed over time to try and avoid a probable memory leak.
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@11dd224a]) and
> a value of type [org.apache.cxf.BusFactory.BusHolder] (value
> [org.apache.cxf.BusFactory$BusHolder@4cf6316f]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> Just to be clear, classes it.cai.auth.ws.core.service.* are those dynamically
> created by CXF accessing the ws pointed by the serviceUrl above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6942) cxf-codegen-plugin wsdlArtifact failed to resolve WSDL
[ https://issues.apache.org/jira/browse/CXF-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351838#comment-15351838 ] Eivind Bergtøl commented on CXF-6942: - I have the same problem (maven 3.3.9). I have been trying to publish wsdl-files to nexus and only depend on the wsdl (wsdl first). At first I had problems with multiple wsdl-files in the same pom leaving only the first generated wsdl in the repository. This is fixed in CXF-6420. However this fix uses the classifier and it seams that, at least version 3.6.1 can't handle the classifier. The problem as it seams is that maven needs a dependency with ```Classifier.wsdl``` as type instead of ```wsdl``` and classifier in classifier tag. Not Working: ``` my.group webservices 0-SNAPSHOT wsdl MyService ``` Working: ``` my.groupl webservices 0-SNAPSHOT MyService.wsdl The problem is then that AbstractCodegenMoho that is checking for the dependencies only checks for ```"wsdl".equals(pArtifact.getType())``` and ignoring classifier. So either fix the dependency module, or have AbstractCodegenMoho check for ```pArtifact.getClassifier()+".wsdl").equals(pArtifact.getType())``` in addition to the checks that are there now. > cxf-codegen-plugin wsdlArtifact failed to resolve WSDL > -- > > Key: CXF-6942 > URL: https://issues.apache.org/jira/browse/CXF-6942 > Project: CXF > Issue Type: Sub-task > Components: Core >Affects Versions: 3.1.6 >Reporter: Torkel Røisli > Fix For: 3.0.0-milestone1 > > > Failed to resolve WSDL artifact no.xxx:artifactId-wsdl:master-SNAPSHOT. > > no.xxx > artifactId-wsdl > master-SNAPSHOT > > Verified to work ok with 3.0.0-milestone1, but failes with 3.1.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6942) cxf-codegen-plugin wsdlArtifact failed to resolve WSDL
[ https://issues.apache.org/jira/browse/CXF-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351838#comment-15351838 ] Eivind Bergtøl edited comment on CXF-6942 at 6/27/16 9:21 PM: -- I have the same problem (maven 3.3.9). I have been trying to publish wsdl-files to nexus and only depend on the wsdl (wsdl first). At first I had problems with multiple wsdl-files in the same pom leaving only the first generated wsdl in the repository. This is fixed in CXF-6420. However this fix uses the classifier and it seams that, at least version 3.6.1 can't handle the classifier. The problem as it seams is that maven needs a dependency with ```Classifier.wsdl``` as type instead of ```wsdl``` and classifier in classifier tag. Not Working: my.group webservices 0-SNAPSHOT wsdl MyService Working: my.groupl webservices 0-SNAPSHOT MyService.wsdl The problem is then that AbstractCodegenMoho that is checking for the dependencies only checks for "wsdl".equals(pArtifact.getType()) and ignoring classifier. So either fix the dependency module, or have AbstractCodegenMoho check for pArtifact.getClassifier()+".wsdl").equals(pArtifact.getType()) in addition to the checks that are there now. was (Author: eivinhb): I have the same problem (maven 3.3.9). I have been trying to publish wsdl-files to nexus and only depend on the wsdl (wsdl first). At first I had problems with multiple wsdl-files in the same pom leaving only the first generated wsdl in the repository. This is fixed in CXF-6420. However this fix uses the classifier and it seams that, at least version 3.6.1 can't handle the classifier. The problem as it seams is that maven needs a dependency with ```Classifier.wsdl``` as type instead of ```wsdl``` and classifier in classifier tag. Not Working: ``` my.group webservices 0-SNAPSHOT wsdl MyService ``` Working: ``` my.groupl webservices 0-SNAPSHOT MyService.wsdl The problem is then that AbstractCodegenMoho that is checking for the dependencies only checks for ```"wsdl".equals(pArtifact.getType())``` and ignoring classifier. So either fix the dependency module, or have AbstractCodegenMoho check for ```pArtifact.getClassifier()+".wsdl").equals(pArtifact.getType())``` in addition to the checks that are there now. > cxf-codegen-plugin wsdlArtifact failed to resolve WSDL > -- > > Key: CXF-6942 > URL: https://issues.apache.org/jira/browse/CXF-6942 > Project: CXF > Issue Type: Sub-task > Components: Core >Affects Versions: 3.1.6 >Reporter: Torkel Røisli > Fix For: 3.0.0-milestone1 > > > Failed to resolve WSDL artifact no.xxx:artifactId-wsdl:master-SNAPSHOT. > > no.xxx > artifactId-wsdl > master-SNAPSHOT > > Verified to work ok with 3.0.0-milestone1, but failes with 3.1.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6957) JAX-RS: ExceptionMapper not called for Fault
Philipp Förmer created CXF-6957: --- Summary: JAX-RS: ExceptionMapper not called for Fault Key: CXF-6957 URL: https://issues.apache.org/jira/browse/CXF-6957 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.6 Reporter: Philipp Förmer Hi, let service be a cxf jax-rs based service which uses a cxf based soap proxy client to communicate with a soap service. If the cxf soap proxy client throws a org.apache.cxf.binding.soap.SoapFault, then the SoapFault is not delegated to the jax-rs ExceptionMapper chain, which is for me an unexpected behaviour. As far as I can see this is caused by: org.apache.cxf.service.invoker.AbstractInvoker.invoke(...), L: 123 * Rethrows exception directly without wrapping it into a fault, if exception is of type org.apache.cxf.interceptor.Fault. SoapFault is a subclass of Fault. org.apache.cxf.jaxrs.JAXRSInvoker.handleFault, L:329 * Passes the cause of the fault to ExceptionUtils.convertFaultToResponse. The cause of the cxf SoapFault is null! org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse, L.65: * Is called with null "ex" parameter and immediatley returns with null, so no exception mapper gets involved. Thank you for your support and great project, Philipp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6942) cxf-codegen-plugin wsdlArtifact failed to resolve WSDL
[ https://issues.apache.org/jira/browse/CXF-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370303#comment-15370303 ] Eivind Bergtøl commented on CXF-6942: - To clarify: The workaround is for Maven to be able to pick up the dependency. Cxf still need to be patched to care to look for one with a classifier in dependency lists produced by maven. > cxf-codegen-plugin wsdlArtifact failed to resolve WSDL > -- > > Key: CXF-6942 > URL: https://issues.apache.org/jira/browse/CXF-6942 > Project: CXF > Issue Type: Sub-task > Components: Core >Affects Versions: 3.1.6 >Reporter: Torkel Røisli > Fix For: 3.0.0-milestone1 > > > Failed to resolve WSDL artifact no.xxx:artifactId-wsdl:master-SNAPSHOT. > > no.xxx > artifactId-wsdl > master-SNAPSHOT > > Verified to work ok with 3.0.0-milestone1, but failes with 3.1.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
[
https://issues.apache.org/jira/browse/CXF-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384027#comment-15384027
]
Tobias Schöneberg commented on CXF-6930:
today i banged my head again, because i had negelected to switch off inbound
data logging...
any news on this issue?
> Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload
> while logging it
> ---
>
> Key: CXF-6930
> URL: https://issues.apache.org/jira/browse/CXF-6930
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Tobias Schöneberg
>
> Hi,
> I think we stumbled over a problem with cxf and the JMS-transport,
> if the {{LoggingFeature}} is used to log incoming response messages.
> The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
> {{null}},
> but from the logged message payload, it's clear that there is a not-null
> response payload coming from the sever.
> I believe, I just figured out that it is in fact the logging of that very
> payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
> How?
> There is a race between the actual "client thread" which waited for the
> server's response
> (i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
> until notified by the ActiveMQ Session Task thread
> (i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
> one one side and the ActiveMQ Session Task thread itself on the other side.
> Once the client thread is notified, it goes on with {{preProcessResult(...)}}
> and {{handleResponse(...)}} and somewhere in there the message's
> {{ByteArrayStream}} is read and the return object is created.
> However, at the same time, back in the ActiveMQ thread, the interceptor chain
> is run.
> In my case it contains the {{LoggingInInterceptor}} which accesses the
> message's *same* {{ByteArrayInputStream}}, in the method
> {{LoggingInInterceptor.logInputStream(...)}} ).
> Now, in {{logInputStream(...)}}, we have
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
> bos.flush();
> bis = new SequenceInputStream(bos.getInputStream(), bis);
> // restore the delegating input stream or the input stream
> if (is instanceof DelegatingInputStream) {
> ((DelegatingInputStream)is).setInputStream(bis);
> } else {
> message.setContent(InputStream.class, bis);
> }
> {code}
> My problem happens if the client thread tries to read the message while
> "{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is
> closed for the in the client thread and it will skip over it (or throw an
> Exception, based on its config).
> My current best and maybe naive guess on how to solve this is to change the
> method {{JMSConduit.processReplyMessage(...)}}
> and execute the if-block around {{exchange.notifyAll();}} only after the
> if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
> WDYT?
> Best reagards
> Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
Francesco Chicchiriccò created CXF-6990:
---
Summary: Swagger tags not sorted if using Swagger2Feature
Key: CXF-6990
URL: https://issues.apache.org/jira/browse/CXF-6990
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.0.10, 3.1.7, 3.2.0
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 3.1.8
With latest updates, the tags generated by {{Swagger2Serializers}} for
{{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6990:
Priority: Minor (was: Major)
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.1.8
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved CXF-6990.
-
Resolution: Fixed
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.1.8
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6990:
Fix Version/s: 3.0.11
3.2.0
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6524) Swagger 2 feature doesn't work with blueprint endpoints
[
https://issues.apache.org/jira/browse/CXF-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418605#comment-15418605
]
Łukasz Dywicki commented on CXF-6524:
-
Sorry for one year delay :-) - yes I added feature at bus level, not endpoint.
With endpoint swagger feature works fine.
> Swagger 2 feature doesn't work with blueprint endpoints
> ---
>
> Key: CXF-6524
> URL: https://issues.apache.org/jira/browse/CXF-6524
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Łukasz Dywicki
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.3, 3.0.7
>
>
> Swagger2 feature is not working with standard blueprint endpoints. Attaching
> of feature fails cause
> {{org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature#initialize(Server,
> Bus)}} method never gets called in this environment. What is being called is
> {{initializeProvider(InterceptorProvider, Bus)}} method which is not
> overriden by AbstractSwaggerFeature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7009) Swagger feature ignore interfaces under OSGi
Łukasz Dywicki created CXF-7009:
---
Summary: Swagger feature ignore interfaces under OSGi
Key: CXF-7009
URL: https://issues.apache.org/jira/browse/CXF-7009
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.7
Environment: Karaf 4.0.5
Reporter: Łukasz Dywicki
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing a valid package name which contains interfaces is not working as well
because it resources are not visible from implementation bundle. This is side
effect of the Swagger resource scanning logic where it query classloader for
resources. This gets forwarded to CXF's BundleDelegatingClassLoader and then to
bundle which is not aware of any resources from packages different than it's
own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7009) Swagger feature ignore interfaces under OSGi
[
https://issues.apache.org/jira/browse/CXF-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Łukasz Dywicki updated CXF-7009:
Description:
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing to Swagger2Feature an valid package name which contains interfaces is
not working as well because it resources are not visible from implementation
bundle. This is side effect of the Swagger resource scanning logic where it
query classloader for resources. This gets forwarded to CXF's
BundleDelegatingClassLoader and then to bundle which is not aware of any
resources from packages different than it's own.
was:
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing a valid package name which contains interfaces is not working as well
because it resources are not visible from implementation bundle. This is side
effect of the Swagger resource scanning logic where it query classloader for
resources. This gets forwarded to CXF's BundleDelegatingClassLoader and then to
bundle which is not aware of any resources from packages different than it's
own.
> Swagger feature ignore interfaces under OSGi
> ----
>
> Key: CXF-7009
> URL: https://issues.apache.org/jira/browse/CXF-7009
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Karaf 4.0.5
>Reporter: Łukasz Dywicki
>
> When more advanced structuring in project is used cxf swagger intergration
> fails to generate proper swagger service descriptor (while it still works for
> wadl).
> For example:
> {code:lang=java|title=SampleResource.java}
> package org.code_house.swagger.example.api;
> @Api
> @Path("/test")
> public interface SampleResource {
> @GET
> @ApiOperation("Something to do")
> String getSomething();
> }
> {code}
> {code:lang=java|title=DefaultSampleResource.java}
> package org.code_house.swagger.example.core.internal;
> import org.code_house.swagger.example.api.SampleResource;
> public class DefaultSampleResource implements SampleResource {
> public String getSomething() {
> return "aaa";
> }
> }
> {code}
> Works properly, however there is no way to get Swagger2 feature picking this
> up. From my analysis it seems that default package calculation uses just
> package names of resources defined in class (impl classes) and ignores
> implemented interfaces.
> Passing to Swagger2Feature an valid package name which contains interfaces is
> not working as well because it resources are not visible from implementation
> bundle. This is side effect of the Swagger resource scanning logic where it
> query classloader for resources. This gets forwarded to CXF's
> BundleDelegatingClassLoader and then to bundle which is not aware of any
> resources from packages different than it's own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7010) Swagger2Feature can not auto-link to SwaggerUi in OSGI
[
https://issues.apache.org/jira/browse/CXF-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421529#comment-15421529
]
Łukasz Dywicki commented on CXF-7010:
-
Hey Sergey,
It is working fine when version is set, and no problems are reported. I am just
a bit concerned about passing String as URI to SwaggerUIService. Classloader
would be safer and can be achieved without wrapping logic by this sequence:
{code:lang=java}
bundle.adapt(BundleWiring.class).getClassLoader
{code}
Not sure if its a bug but service listing (http://localhost:8181/cxf) still
doesn't show up link to swagger ui.
> Swagger2Feature can not auto-link to SwaggerUi in OSGI
> --
>
> Key: CXF-7010
> URL: https://issues.apache.org/jira/browse/CXF-7010
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7010) Swagger2Feature can not auto-link to SwaggerUi in OSGI
[
https://issues.apache.org/jira/browse/CXF-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421529#comment-15421529
]
Łukasz Dywicki edited comment on CXF-7010 at 8/15/16 7:40 PM:
--
Hey Sergey,
It is working fine when ui version is set, and no problems are reported. I am
just a bit concerned about passing String as URI to SwaggerUIService.
Classloader would be safer and can be achieved without wrapping logic by this
sequence:
{code:lang=java}
bundle.adapt(BundleWiring.class).getClassLoader
{code}
Not sure if its a bug but service listing (http://localhost:8181/cxf) still
doesn't show up link to swagger ui.
was (Author: splatch):
Hey Sergey,
It is working fine when version is set, and no problems are reported. I am just
a bit concerned about passing String as URI to SwaggerUIService. Classloader
would be safer and can be achieved without wrapping logic by this sequence:
{code:lang=java}
bundle.adapt(BundleWiring.class).getClassLoader
{code}
Not sure if its a bug but service listing (http://localhost:8181/cxf) still
doesn't show up link to swagger ui.
> Swagger2Feature can not auto-link to SwaggerUi in OSGI
> --
>
> Key: CXF-7010
> URL: https://issues.apache.org/jira/browse/CXF-7010
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7010) Swagger2Feature can not auto-link to SwaggerUi in OSGI
[ https://issues.apache.org/jira/browse/CXF-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421653#comment-15421653 ] Łukasz Dywicki commented on CXF-7010: - I reached these points as well. Property is properly set, however bus argument is null in FormattedServiceListWriter. I can see here a small conflict because SwaggerFeature must be added to endpoint, how service list will work if there will be multiple endpoints on the same bus? > Swagger2Feature can not auto-link to SwaggerUi in OSGI > -- > > Key: CXF-7010 > URL: https://issues.apache.org/jira/browse/CXF-7010 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7010) Swagger2Feature can not auto-link to SwaggerUi in OSGI
[ https://issues.apache.org/jira/browse/CXF-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421807#comment-15421807 ] Łukasz Dywicki commented on CXF-7010: - It works like a charm! :-) > Swagger2Feature can not auto-link to SwaggerUi in OSGI > -- > > Key: CXF-7010 > URL: https://issues.apache.org/jira/browse/CXF-7010 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422504#comment-15422504 ] Łukasz Dywicki commented on CXF-6904: - I checked swagger code and there is JaxRsScanner which simply read classes from JAXRS Application instance, so this could be done even without hacking api listing resource. > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422557#comment-15422557 ] Łukasz Dywicki commented on CXF-6904: - That's good question. If there is already Application instance constructed by CXF we could just bypass it. For now ApiListingResource has null argument in place of @Context Application argument. Swagger does lots of work with servlet context and this is part I can't really follow at this moment. Will share my thoughts later. > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[
https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425106#comment-15425106
]
Łukasz Dywicki commented on CXF-6904:
-
Hey Sergey,
Thanks for your efforts, sadly it doesn't help. To get Application in use we
need JaxrsScanner, and JaxrsScanner is not registered in servlet context..
which is yet another problem.
During debugging I've found that Swagger internally pass some informations over
servlet context and register beanconfig there. It doesn't happen with
JaxrsScanner. More over swagger instances are cached in servlet context. This
is minor issue (updates in code are ignored unless some bundles get refreshed)
compared to second thing I've found. There is one "global" scanner instance
registered under default key which is used everywhere. I'm pretty sure current
swagger integration will return swagger descriptor for first loaded endpoint
and ommit scanning for others - this is affecting regular deployments as well
unless there are separate servlets for each "swaggerized" endpoint.
In case of servlet transport embedded inside Karaf this is out of control of
developer who deploys service. Only one way I got it partially working was
replacing bean config with:
{code:lang=java}
ScannerFactory.setScanner(new DefaultJaxrsScanner());
{code}
ScannerFactory is last resort used by swagger when it can not find any scanner
in servlet context. This is static instance used everywhere, sadly there is no
description generated, no base path, nothing at all, so descriptor is not valid.
> Unable to read swagger annotations if the file is in another osgi bundle
>
>
> Key: CXF-6904
> URL: https://issues.apache.org/jira/browse/CXF-6904
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, OSGi
>Reporter: Christian Lutz
>
> I created a simple example to reproduce the error.
> https://github.com/ChristianLutz/cxf-swagger-osgi-bug
> =
> JAX-RS Swagger2Feature OSGI Issue
> =
> This example is based on the code from
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> How to reproduce the issue:
> mvn install (on the example)
> bin/karaf (I used the current karaf 4.0.5)
>
> on karaf@root()>
> feature:repo-add cxf 3.1.6
> feature:install cxf-rs-description-swagger2
> install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5
> install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5
> install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0
> install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0
>
> It may happen that one component is complaining about a missing guava class
> even if you provided it before. All you have todo is copy guava-18.jar into
> your deploy folder. I think this is a karaf bug. I have to create a ticket
> for. After you place the guava file into your deploy folder and type list,
> all bundles should be active.
> Now open your web browser and type:
> http://localhost:8181/cxf/swaggerSample/swagger.json
> And all you see is the swagger header.
>
> I guess the problem is the ClasspathHelper.class from org.reflections it
> looks like that this one is not able to access the osgi component.
>
> The behavior is similar to this error description:
>
> http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425273#comment-15425273 ] Łukasz Dywicki commented on CXF-6904: - I've submited PR which should allow us to customize swagger lookups done in BaseApiListingResource: https://github.com/swagger-api/swagger-core/pull/1888. Let see if it gets accepted. > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429819#comment-15429819
]
Łukasz Dywicki commented on CXF-6740:
-
I think there might be nicer (not necessarily better) way to solve this.
Swagger uses contextId, configId and scannerId parameters. We don't set these
in BeanConfig so it assumes always defaults and stores it under default key
instead of compound key valid for given endpoint. If we will override contextId
or configId it will start working properly. See my pull request to this issue.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.patch, CXF-6740-Collision-by-Swagger.patch
>
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429923#comment-15429923
]
Łukasz Dywicki commented on CXF-6740:
-
If servlets are configured already in web.xml with swagger parameters - there
is no change necessary. This change applies only endpoint configurations used
with single servlet:
{code:lang=xml|title=Additional configuration in xml}
{code}
This will have the same effect as setting these in servlet init parameter, but
in endpoint scope, without duplicating servlet configuration. This is in fact
an alternative to solution offered by PR which does not require any additional
parameters in swagger configuration.
I tested it under OSGi, will require some more testing in Spring based
deployments.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.patch, CXF-6740-Collision-by-Swagger.patch
>
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430567#comment-15430567
]
Łukasz Dywicki commented on CXF-6740:
-
[~sergey_beryozkin] There is no need to set basepath when context/scanner is is
set, however it is still necessary to generate valid descriptor which could be
used by swagger-ui. These two solutions are quite similar because they affect
attribute name used to cache swagger instance.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
> Fix For: 3.2.0, 3.1.8
>
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.patch, CXF-6740-Collision-by-Swagger.patch
>
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5663) IllegalStateException using AsyncHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430904#comment-15430904
]
Christoph Hümbert commented on CXF-5663:
Hello,
I am facing the same problem when using Apache CXF 3.1.7. I already changed the
HttpCore (4.4.4 > 4.4.5) but the result is the same. The following demo code
shows how I parametrized and that code is working in general beside that
exception.
{code:java}
SOAPMessage requestMessage = null;
MessageFactory mf;
try {
mf = MessageFactory.newInstance(jaxWsProtocol);
requestMessage = mf.createMessage(null, new
ByteArrayInputStream(requestMsg.getBytes("UTF-8")));
} catch (SOAPException e) { ...
} catch (UnsupportedEncodingException e) { ...
} catch (IOException e) {...}
SOAPMessage responseMessage = null;
DispatchImpl dispatchCxf = null;
if(requestMsg != null) {
Service service = Service.create(serviceQName);
service.addPort(portQName, bindingType, endpointUrl);
Dispatch dispatch = service.createDispatch(portQName,
SOAPMessage.class, Service.Mode.MESSAGE);
dispatchCxf = (DispatchImpl)dispatch;
Client client = dispatchCxf.getClient();
HTTPConduit conduit = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setAllowChunking(Boolean.FALSE);
httpClientPolicy.setAutoRedirect(Boolean.TRUE);
httpClientPolicy.setAsyncExecuteTimeout(3L);
httpClientPolicy.setReceiveTimeout(0);
httpClientPolicy.setConnectionTimeout(0);
//httpClientPolicy.setAsyncExecuteTimeoutRejection(true); //
orignal: false
conduit.setClient(httpClientPolicy);
Bus bus = client.getBus();
bus.setProperty("use.async.http.conduit", Boolean.TRUE);
bus.setProperty("org.apache.cxf.transport.http.async.SO_LINGER", 60);
Map rc = dispatch.getRequestContext();
rc.put("use.async.http.conduit", Boolean.TRUE);
rc.put("thread.local.request.context", Boolean.TRUE);
if(credentials != null) {
rc.put(Credentials.class.getName(), credentials);
}
if(soapAction != null){
rc.put(BindingProvider.SOAPACTION_USE_PROPERTY, Boolean.TRUE);
rc.put(BindingProvider.SOAPACTION_URI_PROPERTY, soapAction);
}
try {
responseMessage = dispatchCxf.invoke(requestMessage);
} catch (WebServiceException e) {
if(e.getCause().getClass().equals(IOException.class)) {
if(e.getCause().getMessage().startsWith("Authorization loop
detected on Conduit")) {
System.out.println("Authentication failed: Wrong credentials: "
+ e.getCause().getMessage());
}
} else if(e.getCause().getClass().equals(SocketTimeoutException.class))
{
System.out.println(e.getCause().getMessage());
} else { System.out.println(e.getCause().getMessage());}
throw new WsServiceException(e.getCause().getMessage());
} finally {
try {
dispatchCxf.close();
} catch (IOException e) { /* ignore */ }
}
}
{code}
I created a JUnit test which creates multiple objects with my implementation
by using the Callable interface. The DTOs contain connection information,
credentials,etc. So I have 3 different web services with different credentials
but on the same host. In this test I created 3000 request which will run in
thread pool. Sometimes it happened but sometimes not. When use my
implementation in Apache Tomcat the this exceptions occurs very quickly.
{code:java}
@Test
public void testWithCallable() {
int numberOfHandlers = 3;
SoapRequestHandler handler1 = new SoapRequestHandler(dto1);
...
Set> set = new HashSet>();
ExecutorService pool = Executors.newFixedThreadPool(50);
int numberOfCalls = 1000;
for(int i = 0; i < numberOfCalls; i++) {
TestSoapServiceCallableRunner run1 = new
TestSoapServiceCallableRunner(handler1);
set.add(pool.submit(run1));
TestSoapServiceCallableRunner run2 = new
TestSoapServiceCallableRunner(handler2);
set.add(pool.submit(run2));
TestSoapServiceCallableRunner run3 = new
TestSoapServiceCallableRunner(handler3);
set.add(pool.submit(run3));
}
for (Future afuture : set) {
OutputStream os;
try {
os = verifySoapResult(afuture.get()); IOUtils.closeQuietly(os);
} catch (InterruptedException e) {...
} catch (ExecutionException e) {... }
}
assertEquals(numberOfCalls * numberOfHandlers, set.size());
}
{code}
Workarounds like retrying often run in the same exception again hence it makes
no sense to use it. I try to dive deeper into the topic...
My system: Fedora 24; i5. Ubuntu 14.04/16.04; OpenJDk 1.8.0_101
> IllegalStateException using Asy
[jira] [Created] (CXF-7022) Allow customization of Swagger JSON generation
Francesco Chicchiriccò created CXF-7022:
---
Summary: Allow customization of Swagger JSON generation
Key: CXF-7022
URL: https://issues.apache.org/jira/browse/CXF-7022
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 3.2.0, 3.1.8, 3.0.11
Swagger JSON generation is currently performed in
{{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
The latter can take a former's instance as parameter, thus allowing
customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved CXF-7022.
-
Resolution: Fixed
> Allow customization of Swagger JSON generation
> --
>
> Key: CXF-7022
> URL: https://issues.apache.org/jira/browse/CXF-7022
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Labels: swagger
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Swagger JSON generation is currently performed in
> {{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
> instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
> The latter can take a former's instance as parameter, thus allowing
> customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-6590) MAPCodec: memory leak with sync client when soapfaults returned from endpoint
[ https://issues.apache.org/jira/browse/CXF-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bjørn Hilstad reopened CXF-6590: Estimated Complexity: Moderate (was: Unknown) I verified this fix when it was created and it seemed fine, but it does not actually handle all cases. It does not leak memory anymore in the case where the soapfault uses an wsa.Action of http://www.w3.org/2005/08/addressing/fault. But there is still a leak when the soapfault uses a wsa:Action that can be used for non WSA related faults. This is http://www.w3.org/2005/08/addressing/soap/fault and it is described in the WS-Addressing specification here: https://www.w3.org/TR/ws-addr-soap/#faults . The specification says that this value MAY be used, but you are also allowed to define custom values. The same reproducer can be used to trigger this but you need to update the wsa:Action in the response that is sent from the wiremock-part (file __files\altinnunavailable.xml in archive wiremock.zip) We have tested againt the latest release of cxf (3.1.7) and the problem is there to. To change CXF versions in the reproducer you just update the property cxf.version in pom.xml (archive cxfoom.zip) > MAPCodec: memory leak with sync client when soapfaults returned from endpoint > - > > Key: CXF-6590 > URL: https://issues.apache.org/jira/browse/CXF-6590 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.6 > Environment: CXF 3.0.6, JDK 1.7, CXF 3.1.2 >Reporter: Bjørn Hilstad >Assignee: Daniel Kulp > Fix For: 3.1.3, 3.0.7 > > Attachments: cxfoom.zip, wiremock.zip > > > This bug is similar to CXF-2591 but relates to sync clients. > A simple client using a service with WS-Addressing which makes repeated calls > to a service that returns a soapfault will cause a build up of objects in > MAPCodec::uncorrelatedExchanges. > The real use case is an application using Apache Camel to keep invoking a > service that returns a fault (for instance wsa:DestinationUnreachable) using > the built in redelivery-functions of Apache Camel. > A simple CXF client that reproduces the issue has been created. The client > just invokes a service in a loop and by observing the used memory (jconsole) > and performing memory dumps which can be analyzed using MAT, you can see the > issue. > A standalone wiremock functions as the endpoint. > The reproducers will be attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457477#comment-15457477
]
Francesco Chicchiriccò commented on CXF-7022:
-
Agree, an interface might be overkill in this case: are you going to take care
of such refactoring? I can do it, but not before next Monday.
> Allow customization of Swagger JSON generation
> --
>
> Key: CXF-7022
> URL: https://issues.apache.org/jira/browse/CXF-7022
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Labels: swagger
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Swagger JSON generation is currently performed in
> {{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
> instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
> The latter can take a former's instance as parameter, thus allowing
> customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-159) Endpoint description contains wrong org.apache.cxf.ws.address when using HTTPService style
[
https://issues.apache.org/jira/browse/DOSGI-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502370#comment-15502370
]
Panu Hämäläinen commented on DOSGI-159:
---
So HttpServiceManager has nothing to do e.g. with the
org.osgi.service.http.port property, you just need to ensure that its config
property httpBase specifies the same port. I am not sure when cxfServletAlias
steps in. It is omitted if the service specifies the
org.apache.cxf.ws.httpservice.context property?
This bug seems to be related to DOSGI-225.
> Endpoint description contains wrong org.apache.cxf.ws.address when using
> HTTPService style
> --
>
> Key: DOSGI-159
> URL: https://issues.apache.org/jira/browse/DOSGI-159
> Project: CXF Distributed OSGi
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Christian Schneider
>Priority: Critical
> Fix For: 2.0.0
>
>
> A Service is exported with the following properties:
> {code:xml}
>
> />{code}This results in the following EndpointDescription:{code}***
> EndpointDescription:
> component.id => 0
> component.name => test.simpleprovider
> endpoint.framework.uuid => 103e59c3-876f-0012-1569-9d4713edced0
> endpoint.id => http://:8181/ws/user//UserRepository
> endpoint.package.version. => 1.0.0
> endpoint.service.id => 37
> objectClass => [.UserRepository]
> org.apache.cxf.ws.address =>
> http://:8181/ws/user//UserRepository
> org.apache.cxf.ws.httpservice.context => /ws/user
> service.imported => true
> service.imported.configs => [org.apache.cxf.ws]
> service.intents => [SOAP.1_1, HTTP, SOAP]{code}the problem here is: The
> HTTPService is not running on 8181 but on a different port configured via
> org.osgi.service.http.port and thus the comunication fails. It seems as if
> here a default port is assumed.
> It should atleast honor the org.osgi.service.http.port property, or we need
> some other kind of way to tell it to CXF.
> HTTPService used is the org.ops4j.pax.web.pax-web-jetty-bundle (2.1.0)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502394#comment-15502394 ] Panu Hämäläinen commented on DOSGI-225: --- Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address=/myaddress (in my service properties) - http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property? > Service publication with org.apache.cxf.ws.httpservice.context property does > not work > - > > Key: DOSGI-225 > URL: https://issues.apache.org/jira/browse/DOSGI-225 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen >Assignee: Christian Schneider > Fix For: 2.0.0 > > > For org.apache.cxf.ws.httpservice.context the page > https://cxf.apache.org/distributed-osgi-reference.html says "When this > property is specified, the OSGi HTTP Service is used to expose the service, > rather than a dedicated Jetty HTTP Server. This property doesn't allow the > specification of a port number, as this is provided by the HTTP Service." > However, this does not work with DOSGi 1.7.0. Instead, the service gets > exposed (by PojoConfigurationTypeHandler) at the default address > http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502394#comment-15502394 ] Panu Hämäläinen edited comment on DOSGI-225 at 9/19/16 5:59 AM: Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property? was (Author: hamapa): Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address=/myaddress (in my service properties) - http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property? > Service publication with org.apache.cxf.ws.httpservice.context property does > not work > - > > Key: DOSGI-225 > URL: https://issues.apache.org/jira/browse/DOSGI-225 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen >Assignee: Christian Schneider > Fix For: 2.0.0 > > > For org.apache.cxf.ws.httpservice.context the page > https://cxf.apache.org/distributed-osgi-reference.html says "When this > property is specified, the OSGi HTTP Service is used to expose the service, > rather than a dedicated Jetty HTTP Server. This property doesn't allow the > specification of a port number, as this is provided by the HTTP Service." > However, this does not work with DOSGi 1.7.0. Instead, the service gets > exposed (by PojoConfigurationTypeHandler) at the default address > http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502394#comment-15502394 ] Panu Hämäläinen edited comment on DOSGI-225 at 9/19/16 6:00 AM: Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? was (Author: hamapa): Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property? > Service publication with org.apache.cxf.ws.httpservice.context property does > not work > - > > Key: DOSGI-225 > URL: https://issues.apache.org/jira/browse/DOSGI-225 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen >Assignee: Christian Schneider > Fix For: 2.0.0 > > > For org.apache.cxf.ws.httpservice.context the page > https://cxf.apache.org/distributed-osgi-reference.html says "When this > property is specified, the OSGi HTTP Service is used to expose the service, > rather than a dedicated Jetty HTTP Server. This property doesn't allow the > specification of a port number, as this is provided by the HTTP Service." > However, this does not work with DOSGi 1.7.0. Instead, the service gets > exposed (by PojoConfigurationTypeHandler) at the default address > http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502394#comment-15502394 ] Panu Hämäläinen edited comment on DOSGI-225 at 9/19/16 6:02 AM: Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) - specify empty cxfServletAlias property in HttpServiceManager config? Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? was (Author: hamapa): Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? > Service publication with org.apache.cxf.ws.httpservice.context property does > not work > - > > Key: DOSGI-225 > URL: https://issues.apache.org/jira/browse/DOSGI-225 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen >Assignee: Christian Schneider > Fix For: 2.0.0 > > > For org.apache.cxf.ws.httpservice.context the page > https://cxf.apache.org/distributed-osgi-reference.html says "When this > property is specified, the OSGi HTTP Service is used to expose the service, > rather than a dedicated Jetty HTTP Server. This property doesn't allow the > specification of a port number, as this is provided by the HTTP Service." > However, this does not work with DOSGi 1.7.0. Instead, the service gets > exposed (by PojoConfigurationTypeHandler) at the default address > http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOSGI-226) Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
[ https://issues.apache.org/jira/browse/DOSGI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502416#comment-15502416 ] Panu Hämäläinen commented on DOSGI-226: --- Sounds good, thanks. > Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall > - > > Key: DOSGI-226 > URL: https://issues.apache.org/jira/browse/DOSGI-226 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen >Assignee: Christian Schneider > Fix For: 2.0.0 > > > I have tried to configure DSW in Karaf 4.0.3 via Felix fileinstall with a > config file named "cxf-dsw.cfg". However, the framework never ends up calling > the update method (ManagedService) of org.apache.cxf.dosgi.dsw.Activator. The > problem probably is the syntax (against OSGi spec?) of the service PID > (cxf-dsw). After updating the PID to "org.apache.cxf.dosgi.dsw" in > org.apache.cxf.dosgi.dsw.Activator (and the cfg filename accordingly) things > started to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
[
https://issues.apache.org/jira/browse/CXF-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Javier Irazazábal updated CXF-7064:
---
Description:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
That's urgent to solve this for us.
This is an example of the unwanted output:
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
was:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
That's urgent to solve this for us.
> DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for
> a signed XML file
> --
>
> Key: CXF-7064
> URL: https://issues.apache.org/jira/browse/CXF-7064
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.1.7
> Environment: windows 7/ linux centos 6
>Reporter: Javier Irazazábal
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> HI,
> When implementing a CDATA interceptor in order to include a signed XML file
> in a SOAP envelope, we are getting several CDATA sections in the XML that
> makes the service reject the envelope:
> import java.util.regex.Pattern;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamWriter;
> import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
>
> /**
> * Simple CDATA XML Stream Writer that exports some items as CDATA
> */
> public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
>
> private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
> private static final String CDataOpen = "";
>
> public CDataXMLStreamWriter(XMLStreamWriter del) {
> super(del);
> }
> @Override
> public void writeCharacters(String text) throws XMLStreamException {
> boolean useCData = XML_CHARS.matcher( text ).find();
> if (useCData) {
> //super.writeCharacters(CDataOpen);
> System.o
[jira] [Created] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
Javier Irazazábal created CXF-7064:
--
Summary: DelegatingXMLStreamWriter.writeCData(text) writes several
CDATA sections for a signed XML file
Key: CXF-7064
URL: https://issues.apache.org/jira/browse/CXF-7064
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 3.1.7
Environment: windows 7/ linux centos 6
Reporter: Javier Irazazábal
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
That's urgent to solve this for us.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7087) Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an exception
[
https://issues.apache.org/jira/browse/CXF-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571744#comment-15571744
]
René Neumann commented on CXF-7087:
---
The issue does not require a custom XMLOutputFactory. Simply setting
FORCE_START_DOCUMENT for an entry point and then trying to access the WSDL
triggers the same problem.
As pointed out by Guillaume, the swapped parameters are the culprit.
The real problem here is probably the strange API offering
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
writeProlog, boolean repairing)
{code}
and
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
repairing)
{code}
That is, making an argument optional that is not the last thereby betraying the
expectation that one can go from short version to the long one by simply adding
the defaulted paramater.
Unfortunately, I doubt this can be changed now :(
> Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an
> exception
> --
>
> Key: CXF-7087
> URL: https://issues.apache.org/jira/browse/CXF-7087
> Project: CXF
> Issue Type: Bug
>Reporter: Guillaume Pansier
>
> I defined a service endpoint with a custom XmlOutputFactory
> {code:xml}
> implementor="#Mybean" address="/myService">
>
>
>
>
>
>
> {code}
> When Using the WSDLGetOutInterceptor, I get the following error;
> Can not output XML declaration, after other output has already been done.
> The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when
> using a custom xmlOutputFacory, then writes the prolog. The
> WSDLGetOutInterceptor writes it again and throws the exception.
> This was supposed to be fixed with commit
> 25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm
> correct(changed class: WSDLGetOutInterceptor, commit message: Write the
> prolog only if it hasn't already been written). But I think the change is not
> correct:
> {code}
> -StaxUtils.writeNode(doc, writer, true);
> +StaxUtils.writeDocument(doc, writer, true,
> +
> !MessageUtils.getContextualBoolean(message,
> +
> StaxOutInterceptor.FORCE_START_DOCUMENT,
> +
> false));
> {code}
> Knowing that the signature of StaxUtils.writeDocument is:
> {code}
> public static void writeDocument(Document d, XMLStreamWriter writer, boolean
> writeProlog, boolean repairing)
> {code}
> That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT
> from version 3.3, whereas the boolean writeProlog is always true ! To me, it
> seems like the two parameters have been swapped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7087) Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an exception
[
https://issues.apache.org/jira/browse/CXF-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571744#comment-15571744
]
René Neumann edited comment on CXF-7087 at 10/13/16 12:16 PM:
--
The issue does not require a custom XMLOutputFactory. Simply setting
FORCE_START_DOCUMENT for an entry point and then trying to access the WSDL
triggers the same problem.
As pointed out by Guillaume, the swapped parameters are the culprit.
The real problem here is probably the strange API offering
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
writeProlog, boolean repairing)
{code}
and
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
repairing)
{code}
That is, making an argument optional that is not the last, thereby betraying
the expectation that one can go from short version to the long one by simply
adding the defaulted paramater.
Unfortunately, I doubt the API can be changed now :(
was (Author: necoro):
The issue does not require a custom XMLOutputFactory. Simply setting
FORCE_START_DOCUMENT for an entry point and then trying to access the WSDL
triggers the same problem.
As pointed out by Guillaume, the swapped parameters are the culprit.
The real problem here is probably the strange API offering
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
writeProlog, boolean repairing)
{code}
and
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
repairing)
{code}
That is, making an argument optional that is not the last thereby betraying the
expectation that one can go from short version to the long one by simply adding
the defaulted paramater.
Unfortunately, I doubt this can be changed now :(
> Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an
> exception
> --
>
> Key: CXF-7087
> URL: https://issues.apache.org/jira/browse/CXF-7087
> Project: CXF
> Issue Type: Bug
>Reporter: Guillaume Pansier
>
> I defined a service endpoint with a custom XmlOutputFactory
> {code:xml}
> implementor="#Mybean" address="/myService">
>
>
>
>
>
>
> {code}
> When Using the WSDLGetOutInterceptor, I get the following error;
> Can not output XML declaration, after other output has already been done.
> The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when
> using a custom xmlOutputFacory, then writes the prolog. The
> WSDLGetOutInterceptor writes it again and throws the exception.
> This was supposed to be fixed with commit
> 25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm
> correct(changed class: WSDLGetOutInterceptor, commit message: Write the
> prolog only if it hasn't already been written). But I think the change is not
> correct:
> {code}
> -StaxUtils.writeNode(doc, writer, true);
> +StaxUtils.writeDocument(doc, writer, true,
> +
> !MessageUtils.getContextualBoolean(message,
> +
> StaxOutInterceptor.FORCE_START_DOCUMENT,
> +
> false));
> {code}
> Knowing that the signature of StaxUtils.writeDocument is:
> {code}
> public static void writeDocument(Document d, XMLStreamWriter writer, boolean
> writeProlog, boolean repairing)
> {code}
> That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT
> from version 3.3, whereas the boolean writeProlog is always true ! To me, it
> seems like the two parameters have been swapped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7087) Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an exception
[
https://issues.apache.org/jira/browse/CXF-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571744#comment-15571744
]
René Neumann edited comment on CXF-7087 at 10/13/16 12:22 PM:
--
The issue does not require a custom XMLOutputFactory. Simply setting
FORCE_START_DOCUMENT for an endpoint and then trying to access the WSDL
triggers the same problem.
As pointed out by Guillaume, the swapped parameters are the culprit.
The real problem here is probably the strange API offering
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
writeProlog, boolean repairing)
{code}
and
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
repairing)
{code}
That is, making an argument optional that is not the last, thereby betraying
the expectation that one can go from short version to the long one by simply
adding the defaulted paramater.
Unfortunately, I doubt the API can be changed now :(
was (Author: necoro):
The issue does not require a custom XMLOutputFactory. Simply setting
FORCE_START_DOCUMENT for an entry point and then trying to access the WSDL
triggers the same problem.
As pointed out by Guillaume, the swapped parameters are the culprit.
The real problem here is probably the strange API offering
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
writeProlog, boolean repairing)
{code}
and
{code:java}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean
repairing)
{code}
That is, making an argument optional that is not the last, thereby betraying
the expectation that one can go from short version to the long one by simply
adding the defaulted paramater.
Unfortunately, I doubt the API can be changed now :(
> Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an
> exception
> --
>
> Key: CXF-7087
> URL: https://issues.apache.org/jira/browse/CXF-7087
> Project: CXF
> Issue Type: Bug
>Reporter: Guillaume Pansier
>
> I defined a service endpoint with a custom XmlOutputFactory
> {code:xml}
> implementor="#Mybean" address="/myService">
>
>
>
>
>
>
> {code}
> When Using the WSDLGetOutInterceptor, I get the following error;
> Can not output XML declaration, after other output has already been done.
> The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when
> using a custom xmlOutputFacory, then writes the prolog. The
> WSDLGetOutInterceptor writes it again and throws the exception.
> This was supposed to be fixed with commit
> 25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm
> correct(changed class: WSDLGetOutInterceptor, commit message: Write the
> prolog only if it hasn't already been written). But I think the change is not
> correct:
> {code}
> -StaxUtils.writeNode(doc, writer, true);
> +StaxUtils.writeDocument(doc, writer, true,
> +
> !MessageUtils.getContextualBoolean(message,
> +
> StaxOutInterceptor.FORCE_START_DOCUMENT,
> +
> false));
> {code}
> Knowing that the signature of StaxUtils.writeDocument is:
> {code}
> public static void writeDocument(Document d, XMLStreamWriter writer, boolean
> writeProlog, boolean repairing)
> {code}
> That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT
> from version 3.3, whereas the boolean writeProlog is always true ! To me, it
> seems like the two parameters have been swapped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7094) MQJCA1018: Only one session per connection is allowed
Rainer Müller created CXF-7094: -- Summary: MQJCA1018: Only one session per connection is allowed Key: CXF-7094 URL: https://issues.apache.org/jira/browse/CXF-7094 Project: CXF Issue Type: Bug Components: JMS Affects Versions: 3.1.6 Reporter: Rainer Müller We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container. The WebSphere MQ resource adapter 7.5.0 shows following error message - MQJCA1018: Only one session per connection is allowed In class JMSConduit#setupReplyDestination the existing connection is used to instantiate class MessageListenerContainer. MessageListenerContainer#start calls createSession on given connection. Is there a way to force the 'one session per connection' restriction of our resource adapter? In version 2.7.14 we never had this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7094) MQJCA1018: Only one session per connection is allowed
[
https://issues.apache.org/jira/browse/CXF-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588789#comment-15588789
]
Rainer Müller commented on CXF-7094:
In MessageListenerContainer the code is weird.
A new session is created using the given connection, the destination to create
the consumer was created outside with another session in JMSConduit by calling
jmsConfig.getReplyDestination(session)
{code:java}
session = connection.createSession(transacted, acknowledgeMode);
if (durableSubscriptionName != null && destination instanceof
Topic) {
consumer = session.createDurableSubscriber((Topic)destination,
durableSubscriptionName,
messageSelector,
pubSubNoLocal);
} else {
consumer = session.createConsumer(destination,
messageSelector); <-- two different sessions used here!
}
{code}
> MQJCA1018: Only one session per connection is allowed
> -
>
> Key: CXF-7094
> URL: https://issues.apache.org/jira/browse/CXF-7094
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Rainer Müller
>
> We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container.
> The WebSphere MQ resource adapter 7.5.0 shows following error message
> - MQJCA1018: Only one session per connection is allowed
> In class JMSConduit#setupReplyDestination the existing connection is used to
> instantiate class MessageListenerContainer.
> MessageListenerContainer#start calls createSession on given connection.
> Is there a way to force the 'one session per connection' restriction of our
> resource adapter? In version 2.7.14 we never had this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7094) MQJCA1018: Only one session per connection is allowed
[
https://issues.apache.org/jira/browse/CXF-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588789#comment-15588789
]
Rainer Müller edited comment on CXF-7094 at 10/19/16 1:36 PM:
--
In MessageListenerContainer the code is weird.
A new session is created using the given connection, the destination to create
the consumer was created outside with another session in JMSConduit by calling
jmsConfig.getReplyDestination(session)
{code:java}
session = connection.createSession(transacted, acknowledgeMode);
if (durableSubscriptionName != null && destination instanceof Topic) {
consumer = session.createDurableSubscriber((Topic)destination,
durableSubscriptionName, messageSelector, pubSubNoLocal);
} else {
consumer = session.createConsumer(destination, messageSelector); <-- two
different sessions used here!
}
{code}
was (Author: rainer.mueller):
In MessageListenerContainer the code is weird.
A new session is created using the given connection, the destination to create
the consumer was created outside with another session in JMSConduit by calling
jmsConfig.getReplyDestination(session)
{code:java}
session = connection.createSession(transacted, acknowledgeMode);
if (durableSubscriptionName != null && destination instanceof
Topic) {
consumer = session.createDurableSubscriber((Topic)destination,
durableSubscriptionName,
messageSelector,
pubSubNoLocal);
} else {
consumer = session.createConsumer(destination,
messageSelector); <-- two different sessions used here!
}
{code}
> MQJCA1018: Only one session per connection is allowed
> -
>
> Key: CXF-7094
> URL: https://issues.apache.org/jira/browse/CXF-7094
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Rainer Müller
>
> We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container.
> The WebSphere MQ resource adapter 7.5.0 shows following error message
> - MQJCA1018: Only one session per connection is allowed
> In class JMSConduit#setupReplyDestination the existing connection is used to
> instantiate class MessageListenerContainer.
> MessageListenerContainer#start calls createSession on given connection.
> Is there a way to force the 'one session per connection' restriction of our
> resource adapter? In version 2.7.14 we never had this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7094) MQJCA1018: Only one session per connection is allowed
[ https://issues.apache.org/jira/browse/CXF-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15589437#comment-15589437 ] Rainer Müller commented on CXF-7094: seems to be a duplicate to CXF-7023 > MQJCA1018: Only one session per connection is allowed > - > > Key: CXF-7094 > URL: https://issues.apache.org/jira/browse/CXF-7094 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.6 >Reporter: Rainer Müller > > We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container. > The WebSphere MQ resource adapter 7.5.0 shows following error message > - MQJCA1018: Only one session per connection is allowed > In class JMSConduit#setupReplyDestination the existing connection is used to > instantiate class MessageListenerContainer. > MessageListenerContainer#start calls createSession on given connection. > Is there a way to force the 'one session per connection' restriction of our > resource adapter? In version 2.7.14 we never had this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7094) MQJCA1018: Only one session per connection is allowed
[ https://issues.apache.org/jira/browse/CXF-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rainer Müller closed CXF-7094. -- Resolution: Fixed Fix Version/s: Invalid see CXF-7023 > MQJCA1018: Only one session per connection is allowed > - > > Key: CXF-7094 > URL: https://issues.apache.org/jira/browse/CXF-7094 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.6 >Reporter: Rainer Müller > Fix For: Invalid > > > We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container. > The WebSphere MQ resource adapter 7.5.0 shows following error message > - MQJCA1018: Only one session per connection is allowed > In class JMSConduit#setupReplyDestination the existing connection is used to > instantiate class MessageListenerContainer. > MessageListenerContainer#start calls createSession on given connection. > Is there a way to force the 'one session per connection' restriction of our > resource adapter? In version 2.7.14 we never had this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627 ] Rainer Müller commented on CXF-7023: Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627 ] Rainer Müller edited comment on CXF-7023 at 10/20/16 6:42 PM: -- Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA and Apache CXF version 3.1.6. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. was (Author: rainer.mueller): Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627 ] Rainer Müller edited comment on CXF-7023 at 10/21/16 7:29 AM: -- Patch fixed our issue with WebSphere MQ Resource Adapter 7.5.0.5 running in JBoss EAP 7.0.2.GA and Apache CXF version 3.1.6. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. was (Author: rainer.mueller): Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA and Apache CXF version 3.1.6. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594356#comment-15594356
]
Rainer Müller commented on CXF-7023:
Your last commit (7301fd2) breaks a test in the transport-jms testsuite.
In SoapJmsSpecTest, line 109
{{Assert.assertEquals(null, responseHeader.getSOAPJMSSOAPAction());}}
should be
{{Assert.assertEquals("\"test\"", responseHeader.getSOAPJMSSOAPAction());}}
Could you please fix this to increase the probability to get the pull request
merged?
> SOAP over JMS transport does not use XA transactions with Websphere MQ
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms
> connection, but connection opened in JMSDestination, and transaction started
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may
> be there are better way to provide support for WMQ adapter?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
Concombre Masqué created CXF-7117:
-
Summary: Swagger2Feature not working in OSGi container when jaxrs
server address not attached to CXF servlet
Key: CXF-7117
URL: https://issues.apache.org/jira/browse/CXF-7117
Project: CXF
Issue Type: Bug
Components: OSGi
Affects Versions: 3.1.8
Environment: Apache Karaf 3.0.8
Reporter: Concombre Masqué
Just modify sample description_swagger2_osgi as follows:
http://localhost:9091/test/swaggerSample";>
Then deploy modified bundle into Karaf and browse Swagger service definition at
http://localhost:9091/test/swaggerSample/swagger.json
Result is:
{"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Concombre Masqué updated CXF-7117:
--
Description:
Just modify sample description_swagger2_osgi as follows:
http://localhost:9091/test/swaggerSample";>
Then deploy modified bundle into Karaf and browse Swagger service definition at
http://localhost:9091/test/swaggerSample/swagger.json
Result is:
{"swagger":"2.0"}
was:
Just modify sample description_swagger2_osgi as follows:
http://localhost:9091/test/swaggerSample";>
Then deploy modified bundle into Karaf and browse Swagger service definition at
http://localhost:9091/test/swaggerSample/swagger.json
Result is:
{"swagger":"2.0"}
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7119) ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Hohwiller updated CXF-7119: Affects Version/s: 3.1.3 > ResponseExceptionMapper not used for technical exceptions (e.g. IOException) > > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller > > When using CXF for REST/JAX-RS service clients I quickly noticed that I need > to tweak the error handling. My services use an ExceptionMapper that provides > error details via JSON result payload. Hence I want to access this and render > an exception with further details and more context information what works > fine with ResponseExceptionMapper. > However, when a technical error (IOException such as unkown host, connection > refused, timeout, etc.) occurrs I only get generic errors from CXF client > (org.apache.cxf.interceptor.Fault: Could not send Message.). This is > undesired but unfortunately my custom ResponseExceptionMapper is never called > for such technical errors. There seems to be no way to archive my goal with > CXF itself. I could only wrap the client again with a custom written dynamic > proxy to reach my goal. > It seems that CXF hardwires this behaviour: > https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 > It would be awesome if in such case ResponseExceptionMapper would also be > applied so I have the chance to interfere and produce better exceptions (e.g. > with a message containing the name of the application/microservice that could > not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7119) ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
Jörg Hohwiller created CXF-7119: --- Summary: ResponseExceptionMapper not used for technical exceptions (e.g. IOException) Key: CXF-7119 URL: https://issues.apache.org/jira/browse/CXF-7119 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Jörg Hohwiller When using CXF for REST/JAX-RS service clients I quickly noticed that I need to tweak the error handling. My services use an ExceptionMapper that provides error details via JSON result payload. Hence I want to access this and render an exception with further details and more context information what works fine with ResponseExceptionMapper. However, when a technical error (IOException such as unkown host, connection refused, timeout, etc.) occurrs I only get generic errors from CXF client (org.apache.cxf.interceptor.Fault: Could not send Message.). This is undesired but unfortunately my custom ResponseExceptionMapper is never called for such technical errors. There seems to be no way to archive my goal with CXF itself. I could only wrap the client again with a custom written dynamic proxy to reach my goal. It seems that CXF hardwires this behaviour: https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 It would be awesome if in such case ResponseExceptionMapper would also be applied so I have the chance to interfere and produce better exceptions (e.g. with a message containing the name of the application/microservice that could not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15641468#comment-15641468
]
Concombre Masqué commented on CXF-7117:
---
Hi Sergey,
If I remove both "basePath" and "usePathBasedConfig" it works yes. But I have
to use these properties since I deploy several bundles that expose jax-rs
servers.
Following what you suggest, if I deploy a second bundle (a modified version of
sample description_swagger2_osgi listening on
http://localhost:9090/test/swaggerSample2 for example) then I get the same
Swagger descriptor as first bundle (see issue CXF-6740).
That's why I use "usePathBasedConfig" but the fix for issue CXF-6740 does not
seem to handle jax-rs servers using addresses not under CXF servlet path
("/cxf").
Regards
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
