[jira] [Comment Edited] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339117#comment-15339117
]
David Tarr edited comment on CXF-6944 at 6/20/16 7:47 AM:
--
Sure:
{code:java|title=some-init-method}
SSLSocketFactory sslSocketFactory = getSslSocketFactory();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setCertAlias("the-alias");
tlsClientParameters.setSSLSocketFactory(factory);
...
Client client = ClientProxy.getClient(service);
HTTPConduit conduit = (HTTPConduit) client.getConduit();
conduit.setTlsClientParameters(tlsClientParameters);
// invoke service
{code}
{code:java|title=getSocketFactory()}
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(getTrustStore());
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore, password);
KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();
SSLContext sslContext = SSLContext.getInstance("TLSv1");
sslContext.init(keyManagers, trustManagers, new SecureRandom());
return sslContext.getSocketFactory();
{code}
{code:java|title=getTrustStore()}
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream streamToStore = ...
keystore.load(streamToStore, keystorePassword);
streamToStore.close();
return keystore;
{code}
When I debugged it, as far as I could tell, the trustmanager doesn't return any
reference to cacerts.
was (Author: david tarr):
Sure:
{code:java|title=some-init-method}
SSLSocketFactory sslSocketFactory = getSslSocketFactory();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setCertAlias("the-alias");
tlsClientParameters.setSSLSocketFactory(factory);
...
Client client = ClientProxy.getClient(service);
HTTPConduit conduit = (HTTPConduit) client.getConduit();
conduit.setTlsClientParameters(tlsClientParameters);
// invoke service
{code}
{code:java|title=getSocketFactory()}
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(getTrustStore());
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore, password);
KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();
SSLContext sslContext = SSLContext.getInstance("TLSv1");
sslContext.init(keyManagers, trustManagers, new SecureRandom());
return sslContext.getSocketFactory();
{code}
{code|title=getTrustStore()}
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream streamToStore = ...
keystore.load(streamToStore, keystorePassword);
streamToStore.close();
return keystore;
{code}
When I debugged it, as far as I could tell, the trustmanager doesn't return any
reference to cacerts.
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\j
[jira] [Commented] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339117#comment-15339117
]
David Tarr commented on CXF-6944:
-
Sure:
{code:java|title=some-init-method}
SSLSocketFactory sslSocketFactory = getSslSocketFactory();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setCertAlias("the-alias");
tlsClientParameters.setSSLSocketFactory(factory);
...
Client client = ClientProxy.getClient(service);
HTTPConduit conduit = (HTTPConduit) client.getConduit();
conduit.setTlsClientParameters(tlsClientParameters);
// invoke service
{code}
{code:java|title=getSocketFactory()}
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(getTrustStore());
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore, password);
KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();
SSLContext sslContext = SSLContext.getInstance("TLSv1");
sslContext.init(keyManagers, trustManagers, new SecureRandom());
return sslContext.getSocketFactory();
{code}
{code|title=getTrustStore()}
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream streamToStore = ...
keystore.load(streamToStore, keystorePassword);
streamToStore.close();
return keystore;
{code}
When I debugged it, as far as I could tell, the trustmanager doesn't return any
reference to cacerts.
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6939) can't install cxf-http-async feature
[
https://issues.apache.org/jira/browse/CXF-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339146#comment-15339146
]
Freeman Fang commented on CXF-6939:
---
VOTE for 2nd try is here[1]
[1]http://httpcomponents.10934.n7.nabble.com/VOTE-Release-HttpAsyncClient-4-1-2-based-on-RC2-td28579.html#a28585
> can't install cxf-http-async feature
>
>
> Key: CXF-6939
> URL: https://issues.apache.org/jira/browse/CXF-6939
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> In cxf-http-async feature currently we have
> {code}
>
> cxf-http
> start-level="40">mvn:org.apache.httpcomponents/httpcore-osgi/4.4.4
> start-level="40">mvn:org.apache.httpcomponents/httpclient-osgi/4.5.2
> start-level="40">mvn:org.apache.httpcomponents/httpasyncclient-osgi/4.1.1
> start-level="40">mvn:org.apache.cxf/cxf-rt-transports-http-hc/3.1.7-SNAPSHOT
>
> {code}
> However the latest httpasyncclient-osgi/4.1.1 still need httpclient-osgi 4.4.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6945) cxf-wadl2java-plugin wadlRoot configuration parameter typo
[
https://issues.apache.org/jira/browse/CXF-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6945.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.2.0
3.1.7
Thanks
> cxf-wadl2java-plugin wadlRoot configuration parameter typo
> --
>
> Key: CXF-6945
> URL: https://issues.apache.org/jira/browse/CXF-6945
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.1.6
>Reporter: Jurrie Overgoor
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.7, 3.2.0
>
>
> [Line 48 of
> WADL2JavaMojo.java|https://fisheye6.atlassian.com/browse/cxf/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/wadlto/WADL2JavaMojo.java?r=68a567632a063c6f9bb27a73c151d21f6e855f50&r=857b55796dc7fc2b302e26d99f84df1712ff9c58&r=5c0ca9032922e8d269901447c70db32a7b75ca1a&r=68a567632a063c6f9bb27a73c151d21f6e855f50#to48]
> has a typo. It should be
> $\{basedir\}/src/main/resources/wadl
> instead of
> $\{basedir\}/src/main/resources/wad
> Note the missing "l"
> Workaround is obvious: include
> $\{basedir\}/src/main/resources/wadl
> in your configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6941) Send Comma Separated Array in uril request
[
https://issues.apache.org/jira/browse/CXF-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339242#comment-15339242
]
Sergey Beryozkin commented on CXF-6941:
---
Hi Neal
Why sending multiple parameters with the same name causes a problem, do you
have a JAX-RS client talking to a Spring MVC server and the server fails to
correctly populate the array ? It is a classical case, for example,
HttpServletRequest can understand it and return you a list of values for a
given parameter name.
Bundling multiple values into a single value is a custom option which is
marginally more optimal but it is less interoperable as you can see, for
example, if you have a pure Servlet application then HttpServletRequest won't
be able to understand that it is a multi-value property, it will be a single
value with commas in it which the user code will need to parse itself.
Please provide more details
Cheers, Sergey
> Send Comma Separated Array in uril request
> --
>
> Key: CXF-6941
> URL: https://issues.apache.org/jira/browse/CXF-6941
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.6
> Environment: Mac
>Reporter: Neal Hu
> Fix For: 3.2.0, 3.1.8
>
>
> http://stackoverflow.com/questions/11889997/how-to-send-a-array-in-url-request
> Spring MVC and PHP support send comma separated array in the url request:
> http://localhost:8080/MovieDB/GetJson?name=Actor1,Actor2,Actor3&startDate=20120101&endDate=20120505
> @RequestMapping(value = "/GetJson", method = RequestMethod.GET)
> public void getJson(@RequestParam("name") String[] ticker,
> @RequestParam("startDate") String startDate, @RequestParam("endDate") String
> endDate) {
>//code to get results from db for those params.
> }
> Now jax-rs only support below:
> http://localhost:8080/JerseyPojo/jaxrs/BasicResource/test?nameList=xx&nameList=xxx&nameList=ddd
> @Path("/test")
> @GET
> public String getQueryList([~getadr...@gmail.com]
> When we migrate from Spring MVC to jax-rs, found problem.
> Neal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339614#comment-15339614
]
Sergey Beryozkin commented on CXF-6929:
---
It appears you use an older version of Jetty, and instead add:
{code:xml}
org.apache.cxf
cxf-rt-transports-http-jetty
3.1.7-SNAPSHOT
{code}
and then rewrite your demo code as follows:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(9000);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter( "jaxrs.serviceClasses",
Resource.class.getName() );
servletHolder.setInitParameter( "jaxrs.providers",
Mapper.class.getName() );
server.setHandler(context);
server.start();
server.join();
{code}
?
Works for me:
{noformat}
curl localhost:9000/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Content-Length: 0
* Server Jetty(9.3.5.v20151012) is not blacklisted
< Server: Jetty(9.3.5.v20151012)
<
* Connection #0 to host localhost left intact
{noformat}
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler handler = new ServletContextHandler();
> final ServletHolder holder = new ServletHolder(
> CXFNonSpringJaxrsServlet.class );
> holder.setInitParameter( "jaxrs.serviceClasses",
> Resource.class.getName() );
> holder.setInitParameter( "jaxrs.providers", Mapper.class.getName() );
> handler.addServlet( holder, "/*" );
> server.setHandler( handler );
> server.start();
> System.in.read();
> server.stop();
> }
> public static class Mapper implements
> ExceptionMapper {
> @Override
> public Response toResponse( final NotImplementedException exception )
> {
> exception.printStackTrace();
> return Response.ok().build();
> }
> }
> @Path( "/" )
> public static class Resource {
> @GET
> @Path( "/foo" )
> @Produces( "text/plain" )
> public void foo( @Suspended final AsyncResponse response ) {
> throw new NotImplementedException( "foo" );
> }
> @GET
> @Path( "/bar" )
> @Produces( "text/plain" )
> public void bar( @Suspended final AsyncResponse response ) {
> throw new RuntimeException( "bar" );
> }
> }
> }
> {code}
> curl localhost:/foo hangs forever; curl localhost:/bar does not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339614#comment-15339614
]
Sergey Beryozkin edited comment on CXF-6929 at 6/20/16 2:44 PM:
It appears you use an older version of Jetty, please remove the direct jetty
dependencies and instead add:
{code:xml}
org.apache.cxf
cxf-rt-transports-http-jetty
3.1.7-SNAPSHOT
{code}
and then rewrite your demo code as follows:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(9000);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter( "jaxrs.serviceClasses",
Resource.class.getName() );
servletHolder.setInitParameter( "jaxrs.providers",
Mapper.class.getName() );
server.setHandler(context);
server.start();
server.join();
{code}
?
Works for me:
{noformat}
curl localhost:9000/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Content-Length: 0
* Server Jetty(9.3.5.v20151012) is not blacklisted
< Server: Jetty(9.3.5.v20151012)
<
* Connection #0 to host localhost left intact
{noformat}
was (Author: sergey_beryozkin):
It appears you use an older version of Jetty, please remove the direct jetty
dependencies instead add:
{code:xml}
org.apache.cxf
cxf-rt-transports-http-jetty
3.1.7-SNAPSHOT
{code}
and then rewrite your demo code as follows:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(9000);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter( "jaxrs.serviceClasses",
Resource.class.getName() );
servletHolder.setInitParameter( "jaxrs.providers",
Mapper.class.getName() );
server.setHandler(context);
server.start();
server.join();
{code}
?
Works for me:
{noformat}
curl localhost:9000/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Content-Length: 0
* Server Jetty(9.3.5.v20151012) is not blacklisted
< Server: Jetty(9.3.5.v20151012)
<
* Connection #0 to host localhost left intact
{noformat}
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler hand
[jira] [Comment Edited] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339614#comment-15339614
]
Sergey Beryozkin edited comment on CXF-6929 at 6/20/16 2:44 PM:
It appears you use an older version of Jetty, please remove the direct jetty
dependencies instead add:
{code:xml}
org.apache.cxf
cxf-rt-transports-http-jetty
3.1.7-SNAPSHOT
{code}
and then rewrite your demo code as follows:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(9000);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter( "jaxrs.serviceClasses",
Resource.class.getName() );
servletHolder.setInitParameter( "jaxrs.providers",
Mapper.class.getName() );
server.setHandler(context);
server.start();
server.join();
{code}
?
Works for me:
{noformat}
curl localhost:9000/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Content-Length: 0
* Server Jetty(9.3.5.v20151012) is not blacklisted
< Server: Jetty(9.3.5.v20151012)
<
* Connection #0 to host localhost left intact
{noformat}
was (Author: sergey_beryozkin):
It appears you use an older version of Jetty, and instead add:
{code:xml}
org.apache.cxf
cxf-rt-transports-http-jetty
3.1.7-SNAPSHOT
{code}
and then rewrite your demo code as follows:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(9000);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter( "jaxrs.serviceClasses",
Resource.class.getName() );
servletHolder.setInitParameter( "jaxrs.providers",
Mapper.class.getName() );
server.setHandler(context);
server.start();
server.join();
{code}
?
Works for me:
{noformat}
curl localhost:9000/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Date: Mon, 20 Jun 2016 14:40:15 GMT
< Content-Length: 0
* Server Jetty(9.3.5.v20151012) is not blacklisted
< Server: Jetty(9.3.5.v20151012)
<
* Connection #0 to host localhost left intact
{noformat}
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler handler = new ServletContextHandler();
>
[jira] [Commented] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339668#comment-15339668
]
Colm O hEigeartaigh commented on CXF-6944:
--
Ok thanks. I've looked into it and the SSL logs are a bit misleading. CXF
obtains a HTTPUrlConnection object via url.openConnection(). This is
subsequently "decorated" with the TLS settings. However, by the time
openConnection() is called, the SSL context is not set up. That is why you see
the default CA certs being listed - this occurs on openConnection(). However,
openConnect() does not actually set up the network connection - by the time the
connect is done, the correct truststore settings have been plugged in.
Colm.
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-6944.
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-6944:
Assignee: Colm O hEigeartaigh
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-6944.
--
Resolution: Not A Problem
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6943) Dead lock on Async Response when timeout is set
[
https://issues.apache.org/jira/browse/CXF-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339693#comment-15339693
]
Sergey Beryozkin commented on CXF-6943:
---
It appears this issue is invalid. One has to return a value via the async
response object and not directly, I'll update the code to ignore such methods
as in your example above.
I've update the following test locally:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L119
I added an async response timeout line just before submitting a Runnable at:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L192
All works, but it is not really needed, by default the timeout is unlimited.
Can you please try and rewrite your test accordingly ?
> Dead lock on Async Response when timeout is set
> ---
>
> Key: CXF-6943
> URL: https://issues.apache.org/jira/browse/CXF-6943
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.4, 3.1.6
> Environment: The bug was detected on :
> - Java 1.7.0_11
> - Tomcat 8.0.23
> - CXF 3.0.4
> - Red Hat 6.5
> The bug is also available on :
> - Java 1.8.0_77
> - Tomcat 8.0.35
> - CXF 3.1.6
> - Red Hat 6.5
>Reporter: MOIRE Antony
> Labels: test
> Attachments: Main_Thread_error.txt, Working_Thread_error.txt,
> async-response-test.zip
>
>
> Hello,
> When using AsyncResponse with timeout and an external thread for the
> treatment, it seems that a dead lock appears between the main http thread and
> the treatment thread when the treatment thread finished before the main
> thread :
> Here is the code which reproduces this issue :
> public Response asyncResponseTestKo(HttpServletRequest request, final
> AsyncResponse ar) {
> Response r = null;
> LOGGER.info("Get request asyncResponseTestKo");
> ar.setTimeout(10, TimeUnit.SECONDS);
> poolExecutor.execute(new Runnable() {
> @Override
> public void run() {
> ar.resume(Response.ok().build());
> }
> });
> try {
> Thread.sleep(2000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> return r;
> }
> The main thread error is :
> 2016-06-15 14:47:44
> "http-nio-9080-exec-1" - Thread t@25
>java.lang.Thread.State: BLOCKED
> at
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl.suspendContinuationIfNeeded(AsyncResponseImpl.java:263)
> - waiting to lock <792a9e17> (a
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl) owned by "pool-1-thread-1" t@26
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:191)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> - locked <5f36a728> (a org.apache.cxf.phase.PhaseInterceptorChain)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> at
> org.apache.catalina.core.Applic
[jira] [Comment Edited] (CXF-6943) Dead lock on Async Response when timeout is set
[
https://issues.apache.org/jira/browse/CXF-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339693#comment-15339693
]
Sergey Beryozkin edited comment on CXF-6943 at 6/20/16 3:21 PM:
It appears this issue is invalid. One has to return a value via the async
response object and not directly, I'll update the code to ignore such methods
as in your example above.
I've updated the following test locally:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L119
I added an async response timeout line just before submitting a Runnable at:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L192
All works, but it is not really needed, by default the timeout is unlimited.
Can you please try and rewrite your test accordingly ?
was (Author: sergey_beryozkin):
It appears this issue is invalid. One has to return a value via the async
response object and not directly, I'll update the code to ignore such methods
as in your example above.
I've update the following test locally:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L119
I added an async response timeout line just before submitting a Runnable at:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookContinuationStore.java#L192
All works, but it is not really needed, by default the timeout is unlimited.
Can you please try and rewrite your test accordingly ?
> Dead lock on Async Response when timeout is set
> ---
>
> Key: CXF-6943
> URL: https://issues.apache.org/jira/browse/CXF-6943
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.4, 3.1.6
> Environment: The bug was detected on :
> - Java 1.7.0_11
> - Tomcat 8.0.23
> - CXF 3.0.4
> - Red Hat 6.5
> The bug is also available on :
> - Java 1.8.0_77
> - Tomcat 8.0.35
> - CXF 3.1.6
> - Red Hat 6.5
>Reporter: MOIRE Antony
> Labels: test
> Attachments: Main_Thread_error.txt, Working_Thread_error.txt,
> async-response-test.zip
>
>
> Hello,
> When using AsyncResponse with timeout and an external thread for the
> treatment, it seems that a dead lock appears between the main http thread and
> the treatment thread when the treatment thread finished before the main
> thread :
> Here is the code which reproduces this issue :
> public Response asyncResponseTestKo(HttpServletRequest request, final
> AsyncResponse ar) {
> Response r = null;
> LOGGER.info("Get request asyncResponseTestKo");
> ar.setTimeout(10, TimeUnit.SECONDS);
> poolExecutor.execute(new Runnable() {
> @Override
> public void run() {
> ar.resume(Response.ok().build());
> }
> });
> try {
> Thread.sleep(2000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> return r;
> }
> The main thread error is :
> 2016-06-15 14:47:44
> "http-nio-9080-exec-1" - Thread t@25
>java.lang.Thread.State: BLOCKED
> at
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl.suspendContinuationIfNeeded(AsyncResponseImpl.java:263)
> - waiting to lock <792a9e17> (a
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl) owned by "pool-1-thread-1" t@26
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:191)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> - locked <5f36a728> (a org.apache.cxf.phase.PhaseInterceptorChain)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.ha
[jira] [Commented] (CXF-6944) cacerts is loaded while different truststore is specified
[
https://issues.apache.org/jira/browse/CXF-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339825#comment-15339825
]
David Tarr commented on CXF-6944:
-
Ah okay, thanks!
> cacerts is loaded while different truststore is specified
> -
>
> Key: CXF-6944
> URL: https://issues.apache.org/jira/browse/CXF-6944
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 2.7.18
>Reporter: David Tarr
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> It seems cxf still loads the cacerts eventhough a different truststore is
> specified (programmatically - not via cxf.xml). Could this potentially load
> to a security-risk?
> When I movethe trusted key from the different truststore to cacerts, the
> server is not trusted and the handshake fails. But I have not investigated
> any further.
> {noformat}
> 2016-06-17 13:45:21,213 INFO [main] spring.BusApplicationContext - Loaded
> configuration file cxf.xml.
> 2016-06-17 13:45:21,213 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [META-INF/cxf/cxf.xml]
> 2016-06-17 13:45:21,322 INFO [main]
> spring.ControlledValidationXmlBeanDefinitionReader - Loading XML bean
> definitions from class path resource [cxf.xml]
> 2016-06-17 13:45:21,793 INFO [main] factory.ReflectionServiceFactoryBean -
> Creating Service {http://wwwcom/.} from class
> .
> keyStore is :
> keyStore type is : jks
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
> trustStore is: C:\Java\jdk1.7.0_79\jre\lib\security\cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339860#comment-15339860
]
Florian Diebold commented on CXF-6929:
--
Upgrading Jetty (to 9.3.9 in my case) indeed fixes the problem. Thanks! I
should have thought of that myself.
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler handler = new ServletContextHandler();
> final ServletHolder holder = new ServletHolder(
> CXFNonSpringJaxrsServlet.class );
> holder.setInitParameter( "jaxrs.serviceClasses",
> Resource.class.getName() );
> holder.setInitParameter( "jaxrs.providers", Mapper.class.getName() );
> handler.addServlet( holder, "/*" );
> server.setHandler( handler );
> server.start();
> System.in.read();
> server.stop();
> }
> public static class Mapper implements
> ExceptionMapper {
> @Override
> public Response toResponse( final NotImplementedException exception )
> {
> exception.printStackTrace();
> return Response.ok().build();
> }
> }
> @Path( "/" )
> public static class Resource {
> @GET
> @Path( "/foo" )
> @Produces( "text/plain" )
> public void foo( @Suspended final AsyncResponse response ) {
> throw new NotImplementedException( "foo" );
> }
> @GET
> @Path( "/bar" )
> @Produces( "text/plain" )
> public void bar( @Suspended final AsyncResponse response ) {
> throw new RuntimeException( "bar" );
> }
> }
> }
> {code}
> curl localhost:/foo hangs forever; curl localhost:/bar does not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Diebold resolved CXF-6929.
--
Resolution: Not A Bug
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler handler = new ServletContextHandler();
> final ServletHolder holder = new ServletHolder(
> CXFNonSpringJaxrsServlet.class );
> holder.setInitParameter( "jaxrs.serviceClasses",
> Resource.class.getName() );
> holder.setInitParameter( "jaxrs.providers", Mapper.class.getName() );
> handler.addServlet( holder, "/*" );
> server.setHandler( handler );
> server.start();
> System.in.read();
> server.stop();
> }
> public static class Mapper implements
> ExceptionMapper {
> @Override
> public Response toResponse( final NotImplementedException exception )
> {
> exception.printStackTrace();
> return Response.ok().build();
> }
> }
> @Path( "/" )
> public static class Resource {
> @GET
> @Path( "/foo" )
> @Produces( "text/plain" )
> public void foo( @Suspended final AsyncResponse response ) {
> throw new NotImplementedException( "foo" );
> }
> @GET
> @Path( "/bar" )
> @Produces( "text/plain" )
> public void bar( @Suspended final AsyncResponse response ) {
> throw new RuntimeException( "bar" );
> }
> }
> }
> {code}
> curl localhost:/foo hangs forever; curl localhost:/bar does not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6947) Make it possible to use custom LDAP filters when retrieving group information
Colm O hEigeartaigh created CXF-6947: Summary: Make it possible to use custom LDAP filters when retrieving group information Key: CXF-6947 URL: https://issues.apache.org/jira/browse/CXF-6947 Project: CXF Issue Type: Improvement Components: STS Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.0.10, 3.1.7 Make it possible to use custom LDAP filters when retrieving group information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6947) Make it possible to use custom LDAP filters when retrieving group information
[ https://issues.apache.org/jira/browse/CXF-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-6947: - Fix Version/s: (was: 3.0.10) > Make it possible to use custom LDAP filters when retrieving group information > - > > Key: CXF-6947 > URL: https://issues.apache.org/jira/browse/CXF-6947 > Project: CXF > Issue Type: Improvement > Components: STS >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 3.1.7 > > > Make it possible to use custom LDAP filters when retrieving group information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6947) Make it possible to use custom LDAP filters when retrieving group information
[ https://issues.apache.org/jira/browse/CXF-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-6947. -- Resolution: Fixed > Make it possible to use custom LDAP filters when retrieving group information > - > > Key: CXF-6947 > URL: https://issues.apache.org/jira/browse/CXF-6947 > Project: CXF > Issue Type: Improvement > Components: STS >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 3.1.7 > > > Make it possible to use custom LDAP filters when retrieving group information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6938) Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of heap memory
[ https://issues.apache.org/jira/browse/CXF-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15340225#comment-15340225 ] RANADEEP SHARMA commented on CXF-6938: -- Hi Sergei, I saw your response. I have replied back on the thread. Please let me know if you have a workaround better than the one I had suggested, considering my requirements. Regards, Ranadeep. > Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of > heap memory > > > Key: CXF-6938 > URL: https://issues.apache.org/jira/browse/CXF-6938 > Project: CXF > Issue Type: Task > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.6 > Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7 >Reporter: RANADEEP SHARMA >Assignee: Sergey Beryozkin > > We have an application with REST client components for making calls to > Backend web services. During our routine performance test, JProfiler tool > shows lots of Bus property entries (with keys named > "bus.providers.set.") populated while creating instances of > ClientProviderFactory. > These Bus property entries seem to stay in heap for the whole duration of the > 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap. > In short, GC doesn't seem to happening frequently enough to keep the heap > usage within limits. > Is this some sort of a bug or, lack of necessary configuration in CXF? > Either ways, we need your guidance for trouble-shooting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6929) Request hangs when using JAX-RS AsyncResponse and Exception mapper
[
https://issues.apache.org/jira/browse/CXF-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15340248#comment-15340248
]
Sergey Beryozkin commented on CXF-6929:
---
Np, good it all works as expected
> Request hangs when using JAX-RS AsyncResponse and Exception mapper
> --
>
> Key: CXF-6929
> URL: https://issues.apache.org/jira/browse/CXF-6929
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.1, 3.1.6
>Reporter: Florian Diebold
>
> I have a JAX-RS resource which takes an AsyncResponse, but immediately throws
> an exception before returning from the function. If the exception is then
> mapped by an ExceptionMapper, the response seems to be never sent, and the
> request hangs (stays suspended forever). Am I doing something wrong?
> Example code:
> {code}
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> import javax.ws.rs.container.AsyncResponse;
> import javax.ws.rs.container.Suspended;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.ext.ExceptionMapper;
> import org.apache.commons.lang.NotImplementedException;
> import org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet;
> import org.eclipse.jetty.server.Connector;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.server.ServerConnector;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
> public class ServerDemo2 {
> public static void main( final String[] args ) throws Exception {
> final Server server = new Server();
> final ServerConnector connector = new ServerConnector( server );
> connector.setHost( "localhost" );
> connector.setPort( );
> server.setConnectors( new Connector[] { connector } );
> final ServletContextHandler handler = new ServletContextHandler();
> final ServletHolder holder = new ServletHolder(
> CXFNonSpringJaxrsServlet.class );
> holder.setInitParameter( "jaxrs.serviceClasses",
> Resource.class.getName() );
> holder.setInitParameter( "jaxrs.providers", Mapper.class.getName() );
> handler.addServlet( holder, "/*" );
> server.setHandler( handler );
> server.start();
> System.in.read();
> server.stop();
> }
> public static class Mapper implements
> ExceptionMapper {
> @Override
> public Response toResponse( final NotImplementedException exception )
> {
> exception.printStackTrace();
> return Response.ok().build();
> }
> }
> @Path( "/" )
> public static class Resource {
> @GET
> @Path( "/foo" )
> @Produces( "text/plain" )
> public void foo( @Suspended final AsyncResponse response ) {
> throw new NotImplementedException( "foo" );
> }
> @GET
> @Path( "/bar" )
> @Produces( "text/plain" )
> public void bar( @Suspended final AsyncResponse response ) {
> throw new RuntimeException( "bar" );
> }
> }
> }
> {code}
> curl localhost:/foo hangs forever; curl localhost:/bar does not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-6938) Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of heap memory
[ https://issues.apache.org/jira/browse/CXF-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reopened CXF-6938: --- > Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of > heap memory > > > Key: CXF-6938 > URL: https://issues.apache.org/jira/browse/CXF-6938 > Project: CXF > Issue Type: Task > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.6 > Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7 >Reporter: RANADEEP SHARMA >Assignee: Sergey Beryozkin > > We have an application with REST client components for making calls to > Backend web services. During our routine performance test, JProfiler tool > shows lots of Bus property entries (with keys named > "bus.providers.set.") populated while creating instances of > ClientProviderFactory. > These Bus property entries seem to stay in heap for the whole duration of the > 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap. > In short, GC doesn't seem to happening frequently enough to keep the heap > usage within limits. > Is this some sort of a bug or, lack of necessary configuration in CXF? > Either ways, we need your guidance for trouble-shooting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6938) Setting the providers on a bus causes a leak if this bus is used by per-request clients
[ https://issues.apache.org/jira/browse/CXF-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6938: -- Priority: Minor (was: Major) Summary: Setting the providers on a bus causes a leak if this bus is used by per-request clients (was: Unwanted bunch of Bus Provider objects in HashMap occupying large volumes of heap memory) > Setting the providers on a bus causes a leak if this bus is used by > per-request clients > --- > > Key: CXF-6938 > URL: https://issues.apache.org/jira/browse/CXF-6938 > Project: CXF > Issue Type: Task > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.6 > Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7 >Reporter: RANADEEP SHARMA >Assignee: Sergey Beryozkin >Priority: Minor > > We have an application with REST client components for making calls to > Backend web services. During our routine performance test, JProfiler tool > shows lots of Bus property entries (with keys named > "bus.providers.set.") populated while creating instances of > ClientProviderFactory. > These Bus property entries seem to stay in heap for the whole duration of the > 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap. > In short, GC doesn't seem to happening frequently enough to keep the heap > usage within limits. > Is this some sort of a bug or, lack of necessary configuration in CXF? > Either ways, we need your guidance for trouble-shooting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6938) Setting the providers on a bus causes a leak if this bus is used by per-request clients
[ https://issues.apache.org/jira/browse/CXF-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15340303#comment-15340303 ] Sergey Beryozkin commented on CXF-6938: --- Workarounds: - use the interceptor code to clean up the bus as shown by yourself - allocate a client specific bus and refer to the shared providers directly from the client - do not register the providers on the bus - avoid creating per-request clients and inject a thread safe client instead > Setting the providers on a bus causes a leak if this bus is used by > per-request clients > --- > > Key: CXF-6938 > URL: https://issues.apache.org/jira/browse/CXF-6938 > Project: CXF > Issue Type: Task > Components: Bus, JAX-RS >Affects Versions: 3.1.0, 3.1.6 > Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7 >Reporter: RANADEEP SHARMA >Assignee: Sergey Beryozkin >Priority: Minor > > We have an application with REST client components for making calls to > Backend web services. During our routine performance test, JProfiler tool > shows lots of Bus property entries (with keys named > "bus.providers.set.") populated while creating instances of > ClientProviderFactory. > These Bus property entries seem to stay in heap for the whole duration of the > 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap. > In short, GC doesn't seem to happening frequently enough to keep the heap > usage within limits. > Is this some sort of a bug or, lack of necessary configuration in CXF? > Either ways, we need your guidance for trouble-shooting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6948) WebClient may cause JMX CounterRepository OOM if a request URI varies a lot
Sergey Beryozkin created CXF-6948: - Summary: WebClient may cause JMX CounterRepository OOM if a request URI varies a lot Key: CXF-6948 URL: https://issues.apache.org/jira/browse/CXF-6948 Project: CXF Issue Type: Bug Components: JAX-RS, Management Reporter: Sergey Beryozkin Fix For: 3.0.10, 3.1.7, 3.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6948) WebClient may cause JMX CounterRepository OOM if a request URI varies a lot
[ https://issues.apache.org/jira/browse/CXF-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6948. --- Resolution: Fixed Assignee: Sergey Beryozkin > WebClient may cause JMX CounterRepository OOM if a request URI varies a lot > - > > Key: CXF-6948 > URL: https://issues.apache.org/jira/browse/CXF-6948 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Management >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.0.10, 3.1.7, 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
