[jira] [Commented] (CXF-6291) Improve versatility of @WSDLDocumentation
[
https://issues.apache.org/jira/browse/CXF-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403583#comment-15403583
]
Kent Chen commented on CXF-6291:
Yes, I need it too.
> Improve versatility of @WSDLDocumentation
> -
>
> Key: CXF-6291
> URL: https://issues.apache.org/jira/browse/CXF-6291
> Project: CXF
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.0.4
>Reporter: Olivier Malik Costet
>Priority: Minor
>
> It would be nice if the @WSDLDocumantation annotation were more versatile.
> I'm building an RPC/literal SOAP service. For each method I define, I want
> the service to document the individual parameters. To that end, I would like
> to be able to place a wsdl:documentation element on the individual wsdl:part
> element of the enclosing wsdl:message. CXF does not appear currently to
> support this.
> Sample:
> {code:java}
> @XmlType( name = "customType" )
> //doc either here, or in the @WebMethod parameter... but @WSDLDocumentation
> is currently not allowed on method parameters
> @WSDLDocumentation( "This is the documentation for this type" )
> public class SomeType {
>private String value;
>public SomeType();
>@XmlValue
>public String getValue();
> }
> @WebService
> public class MyServiceEndpoint {
>@WebMethod( operationName="someOperation" )
>public void someMethod(
> @WebParam( name="parameter" )
> //@WSDLDocumentation annotation currently not allowed on method
> parameter
> //@WSDLDocumentation( "This parameter's documentation" )
> SomeType someType )
>{
> ...
>}
> }
> {code}
> Code should result in WSDL:
> {code:xml}
>
> elementFormDefault="unqualified" targetNamespace="sampleNamespace">
>
>
>
>
>
>
>
> *I WOULD LIKE THE DOCUMENTATION
> HERE*
>
>
>
>
>
>
> name="someOperationResponse">
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6908) Prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound
[
https://issues.apache.org/jira/browse/CXF-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403635#comment-15403635
]
Colm O hEigeartaigh commented on CXF-6908:
--
CXF 2.7.x is no longer maintained, there will be no more releases.
Colm.
> Prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound
> ---
>
> Key: CXF-6908
> URL: https://issues.apache.org/jira/browse/CXF-6908
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Reporter: Alessio Soldano
>Assignee: Daniel Kulp
> Fix For: 3.1.7, 3.2.0
>
>
> I have an endpoint as follows:
> {noformat}
> @WebServiceProvider(wsdlLocation = "WEB-INF/FaultService.wsdl",
> targetNamespace = "http://signencrypt.foo.github.com/";)
> @ServiceMode(Mode.MESSAGE)
> @BindingType(SOAPBinding.SOAP11HTTP_BINDING)
> public class FaultService implements Provider
> {
>@Resource
>private WebServiceContext _wsContext;
>@Override
>public SOAPMessage invoke(SOAPMessage request)
>{
> try
> {
> MessageFactory messageFactory = MessageFactory.newInstance();
> SOAPMessage msg = messageFactory.createMessage();
> msg.getSOAPBody().addFault(new
> QName("http://schemas.xmlsoap.org/soap/envelope/";, "Server"),
>"Reason: cos I'm hungry");
> return msg;
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> return null;
>}
> }
> {noformat}
> The client fails in processing the ws-security soap message that's returned
> by the endpoint above:
> {noformat}
> ...
> Caused by: org.apache.xml.security.encryption.XMLEncryptionException: The
> prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound.
> [java] Original Exception was org.xml.sax.SAXParseException;
> lineNumber: 1; columnNumber: 212; The prefix "SOAP-ENV" for element
> "SOAP-ENV:Fault" is not bound.
> [java] at
> org.apache.xml.security.encryption.DocumentSerializer.deserialize(DocumentSerializer.java:93)
> [java] at
> org.apache.xml.security.encryption.DocumentSerializer.deserialize(DocumentSerializer.java:49)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.decryptElement(XMLCipher.java:1685)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.decryptElementContent(XMLCipher.java:1716)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.doFinal(XMLCipher.java:990)
> [java] at
> org.apache.ws.security.processor.ReferenceListProcessor.decryptEncryptedData(ReferenceListProcessor.java:340)
> [java] ... 27 more
> [java] Caused by: org.xml.sax.SAXParseException; lineNumber: 1;
> columnNumber: 212; The prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not
> bound.
> [java] at
> org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:244)
> {noformat}
> It seems that when the soap fault in the endpoint is created with no explicit
> ns prefix for the envelope, the code in
> SoapOutInterceptor::writeSoapEnvelopeStart modifies the namespace prefixes
> and basically turns a message like
> {noformat}
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
> {noformat}
> into
> {noformat}
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
> {noformat}
> (SOAP-ENV is the saaj impl default value for missing explicit soap envelope
> prefix)
> This is probably causing a problem with the fault later added in the body
> because of the ns prefix SOAP-ENV not being bound anymore in the envelope.
> The problem is avoided by explicitly setting the fault prefix in the endpoint:
> {noformat}
> msg.getSOAPPart().getEnvelope().setPrefix("fooe");
> {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=15403645#comment-15403645
]
Arnaud Masciotra commented on CXF-6943:
---
This is a big breaking change (ignoring methods with non-void return type) ...
I had to rework all my code, after upgrading to 3.1.7.
Even if I understand the need and the mistake it could be done ...
In my case, I was using return type (always with null returned), in order to
generate a valid WADL. How generating a valid WADL response tag for async
response in this case, if the return type is always void ?
Could it be less impacting to raised an exception if the return value is set to
null or Void in case of AsyncResponse ?
I just noticed, that the @Suspended JAX-RS 2.0 annotation of AsyncResponse has
to be on the implementation now, it was working on inherited interface before
3.1.7 ... An other side effect of the modification ?
> 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
>Assignee: Sergey Beryozkin
> Labels: test
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> 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
[jira] [Resolved] (FEDIZ-172) OIDC DataProvider should support client_credentials clients
[ https://issues.apache.org/jira/browse/FEDIZ-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-172. --- Resolution: Fixed Assignee: Colm O hEigeartaigh > OIDC DataProvider should support client_credentials clients > > > Key: FEDIZ-172 > URL: https://issues.apache.org/jira/browse/FEDIZ-172 > Project: CXF-Fediz > Issue Type: Improvement > Components: OIDC >Reporter: Sergey Beryozkin >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > OAuth2 Client Credentials (https://tools.ietf.org/html/rfc6749#section-4.4) > is a simplest way for OAuth2 machine clients to request the access token. > For example, instead of the machine client authenticating with STS first and > then using the received assertion to authenticate against OAuth2 > AccessTokenService and use client_credentials to get an access token it is > much simpler for such a client to simply authenticate directly with the > AccessTokenService: > https://tools.ietf.org/html/rfc6749#section-4.4.2 > In this case the step involving the client authenticating with STS will be > done by AccessTokenService. > Both approaches are equivalent but the latter is simpler for the client and > makes the client code OAuth2-portable. > Note the data provider will already support such clients if they have been > pre-registered. However, pre-registering the clients to support their > authentication in cases when their data already exist in Syncope, LDAP, etc, > can be unrealistic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6908) Prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound
[
https://issues.apache.org/jira/browse/CXF-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403688#comment-15403688
]
Jochen Riedlinger commented on CXF-6908:
Thank you very much for that information.
I'll ask the customer support of our commercially supported product how they
get bugfixes into their products that are based on CXF 2.7.x.
Eventually the CXF based product stack is still supported for several years
> Prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound
> ---
>
> Key: CXF-6908
> URL: https://issues.apache.org/jira/browse/CXF-6908
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Reporter: Alessio Soldano
>Assignee: Daniel Kulp
> Fix For: 3.1.7, 3.2.0
>
>
> I have an endpoint as follows:
> {noformat}
> @WebServiceProvider(wsdlLocation = "WEB-INF/FaultService.wsdl",
> targetNamespace = "http://signencrypt.foo.github.com/";)
> @ServiceMode(Mode.MESSAGE)
> @BindingType(SOAPBinding.SOAP11HTTP_BINDING)
> public class FaultService implements Provider
> {
>@Resource
>private WebServiceContext _wsContext;
>@Override
>public SOAPMessage invoke(SOAPMessage request)
>{
> try
> {
> MessageFactory messageFactory = MessageFactory.newInstance();
> SOAPMessage msg = messageFactory.createMessage();
> msg.getSOAPBody().addFault(new
> QName("http://schemas.xmlsoap.org/soap/envelope/";, "Server"),
>"Reason: cos I'm hungry");
> return msg;
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> return null;
>}
> }
> {noformat}
> The client fails in processing the ws-security soap message that's returned
> by the endpoint above:
> {noformat}
> ...
> Caused by: org.apache.xml.security.encryption.XMLEncryptionException: The
> prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not bound.
> [java] Original Exception was org.xml.sax.SAXParseException;
> lineNumber: 1; columnNumber: 212; The prefix "SOAP-ENV" for element
> "SOAP-ENV:Fault" is not bound.
> [java] at
> org.apache.xml.security.encryption.DocumentSerializer.deserialize(DocumentSerializer.java:93)
> [java] at
> org.apache.xml.security.encryption.DocumentSerializer.deserialize(DocumentSerializer.java:49)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.decryptElement(XMLCipher.java:1685)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.decryptElementContent(XMLCipher.java:1716)
> [java] at
> org.apache.xml.security.encryption.XMLCipher.doFinal(XMLCipher.java:990)
> [java] at
> org.apache.ws.security.processor.ReferenceListProcessor.decryptEncryptedData(ReferenceListProcessor.java:340)
> [java] ... 27 more
> [java] Caused by: org.xml.sax.SAXParseException; lineNumber: 1;
> columnNumber: 212; The prefix "SOAP-ENV" for element "SOAP-ENV:Fault" is not
> bound.
> [java] at
> org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:244)
> {noformat}
> It seems that when the soap fault in the endpoint is created with no explicit
> ns prefix for the envelope, the code in
> SoapOutInterceptor::writeSoapEnvelopeStart modifies the namespace prefixes
> and basically turns a message like
> {noformat}
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
> {noformat}
> into
> {noformat}
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
> {noformat}
> (SOAP-ENV is the saaj impl default value for missing explicit soap envelope
> prefix)
> This is probably causing a problem with the fault later added in the body
> because of the ns prefix SOAP-ENV not being bound anymore in the envelope.
> The problem is avoided by explicitly setting the fault prefix in the endpoint:
> {noformat}
> msg.getSOAPPart().getEnvelope().setPrefix("fooe");
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6986) Don't require an application class if using CDI
John D. Ament created CXF-6986: -- Summary: Don't require an application class if using CDI Key: CXF-6986 URL: https://issues.apache.org/jira/browse/CXF-6986 Project: CXF Issue Type: Improvement Reporter: John D. Ament The current CXF-CDI integration assumes there will be an application class. It would be great if CXF did not require an application class, to simplify developer workload. -- 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=15403755#comment-15403755
]
Sergey Beryozkin commented on CXF-6943:
---
It was not a breaking change. It was a fix preventing the users writing an
/invalid JAX-RS 2.0 code - we can't have CXF supporting the invalid code.
The fact WADL does not correctly represent such methods is a minor issue can
which can be addressed (I'll open a minor enhancement request and let you
know). Most likely one would need to depend on some extra annotations already
recognized by the WADL generator but some fix may be needed there to check if
it is AsyncResponse.
I'll check on AsyncResponse and the impl-only restriction in 3.1.7
> 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
>Assignee: Sergey Beryozkin
> Labels: test
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> 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.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:20
[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=15403755#comment-15403755
]
Sergey Beryozkin edited comment on CXF-6943 at 8/2/16 10:44 AM:
It was not a breaking change. It was a fix preventing the users writing an
invalid JAX-RS 2.0 code - we can't have CXF supporting the invalid code.
The fact WADL does not correctly represent such methods is a minor issue can
which can be addressed (I'll open a minor enhancement request and let you
know). Most likely one would need to depend on some extra annotations already
recognized by the WADL generator but some fix may be needed there to check if
it is AsyncResponse.
I'll check on AsyncResponse and the impl-only restriction in 3.1.7
was (Author: sergey_beryozkin):
It was not a breaking change. It was a fix preventing the users writing an
/invalid JAX-RS 2.0 code - we can't have CXF supporting the invalid code.
The fact WADL does not correctly represent such methods is a minor issue can
which can be addressed (I'll open a minor enhancement request and let you
know). Most likely one would need to depend on some extra annotations already
recognized by the WADL generator but some fix may be needed there to check if
it is AsyncResponse.
I'll check on AsyncResponse and the impl-only restriction in 3.1.7
> 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
>Assignee: Sergey Beryozkin
> Labels: test
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> 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(HttpS
[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=15403755#comment-15403755
]
Sergey Beryozkin edited comment on CXF-6943 at 8/2/16 10:45 AM:
It was not a breaking change. It was a fix preventing the users writing an
invalid JAX-RS 2.0 code - we can't have CXF supporting the invalid code.
The fact WADL does not correctly represent such methods is a minor issue which
can be addressed (I'll open a minor enhancement request and let you know). Most
likely one would need to depend on some extra annotations already recognized by
the WADL generator but some fix may be needed there to check if it is
AsyncResponse.
I'll check on AsyncResponse and the impl-only restriction in 3.1.7
was (Author: sergey_beryozkin):
It was not a breaking change. It was a fix preventing the users writing an
invalid JAX-RS 2.0 code - we can't have CXF supporting the invalid code.
The fact WADL does not correctly represent such methods is a minor issue can
which can be addressed (I'll open a minor enhancement request and let you
know). Most likely one would need to depend on some extra annotations already
recognized by the WADL generator but some fix may be needed there to check if
it is AsyncResponse.
I'll check on AsyncResponse and the impl-only restriction in 3.1.7
> 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
>Assignee: Sergey Beryozkin
> Labels: test
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> 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(HttpServle
[jira] [Created] (CXF-6987) Consider both CDI managed and not CDI managed beans in CXFCdiServlet
John D. Ament created CXF-6987:
--
Summary: Consider both CDI managed and not CDI managed beans in
CXFCdiServlet
Key: CXF-6987
URL: https://issues.apache.org/jira/browse/CXF-6987
Project: CXF
Issue Type: Improvement
Reporter: John D. Ament
CXF's CDI integration integration assumes that all of the components included
will be CDI beans.
- It ignores classes defined.
- It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider both CDI managed and not CDI managed beans in CXFCdiServlet
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403759#comment-15403759
]
John D. Ament commented on CXF-6987:
BTW, I'll need a few days, but I plan to provide a patch.
> Consider both CDI managed and not CDI managed beans in CXFCdiServlet
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans.
> - It ignores classes defined.
> - It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403757#comment-15403757 ] John D. Ament commented on CXF-6986: BTW, I plan to provide a patch for this within a day or two. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403788#comment-15403788
]
Andriy Redko commented on CXF-6740:
---
Hi Niten,
You basically have to pull latest master (https://github.com/apache/cxf) and
apply the patch attached to this ticket (CXF-6740-Collision-by-Swagger.patch).
The fix is not yet merged into master, waiting for Swagger 1.5.10 release.
Thanks.
Best Regards,
Andriy Redko
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.patch, CXF-6740-Collision-by-Swagger.patch
>
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6982) Race condition when publishing jax-rs server endpoints
[ https://issues.apache.org/jira/browse/CXF-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403827#comment-15403827 ] Sergey Beryozkin commented on CXF-6982: --- Hi, Can you explain please why the endpoint is being unregistered while it is in the process of being registered ? Just wonder where the possible fix if any should go. > Race condition when publishing jax-rs server endpoints > -- > > Key: CXF-6982 > URL: https://issues.apache.org/jira/browse/CXF-6982 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Eugene > > When using cxf inside OSGi container and when it starts I have very strange > behavior (time to time). > The JaxRs server's that defined it blueprint xml publish concurrently via > Blueprint Extenders (I find out that by default there is 3 thread of > extenders). > It happens if one extender register the service and another extender > unregister the same service. > In logs I see: > http://pastebin.com/n5A4YeTz > When it happens, services plays hide-and-seek indefinitely. > Aetos 3.0.2.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6984) OAuthJSonProvider mixes expirytime and issuer in writeTokenIntrospection.
[
https://issues.apache.org/jira/browse/CXF-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6984.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.1.8
3.2.0
Thanks for spotting it
> OAuthJSonProvider mixes expirytime and issuer in writeTokenIntrospection.
> -
>
> Key: CXF-6984
> URL: https://issues.apache.org/jira/browse/CXF-6984
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.1.6
>Reporter: Svein Otto Solem
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Checks that Issuer is nonnull but outputs expiry value instead of issuer.
> {code:title=org.apache.cxf.rs.security.oauth2.provider.OAuthJSONProvider.java|borderStyle=solid}
> // From line 116, version 3.1.6
> if (obj.getIss() != null) {
> sb.append(",");
> appendJsonPair(sb, "iss", obj.getExp(), false); // Wrong value, shoud be
> obj.getIss()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6985) parameter state may contain spaces, it must be urlencoded in response.
[ https://issues.apache.org/jira/browse/CXF-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6985. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.1.8 3.2.0 I tried to avoid decoding the request parameters in the 1st place but it can introduce the side-effects with the way redirect and audience URIs are validated and is quite sensitive, so for now it is indeed simpler to follow your suggestion. I'll need to have a closer look at it later on too, thanks > parameter state may contain spaces, it must be urlencoded in response. > -- > > Key: CXF-6985 > URL: https://issues.apache.org/jira/browse/CXF-6985 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.1.6 >Reporter: Svein Otto Solem >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.8 > > > In org.apache.cxf.rs.security.oauth2.services.AbstractImplicitGrantService > the state parameter is not queryEncoded. Since it could contain spaces (as of > RFC 6749 https://tools.ietf.org/html/rfc6749#page-72) it should be > queryEncoded in method finalizeResponse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-6987:
---
Summary: Consider classes attribute of application when using CDI (was:
Consider both CDI managed and not CDI managed beans in CXFCdiServlet)
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans.
> - It ignores classes defined.
> - It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-6987:
---
Description:
CXF's CDI integration integration assumes that all of the components included
will be CDI beans. They either need to be defined as singletons, or picked up
via scanning. If singleton is specified, the classes are ignored.
- It ignores classes defined.
was:
CXF's CDI integration integration assumes that all of the components included
will be CDI beans.
- It ignores classes defined.
- It doesn't handle {{@Vetoed}} beans.
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405042#comment-15405042 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/149 Apologies, as some formatting changes went in as well. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405041#comment-15405041 ] ASF GitHub Bot commented on CXF-6987: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/149 [CXF-6987] Also consider the classees defined on an application when … …singletons are populated. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-6987 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/149.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #149 commit ac209a93df3403424ea2300bd2252d55b65b0836 Author: John D. Ament Date: 2016-08-02T23:49:29Z [CXF-6987] Also consider the classees defined on an application when singletons are populated. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6987: --- Affects Version/s: 3.1.6 > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6986: --- Affects Version/s: 3.1.6 > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405093#comment-15405093 ] ASF GitHub Bot commented on CXF-6986: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/150 [CXF-6986] If no application classes found, install a default applica… …tion. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-6986 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/150.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #150 commit 9fd181a69e7adc314a86613dc7a6a4cc0e8ebabb Author: John D. Ament Date: 2016-08-03T00:34:08Z [CXF-6986] If no application classes found, install a default application. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405094#comment-15405094 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/150 Don't merge - discussion only right now. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405095#comment-15405095
]
ASF GitHub Bot commented on CXF-6987:
-
Github user reta commented on a diff in the pull request:
https://github.com/apache/cxf/pull/149#discussion_r73263806
--- Diff:
integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
---
@@ -179,7 +185,13 @@ private JAXRSServerFactoryBean
createFactoryInstance(final Application applicati
classified.get(Path.class).add(singleton);
}
}
-
+
+// now loop through the classes
+Set> classes = application.getClasses();
+if (!classes.isEmpty()) {
+classified.get(Path.class).addAll(loadServices(beanManager,
classes));
+
classified.get(Provider.class).addAll(loadProviders(beanManager, classes));
--- End diff --
Would you mind to add Feature.class as well? Yeah, it is CXF, not JAX-RS
feature, but it won't hurt to have the same behavior as with singletons. Minor
comment though, leaving choice to you. Thank you.
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.6
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405098#comment-15405098 ] ASF GitHub Bot commented on CXF-6987: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/149 LGTM, thank you. Good one, covers more JAX-RS/CDI scenarios. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405107#comment-15405107
]
ASF GitHub Bot commented on CXF-6987:
-
Github user johnament commented on a diff in the pull request:
https://github.com/apache/cxf/pull/149#discussion_r73264429
--- Diff:
integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
---
@@ -179,7 +185,13 @@ private JAXRSServerFactoryBean
createFactoryInstance(final Application applicati
classified.get(Path.class).add(singleton);
}
}
-
+
+// now loop through the classes
+Set> classes = application.getClasses();
+if (!classes.isEmpty()) {
+classified.get(Path.class).addAll(loadServices(beanManager,
classes));
+
classified.get(Provider.class).addAll(loadProviders(beanManager, classes));
--- End diff --
Shoot, thanks. I actually wrote the code for features, but then removed it
in my formatting clean up.
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.6
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405116#comment-15405116
]
ASF GitHub Bot commented on CXF-6987:
-
Github user johnament commented on a diff in the pull request:
https://github.com/apache/cxf/pull/149#discussion_r73265627
--- Diff:
integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
---
@@ -179,7 +185,13 @@ private JAXRSServerFactoryBean
createFactoryInstance(final Application applicati
classified.get(Path.class).add(singleton);
}
}
-
+
+// now loop through the classes
+Set> classes = application.getClasses();
+if (!classes.isEmpty()) {
+classified.get(Path.class).addAll(loadServices(beanManager,
classes));
+
classified.get(Provider.class).addAll(loadProviders(beanManager, classes));
--- End diff --
Fixed, thanks @reta
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.6
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405132#comment-15405132
]
ASF GitHub Bot commented on CXF-6987:
-
Github user reta commented on a diff in the pull request:
https://github.com/apache/cxf/pull/149#discussion_r73266477
--- Diff:
integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
---
@@ -179,7 +185,13 @@ private JAXRSServerFactoryBean
createFactoryInstance(final Application applicati
classified.get(Path.class).add(singleton);
}
}
-
+
+// now loop through the classes
+Set> classes = application.getClasses();
+if (!classes.isEmpty()) {
+classified.get(Path.class).addAll(loadServices(beanManager,
classes));
+
classified.get(Provider.class).addAll(loadProviders(beanManager, classes));
--- End diff --
:+1: Thanks!
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.6
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6988) Improved test suite for CDI systests
John D. Ament created CXF-6988: -- Summary: Improved test suite for CDI systests Key: CXF-6988 URL: https://issues.apache.org/jira/browse/CXF-6988 Project: CXF Issue Type: Improvement Reporter: John D. Ament The CDI systests assume certain behaviors within tests. They should be a bit more flexible in their supported environments, and not always need to deploy the entire classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405209#comment-15405209 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/149 Restarted jenkins, test failure seems unrelated. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
