[jira] [Closed] (CXF-1714) ASM package are not stated as optional imports in the bundle's MANIFEST
[ https://issues.apache.org/jira/browse/CXF-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier closed CXF-1714. --- Estimated Complexity: Novice (was: Moderate) Thanks for the fix > ASM package are not stated as optional imports in the bundle's MANIFEST > --- > > Key: CXF-1714 > URL: https://issues.apache.org/jira/browse/CXF-1714 > Project: CXF > Issue Type: Wish > Components: OSGi >Affects Versions: 2.1.1, 2.0.7 > Environment: OW2 JOnAS , using CXF in an OSGi gateway (Felix) >Reporter: Guillaume Sauthier >Assignee: Daniel Kulp > Fix For: 2.4.1 > > > I've found that the package 'org.objectweb.asm' was in the list of > Import-Package of the bundle. > It's not described as optional, even if in the code (I looked at the > WrapperHelper class) it seems to handle the case where ASM is not present, so > I cannot deploy the CXF bundle if the gateway do not have the > 'org.objectweb.asm' package available. > So it seems logical to add a resolution:=optional statement in the bnd file. > I have described that issue as a wish because there is a simple workaround: > simply provide a bundle exporting the right package; but I don't really like > this solution because, I know, from experience, that ASM is not a easily > shareable library, because of API incompatibilities, it far more easier to > embed its privatized version of ASM (using jarjar or the "new" > maven-shadow-plugin its easy) in a private package: org.apache.cxf.asm. So > that you don't have to describe the imports because ASM is now part of the > distribution + you are sure to never have ASM version incompatibilities > issue. Moreover, the ASM core is really lightweight... > So to sum up, I have 2 solutions: > 1. add resolution:=optional to the import statement > 2. or privatize ASM automatically > My preference goes to #2 :) > BTW, does that make sens to have a "Bundle" component in JIRA, or the OSGi > issues will go to the "Build system" component ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3570) HTTPConduit reads response before it completes sending request
HTTPConduit reads response before it completes sending request
--
Key: CXF-3570
URL: https://issues.apache.org/jira/browse/CXF-3570
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.4
Reporter: David Liu
Priority: Critical
Hi,
In CXF 2.4, HTTP Conduit has a new debug log as below. However, this logging
message can cause HTTPConduit reads the response before it completes sending
request, and it results in an IOException in the client side.
The reason is that the method *connection.getContentType()* will trigger
httpconnect to send current data to the HttpServer and want the server to
return the response, so the server thinks the client complete the whole request
and the server just reply nothing and closes the http connection.
Code in HttpConduit.java
{code}
protected void onFirstWrite() throws IOException {
...
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Sending "
+ connection.getRequestMethod()
+ " Message with Headers to "
+ connection.getURL()
+ " Conduit :"
+ conduitName
+ "\nContent-Type: " + connection.getContentType() + "\n");
}
}
{code}
To reproduce the issue: please create a simple web service in cxf 2.4 and
enable its debug log, and then use a generated proxy client to call the http
service, then you can see the error below.
David
Exception:
{code}
Caused by: java.io.IOException: IOException invoking
http://localhost:/Hello: Stream is closed
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 2 more
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3570) HTTPConduit reads response before it completes sending request
[
https://issues.apache.org/jira/browse/CXF-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045399#comment-13045399
]
Willem Jiang commented on CXF-3570:
---
It's a known issue CXF-3466 and will be fixed in CXF 2.4.1.
> HTTPConduit reads response before it completes sending request
> --
>
> Key: CXF-3570
> URL: https://issues.apache.org/jira/browse/CXF-3570
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4
>Reporter: David Liu
>Priority: Critical
> Fix For: 2.4.1
>
>
> Hi,
> In CXF 2.4, HTTP Conduit has a new debug log as below. However, this
> logging message can cause HTTPConduit reads the response before it completes
> sending request, and it results in an IOException in the client side.
> The reason is that the method *connection.getContentType()* will trigger
> httpconnect to send current data to the HttpServer and want the server to
> return the response, so the server thinks the client complete the whole
> request and the server just reply nothing and closes the http connection.
> Code in HttpConduit.java
> {code}
> protected void onFirstWrite() throws IOException {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Sending "
> + connection.getRequestMethod()
> + " Message with Headers to "
> + connection.getURL()
> + " Conduit :"
> + conduitName
> + "\nContent-Type: " + connection.getContentType() +
> "\n");
> }
> }
> {code}
> To reproduce the issue: please create a simple web service in cxf 2.4 and
> enable its debug log, and then use a generated proxy client to call the http
> service, then you can see the error below.
> David
> Exception:
> {code}
> Caused by: java.io.IOException: IOException invoking
> http://localhost:/Hello: Stream is closed
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 2 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3570) HTTPConduit reads response before it completes sending request
[
https://issues.apache.org/jira/browse/CXF-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-3570.
---
Resolution: Duplicate
Fix Version/s: 2.4.1
> HTTPConduit reads response before it completes sending request
> --
>
> Key: CXF-3570
> URL: https://issues.apache.org/jira/browse/CXF-3570
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4
>Reporter: David Liu
>Priority: Critical
> Fix For: 2.4.1
>
>
> Hi,
> In CXF 2.4, HTTP Conduit has a new debug log as below. However, this
> logging message can cause HTTPConduit reads the response before it completes
> sending request, and it results in an IOException in the client side.
> The reason is that the method *connection.getContentType()* will trigger
> httpconnect to send current data to the HttpServer and want the server to
> return the response, so the server thinks the client complete the whole
> request and the server just reply nothing and closes the http connection.
> Code in HttpConduit.java
> {code}
> protected void onFirstWrite() throws IOException {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Sending "
> + connection.getRequestMethod()
> + " Message with Headers to "
> + connection.getURL()
> + " Conduit :"
> + conduitName
> + "\nContent-Type: " + connection.getContentType() +
> "\n");
> }
> }
> {code}
> To reproduce the issue: please create a simple web service in cxf 2.4 and
> enable its debug log, and then use a generated proxy client to call the http
> service, then you can see the error below.
> David
> Exception:
> {code}
> Caused by: java.io.IOException: IOException invoking
> http://localhost:/Hello: Stream is closed
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 2 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3571) CXF HTTPTransportFactory should throw exception when it can't find a HTTPDestinationFactory
CXF HTTPTransportFactory should throw exception when it can't find a HTTPDestinationFactory --- Key: CXF-3571 URL: https://issues.apache.org/jira/browse/CXF-3571 Project: CXF Issue Type: Improvement Components: Transports Affects Versions: 2.4 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.4.1 If we don't put the cxf-rt-transport-http-jetty jar into the class path, and still want to publish a server with the address start with http like "http://localhost:9000/myserver";. We should get some warning for the HTTPTransportFactory, but in CXF 2.4.0, we get no any warning about it, as the HTTPTransportFactory is trying to use ServletDestinationFactory to create destination for it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3571) CXF HTTPTransportFactory should throw exception when it can't find a HTTPDestinationFactory
[ https://issues.apache.org/jira/browse/CXF-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-3571. --- Resolution: Fixed Applied patch into the trunk. > CXF HTTPTransportFactory should throw exception when it can't find a > HTTPDestinationFactory > --- > > Key: CXF-3571 > URL: https://issues.apache.org/jira/browse/CXF-3571 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.4 >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.4.1 > > > If we don't put the cxf-rt-transport-http-jetty jar into the class path, and > still want to publish a server with the address start with http like > "http://localhost:9000/myserver";. We should get some warning for the > HTTPTransportFactory, but in CXF 2.4.0, we get no any warning about it, as > the HTTPTransportFactory is trying to use ServletDestinationFactory to create > destination for it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3572) Add a check of the message content list to avoid the OoM error from the HolderOutInterceptor
Add a check of the message content list to avoid the OoM error from the
HolderOutInterceptor
Key: CXF-3572
URL: https://issues.apache.org/jira/browse/CXF-3572
Project: CXF
Issue Type: Improvement
Components: JAX-WS Runtime
Reporter: Willem Jiang
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.4.1, 2.3.5
The blow code in the HolderOutInterceptor will throw the OOM error when the
inObjects is same with the outObjects.
Although this issue only happens when the Camel route set a wrong response
message body, but it could be helpful if CXF can write some error log for it
and prevent the OOM error.
{code}
if (!Boolean.TRUE.equals(message.get(Message.REQUESTOR_ROLE))) {
List parts = op.getOutput().getMessageParts();
MessageContentsList inObjects =
MessageContentsList.getContentsList(exchange.getInMessage());
if (inObjects != null) {
for (int x = 0; x < inObjects.size(); x++) {
Object o = inObjects.get(x);
if (o instanceof Holder) {
outObjects.set(x + 1, o);
}
}
}
..
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3572) Add a check of the message content list to avoid the OoM error from the HolderOutInterceptor
[
https://issues.apache.org/jira/browse/CXF-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-3572.
---
Resolution: Fixed
Applied patch into trunk and 2.3.x-fixes branch.
> Add a check of the message content list to avoid the OoM error from the
> HolderOutInterceptor
>
>
> Key: CXF-3572
> URL: https://issues.apache.org/jira/browse/CXF-3572
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
>Reporter: Willem Jiang
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
>
> The blow code in the HolderOutInterceptor will throw the OOM error when the
> inObjects is same with the outObjects.
> Although this issue only happens when the Camel route set a wrong response
> message body, but it could be helpful if CXF can write some error log for it
> and prevent the OOM error.
> {code}
> if (!Boolean.TRUE.equals(message.get(Message.REQUESTOR_ROLE))) {
> List parts = op.getOutput().getMessageParts();
> MessageContentsList inObjects =
> MessageContentsList.getContentsList(exchange.getInMessage());
> if (inObjects != null) {
> for (int x = 0; x < inObjects.size(); x++) {
> Object o = inObjects.get(x);
> if (o instanceof Holder) {
> outObjects.set(x + 1, o);
> }
> }
> }
> ..
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3573) CXF/JAX-RS can not handle encoded urls that contain a jsessionid
CXF/JAX-RS can not handle encoded urls that contain a jsessionid Key: CXF-3573 URL: https://issues.apache.org/jira/browse/CXF-3573 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 2.2.12 Reporter: Xi Zhang CXF/JAX-RS stack can not handle encoded urls that contain a jsessionid, I get the warning in the logger after ich try to get data thru REST URL that contains a session cookie lsited below http://localhost:8099/workplace/service;jsessionid=ctjy3rhkbyya1j73rceiw2rup?patientId=1109&responseTimeZone=America%2FLos_Angeles&noCache=1307087541416 Jun 7, 2011 4:58:40 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod WARNING: No operation matching request path /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP Method : GET, ContentType : */*, Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. Jun 7, 2011 4:58:40 PM org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper toResponse WARNING: WebApplicationException has been caught : no cause is available 2011-06-07 16:58:40,457 WARN o.a.cxf.jaxrs.utils.JAXRSUtils[]: No operation matching request path /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP Method : GET, ContentType : */*, Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. 2011-06-07 16:58:40,473 WARN o.a.c.j.i.WebApplicationExceptionMapper[]: WebApplicationException has been caught : no cause is available -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3573) CXF/JAX-RS can not handle encoded urls that contain a jsessionid
[ https://issues.apache.org/jira/browse/CXF-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045474#comment-13045474 ] Sergey Beryozkin commented on CXF-3573: --- Hi, can you please try CXF 2.3.4 or CXF 2.4.0 ? There were relevant changes there. CXF 2.2.x branch is not officially supported anymore thanks > CXF/JAX-RS can not handle encoded urls that contain a jsessionid > > > Key: CXF-3573 > URL: https://issues.apache.org/jira/browse/CXF-3573 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.2.12 >Reporter: Xi Zhang > > CXF/JAX-RS stack can not handle encoded urls that contain a jsessionid, > I get the warning in the logger after ich try to get data thru REST URL that > contains a session cookie lsited below > http://localhost:8099/workplace/service;jsessionid=ctjy3rhkbyya1j73rceiw2rup?patientId=1109&responseTimeZone=America%2FLos_Angeles&noCache=1307087541416 > Jun 7, 2011 4:58:40 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod > WARNING: No operation matching request path > /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP Method : GET, > ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > Jun 7, 2011 4:58:40 PM > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper toResponse > WARNING: WebApplicationException has been caught : no cause is available > 2011-06-07 16:58:40,457 WARN o.a.cxf.jaxrs.utils.JAXRSUtils[]: No operation > matching request path /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP > Method : GET, ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > 2011-06-07 16:58:40,473 WARN o.a.c.j.i.WebApplicationExceptionMapper[]: > WebApplicationException has been caught : no cause is available -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3574) JMSPropertyType should support non string properties
JMSPropertyType should support non string properties Key: CXF-3574 URL: https://issues.apache.org/jira/browse/CXF-3574 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.3 Reporter: Rakesh The class: JMSPropertyType accepts only string property values, this causes major problems when other object types need to be sent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3573) CXF/JAX-RS can not handle encoded urls that contain a jsessionid
[ https://issues.apache.org/jira/browse/CXF-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045520#comment-13045520 ] Xi Zhang commented on CXF-3573: --- No improvement in the CXF releases tested: 2.3.3, 2.3.4, 2.4.0 I got always same warning Jun 7, 2011 6:21:51 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod WARNING: No operation matching request path /;jsessionid=9fav5csenpgyuqq06ffgehpy is found, HTTP Method : GET, ContentType : */*, Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. Jun 7, 2011 6:21:51 PM org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper toResponse WARNING: WebApplicationException has been caught : no cause is available 2011-06-07 18:21:51,278 WARN o.a.cxf.jaxrs.utils.JAXRSUtils[]: No operation matching request path /;jsessionid=9fav5csenpgyuqq06ffgehpy is found, HTTP Method : GET, ContentType : */*, Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. 2011-06-07 18:21:51,293 WARN o.a.c.j.i.WebApplicationExceptionMapper[]: WebApplicationException has been caught : no cause is available > CXF/JAX-RS can not handle encoded urls that contain a jsessionid > > > Key: CXF-3573 > URL: https://issues.apache.org/jira/browse/CXF-3573 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.2.12 >Reporter: Xi Zhang > > CXF/JAX-RS stack can not handle encoded urls that contain a jsessionid, > I get the warning in the logger after ich try to get data thru REST URL that > contains a session cookie lsited below > http://localhost:8099/workplace/service;jsessionid=ctjy3rhkbyya1j73rceiw2rup?patientId=1109&responseTimeZone=America%2FLos_Angeles&noCache=1307087541416 > Jun 7, 2011 4:58:40 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod > WARNING: No operation matching request path > /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP Method : GET, > ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > Jun 7, 2011 4:58:40 PM > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper toResponse > WARNING: WebApplicationException has been caught : no cause is available > 2011-06-07 16:58:40,457 WARN o.a.cxf.jaxrs.utils.JAXRSUtils[]: No operation > matching request path /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP > Method : GET, ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > 2011-06-07 16:58:40,473 WARN o.a.c.j.i.WebApplicationExceptionMapper[]: > WebApplicationException has been caught : no cause is available -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3573) CXF/JAX-RS can not handle encoded urls that contain a jsessionid
[ https://issues.apache.org/jira/browse/CXF-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045612#comment-13045612 ] Sergey Beryozkin commented on CXF-3573: --- I'll investigate. How is your root resource annotated ? Particularly, what are class and resource method Path values ? > CXF/JAX-RS can not handle encoded urls that contain a jsessionid > > > Key: CXF-3573 > URL: https://issues.apache.org/jira/browse/CXF-3573 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.2.12 >Reporter: Xi Zhang > > CXF/JAX-RS stack can not handle encoded urls that contain a jsessionid, > I get the warning in the logger after ich try to get data thru REST URL that > contains a session cookie lsited below > http://localhost:8099/workplace/service;jsessionid=ctjy3rhkbyya1j73rceiw2rup?patientId=1109&responseTimeZone=America%2FLos_Angeles&noCache=1307087541416 > Jun 7, 2011 4:58:40 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod > WARNING: No operation matching request path > /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP Method : GET, > ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > Jun 7, 2011 4:58:40 PM > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper toResponse > WARNING: WebApplicationException has been caught : no cause is available > 2011-06-07 16:58:40,457 WARN o.a.cxf.jaxrs.utils.JAXRSUtils[]: No operation > matching request path /;jsessionid=ctjy3rhkbyya1j73rceiw2rup is found, HTTP > Method : GET, ContentType : */*, Accept : > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > 2011-06-07 16:58:40,473 WARN o.a.c.j.i.WebApplicationExceptionMapper[]: > WebApplicationException has been caught : no cause is available -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3513) [cxf-codegen-plugin][Generate WSDL->Java][illegal character]
[
https://issues.apache.org/jira/browse/CXF-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045622#comment-13045622
]
Daniel Kulp commented on CXF-3513:
--
I cannot reproduce the wsimport version you have above. If I add an
enumeration like:
{code:xml}
{code}
and I run wsimport, I get:
{code:java}
@XmlEnumValue("Supr\u00eame")
SUPR\u00caME("Supr\u00eame"),
@XmlEnumValue("Agu\u00e9")
AGU\u00c9("Agu\u00e9"),
@XmlEnumValue("Grav\u00e8")
GRAV\u00c8("Grav\u00e8"),
@XmlEnumValue("DECISION\u00e9\u00e0\u00e7\u00e8ETTT")
DECISIO_N\u00c9\u00c0\u00c7\u00c8_ETTT("DECISION\u00e9\u00e0\u00e7\u00e8ETTT");
{code}
which is exactly what I get from the CXF wsdl2java command and is per spec.
> [cxf-codegen-plugin][Generate WSDL->Java][illegal character]
>
>
> Key: CXF-3513
> URL: https://issues.apache.org/jira/browse/CXF-3513
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP
> Red Hat 5.3 64Bits
>Reporter: SQLI EQUERRE
>Priority: Minor
>
> I use a maven plugin (cxf-codegen-plugin) to generate wsdl to java
> here's my config :
>
> org.apache.cxf
> cxf-codegen-plugin
> 2.4.0
>
>
> generate-sources
> generate-sources
>
> wsdl2java
>
>
>
>
>
>
>
> ${basedir}/src/main/bindings/jaxb-bindings.xml
>
> true
>
> ${basedir}/src/main/wsdl
>
> **/*.wsdl
>
> ${basedir}/src/main/java
>
>
> My wsdl file has this enumeration :
>
>
>
>
>
>
>
>
>
> In conclusion, one enumeration with french accent.
> But my java file generated with CxF-codegen-plugin looks like this :
> /**
> * Java class for Type.
> *
> * The following schema fragment specifies the expected content contained
> within this class.
> *
> *
> *
> *
> *
> *
> *
> *
> */
> @XmlType(name = "Type")
> @XmlEnum
> public enum Type {
>
> @XmlEnumValue("DECISION\u00c3\u00a9\u00c3\u00a0\u00c3\u00a7\u00c3\u00a8ETTT")
>
> DECISIONÃ_Ã_Ã_Ã_ETTT("DECISION\u00c3\u00a9\u00c3\u00a0\u00c3\u00a7\u00c3\u00a8ETTT"),
> ELABORATION("ELABORATION"),
> VALIDATION("VALIDATION");
>
>
>
> And with wsimport command line (wsimport -s c:\ test.wsdl.) looks like this :
> /**
> * Java class for Type.
> *
> * The following schema fragment specifies the expected content contained
> within this class.
> *
> *
> *
> *
> *
> *
> *
> *
> */
> @XmlType(name = "Type")
> @XmlEnum
> public enum Type {
> @XmlEnumValue("DECISION\u00e9\u00e0\u00e7\u00e8ETTT")
> DECISIO_NÉÀÇÈ_ETTT("DECISION\u00e9\u00e0\u00e7\u00e8ETTT"),
> ELABORATION("ELABORATION"),
> VALIDATION("VALIDATION");
>
> This is better !
> Thank you for your answers :)
> PS: sorry for my English
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3575) Have FailoverFeature working with LoadDistributorTargetSelector
Have FailoverFeature working with LoadDistributorTargetSelector --- Key: CXF-3575 URL: https://issues.apache.org/jira/browse/CXF-3575 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 2.4.1 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.4.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3575) Have FailoverFeature working with LoadDistributorTargetSelector
[ https://issues.apache.org/jira/browse/CXF-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3575. --- Resolution: Fixed > Have FailoverFeature working with LoadDistributorTargetSelector > --- > > Key: CXF-3575 > URL: https://issues.apache.org/jira/browse/CXF-3575 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 2.4.1 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4.1 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3576) Potential overflow for lifetime calculation in STSClient
Potential overflow for lifetime calculation in STSClient Key: CXF-3576 URL: https://issues.apache.org/jira/browse/CXF-3576 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.4 Reporter: Oliver Wulff Fix For: 2.4.1 This code performs integer multiply and then converts the result to a long: expirationTime.setTime(creationTime.getTime() + (ttl * 1000)); Fix: expirationTime.setTime(creationTime.getTime() + (ttl * 1000L)); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3576) Potential overflow for lifetime calculation in STSClient
[ https://issues.apache.org/jira/browse/CXF-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated CXF-3576: -- Attachment: patch.diff diff of patch attached > Potential overflow for lifetime calculation in STSClient > > > Key: CXF-3576 > URL: https://issues.apache.org/jira/browse/CXF-3576 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Oliver Wulff > Fix For: 2.4.1 > > Attachments: patch.diff > > > This code performs integer multiply and then converts the result to a long: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000)); > Fix: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000L)); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3570) HTTPConduit reads response before it completes sending request
[
https://issues.apache.org/jira/browse/CXF-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045760#comment-13045760
]
David Liu commented on CXF-3570:
Thanks Willem.
David
> HTTPConduit reads response before it completes sending request
> --
>
> Key: CXF-3570
> URL: https://issues.apache.org/jira/browse/CXF-3570
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4
>Reporter: David Liu
>Priority: Critical
> Fix For: 2.4.1
>
>
> Hi,
> In CXF 2.4, HTTP Conduit has a new debug log as below. However, this
> logging message can cause HTTPConduit reads the response before it completes
> sending request, and it results in an IOException in the client side.
> The reason is that the method *connection.getContentType()* will trigger
> httpconnect to send current data to the HttpServer and want the server to
> return the response, so the server thinks the client complete the whole
> request and the server just reply nothing and closes the http connection.
> Code in HttpConduit.java
> {code}
> protected void onFirstWrite() throws IOException {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Sending "
> + connection.getRequestMethod()
> + " Message with Headers to "
> + connection.getURL()
> + " Conduit :"
> + conduitName
> + "\nContent-Type: " + connection.getContentType() +
> "\n");
> }
> }
> {code}
> To reproduce the issue: please create a simple web service in cxf 2.4 and
> enable its debug log, and then use a generated proxy client to call the http
> service, then you can see the error below.
> David
> Exception:
> {code}
> Caused by: java.io.IOException: IOException invoking
> http://localhost:/Hello: Stream is closed
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 2 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3576) Potential overflow for lifetime calculation in STSClient
[ https://issues.apache.org/jira/browse/CXF-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045788#comment-13045788 ] Christian Schneider commented on CXF-3576: -- Hi Oli. This is no ordinary patch file. How do I apply this? > Potential overflow for lifetime calculation in STSClient > > > Key: CXF-3576 > URL: https://issues.apache.org/jira/browse/CXF-3576 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Oliver Wulff > Fix For: 2.4.1 > > Attachments: patch.diff > > > This code performs integer multiply and then converts the result to a long: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000)); > Fix: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000L)); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3576) Potential overflow for lifetime calculation in STSClient
[ https://issues.apache.org/jira/browse/CXF-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated CXF-3576: -- Attachment: STSClient.patch I've updated the patch and attached again. I used the following tool to create the patch: diff -crB > Potential overflow for lifetime calculation in STSClient > > > Key: CXF-3576 > URL: https://issues.apache.org/jira/browse/CXF-3576 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Oliver Wulff > Fix For: 2.4.1 > > Attachments: STSClient.patch, patch.diff > > > This code performs integer multiply and then converts the result to a long: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000)); > Fix: > expirationTime.setTime(creationTime.getTime() + (ttl * 1000L)); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
