[jira] [Commented] (CXF-7276) Atmosphere init code should be moved out of AtmosphereWebSocketServlet Destination
[ https://issues.apache.org/jira/browse/CXF-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962193#comment-15962193 ] Akitoshi Yoshida commented on CXF-7276: --- Hi Andriy, Sergey, Thanks for resolving this issue. Indeed this ServletConfigAware is potentially useful for other servlet based destinations. regards, aki > Atmosphere init code should be moved out of AtmosphereWebSocketServlet > Destination > -- > > Key: CXF-7276 > URL: https://issues.apache.org/jira/browse/CXF-7276 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Andriy Redko > > Unfortunately, moving Atmosphere initialization code out of the > AtmosphereWebSocketServletDestination may not be possible at the moment. As > we have discovered, Atmosphere has following constraints: > - needs ServletConfig to initialize properly (and leverage f.e. JSR-356 > support) > - the ServetConfig instance is not available yet at the moment when > Destination / DestinationRegistry are being created / initialized > In order to somehow workaround that, the suggestion is to introduce interface > `ServletConfigAware` so `AtmosphereWebSocketServletDestination` will > implement it. In turn, `CXFNonSpringServlet` is going to notify all > interested destination when the instance of `ServletConfig` becomes > available. At this time, we are able to (re)initialize the > `AtmosphereFramework` with JSR-356 support if available. With that, CXF > WebSocket transport could be run on Tomcat 8+ natively. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7276) Atmosphere init code should be moved out of AtmosphereWebSocketServlet Destination
[ https://issues.apache.org/jira/browse/CXF-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15960476#comment-15960476 ] Akitoshi Yoshida commented on CXF-7276: --- [~reta] I am sorry for my delay. I'll look at this weekend. When I looked at it a while ago, I thought we could change atmosphere itself to delay its jsr356 related init code so that it becomes easier for another framework to use jsr356 with atmosphere. If we have several options, we can choose one based on its complexity (choosing a less-invasive, simpler option) and its practicability (choosing an option supporting wider use cases). Thanks a lot for looking into this. regards, aki > Atmosphere init code should be moved out of AtmosphereWebSocketServlet > Destination > -- > > Key: CXF-7276 > URL: https://issues.apache.org/jira/browse/CXF-7276 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Andriy Redko > > Unfortunately, moving Atmosphere initialization code out of the > AtmosphereWebSocketServletDestination may not be possible at the moment. As > we have discovered, Atmosphere has following constraints: > - needs ServletConfig to initialize properly (and leverage f.e. JSR-356 > support) > - the ServetConfig instance is not available yet at the moment when > Destination / DestinationRegistry are being created / initialized > In order to somehow workaround that, the suggestion is to introduce interface > `ServletConfigAware` so `AtmosphereWebSocketServletDestination` will > implement it. In turn, `CXFNonSpringServlet` is going to notify all > interested destination when the instance of `ServletConfig` becomes > available. At this time, we are able to (re)initialize the > `AtmosphereFramework` with JSR-356 support if available. With that, CXF > WebSocket transport could be run on Tomcat 8+ natively. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7096) Server side memory leaking if clients do not send CloseSequence
[ https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15612371#comment-15612371 ] Akitoshi Yoshida commented on CXF-7096: --- [~zzaili] you can look at the possibility to remove the sequences by adding some clean-up code in Destination.java. I have no time to look at this now and the following is from my memory. I think there is no active component to delete those expired sequences. By the way, there is property maxSequences to limit the number of active sequences. regards, aki p.s. why is your client creating a new sequence without terminating the old sequence or not using the old sequence if it is not terminated? > Server side memory leaking if clients do not send CloseSequence > --- > > Key: CXF-7096 > URL: https://issues.apache.org/jira/browse/CXF-7096 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.6, 3.1.7, 3.1.8 > Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual > Studio 12 client, Java 7, JBoss EAP 6 >Reporter: Andy Zhang >Priority: Blocker > Labels: features > Fix For: 3.1.9 > > > I have a dot net client that invokes a RM web service many times. It does not > send CloseSequence at the end. The server side tries to terminate the > sequence based on inactivityTimeout in the WSDL. But it does not seem to > cleanup the sequence completely since the memory usage gets larger and larger > and eventually the server will run out of memory. java.lang.OutOfMemoryError: > Java heap space -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15503492#comment-15503492
]
Akitoshi Yoshida commented on CXF-7045:
---
sounds good.
thanks.
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502694#comment-15502694
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy, Sergey,
on second thought, maybe it's practical to introduce a jackson feature and we
can deal with the version upgrading issue when we actually encounter one.
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502676#comment-15502676
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy, Sergey,
Umm. I am missing to see the benefit of having a cxf-jackson feature. If this
feature is only used by the swagger2 feature and no other cxf component is
using it, there is no benefit of it at this moment. And if other cxf
components start using it for their jackson scenarios, we will need to
synchronized its versions across all those jackson consuming components (so we
can go less frequent upgrade or must introduce multiple versioned jackson
features (e.g., jackson-nn) used by specific components. In short, I think
introducing a jackson feature now seems to make our life more complicated, no?
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492793#comment-15492793
]
Akitoshi Yoshida commented on CXF-7045:
---
[~reta] Hi Andriy, thanks for investigating the root cause.
Regarding com.fasterxml.jackson.jaxrs, it was referenced by swagger-jars 1.5.4,
but not by the recent ones. And it used to all work with cxf-3.1.5. I remember
swagger-feature of cxf-3.1.6 was broken because of the late change to the
jackson version in parent/pom.xml that was inconsistent with the jackson
version used by swagger. I remember fixing this issue in 3.1.7-SNAPSHOT and
tested it to work using the cxf-rt-rs-service-description-swagger feature. But
somehow, the released cxf 3.1.7 seems to have the wiring issue.
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488673#comment-15488673
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy,
well, I verified the original feature.xml
https://github.com/apache/cxf/commit/af7de1d82d77e3653b72ee83b4aa3f91e1a1d039
and those jackson bundles were there and those entries are still there in the
current feature.xml.
https://github.com/apache/cxf/blob/master/osgi/karaf/features/src/main/resources/features.xml#L236-L254
so, you don't need to install them extra when using cxf's swagger feature.
The only occasion this can go wrong is that since we are pulling the jackson
version from swagger transitively and write them into the
cxf-description-swagger's manifest. So, if someone changes cxf parent's jackson
version while keeping the swagger version, the jackson version referenced in
cxf's feature.xml and what is actually referenced in cf-description-swagger's
manifest might diverge too far so that the wiring can fail. And I suspect this
was what had happened in your situation.
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487534#comment-15487534
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy,
aren't they already in the feature descriptor? I remember using that feature to
install all those jackson bundles. And I thought there was no extra
installation needed.
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487130#comment-15487130
]
Akitoshi Yoshida commented on CXF-7045:
---
[~reta] hi andriy, this change seems to be a follow up to your previous change
of adding explicit jackson install commands. Shouldn't these jackson bundles
automatically be installed with cxf-rs-description-swagger2 feature, no?
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7007) Allow customizing atmosphere's config parameters when using websocket transport
Akitoshi Yoshida created CXF-7007: - Summary: Allow customizing atmosphere's config parameters when using websocket transport Key: CXF-7007 URL: https://issues.apache.org/jira/browse/CXF-7007 Project: CXF Issue Type: Improvement Components: Transports Reporter: Akitoshi Yoshida The atmosphere framework in CXF is currently set up with some predefined options and there is no way to change this setting except customizing its protocol interceptor. To be able to customize the behavior of websocket processing, those options to be made configurable, possibly using a specific Feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6994) RMCaptureInInterceptor running on GET requests
[ https://issues.apache.org/jira/browse/CXF-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6994. --- Resolution: Fixed Fix Version/s: 3.2.0 PR merged. thanks. > RMCaptureInInterceptor running on GET requests > -- > > Key: CXF-6994 > URL: https://issues.apache.org/jira/browse/CXF-6994 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 >Reporter: Alessio Soldano >Assignee: Akitoshi Yoshida > Fix For: 3.2.0, 3.1.8 > > > The changes at > https://github.com/apache/cxf/commit/0dd29509e42fc412ec0cf214e66885d26da9850e > are causing a regression in case of (wsdl) get requests being processed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6994) RMCaptureInInterceptor running on GET requests
[ https://issues.apache.org/jira/browse/CXF-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6994: - Assignee: Akitoshi Yoshida > RMCaptureInInterceptor running on GET requests > -- > > Key: CXF-6994 > URL: https://issues.apache.org/jira/browse/CXF-6994 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 >Reporter: Alessio Soldano >Assignee: Akitoshi Yoshida > Fix For: 3.1.8 > > > The changes at > https://github.com/apache/cxf/commit/0dd29509e42fc412ec0cf214e66885d26da9850e > are causing a regression in case of (wsdl) get requests being processed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5781) Port ou of Range: -1
[
https://issues.apache.org/jira/browse/CXF-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364016#comment-15364016
]
Akitoshi Yoshida commented on CXF-5781:
---
Hi Maninder,
CXF Team terminated the maintenance of CXF 2.7.x in 2015. As a result, all
recent patches including security related ones are not included in CXF 2.7.x.
If you are using one of the 2.7.x versions, I would recommend you to get a
commercial support to get fixes for 2.7.x or to manage this process on your
own. Please refer to http://cxf.apache.org/commercial-cxf-offerings.html
Thank you.
regards, aki
> Port ou of Range: -1
>
>
> Key: CXF-5781
> URL: https://issues.apache.org/jira/browse/CXF-5781
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Colm O hEigeartaigh
>Priority: Critical
> Fix For: 3.0.1
>
>
> I'm trying to access a service available in the URL
> (https://homologwsincom.in.gov.br/services/servicoIN) and when I run the
> ServicoINPortType_ServicoINHttpPort_Client.java (write automatic for CXF 3.0)
> class, with appropriate amendments security header, happens the exception
> below. All classes containing this url in the code generated automatically
> been changed to possess the number of tcp port 443 getting written as
> ("https://homologwsincom.in.gov.br:443/services/servicoIN";). I add the port
> number 443 in the URL as an attempt to fix the problem.
> In initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java
> the URL (https://homologwsincom.in.gov.br:443/services/servicoIN?wsdl) was
> changed to (https:// homologwsincom.in.gov.br/services/servicoIN) without the
> TCP port number.
> At runtime, the realized change in the value of the local variable called
> "address" to include the number of TCP port 443 again and everything worked
> normally. I would like the above method does not alter the provided URL.
> Below, the stacktrace:
> ADVERTÊNCIA: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException: IllegalArgumentException invoking
> https://homologwsincom.in.gov.br/services/servicoIN: port out of range:-1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1359)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.close(NettyHttpConduit.java:153)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy40.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:62)
> Caused by: java.lang.IllegalArgumentException: port out of range:-1
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.(InetSocketAddress.java:224)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.connect(NettyHttpConduit.java:293)
> at
> org.apache.
[jira] [Resolved] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6952.
---
Resolution: Not A Problem
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15363973#comment-15363973
]
Akitoshi Yoshida commented on CXF-6952:
---
Hi Niten,
Sergey was working the refactoring of the package for 3.2.0-SNAPSHOT, so
something may be not working temporarily if you work on a SNAPSHOT version.
By the way, you will need cxf-rt-rs-service-description-swagger to do swagger
or swagger2 and there is no swagger2 specific cxf component. The osgi feature
is only enabled for swagger2 as there was no osgi support for swagger.
To install the sample jax_rs_description_swagger2_osgi, you need to build it
first as described in its README.txt file. Sample artifacts are not published
in apache central.
Could you follow the steps described in README.txt exactly and just replacing
whatever 3,.n.m with 3.1.5. That should work.
regards, aki
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
[ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6863. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 Closing this ticket as the attachments handling has been corrected. The issue specifically related to security processing applied to attachments is tracked the linked ticket. > WS-RM 3.x does not work with attachments upon a network error > - > > Key: CXF-6863 > URL: https://issues.apache.org/jira/browse/CXF-6863 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.3, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Fix For: 3.1.7, 3.2.0 > > Attachments: > 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch > > > When sending messages with an attachment, the CXF 3.x WS-RM code may lose > message at the client side when a network error occurs. This was working with > CXF 2.x WS-RM. > This problem is related to the change CXF-4866 which changed the way how the > outgoing message is captured. Previously, the entire message was buffered and > captured, which isolated this capturing from network issue. In 3.x, only the > SOAP part is captured in this way and not the attachments. As a result, an > exception will be thrown during the attachment serialization when a network > error occurs and the message will not be correctly placed in the > retransmission queue. > By comparing CXF 3.x and 2.x code, > In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and > this can trigger a Fault from AttachmentOutInterceptor.handleMessage. > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], > int, int) line: 61 > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) > line: 60 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 182 > AttachmentOutInterceptor.handleMessage(Message) line: 77 > whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the > buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts > WriteOnCloseOutputStream to isolate itself from any network issue. > WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 172 > AttachmentOutInterceptor.handleMessage(Message) line: 72 > CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to > capture the message entirely. > There seem to be other issues with attachments handling in CXF 3.x. Along > with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6952.
---
Resolution: Not A Problem
I am closing this ticket as it appears to be a non-issue.
If you have further questions, please use users@cxf list.
regards, aki
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358071#comment-15358071
]
Akitoshi Yoshida commented on CXF-6952:
---
You can try 3.1.5 or older or the 3.1.x or 3.2.x SNAPSHOT.
There was a jackson versioning issue in 3.1.6. which broke the simple
karat-feature based setup instruction given in its README.txt. (in other words,
you would need to install appropriate jackson bundles manually when you are
using cxf 3.1.6 sample). The other versions of cxf sample should work out of
the box following the instruction.
Regarding a clean karaf, I mentioned it because if you have some conflicting
bundles already deployed, that could interfere with the simple setup.
If you start with a clean karaf and follow the sample instruction, you are sure
that there will be no conflicting bundles.
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357157#comment-15357157
]
Akitoshi Yoshida commented on CXF-6952:
---
and as for cxf-3.2.0-SNAPSHOT's sample, it is also returning the correctly
generated swagger documents.
I would suggest you to try the cxf sample on a clean karaf instance.
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357123#comment-15357123
]
Akitoshi Yoshida commented on CXF-6952:
---
I just tried cxf-3.1.5 on both karaf-4.0.5 and karaf-3.0.6, following the
instruction steps given in README.txt of
samples/jax_rs/description_swagger2_osgi, which are as simple as
feature:repo-add cxf 3.1.5
feature:install cxf-rs-description-swagger2
install -s mvn:org.apache.cxf.samples/jax_rs_description_swagger2_osgi/3.1.5
and after that, both swagger URLs
http://localhost:8181/cxf/swaggerSample/swagger.json
http://localhost:8181/cxf/swaggerSample/swagger.yaml
are returning the correctly generated swagger documents.
Therefore, if you can't run the sample, I suppose either you have modified at
the sample app or your karaf container is not correctly set up (e.g., no access
to the maven repos).
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6952) Swagger2Featue not scanning CXF resources
[
https://issues.apache.org/jira/browse/CXF-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356924#comment-15356924
]
Akitoshi Yoshida commented on CXF-6952:
---
i'll be looking into it today.
> Swagger2Featue not scanning CXF resources
> -
>
> Key: CXF-6952
> URL: https://issues.apache.org/jira/browse/CXF-6952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.5
> Environment: Windows
>Reporter: Niten Aggarwal
> Labels: features
>
> Swagger2Feature is not scanning end points configured in OSGI blueprint and
> always returning default Swagger Json.
> To reproduce issue, I deployed
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi
> project as well into my Karaf runtime but no luck and same default Json is
> returned.
> https://issues.apache.org/jira/browse/CXF-6524
> https://issues.apache.org/jira/browse/CXF-6541
> Was following above bugs and it seems with versions 3.0.6, 3.1.2 this issue
> should be resolved so I tried with cxf versions 3.1.2, 3.1.3 and 3.1.5 but no
> luck.
> Also the samples distribution which is using 3.2.0-SNAPSHOT, also returns
> default json.
> Default json which I am getting..
> {"swagger":"2.0","info":{"description":"The
> Application","version":"1.0.0","title":"Sample REST
> Application","contact":{"name":"us...@cxf.apache.org"},"license":{"name":"Apache
> 2.0
> License","url":"http://www.apache.org/licenses/LICENSE-2.0.html"}},"basePath":"/cxf/swaggerSample"}
> Also sample Json doesn't recognize base path and always returned at
> http://localhost:8181/swaggerSample/swagger.json.
> Thanks
> Niten
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
[ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320266#comment-15320266 ] Akitoshi Yoshida commented on CXF-6863: --- Hi Dennis, Ok. Right. That is a good point. Regarding the attachments encryption/signature, we have the processed attachments and the merging itself shouldn't corrupt the data, I think, because encryption/signing is done within each attachment and not across multiple parts. The security processed attachments themselves are reusable for retransmission because there is no timestamp attached to them. However, the retransmission will currently re-apply security processing to the attachments and that will be wrong. We we re-use the processed attachments, we need to skip security processing for the attachments at retransmission. Alternatively, we could store the original attachments when ws-sec on attachments is configured and apply security processing at each retransmission. In any case, we will need one of these two options to support ws-rm + ws-security on attachments. regards, aki > WS-RM 3.x does not work with attachments upon a network error > - > > Key: CXF-6863 > URL: https://issues.apache.org/jira/browse/CXF-6863 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.3, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Attachments: > 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch > > > When sending messages with an attachment, the CXF 3.x WS-RM code may lose > message at the client side when a network error occurs. This was working with > CXF 2.x WS-RM. > This problem is related to the change CXF-4866 which changed the way how the > outgoing message is captured. Previously, the entire message was buffered and > captured, which isolated this capturing from network issue. In 3.x, only the > SOAP part is captured in this way and not the attachments. As a result, an > exception will be thrown during the attachment serialization when a network > error occurs and the message will not be correctly placed in the > retransmission queue. > By comparing CXF 3.x and 2.x code, > In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and > this can trigger a Fault from AttachmentOutInterceptor.handleMessage. > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], > int, int) line: 61 > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) > line: 60 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 182 > AttachmentOutInterceptor.handleMessage(Message) line: 77 > whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the > buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts > WriteOnCloseOutputStream to isolate itself from any network issue. > WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 172 > AttachmentOutInterceptor.handleMessage(Message) line: 72 > CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to > capture the message entirely. > There seem to be other issues with attachments handling in CXF 3.x. Along > with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
[ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318472#comment-15318472 ] Akitoshi Yoshida commented on CXF-6863: --- Hi Dennis, I'm not sure if we are on the same page. We are not serializing and storing the entire message like before (or as in 2.7.x). We capture the plain soap part and the only the attachments part separately but merge them into one blob so that we can reconstruct that state of the message in one DB-read for later retransmission. So the security processing will take place on the plain content and get applied on each retransmission. So, I'm not sure if you are pointing to another issue not identified above. Please let me know. thanks. regards, aki > WS-RM 3.x does not work with attachments upon a network error > - > > Key: CXF-6863 > URL: https://issues.apache.org/jira/browse/CXF-6863 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.3, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Attachments: > 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch > > > When sending messages with an attachment, the CXF 3.x WS-RM code may lose > message at the client side when a network error occurs. This was working with > CXF 2.x WS-RM. > This problem is related to the change CXF-4866 which changed the way how the > outgoing message is captured. Previously, the entire message was buffered and > captured, which isolated this capturing from network issue. In 3.x, only the > SOAP part is captured in this way and not the attachments. As a result, an > exception will be thrown during the attachment serialization when a network > error occurs and the message will not be correctly placed in the > retransmission queue. > By comparing CXF 3.x and 2.x code, > In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and > this can trigger a Fault from AttachmentOutInterceptor.handleMessage. > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], > int, int) line: 61 > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) > line: 60 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 182 > AttachmentOutInterceptor.handleMessage(Message) line: 77 > whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the > buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts > WriteOnCloseOutputStream to isolate itself from any network issue. > WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 172 > AttachmentOutInterceptor.handleMessage(Message) line: 72 > CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to > capture the message entirely. > There seem to be other issues with attachments handling in CXF 3.x. Along > with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
[ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6863: - Assignee: Akitoshi Yoshida > WS-RM 3.x does not work with attachments upon a network error > - > > Key: CXF-6863 > URL: https://issues.apache.org/jira/browse/CXF-6863 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.3, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Attachments: > 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch > > > When sending messages with an attachment, the CXF 3.x WS-RM code may lose > message at the client side when a network error occurs. This was working with > CXF 2.x WS-RM. > This problem is related to the change CXF-4866 which changed the way how the > outgoing message is captured. Previously, the entire message was buffered and > captured, which isolated this capturing from network issue. In 3.x, only the > SOAP part is captured in this way and not the attachments. As a result, an > exception will be thrown during the attachment serialization when a network > error occurs and the message will not be correctly placed in the > retransmission queue. > By comparing CXF 3.x and 2.x code, > In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and > this can trigger a Fault from AttachmentOutInterceptor.handleMessage. > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], > int, int) line: 61 > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) > line: 60 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 182 > AttachmentOutInterceptor.handleMessage(Message) line: 77 > whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the > buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts > WriteOnCloseOutputStream to isolate itself from any network issue. > WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 172 > AttachmentOutInterceptor.handleMessage(Message) line: 72 > CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to > capture the message entirely. > There seem to be other issues with attachments handling in CXF 3.x. Along > with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6932) Websocket conduit may fail to transmit the entire message
[ https://issues.apache.org/jira/browse/CXF-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314175#comment-15314175 ] Akitoshi Yoshida commented on CXF-6932: --- here is a test case for this conduit issue provided by Colm https://github.com/coheigea/testcases/blob/master/apache/cxf/cxf-transports/src/test/java/org/apache/coheigea/cxf/transports/websocket/WSSecurityWebsocketTest.java > Websocket conduit may fail to transmit the entire message > - > > Key: CXF-6932 > URL: https://issues.apache.org/jira/browse/CXF-6932 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.6, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > > CXF's Websocket conduit may split a request message into several messages > when sending a large message. These split messages cannot be reassembled > correctly at the server at the moment. One temporary workaround is to set the > buffer size to a larger value so that the request message is sent as a single > message. A more effective solution would be to support the chunking and > reassembling of these messages. > As related to this issue, the server side Websocket transport currently > buffers the response so that it is returned as a single message. As this > buffering is inefficient, we should use the chunking mode.by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6932) Websocket conduit may fail to transmit the entire message
Akitoshi Yoshida created CXF-6932: - Summary: Websocket conduit may fail to transmit the entire message Key: CXF-6932 URL: https://issues.apache.org/jira/browse/CXF-6932 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 3.0.9, 3.1.6 Reporter: Akitoshi Yoshida Assignee: Akitoshi Yoshida CXF's Websocket conduit may split a request message into several messages when sending a large message. These split messages cannot be reassembled correctly at the server at the moment. One temporary workaround is to set the buffer size to a larger value so that the request message is sent as a single message. A more effective solution would be to support the chunking and reassembling of these messages. As related to this issue, the server side Websocket transport currently buffers the response so that it is returned as a single message. As this buffering is inefficient, we should use the chunking mode.by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
[ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15313883#comment-15313883 ] Akitoshi Yoshida commented on CXF-6863: --- referencing the two tickets that are prerequisite for fixing this issue. > WS-RM 3.x does not work with attachments upon a network error > - > > Key: CXF-6863 > URL: https://issues.apache.org/jira/browse/CXF-6863 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.3, 3.0.9 >Reporter: Akitoshi Yoshida > > When sending messages with an attachment, the CXF 3.x WS-RM code may lose > message at the client side when a network error occurs. This was working with > CXF 2.x WS-RM. > This problem is related to the change CXF-4866 which changed the way how the > outgoing message is captured. Previously, the entire message was buffered and > captured, which isolated this capturing from network issue. In 3.x, only the > SOAP part is captured in this way and not the attachments. As a result, an > exception will be thrown during the attachment serialization when a network > error occurs and the message will not be correctly placed in the > retransmission queue. > By comparing CXF 3.x and 2.x code, > In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and > this can trigger a Fault from AttachmentOutInterceptor.handleMessage. > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], > int, int) line: 61 > URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) > line: 60 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 182 > AttachmentOutInterceptor.handleMessage(Message) line: 77 > whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the > buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts > WriteOnCloseOutputStream to isolate itself from any network issue. > WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 > CacheAndWriteOutputStream.write(byte[]) line: 89 > AttachmentSerializer.writeProlog() line: 172 > AttachmentOutInterceptor.handleMessage(Message) line: 72 > CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to > capture the message entirely. > There seem to be other issues with attachments handling in CXF 3.x. Along > with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6646) CXF 3.x WSRM message may not be retrieved from database
[ https://issues.apache.org/jira/browse/CXF-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6646. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 3.0.10 applied the provided patch. thanks to kai. > CXF 3.x WSRM message may not be retrieved from database > --- > > Key: CXF-6646 > URL: https://issues.apache.org/jira/browse/CXF-6646 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.4 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: > 0001-CXF-3.x-WSRM-Replace-RewindableInputStream-with-Cach.patch, > 0001-WSRM-enable-RMTxStore-for-different-database-impleme.patch, > 0002-WSRM-enable-RMTxStore-for-different-database-impleme.patch > > > With CXF-4866, CXF-352 changes to the RMTxStore implementation were > introduced. > Running the JUnit Tests for rt/ws/rm with a newer Derby version, some tests > will fail. > You can switch to version 10.8.2.2 and messages won't be recovered from > database, as database connection will be released before message is read. > I used the CachedOutputStream to cache the message. Find attached the patch > files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6646) CXF 3.x WSRM message may not be retrieved from database
[ https://issues.apache.org/jira/browse/CXF-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6646: - Assignee: Akitoshi Yoshida > CXF 3.x WSRM message may not be retrieved from database > --- > > Key: CXF-6646 > URL: https://issues.apache.org/jira/browse/CXF-6646 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.4 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Attachments: > 0001-CXF-3.x-WSRM-Replace-RewindableInputStream-with-Cach.patch, > 0001-WSRM-enable-RMTxStore-for-different-database-impleme.patch, > 0002-WSRM-enable-RMTxStore-for-different-database-impleme.patch > > > With CXF-4866, CXF-352 changes to the RMTxStore implementation were > introduced. > Running the JUnit Tests for rt/ws/rm with a newer Derby version, some tests > will fail. > You can switch to version 10.8.2.2 and messages won't be recovered from > database, as database connection will be released before message is read. > I used the CachedOutputStream to cache the message. Find attached the patch > files. -- 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=15291003#comment-15291003 ] Akitoshi Yoshida commented on CXF-6904: --- Hi Sergey, I don't think it is an issue that CXF can solve. I am not sure if it is a Swagger issue (i.e., Swagger is using org.reflections' ClasspathHelper.fromPackage wrong) or an org.reflections ClasspathHelper's issue (i.e., not finding the right classpath url when it is looking up a resource of a java package residing in two OSGi depending bundles). Hi Christian, that is interesting. we can keep this issue to track this problem. regards, aki > 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=15288904#comment-15288904 ] Akitoshi Yoshida commented on CXF-6904: --- A temporary workaround that worked for me is to add a dummy resource in the api bundle (eg., an empty file named api in cxf-swagger2-osgi-api/src//main/resources/demo/jaxrs/swagger/server/) and update the impl bundle's blueprint.xml to have this resource listed as well (i.e., this is not a package but adding this will instruct ClasspathHelper.fromPackage to look up a resource demo/jaxrs/swagger/server/api and will find the api bundle url) With this change, the both bundle urls are added to the reflection's config object and its reflections.getTypesAnnotatedWith(Path.class) etc will find the annotated classes from the api bundle. When I use a similar set up in webapp+spring, where the annotated classes are placed in the api.jar and the impl/beans/web.xml part in impl.war, without the above workaround, CasspathHelper.fromPackage finds both classpath urls and the annotated classes are found. In contrast, with the osgi setup, if we have only , ClasspathHelper.fromPackage will only add the impl's bundle url to the reflection's config. As a result, reflections.getTypesAnnotatedWith(Path.class) etc are not finding any annotated classes. Even with the honorInherited option of reflections.getTypesAnnotatedWith(Path.class, true) to look up in the annotations from its super classes because it doesn't lookup for the non Inherited annotations ( https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/Inherited.html) If someone has a suggestion in resolving this problem without adding a dummy resource, that would be appreciated. > 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=15288788#comment-15288788 ] Akitoshi Yoshida commented on CXF-6904: --- I am looking into it. It seems there is some limitation (or strange behavior) in in.reflections to look up a package under osgi. when it is looking up demo.jaxrs.swagger.server using its ClasspathHelper.forPackage with impl's bundle, it doesn't look up into api's bundle. when it is looking up demo.jaxrs.swagger.server.Sample.class using its ClasspathHelper.forResource with impl's bundle, it does look up into api's bundle. i think i have some temporary workaround. will update it today. > 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] [Comment Edited] (CXF-6886) CXF 3.x WSRM attachments are not retransmitted
[ https://issues.apache.org/jira/browse/CXF-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270471#comment-15270471 ] Akitoshi Yoshida edited comment on CXF-6886 at 5/4/16 10:58 AM: applied kai's patch with some modification. Thank you for your work. For those ws-rm scenarios without attachments, this patch should not change the behavior. For those scenarios with attachments, the attachments are persisted and retrieved from the storage. There is still a related issue regarding WS-RM with or without attachments, which is tracked by CXF-6646, as mentioned. was (Author: ay): applied kai's patch with some modification. For those ws-rm scenarios without attachments, this patch should not change the behavior. For those scenarios with attachments, the attachments are persisted and retrieved from the storage. There is still a related issue regarding WS-RM with or without attachments, which is tracked by CXF-6646, as mentioned. > CXF 3.x WSRM attachments are not retransmitted > -- > > Key: CXF-6886 > URL: https://issues.apache.org/jira/browse/CXF-6886 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.6, 3.0.9 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: > 0001-WSRM-handle-attachments-for-retransmission-fixes.patch, > esb-ext-cxf.git-acd68897e4bc05c1676a9b12f47b9b6c1fb862e2.patch > > > With CXF-4866, CXF-352 changes to the WSRM implementation were introduced. > When Retransmission is started from RMStore, attachments get lost. > According to the comment from Aki in CXF-6646 implementation was changed > regarding storing a message for retransmission. > Soap message and attachments are stored as blob. So no need for attachments > table anymore. > RMUtils was enhanced by two methods. One encodes the soap message and the > attachment as multipart message, the other decodes the stored blob into soap > message and attachments. > Patch is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6886) CXF 3.x WSRM attachments are not retransmitted
[ https://issues.apache.org/jira/browse/CXF-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6886. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 3.0.10 applied kai's patch with some modification. For those ws-rm scenarios without attachments, this patch should not change the behavior. For those scenarios with attachments, the attachments are persisted and retrieved from the storage. There is still a related issue regarding WS-RM with or without attachments, which is tracked by CXF-6646, as mentioned. > CXF 3.x WSRM attachments are not retransmitted > -- > > Key: CXF-6886 > URL: https://issues.apache.org/jira/browse/CXF-6886 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.6, 3.0.9 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: > 0001-WSRM-handle-attachments-for-retransmission-fixes.patch, > esb-ext-cxf.git-acd68897e4bc05c1676a9b12f47b9b6c1fb862e2.patch > > > With CXF-4866, CXF-352 changes to the WSRM implementation were introduced. > When Retransmission is started from RMStore, attachments get lost. > According to the comment from Aki in CXF-6646 implementation was changed > regarding storing a message for retransmission. > Soap message and attachments are stored as blob. So no need for attachments > table anymore. > RMUtils was enhanced by two methods. One encodes the soap message and the > attachment as multipart message, the other decodes the stored blob into soap > message and attachments. > Patch is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6886) CXF 3.x WSRM attachments are not retransmitted
[ https://issues.apache.org/jira/browse/CXF-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6886: - Assignee: Akitoshi Yoshida > CXF 3.x WSRM attachments are not retransmitted > -- > > Key: CXF-6886 > URL: https://issues.apache.org/jira/browse/CXF-6886 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.6, 3.0.9 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Attachments: > esb-ext-cxf.git-acd68897e4bc05c1676a9b12f47b9b6c1fb862e2.patch > > > With CXF-4866, CXF-352 changes to the WSRM implementation were introduced. > When Retransmission is started from RMStore, attachments get lost. > According to the comment from Aki in CXF-6646 implementation was changed > regarding storing a message for retransmission. > Soap message and attachments are stored as blob. So no need for attachments > table anymore. > RMUtils was enhanced by two methods. One encodes the soap message and the > attachment as multipart message, the other decodes the stored blob into soap > message and attachments. > Patch is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6876) Unable to get XML response from org.apache.cxf.message.Message.getContent(InputStream.class)
[
https://issues.apache.org/jira/browse/CXF-6876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6876.
---
Resolution: Not A Bug
Message.getContent(InputStream.class) is supposed to return an instance of
InputStream and SequenceInputStream is a valid InputStream. Hence, this is not
a bug and I am closing this ticket.
If you have further questions, the right place to ask your questions or
describe your requirement is the users@cxf mailing list.
Thanks.
Regards, aki
> Unable to get XML response from
> org.apache.cxf.message.Message.getContent(InputStream.class)
>
>
> Key: CXF-6876
> URL: https://issues.apache.org/jira/browse/CXF-6876
> Project: CXF
> Issue Type: Bug
>Reporter: pravin deore
>
> In the version 2.7.8
> org.apache.cxf.message.Message.getContent(InputStream.class) used to return
> the InputStream object but with version 3.0.5 we are now getting the
> SequenceInputStream object ,and there is no way to get the inputstream from
> it.
> Issue is because of code change being made in "LoggingInInterceptor" class
> logInputStream(message, is, buffer, encoding, ct) method which contains the
> following code
> //only copy up to the limit since that's all we need to log
> //we can stream the rest
> 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);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6878) Protect against other exception during consuming left-over data
[ https://issues.apache.org/jira/browse/CXF-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6878. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 3.0.10 > Protect against other exception during consuming left-over data > --- > > Key: CXF-6878 > URL: https://issues.apache.org/jira/browse/CXF-6878 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.5, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Fix For: 3.0.10, 3.1.7, 3.2.0 > > > Make the processing of the fault response serialization more robust so that > an exception thrown during the cleanup of the left-over input stream will not > abort the fault response serialization processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6878) Protect against other exception during consuming left-over data
[ https://issues.apache.org/jira/browse/CXF-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida updated CXF-6878: -- Description: Make the processing of the fault response serialization more robust so that an exception thrown during the cleanup of the left-over input stream will not abort the fault response serialization processing. was: Make it more robust during the fault response serialization so that an exception thrown during the consumption of the left-over input stream does abort the fault response serialization. > Protect against other exception during consuming left-over data > --- > > Key: CXF-6878 > URL: https://issues.apache.org/jira/browse/CXF-6878 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.5, 3.0.9 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > > Make the processing of the fault response serialization more robust so that > an exception thrown during the cleanup of the left-over input stream will not > abort the fault response serialization processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6878) Protect against other exception during consuming left-over data
Akitoshi Yoshida created CXF-6878: - Summary: Protect against other exception during consuming left-over data Key: CXF-6878 URL: https://issues.apache.org/jira/browse/CXF-6878 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 3.0.9, 3.1.5 Reporter: Akitoshi Yoshida Assignee: Akitoshi Yoshida Make it more robust during the fault response serialization so that an exception thrown during the consumption of the left-over input stream does abort the fault response serialization. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6646) CXF 3.x WSRM message may not be retrieved from database
[ https://issues.apache.org/jira/browse/CXF-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231879#comment-15231879 ] Akitoshi Yoshida commented on CXF-6646: --- While looking at the change introduced with CXF-4866, it seems to require a more drastic change to fix the issue. The patch currently attached to this ticket preserves the content in some cases but it uses a complex sequence of operations and it also does not cover for the attachments. If we are to stay in the current model, one option will be to go back to use CachedOutputStream in RMMessage and serialize the whole message including the attachments in one blob associated with this content. In that way, the DB operation is kept simpler (one table write) when storing a multipart message and it also keeps the management of attachment resources simpler (no need to cache the attachment streams separately). > CXF 3.x WSRM message may not be retrieved from database > --- > > Key: CXF-6646 > URL: https://issues.apache.org/jira/browse/CXF-6646 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.4 >Reporter: Kai Rommel >Assignee: Akitoshi Yoshida > Attachments: > 0001-WSRM-enable-RMTxStore-for-different-database-impleme.patch, > 0002-WSRM-enable-RMTxStore-for-different-database-impleme.patch > > > With CXF-4866, CXF-352 changes to the RMTxStore implementation were > introduced. > Running the JUnit Tests for rt/ws/rm with a newer Derby version, some tests > will fail. > You can switch to version 10.8.2.2 and messages won't be recovered from > database, as database connection will be released before message is read. > I used the CachedOutputStream to cache the message. Find attached the patch > files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6646) CXF 3.x WSRM message may not be retrieved from database
[ https://issues.apache.org/jira/browse/CXF-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida updated CXF-6646: -- Assignee: (was: Akitoshi Yoshida) > CXF 3.x WSRM message may not be retrieved from database > --- > > Key: CXF-6646 > URL: https://issues.apache.org/jira/browse/CXF-6646 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.4 >Reporter: Kai Rommel > Attachments: > 0001-WSRM-enable-RMTxStore-for-different-database-impleme.patch, > 0002-WSRM-enable-RMTxStore-for-different-database-impleme.patch > > > With CXF-4866, CXF-352 changes to the RMTxStore implementation were > introduced. > Running the JUnit Tests for rt/ws/rm with a newer Derby version, some tests > will fail. > You can switch to version 10.8.2.2 and messages won't be recovered from > database, as database connection will be released before message is read. > I used the CachedOutputStream to cache the message. Find attached the patch > files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error
Akitoshi Yoshida created CXF-6863: - Summary: WS-RM 3.x does not work with attachments upon a network error Key: CXF-6863 URL: https://issues.apache.org/jira/browse/CXF-6863 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.0.9, 3.1.3 Reporter: Akitoshi Yoshida When sending messages with an attachment, the CXF 3.x WS-RM code may lose message at the client side when a network error occurs. This was working with CXF 2.x WS-RM. This problem is related to the change CXF-4866 which changed the way how the outgoing message is captured. Previously, the entire message was buffered and captured, which isolated this capturing from network issue. In 3.x, only the SOAP part is captured in this way and not the attachments. As a result, an exception will be thrown during the attachment serialization when a network error occurs and the message will not be correctly placed in the retransmission queue. By comparing CXF 3.x and 2.x code, In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and this can trigger a Fault from AttachmentOutInterceptor.handleMessage. URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], int, int) line: 61 URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) line: 60 CacheAndWriteOutputStream.write(byte[]) line: 89 AttachmentSerializer.writeProlog() line: 182 AttachmentOutInterceptor.handleMessage(Message) line: 77 whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts WriteOnCloseOutputStream to isolate itself from any network issue. WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466 CacheAndWriteOutputStream.write(byte[]) line: 89 AttachmentSerializer.writeProlog() line: 172 AttachmentOutInterceptor.handleMessage(Message) line: 72 CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to capture the message entirely. There seem to be other issues with attachments handling in CXF 3.x. Along with other issues CXF-6646, I am not sure how we should fix all these issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6766) Option to disable XMLConstants.FEATURE_SECURE_PROCESSING in XSLTJaxbProvider
[ https://issues.apache.org/jira/browse/CXF-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130789#comment-15130789 ] Akitoshi Yoshida commented on CXF-6766: --- Hi Sergey, shouldn't this be done in a consistent manner in all the parser usages in cxf, maybe then using a combination of a system property and a bus property? regards, aki > Option to disable XMLConstants.FEATURE_SECURE_PROCESSING in XSLTJaxbProvider > > > Key: CXF-6766 > URL: https://issues.apache.org/jira/browse/CXF-6766 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.4 >Reporter: Vjacheslav Borisov >Assignee: Sergey Beryozkin >Priority: Trivial > Fix For: 3.1.5, 3.0.8, 3.2.0 > > Attachments: XSLTJaxbProvider.java.patch > > > XSLTJaxbProvider configures > factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, Boolean.TRUE); > We need option to disable this feature in some projects, e.g. to call xslt > extension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128696#comment-15128696
]
Akitoshi Yoshida commented on CXF-6605:
---
No, only a warning-log is written during the assertion building.
It is not clear whether it is required for cxf to throw an exception in this
case or it is allowed to ignore it and let the downstream app or extension
component decide because the upstream component (neethi) is not rejecting it.
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip,
> ordermanagementUpdated.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6605.
---
Resolution: Invalid
as this is not a valid issue, i'll resolve it as invalid.
as a minor improvement, i added a warning log when the addressing policy is not
correctly recognized by neethi.
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip,
> ordermanagementUpdated.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6552) Multiple chained schema imports not handled correctly
[
https://issues.apache.org/jira/browse/CXF-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6552:
--
Fix Version/s: 2.7.18
3.0.7
> Multiple chained schema imports not handled correctly
> -
>
> Key: CXF-6552
> URL: https://issues.apache.org/jira/browse/CXF-6552
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
> Fix For: 3.1.3, 2.7.18, 3.0.7
>
>
> We seems to still have issue with xsd/wsdl schema import location rewrite in
> scenarios as follows:
> {noformat}
> `-- WEB-INF
> `-- classes
> `-- wsdl
> |-- sayhi
> | |-- a.wsdl
> | |-- sayhi
> | | |-- a.wsdl
> | | `-- sayhi-schema1.xsd
> | `-- sayhi-schema1.xsd
> `-- thewsdl
> `-- sayHi.wsdl
> {noformat}
> WEB-INF/classes/wsdl/thewsdl/sayHi.wsdl being the entry point and importing
> "../sayhi/sayhi-schema1.xsd", WEB-INF/classes/wsdl/sayhi/sayhi-schema1.xsd
> importing "sayhi/sayhi-schema1.xsd".
> The problem is that the second import is not rewritten because when filling
> up the schema map used for wsdl/xsd updates, relative key values are
> erroneously used (IOW the second import "say/sayhi-schema1.xsd" is not
> resolved on top of the first one "../sayhi/sayhi-schema1.xsd", while it
> should).
--
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=15126000#comment-15126000
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
the swagger team wants to have a non-servletcontext based option (as done with
SwaggerContextService) and they are open to adding the path option there so
that our per-path configuration use-case can also be supported.
https://groups.google.com/forum/#!topic/swagger-swaggersocket/bf7uVBWYRTw
So we can go that way. Could you comment to the above swagger-thread that you
will be working on this solution? I hope the patch canl get into 1.5.7. That
will be great.
Thanks.
regards, aki
> 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
>
>
> 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-6760) extract swagger2 feature in its own module
[ https://issues.apache.org/jira/browse/CXF-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121394#comment-15121394 ] Akitoshi Yoshida commented on CXF-6760: --- that sounds good. originally, i thought we can't do this during a micro-version update, but i think it should be okay with it as nothing really changes except one needs to add another dependency when they do the upgrade. so we can first do this in master and bring it down to 3.1.x at some time. > extract swagger2 feature in its own module > -- > > Key: CXF-6760 > URL: https://issues.apache.org/jira/browse/CXF-6760 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Romain Manni-Bucau > > the feature is not provided *with*dependencies so if cxf is in the container > and swagger the webapp then it leads very easily to issues. > Having an external module would make it smoother for integrations and doesnt > really hurt CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6740:
--
Attachment: 0001-temporary-work-for-cxf-6740-take-2.patch
> 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
>
>
> 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=15119692#comment-15119692
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey, Andriy,
I updated the code along our discussion.
The swagger-core code is in my alt-1482b branch [1] with its diff[2] to its
origin 01-08 version.
And cxf's change is attached [3] in this ticket.
[1] https://github.com/elakito/swagger-core/tree/alt-1482b
[2]
https://github.com/elakito/swagger-core/commit/7bca845dd844efaef4f41c8fdb1918121763fa02
[3] 0001-temporary-work-for-cxf-6740-take-2.patch
regards, aki
> 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.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=15119542#comment-15119542
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
Okay. I'll see how that approach will look alike. That will be a minor change
to my previous code.
Yes. and in any case, we would like to have the fix goes into swagger-core
because otherwise we will need to duplicate their ApiListingResource in cxf ;-(
regards, aki
> 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.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=15119193#comment-15119193
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
Okay. Then, we have an approach either using this technique to ensure the
attributes are held TL or using maps Map and Map as the values set in the context and doing the secondary lookup using
the basePath from these maps.
I think the second approach is simpler to manage and besides it does not
unnecessarily contaminate the TL pools, at least for us. How do you think?
A difficult question is whether this approach also works for the issue reporter
of swagger-1482 and also acceptable for the swagger-core team.
regards, aki
> 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.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=15119055#comment-15119055
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
I am talking about servletContext that is injected in our code both to our
custom RequestFilter instance and Swagger's ApiListingResource.
As this seems to be a natural way to pass information from CXF to Swagger.
However, I think we should use a map as its value because it seems to be shared
among all the calling threads?
Or I am missing something here because when I use a normal thread, I observe
the thread-local behavior but not with the two calling threads.
regards, aki
> 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.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] [Updated] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6740:
--
Attachment: 0001-temporary-work-for-cxf-6740.patch
> 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.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=15119041#comment-15119041
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy, Sergey,
My temporary change to swagger-core is in my git branch [1]
It is branched from the origin's 01-18 version with this minor change [2]. That
means, it does not include the change included with swagger-1482.
And I am attachning the change and some samples for cxf as a patch file against
cxf's current master [3]
Once you build both swagger-core and cxf projects including the two samples at
its sample folders. You can install them on karaf by running the karaf comands
feature:repo-add cxf 3.2.0-SNAPSHOT
feature:install cxf-rs-description-swagger2
install -s mvn:org.apache.cxf.samples/jax_rs_description_swagger2_osgi
install -s mvn:org.apache.cxf.samples/jax_rs_description_swagger2_osgi2
and from the console, run
curl http://localhost:8181/cxf/swaggerSample/swagger.yaml
and
curl http://localhost:8181/cxf/swaggerSample2/swagger.yaml
to get two different swagger documents.
However, as I mentioned, if the first call is held between its set and get
lines and the second call's set is invoked, both calls will get the second
document. And this was my question mentioned earlier, whether we should add
another context attribute "swagger.local" with true or false to use the
uri-path to do the lookup in the context when this is set to true.
[1] https://github.com/elakito/swagger-core/tree/alt-1482
[2]
https://github.com/elakito/swagger-core/commit/957e06ecce5a1286e882c6fda2c0a776eec9f2c0
[3] 0001-temporary-work-for-cxf-6740.patch attached in this ticket
> 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
>
> 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#63
[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=15118940#comment-15118940
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
thanks for verifying the issue. I think the patch applied there is somewhat
unnecessarily complex (in terms of the code change and classes added and the
configuration required) and we could suggest a simpler approach along what I
sketched. Yes. I can share the stuff that I experimented. The only issue that I
had with what I did was that I was not getting the thread-local behavior from
context.setAttribtue(key) and context.getAttribtue(key) when I was using out of
the box configuration with the cxf's jaxrs sample code on Karaf. Do I need to
set some property or does it not work this way? Sergey?
regards, aki
> 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
>
> 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=15115422#comment-15115422
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
We can keep it on your name and we can sync/exchange our status here.
thanks.
regards, aki
> 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
>
> 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=15115173#comment-15115173
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
no problem. I might have prematurely reopened the issue ;-)
I thought the patched code still doesn't provide a way to pass the configured
scanner/beanconfig from its user (cxf) to the swagger resource.
I played a little bit last friday by setting the both Id's (setting them to the
corresponding jaxrs' root path) but didn't get the behavior that I wanted.
And I wandered how the patched code can pick up the configured scanner. Then, I
went for another way and experimented with a slightly modified pre-patched
swagger code and passed a scanner instance directly over the context to the
swagger resource (briefly sketched in my previous comment).
I'll spend a little more time today to see if I missed something.
regards, aki
> 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
>
> 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-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115146#comment-15115146
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi Sabiya,
your updated service is working for me with the pom dependency that you have.
Have you verified if the addressing header is correctly set in the request
message?
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip,
> ordermanagementUpdated.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida reopened CXF-6740:
---
Hi Andriy, Sergey,
I think we need another solution. The one done in swagger-jaxrs doesn't cover
our use case, where we need to manage multiple configurations over a single
servlet component.
I think we need another approach and I think we could get a much simpler patch
by inserting both swagger and beanconfig/scanner instances to the
thread-localized server context using a jaxrs's RequewtFilter and tell
Swagger's ApiListingResource to get them from the context. In this way, we can
insert a configuration specific swagger/scanner during the call and pass them
to the swagger's resource.
If we don't/can't use the thread-localized context to pass the configuration
specific objects to Swagger's ApiRequestResource, we need to assign a unique
path and pass an extra switch property so that Swagger's ApiRequestResource can
use the specific path key (e.g. swagger- or scanner-) to do the
lookup instead of using just swagger or scanner).
How do you think?
regards, aki
> 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
>
> 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=15110595#comment-15110595
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
there seems to be a recent update to swagger regarding this issue.
https://github.com/swagger-api/swagger-core/issues/1482
it looks like the problem might have been solved with this patch.
regards, aki
> 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
>
> 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=15110338#comment-15110338
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy, Sergey,
sounds good.
Thanks.
regards, aki
> 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
>
> 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=15108800#comment-15108800
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey, Andriy,
maybe we could replace the static usage (i.e., ScannerFactory.getScanner,
ApiListingResource.initialized, etc) and cache the scanner and swagger
instances under a specific root path key in the servlet context object so that
the scenario specific bean scanner instance is passed to the corresponding
ApiListingResource instance? Or what is the current suggested approach?
regards, aki
> 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
>
> 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-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=15108483#comment-15108483
]
Akitoshi Yoshida commented on CXF-6750:
---
this is my guess, but could it be that you are setting a null interceptor to
the outbound interceptor chain?
> 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());
>
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108309#comment-15108309
]
Akitoshi Yoshida commented on CXF-6605:
---
Well, the problem is not about the wrong policy setting (i.e., using wsp:policy
instead of wsp:Policy) throwing an exception for the wsam-2007/05 namespace and
not for the sam-2007/02 namespace and making it work for both cases. The
problem is actually about the wrong policy setting not throwing an exception
for the wsam-2007/02 namespage. According to the ws-addressing 1.0 metadata
spec [1] and its xsd schema (both 2007/02 and 2007/05 versions [2,3]), the
Addressing element must have a single wsp:Policy element child. So, having the
lowercased tsp:policy there violates this requirement and should be rejected.
[1] https://www.w3.org/TR/ws-addr-metadata
[2] https://www.w3.org/2007/02/addressing/metadata/ws-addr-metadata.xsd
[3] https://www.w3.org/2007/05/addressing/metadata/ws-addr-metadata.xsd
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106732#comment-15106732
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi Sabiya,
I am not getting any error with your sample after fixing the wsdl as mentioned.
So, I am wondering if you are still having the same issue? Could it be that the
service was not updated or the client is sending the invalid message?
The below unit test is similar to your setup that is working fine with the
2007/05 namespace.
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/policy/NestedAddressingPolicyTest.java
So, I am still not convinced that the code needs to be changed. We will need a
valid test case that demonstrates the current code is failing.
Thanks.
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106694#comment-15106694
]
Akitoshi Yoshida commented on CXF-6605:
---
No, as the namespace consolidation code does not need to run for the 2007/02
namespace.
For the 2007/05, the namespace consolidation code needs to run but when there
is an invalid nested policy element, this code isn't triggered.
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106550#comment-15106550
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi Sabiya,
I think the cause of the problem is in your wsdl's policy configuration.
it has the lower-cased policy element
this is not recognized by the policy framework (neethi). If you use the correct
form
instead, your sample should work with cxf correctly.
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106481#comment-15106481
]
Akitoshi Yoshida commented on CXF-6605:
---
it looks like somehow the assertion builder is not converting the 2007/05
assertion to the default 2007/02 in the provided sample.
in contrast, the conversion is taking place for the existing systests/ws-specs
tests
i'll look into why.
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida reassigned CXF-6605:
-
Assignee: Akitoshi Yoshida
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
>Assignee: Akitoshi Yoshida
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt, ordermanagement.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6720) AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close
[ https://issues.apache.org/jira/browse/CXF-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6720. --- Resolution: Fixed Fix Version/s: 3.2.0 3.0.8 3.1.5 > AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close > --- > > Key: CXF-6720 > URL: https://issues.apache.org/jira/browse/CXF-6720 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.0.7, 3.1.4 > Environment: IBM Liberty Profile with CXF and JavaMelody, but this is > mostly a discussion about Servlet/Flushable-spec and flush after close. >Reporter: John Hestad >Assignee: Akitoshi Yoshida >Priority: Minor > Labels: Closable, Flushable, IBM_JAVA, JavaMelody, > LibertyProfile, OutputStream, core, flush, flushBuffer, servlet-api > Fix For: 3.1.5, 3.0.8, 3.2.0 > > > Bug location: > https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L806 > ServletResponse.flushBuffer: > http://grepcode.com/file/repo1.maven.org/maven2/javax.servlet/javax.servlet-api/3.1.0/javax/servlet/ServletResponse.java#ServletResponse.flushBuffer%28%29 > Reading the javadoc of ServletResponse.flushBuffer, Closable and Flushable > interfaces tells me that calling flushBuffer on a ServletResponse containing > a closed stream could give an IOException. > We have had problems with this in Liberty Profile, while using CXF together > with CXF. > Background story: > 1) Javamelody issue: https://github.com/javamelody/javamelody/issues/411 > 2) Old discussion: > https://groups.google.com/forum/#!topic/javamelody/kX31sRTFrHE/discussion > 3) IBM WasDev issue: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ > To make a short recap: > 1) Soap-call to the service > 2) Cxf calls close() -> OutputStream closes > 3) Cxf calls flushBuffer which hits JavaMelody's ServletResponse-wrapper > which again calls flush on the OutputStream > 4) Ibm Liberty Profile throws an IOException telling the stream is closed. > If we exclude JavaMelody: > 3) Cxf calls flushBuffer which hits Liberty Profile's ServletResponse-wrapper > which checks if the stream is already close and returns early. > Update: Added crossreference to the IBM WasDev issue from the wrong one: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6720) AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close
[ https://issues.apache.org/jira/browse/CXF-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6720: - Assignee: Akitoshi Yoshida > AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close > --- > > Key: CXF-6720 > URL: https://issues.apache.org/jira/browse/CXF-6720 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.0.7, 3.1.4 > Environment: IBM Liberty Profile with CXF and JavaMelody, but this is > mostly a discussion about Servlet/Flushable-spec and flush after close. >Reporter: John Hestad >Assignee: Akitoshi Yoshida >Priority: Minor > Labels: Closable, Flushable, IBM_JAVA, JavaMelody, > LibertyProfile, OutputStream, core, flush, flushBuffer, servlet-api > > Bug location: > https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L806 > ServletResponse.flushBuffer: > http://grepcode.com/file/repo1.maven.org/maven2/javax.servlet/javax.servlet-api/3.1.0/javax/servlet/ServletResponse.java#ServletResponse.flushBuffer%28%29 > Reading the javadoc of ServletResponse.flushBuffer, Closable and Flushable > interfaces tells me that calling flushBuffer on a ServletResponse containing > a closed stream could give an IOException. > We have had problems with this in Liberty Profile, while using CXF together > with CXF. > Background story: > 1) Javamelody issue: https://github.com/javamelody/javamelody/issues/411 > 2) Old discussion: > https://groups.google.com/forum/#!topic/javamelody/kX31sRTFrHE/discussion > 3) IBM WasDev issue: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ > To make a short recap: > 1) Soap-call to the service > 2) Cxf calls close() -> OutputStream closes > 3) Cxf calls flushBuffer which hits JavaMelody's ServletResponse-wrapper > which again calls flush on the OutputStream > 4) Ibm Liberty Profile throws an IOException telling the stream is closed. > If we exclude JavaMelody: > 3) Cxf calls flushBuffer which hits Liberty Profile's ServletResponse-wrapper > which checks if the stream is already close and returns early. > Update: Added crossreference to the IBM WasDev issue from the wrong one: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072882#comment-15072882
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi Sabiya,
we would like to know your exact setup to understand why you are observing this
problem because this problem normally should not happen (i.e., the code makes
sure that you don't need to explicitly handle both namespaces at that location
because you should be seeing only the wsam-2007/02 namespace there even when
the wsam-2007/05 namespace is used).
For a normal use-case, there is a test case in systests/ws-specs that uses the
wsam-2007/05 namespace.
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/policy/AddressingPolicy0705Test.java
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch,
> ErrorMessageAtClient.bmp, ExceptionTrace.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6720) AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close
[ https://issues.apache.org/jira/browse/CXF-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067960#comment-15067960 ] Akitoshi Yoshida commented on CXF-6720: --- Hi Dan, thanks for your comments. The current jetty tests are all running fine without the flushBuffer line. So I'll remove the line. regards, aki > AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close > --- > > Key: CXF-6720 > URL: https://issues.apache.org/jira/browse/CXF-6720 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.0.7, 3.1.4 > Environment: IBM Liberty Profile with CXF and JavaMelody, but this is > mostly a discussion about Servlet/Flushable-spec and flush after close. >Reporter: John Hestad >Priority: Minor > Labels: Closable, Flushable, IBM_JAVA, JavaMelody, > LibertyProfile, OutputStream, core, flush, flushBuffer, servlet-api > > Bug location: > https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L806 > ServletResponse.flushBuffer: > http://grepcode.com/file/repo1.maven.org/maven2/javax.servlet/javax.servlet-api/3.1.0/javax/servlet/ServletResponse.java#ServletResponse.flushBuffer%28%29 > Reading the javadoc of ServletResponse.flushBuffer, Closable and Flushable > interfaces tells me that calling flushBuffer on a ServletResponse containing > a closed stream could give an IOException. > We have had problems with this in Liberty Profile, while using CXF together > with CXF. > Background story: > 1) Javamelody issue: https://github.com/javamelody/javamelody/issues/411 > 2) Old discussion: > https://groups.google.com/forum/#!topic/javamelody/kX31sRTFrHE/discussion > 3) IBM WasDev issue: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ > To make a short recap: > 1) Soap-call to the service > 2) Cxf calls close() -> OutputStream closes > 3) Cxf calls flushBuffer which hits JavaMelody's ServletResponse-wrapper > which again calls flush on the OutputStream > 4) Ibm Liberty Profile throws an IOException telling the stream is closed. > If we exclude JavaMelody: > 3) Cxf calls flushBuffer which hits Liberty Profile's ServletResponse-wrapper > which checks if the stream is already close and returns early. > Update: Added crossreference to the IBM WasDev issue from the wrong one: > https://developer.ibm.com/answers/questions/244982/why-does-httpoutputstreamflush-when-stream-is-clos/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067849#comment-15067849
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi Sabiya,
thanks for the update. It is still not clear to me when the problem that you
describes occurs.
Although CXF internally uses the old 2007/02 namespace during the policy
checking but both 2007/05 and 2007/02 assertions should be handled correctly as
they are internally converted into the 2007/02 assertions. So, I suppose there
is no problem under normal circumstances. (e.g., you can replace all the
2007/02 namespaces to the 2007/05 namespaces in CXF's systests/ws-spec and all
the tests should still pass).
To understand the problem, I would like to see a test case that fails without
your patch. Could you provide one?
Thanks.
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
> Labels: easyfix
> Attachments: AddressingMetadataNamespace.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6605) WS-Addressing 07/05 not working
[
https://issues.apache.org/jira/browse/CXF-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066367#comment-15066367
]
Akitoshi Yoshida commented on CXF-6605:
---
Hi,
thank you for investigating this issue.
I wanted to look at the attached patch file, but you seem to have generated
this patch file after some unintentional massive changes and therefore the file
is huge (over 2MB).
Could you reattach the patch file that only contains the relevant change for
this issue?
regards, aki
> WS-Addressing 07/05 not working
> ---
>
> Key: CXF-6605
> URL: https://issues.apache.org/jira/browse/CXF-6605
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.2
> Environment: Win 8, current Spring Boot, Embedded Tomcat
>Reporter: Stefan Kuhn
> Labels: easyfix
> Attachments: AddressingMetadataNamespaceFix.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> using
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"; instead of
> xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata";
> invalidates valid WS requests.
> e.g. in my usecase, the WSDL uses
>
>
>
>
>
> and
> type="tns:OrderManagementServiceOutboundPortType">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
> Springs CXF configuration uses the policy interceptor with
>
>
>
>
>
>
> and
> publish="true"
> implementor="#outbound"
> address="/OrderManagementServiceOutbound"
> serviceName="s:OrderManagementServiceOutbound"
> endpointName="s:OrderManagementResponsePort"
> wsdlLocation="/wsdl/OrderManagementServiceOutbound.wsdl"
> xmlns:s="urn:OrderManagementServiceOutbound">
>
>
>value="${ws.stacktrace-enabled:false}" />
>value="${ws.exception-message-cause-enabled:false}" />
>
>
>
>
>
>
>
>
> I've used CXF and SOAP-UI as a client for the server application, both
> successful for 2007/02, both unsuccessful for 2007/05.
> CXF replies to the same request with
>
> xmlns:ns1="http://www.w3.org/2005/08/addressing";>ns1:MessageAddressingHeaderRequired
> A required header representing a Message Addressing
> Property is not present
>
> It seems to me, that the qualified name of ADDRESSING_ASSERTION_QNAME_0705 is
> not added to the QName[] types in
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.assertAddressing(Message,
> EndpointReferenceType, EndpointReferenceType), Line 334.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6720) AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close
[ https://issues.apache.org/jira/browse/CXF-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066354#comment-15066354 ] Akitoshi Yoshida commented on CXF-6720: --- Memo this close and flush was added with this http://svn.apache.org/viewvc?view=revision&revision=548549 I think we can remove the flushBuffer line as I suppose the close on the stream will be flushing the response buffer. But I don't know if there is a case that is not the case and this flushBuffer needs to be called. In that case, we might need to keep it with some condition/protection (e.g. checking !response.isCommitted() before or catching the unexpected exception). Dan, how do you think? > AbstractHTTPDestination#WrappedOutputStream.close() calls flush after close > --- > > Key: CXF-6720 > URL: https://issues.apache.org/jira/browse/CXF-6720 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.0.7, 3.1.4 > Environment: IBM Liberty Profile with CXF and JavaMelody, but this is > mostly a discussion about Servlet/Flushable-spec and flush after close. >Reporter: John Hestad >Priority: Minor > Labels: Closable, Flushable, IBM_JAVA, JavaMelody, > LibertyProfile, OutputStream, core, flush, flushBuffer, servlet-api > > Bug location: > https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L806 > ServletResponse.flushBuffer: > http://grepcode.com/file/repo1.maven.org/maven2/javax.servlet/javax.servlet-api/3.1.0/javax/servlet/ServletResponse.java#ServletResponse.flushBuffer%28%29 > Reading the javadoc of ServletResponse.flushBuffer, Closable and Flushable > interfaces tells me that calling flushBuffer on a ServletResponse containing > a closed stream could give an IOException. > We have had problems with this in Liberty Profile, while using CXF together > with CXF. > Background story: > 1) https://github.com/javamelody/javamelody/issues/411 > 2) https://groups.google.com/forum/#!topic/javamelody/kX31sRTFrHE/discussion > 3) http://www-01.ibm.com/support/docview.wss?uid=swg1PI46480 > To make a short recap: > 1) Soap-call to the service > 2) Cxf calls close() -> OutputStream closes > 3) Cxf calls flushBuffer which hits JavaMelody's ServletResponse-wrapper > which again calls flush on the OutputStream > 4) Ibm Liberty Profile throws an IOException telling the stream is closed. > If we exclude JavaMelody: > 3) Cxf calls flushBuffer which hits Liberty Profile's ServletResponse-wrapper > which checks if the stream is already close and returns early. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6675) Update commons-collections from 3.2.1 to 3.2.2
[ https://issues.apache.org/jira/browse/CXF-6675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046649#comment-15046649 ] Akitoshi Yoshida commented on CXF-6675: --- Yes. You can just replace it manually and that should not create any problem. > Update commons-collections from 3.2.1 to 3.2.2 > -- > > Key: CXF-6675 > URL: https://issues.apache.org/jira/browse/CXF-6675 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.5, 2.7.18, 3.1.4 >Reporter: Gary Gregory >Assignee: Colm O hEigeartaigh > Fix For: 3.1.5, 3.0.8 > > > Update commons-collections from 3.2.1 to 3.2.2. > See > https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6699) DefaultAddress not set in HTTPConduit class
[
https://issues.apache.org/jira/browse/CXF-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6699.
---
Resolution: Fixed
Fix Version/s: 3.2.0
3.0.8
3.1.5
fixed, thanks to kai.
> DefaultAddress not set in HTTPConduit class
> ---
>
> Key: CXF-6699
> URL: https://issues.apache.org/jira/browse/CXF-6699
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.0.7
>Reporter: Kai Rommel
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> With [CXF-6404] changes to class HTTPConduit were introduced, which leads to
> regression errors.
> Commit 1b7e0dfc9c2eb3249ec12624ef3aff473424265c removes the setting of the
> variable result with the DefaultAddress in line 682.
> When in the latest implementation of method setupAddress() only QUERY_STRING
> is set, in line 691 following address will be set:
> result = result + "?" + queryString;
> To receive a valid address, result must be set before. Therefore add after
> line 684: result = defaultAddress.getString();
> Section should look this way:
> if (defaultAddress != null) {
>result = defaultAddress.getString();
>message.put(Message.ENDPOINT_ADDRESS,
>defaultAddress.getString());
> }
> Best regards
> Kai
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6699) DefaultAddress not set in HTTPConduit class
[
https://issues.apache.org/jira/browse/CXF-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida reassigned CXF-6699:
-
Assignee: Akitoshi Yoshida
> DefaultAddress not set in HTTPConduit class
> ---
>
> Key: CXF-6699
> URL: https://issues.apache.org/jira/browse/CXF-6699
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.0.7
>Reporter: Kai Rommel
>Assignee: Akitoshi Yoshida
>
> With [CXF-6404] changes to class HTTPConduit were introduced, which leads to
> regression errors.
> Commit 1b7e0dfc9c2eb3249ec12624ef3aff473424265c removes the setting of the
> variable result with the DefaultAddress in line 682.
> When in the latest implementation of method setupAddress() only QUERY_STRING
> is set, in line 691 following address will be set:
> result = result + "?" + queryString;
> To receive a valid address, result must be set before. Therefore add after
> line 684: result = defaultAddress.getString();
> Section should look this way:
> if (defaultAddress != null) {
>result = defaultAddress.getString();
>message.put(Message.ENDPOINT_ADDRESS,
>defaultAddress.getString());
> }
> Best regards
> Kai
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5738) given soap action does not match any operation
[ https://issues.apache.org/jira/browse/CXF-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034106#comment-15034106 ] Akitoshi Yoshida commented on CXF-5738: --- as far as I remember, this stricter check was added in cxf to prevent certain attacks. you can also disable this check by activating property allowNonMatchingToDefaultSoapAction at the endpoint (see CXF-5738) this ticket was not attended for a long time and i don't know if there is some issue left to address. please let me know if we can close this ticket. regards, aki > given soap action does not match any operation > -- > > Key: CXF-5738 > URL: https://issues.apache.org/jira/browse/CXF-5738 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 2.7.11 >Reporter: Nicola > > I'm generating a service from an existing wsdl > (http://195.250.34.59/temp/original.wsdl), after creating the service the cxf > generated wsdl has some small difference from the original one > (http://195.250.34.59/temp/cxf_generated.wsdl), if I create client methods, > using for example soapui, from the cxf generated wsdl all is fine but if I > use the original wsdl the requests fail with the error: > "the given soapaction does not match an operation" > the problem is the SOAPAction http header: > cxf expects no SOAPAction header or an empty one, if you look at the wsdl > generated by cxf you can see a section not present in the original wsdl that > define an empty soap action: > > after this section there is also the original one that define: > http://test.example.com//updateList"/> > I defined an interceptor that remove the SOAPAction http header if present > and this workaround the problem > cxf should not modify the original wsdl or however should accept calls > generated using the provided wsdl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-6696) Java2WS - SEI - multiple classpaths
[ https://issues.apache.org/jira/browse/CXF-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida closed CXF-6696. - Resolution: Invalid For questions, please use CXF's users mailing list. See more info at https://cxf.apache.org/mailing-lists.html > Java2WS - SEI - multiple classpaths > --- > > Key: CXF-6696 > URL: https://issues.apache.org/jira/browse/CXF-6696 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benjamin Kastelic >Priority: Minor > > Greetings! > First of all, this is more of a question than a bug. Here it goes. > I'm working on a project, where the SEI class is in Maven module A, schema > classes are in module B and the SEI interface is in module C. I am trying to > generate a WSDL from the SEI class. > I have run the java2ws plugin by setting the classpath to > "moduleX/target/classes", but the plugin throws an error, that the classes > from modules B and C cannot be loaded/found. > Is this even supported or am I doing something wrong? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015585#comment-15015585
]
Akitoshi Yoshida edited comment on CXF-6665 at 11/20/15 10:53 AM:
--
As cxf 2.7.x already reached its EOL, although the fix is already in the
2.7.19-SNAPSHOT, there will be unlikely an apache release for it.
Either you stay with the earlier 2.7.x version, upgrade to the current 3.0.x or
3.1.x version, or create your local 2.7.18 version to avoid this issue. But the
issue itself can only occur when the client does not set the request headers
according to the specs. So, updating the client version which does not have
this issue could also be an option.
was (Author: ay):
As cxf 2.7.x already reached its EOL, although the fix is already in the
2.7.19-SNAPSHOT, there will be unlikely an apache release for it.
Either you stay with the earlier version or patch it locally to avoid this
issue. But the issue itself can only occur when the client does not set the
request headers according to the specs. So, updating the client version which
does not have this issue could also be an option.
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17, 2.7.18
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida resolved CXF-6665.
---
Resolution: Won't Fix
fixed in the 2.7.19-SNAPSHOT but no plan for release at the moment.
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17, 2.7.18
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015585#comment-15015585
]
Akitoshi Yoshida commented on CXF-6665:
---
As cxf 2.7.x already reached its EOL, although the fix is already in the
2.7.19-SNAPSHOT, there will be unlikely an apache release for it.
Either you stay with the earlier version or patch it locally to avoid this
issue. But the issue itself can only occur when the client does not set the
request headers according to the specs. So, updating the client version which
does not have this issue could also be an option.
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17, 2.7.18
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6575) WS-A Action generation defect
[ https://issues.apache.org/jira/browse/CXF-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992309#comment-14992309 ] Akitoshi Yoshida commented on CXF-6575: --- the released versions are available now at the central repo and you can also download the distributions from https://cxf.apache.org/download.html > WS-A Action generation defect > - > > Key: CXF-6575 > URL: https://issues.apache.org/jira/browse/CXF-6575 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.6 > Environment: WildFly 8.1.0-Final >Reporter: Bas Nossing >Assignee: Akitoshi Yoshida > Fix For: 3.1.3, 2.7.18, 3.0.7 > > > Some of our customers have complained about the ws-addressing "action" value > our system outputs in faults being incorrect. > Service WSDL from which we generated JAX-WS classes: > * AanleverService_WUS20V12.wsdl: http://pastebin.com/BSMais7F > * digipoort-koppelvlak-1.2.xsd: http://pastebin.com/DRXc0Tfa > Correct fault message: > http://pastebin.com/GAKRshWE > Incorrect fault message: > http://pastebin.com/p7XjJKb9 > Expected value: > http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService/aanleveren/Fault/ > Produced value: > http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService_V1_2/aanleveren/Fault/aanleverFault -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992084#comment-14992084
]
Akitoshi Yoshida commented on CXF-6665:
---
just pushed the fix to the 2.7.x-fixes branch
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=39e65abf8fe2b181a9262c5953c389e9bb7ca706
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17, 2.7.18
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6665:
--
Affects Version/s: 2.7.18
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17, 2.7.18
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991991#comment-14991991
]
Akitoshi Yoshida commented on CXF-6665:
---
Here is a short update and the info about this problem.
The relevant code that brought this regression to 2.7.x is about handling a
non-conformant soap 1.2 multipart request header that does not set the
start-info and action properties. So, the code itself is normally never
executed, assuming most clients follow the relevant specs and set these
properties. We have tested this code for CXF 3.1.x and 3.0.x at that time and
have some test cases. However, in CXF 2.7.x, this code was integrated
incorrectly and didn't expose this issue earlier.
We will fix this issue for 2.7.x.
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida reassigned CXF-6665:
-
Assignee: Akitoshi Yoshida
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17
>Reporter: Tom Cunningham
>Assignee: Akitoshi Yoshida
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6665) ClassCastException in SoapActionInInterceptor
[
https://issues.apache.org/jira/browse/CXF-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991750#comment-14991750
]
Akitoshi Yoshida commented on CXF-6665:
---
It looks like we have regression in 2.7.17.
will look into it.
> ClassCastException in SoapActionInInterceptor
> -
>
> Key: CXF-6665
> URL: https://issues.apache.org/jira/browse/CXF-6665
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 2.7.17
>Reporter: Tom Cunningham
>
> Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf
> 2.7.17.I do not see this error in previous versions of CXF - it looks
> like this is caused by the changes in CXF-6433.
> 02:54:00,882 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has
> thrown exception, unwinding now
> java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be
> cast to java.util.Map
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
> at
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6667) Closing a source sequence in WS-RM may lead to inconsistent sequence status
[ https://issues.apache.org/jira/browse/CXF-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CXF-6667. --- Resolution: Fixed Fix Version/s: 3.0.8 3.1.5 > Closing a source sequence in WS-RM may lead to inconsistent sequence status > --- > > Key: CXF-6667 > URL: https://issues.apache.org/jira/browse/CXF-6667 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.7, 3.1.4 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > Fix For: 3.1.5, 3.0.8 > > > This issue affets WS-RM feature used with RMStore. > When the source sequence is closed by an out-of-band close message (sending > CloseSequence in WS-RM 1.1 or sending an empty LastMessage in WS-RM 1.0), the > sequence status in the RMStore is not updated. As a result, when the endpoint > is shutdown and restarted, it will find the old sequence which was actually > closed and use that sequence to send new messages. This may lead to message > loss at the server under WS-RM 1.0 or to a permanent error under WS-RM 1.1. > More precisely, this issue can happen when the following conditions hold. > 1. the sequence is closed either upon the shutdown of the WS-RM endpoint > (e.g., when its terminateOnShutdown is set to true) or when the closeSequence > operation is invoked by other means (e.g., over JMX console) > 2. there is at least one unacknowledged message still stored in the sequence > 3. a persistent storage is used > Although the underlining issue itself also existed in CXF 2.7.x, because the > default value of termninateOnShutdown property in CXF 3.0 was changed [1] > from false to true, this issue can be observed when migrating scenarios from > CXF 2.7.x to CXF 3.x.x. > [1] > https://github.com/apache/cxf/commit/98d04f03af91e51e3e700f6ddb1c5fb91af07495 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6667) Closing a source sequence in WS-RM may lead to inconsistent sequence status
[ https://issues.apache.org/jira/browse/CXF-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida updated CXF-6667: -- Summary: Closing a source sequence in WS-RM may lead to inconsistent sequence status (was: Closing a source sequence in WS-RM may lead to inconsistent sequence statusw) > Closing a source sequence in WS-RM may lead to inconsistent sequence status > --- > > Key: CXF-6667 > URL: https://issues.apache.org/jira/browse/CXF-6667 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.7, 3.1.4 >Reporter: Akitoshi Yoshida >Assignee: Akitoshi Yoshida > > This issue affets WS-RM feature used with RMStore. > When the source sequence is closed by an out-of-band close message (sending > CloseSequence in WS-RM 1.1 or sending an empty LastMessage in WS-RM 1.0), the > sequence status in the RMStore is not updated. As a result, when the endpoint > is shutdown and restarted, it will find the old sequence which was actually > closed and use that sequence to send new messages. This may lead to message > loss at the server under WS-RM 1.0 or to a permanent error under WS-RM 1.1. > More precisely, this issue can happen when the following conditions hold. > 1. the sequence is closed either upon the shutdown of the WS-RM endpoint > (e.g., when its terminateOnShutdown is set to true) or when the closeSequence > operation is invoked by other means (e.g., over JMX console) > 2. there is at least one unacknowledged message still stored in the sequence > 3. a persistent storage is used > Although the underlining issue itself also existed in CXF 2.7.x, because the > default value of termninateOnShutdown property in CXF 3.0 was changed [1] > from false to true, this issue can be observed when migrating scenarios from > CXF 2.7.x to CXF 3.x.x. > [1] > https://github.com/apache/cxf/commit/98d04f03af91e51e3e700f6ddb1c5fb91af07495 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6667) Closing a source sequence in WS-RM may lead to inconsistent sequence statusw
Akitoshi Yoshida created CXF-6667: - Summary: Closing a source sequence in WS-RM may lead to inconsistent sequence statusw Key: CXF-6667 URL: https://issues.apache.org/jira/browse/CXF-6667 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.1.4, 3.0.7 Reporter: Akitoshi Yoshida Assignee: Akitoshi Yoshida This issue affets WS-RM feature used with RMStore. When the source sequence is closed by an out-of-band close message (sending CloseSequence in WS-RM 1.1 or sending an empty LastMessage in WS-RM 1.0), the sequence status in the RMStore is not updated. As a result, when the endpoint is shutdown and restarted, it will find the old sequence which was actually closed and use that sequence to send new messages. This may lead to message loss at the server under WS-RM 1.0 or to a permanent error under WS-RM 1.1. More precisely, this issue can happen when the following conditions hold. 1. the sequence is closed either upon the shutdown of the WS-RM endpoint (e.g., when its terminateOnShutdown is set to true) or when the closeSequence operation is invoked by other means (e.g., over JMX console) 2. there is at least one unacknowledged message still stored in the sequence 3. a persistent storage is used Although the underlining issue itself also existed in CXF 2.7.x, because the default value of termninateOnShutdown property in CXF 3.0 was changed [1] from false to true, this issue can be observed when migrating scenarios from CXF 2.7.x to CXF 3.x.x. [1] https://github.com/apache/cxf/commit/98d04f03af91e51e3e700f6ddb1c5fb91af07495 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6655) Error Invalid address. Endpoint address cannot be null
[ https://issues.apache.org/jira/browse/CXF-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982313#comment-14982313 ] Akitoshi Yoshida commented on CXF-6655: --- Alessio and I had an irc chat a few days ago and I described briefly how to reproduce the problem and the cases where the problem doesn't occur. The problem can be reproduced when using the same setup sequence as Jaume's description. If the address is set earlier at the port creation as Jaume comments above or somewhere before the conduit setup by setting BindingProvider.ENDPOINT_ADDRESS_PROPERTY of the port, the problem does not occur. In other words, a workaround for new clients is to set BindingProvider.ENDPOINT_ADDRESS_PROPERTY before the conduit setup to avoid this issue. But I think this problem can be resolved somewhere in the cxf code so that the setting the address at the end should work as before. > Error Invalid address. Endpoint address cannot be null > -- > > Key: CXF-6655 > URL: https://issues.apache.org/jira/browse/CXF-6655 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6, 3.1.3 >Reporter: Jaume Vicens > > When creating a client setting proxy config first and then endopoint address, > we get Exception when Sending Message (this worked perfectly in CXF 3.0.2): > java.net.URISyntaxException: Invalid address. Endpoint address cannot be > null. at index 0: > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:48) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > . > . > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 16 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > Could not send Message. > javax.xml.ws.WebServiceException: Could not send Message. > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:149) > .. > .. > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 9 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > This is Client Creation: > Service service = HydraWebService.create(SERVICE_NAME); > port = service.getPort(HydraService.class); > > Client client = ClientProxy.getClient(port); > client.getInInterceptors().add(new LoggingInInterceptor()); > client.getOutInte
[jira] [Commented] (CXF-6655) Error Invalid address. Endpoint address cannot be null
[ https://issues.apache.org/jira/browse/CXF-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978220#comment-14978220 ] Akitoshi Yoshida commented on CXF-6655: --- asked Alessio to have a look. > Error Invalid address. Endpoint address cannot be null > -- > > Key: CXF-6655 > URL: https://issues.apache.org/jira/browse/CXF-6655 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6, 3.1.3 >Reporter: Jaume Vicens > > When creating a client setting proxy config first and then endopoint address, > we get Exception when Sending Message (this worked perfectly in CXF 3.0.2): > java.net.URISyntaxException: Invalid address. Endpoint address cannot be > null. at index 0: > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:48) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > . > . > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 16 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > Could not send Message. > javax.xml.ws.WebServiceException: Could not send Message. > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:149) > .. > .. > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 9 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > This is Client Creation: > Service service = HydraWebService.create(SERVICE_NAME); > port = service.getPort(HydraService.class); > > Client client = ClientProxy.getClient(port); > client.getInInterceptors().add(new LoggingInInterceptor()); > client.getOutInterceptors().add(new LoggingOutInterceptor()); > HTTPConduit http = (HTTPConduit) client.getConduit(); > HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); > httpClientPolicy.setAllowChunking(false); > httpClientPolicy.setReceiveTimeout(0); > httpClientPolicy.setProxyServerType(ProxyServerType.HTTP); > httpClientPolicy.setProxyServer(ConnectorConfiguration.getProxyURL()); > httpClientPolicy.setProxyServerPort(Integer.parseInt(ConnectorConfiguration.getProxyPort())); > http.setClient(httpClientPolicy); > BindingProvider provider = (BindingProvider) port; > > > provider.getRequestContext().put(BindingProvider.ENDPO
[jira] [Commented] (CXF-6655) Error Invalid address. Endpoint address cannot be null
[ https://issues.apache.org/jira/browse/CXF-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978203#comment-14978203 ] Akitoshi Yoshida commented on CXF-6655: --- This regression appears to be the result of a series of optimization done in HTTPConduit recently CXF-6404 CXF-6415. As such, reverting the following commits in the order will go back to the previous state which does not have this issue. 79f9a1056d979b138041ef0693052d3f989ef522 dd1b3ebf5b10651a2220a54a1f6e276d2197acf0 88a7cd850f0471d6e51f9045bf01f775a905cbf2 > Error Invalid address. Endpoint address cannot be null > -- > > Key: CXF-6655 > URL: https://issues.apache.org/jira/browse/CXF-6655 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6, 3.1.3 >Reporter: Jaume Vicens >Assignee: Akitoshi Yoshida > > When creating a client setting proxy config first and then endopoint address, > we get Exception when Sending Message (this worked perfectly in CXF 3.0.2): > java.net.URISyntaxException: Invalid address. Endpoint address cannot be > null. at index 0: > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:48) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > . > . > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 16 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > Could not send Message. > javax.xml.ws.WebServiceException: Could not send Message. > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:149) > .. > .. > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 9 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > This is Client Creation: > Service service = HydraWebService.create(SERVICE_NAME); > port = service.getPort(HydraService.class); > > Client client = ClientProxy.getClient(port); > client.getInInterceptors().add(new LoggingInInterceptor()); > client.getOutInterceptors().add(new LoggingOutInterceptor()); > HTTPConduit http = (HTTPConduit) client.getConduit(); > HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); > httpClientPolicy.setAllowChunking(false); > httpClientPolicy.setReceiveTimeout(0); > httpClientPolicy.setProxyServerTy
[jira] [Updated] (CXF-6655) Error Invalid address. Endpoint address cannot be null
[ https://issues.apache.org/jira/browse/CXF-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida updated CXF-6655: -- Assignee: (was: Akitoshi Yoshida) > Error Invalid address. Endpoint address cannot be null > -- > > Key: CXF-6655 > URL: https://issues.apache.org/jira/browse/CXF-6655 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6, 3.1.3 >Reporter: Jaume Vicens > > When creating a client setting proxy config first and then endopoint address, > we get Exception when Sending Message (this worked perfectly in CXF 3.0.2): > java.net.URISyntaxException: Invalid address. Endpoint address cannot be > null. at index 0: > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:48) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > . > . > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 16 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > Could not send Message. > javax.xml.ws.WebServiceException: Could not send Message. > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:149) > .. > .. > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 9 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > This is Client Creation: > Service service = HydraWebService.create(SERVICE_NAME); > port = service.getPort(HydraService.class); > > Client client = ClientProxy.getClient(port); > client.getInInterceptors().add(new LoggingInInterceptor()); > client.getOutInterceptors().add(new LoggingOutInterceptor()); > HTTPConduit http = (HTTPConduit) client.getConduit(); > HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); > httpClientPolicy.setAllowChunking(false); > httpClientPolicy.setReceiveTimeout(0); > httpClientPolicy.setProxyServerType(ProxyServerType.HTTP); > httpClientPolicy.setProxyServer(ConnectorConfiguration.getProxyURL()); > httpClientPolicy.setProxyServerPort(Integer.parseInt(ConnectorConfiguration.getProxyPort())); > http.setClient(httpClientPolicy); > BindingProvider provider = (BindingProvider) port; > > > provider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, > wsdlURL.toString());
[jira] [Assigned] (CXF-6655) Error Invalid address. Endpoint address cannot be null
[ https://issues.apache.org/jira/browse/CXF-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida reassigned CXF-6655: - Assignee: Akitoshi Yoshida > Error Invalid address. Endpoint address cannot be null > -- > > Key: CXF-6655 > URL: https://issues.apache.org/jira/browse/CXF-6655 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6, 3.1.3 >Reporter: Jaume Vicens >Assignee: Akitoshi Yoshida > > When creating a client setting proxy config first and then endopoint address, > we get Exception when Sending Message (this worked perfectly in CXF 3.0.2): > java.net.URISyntaxException: Invalid address. Endpoint address cannot be > null. at index 0: > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:48) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > . > . > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 16 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > Could not send Message. > javax.xml.ws.WebServiceException: Could not send Message. > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:149) > .. > .. > Caused by: java.io.IOException: java.net.URISyntaxException: Invalid address. > Endpoint address cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:490) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 9 more > Caused by: java.net.URISyntaxException: Invalid address. Endpoint address > cannot be null. at index 0: > at > org.apache.cxf.transport.http.HTTPConduit.setAndGetDefaultAddress(HTTPConduit.java:732) > at > org.apache.cxf.transport.http.HTTPConduit.setupAddress(HTTPConduit.java:677) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:488) > ... 17 more > This is Client Creation: > Service service = HydraWebService.create(SERVICE_NAME); > port = service.getPort(HydraService.class); > > Client client = ClientProxy.getClient(port); > client.getInInterceptors().add(new LoggingInInterceptor()); > client.getOutInterceptors().add(new LoggingOutInterceptor()); > HTTPConduit http = (HTTPConduit) client.getConduit(); > HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); > httpClientPolicy.setAllowChunking(false); > httpClientPolicy.setReceiveTimeout(0); > httpClientPolicy.setProxyServerType(ProxyServerType.HTTP); > httpClientPolicy.setProxyServer(ConnectorConfiguration.getProxyURL()); > httpClientPolicy.setProxyServerPort(Integer.parseInt(ConnectorConfiguration.getProxyPort())); > http.setClient(httpClientPolicy); > BindingProvider provider = (BindingProvider) port; > > > provider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRES
