[jira] [Closed] (CXF-7881) HttpConduit.handleResponseOnWorkqueue will always handle response on current thread when allowCurrentThread is false and the work queue rejects the execution

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7881.


> HttpConduit.handleResponseOnWorkqueue will always handle response on current 
> thread when allowCurrentThread is false and the work queue rejects the 
> execution
> -
>
> Key: CXF-7881
> URL: https://issues.apache.org/jira/browse/CXF-7881
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Jan Hallonsten
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Creating this Jira according to the discussion 
> [here|http://cxf.547215.n5.nabble.com/Response-always-handled-on-current-thread-when-WorkQueue-rejects-execution-tt5793019.html]
> In the method 
> [org.apache.cxf.transport.http.HTTPConduit.handleResponseOnWorkqueue(boolean 
> allowCurrentThread, boolean 
> forceWQ)|https://github.com/apache/cxf/blob/540bb76f6f3d3d23944c566905f9f395c6f86b79/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java#L1190]
> If the work queue is full so that RejectedExecutionException is thrown and 
> allowCurrentThread is false like when called from 
> [AsyncHttpConduit|https://github.com/apache/cxf/blob/6db38f9984b9c0bf6309a3d7e26d5a9ab8055d1f/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduit.java#L600]
>  the expression in the if statement below will always return false and the 
> response will be handled on the current thread via the call to 
> handleResponseInternal. When used from AsyncHttpConduit this will be the IO 
> core thread which is not a good idea.
> {code:java}
> } catch (RejectedExecutionException rex) {
> if (allowCurrentThread
> && policy != null
> && policy.isSetAsyncExecuteTimeoutRejection()
> && policy.isAsyncExecuteTimeoutRejection()) {
> throw rex;
> }
> if (!hasLoggedAsyncWarning) {
> LOG.warning("EXECUTOR_FULL_WARNING");
> hasLoggedAsyncWarning = true;
> }
> LOG.fine("EXECUTOR_FULL");
> handleResponseInternal();
> }
> {code}
> I think that the code above should be changed to
> {code:java}
> } catch (RejectedExecutionException rex) { 
>  if (!allowCurrentThread 
>  || (policy != null 
>  && policy.isSetAsyncExecuteTimeoutRejection() 
>  && policy.isAsyncExecuteTimeoutRejection())) { 
>  throw rex; 
>  } 
>  if (!hasLoggedAsyncWarning) { 
>  LOG.warning("EXECUTOR_FULL_WARNING"); 
>  hasLoggedAsyncWarning = true; 
>  } 
>  LOG.fine("EXECUTOR_FULL"); 
>  handleResponseInternal(); 
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7864) STS: Expires lifetime is ignored if no lifetime created was specified

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7864.


> STS: Expires lifetime is ignored if no lifetime created was specified
> -
>
> Key: CXF-7864
> URL: https://issues.apache.org/jira/browse/CXF-7864
> Project: CXF
>  Issue Type: Bug
>  Components: STS
>Affects Versions: 3.2.6
>Reporter: Thomas Papke
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> WS-trust define that a `/wst:RequestSecurityToken/wst:Lifetime` can be 
> specified with only having `wsu:Expires`. In that case the creationTime shall 
> be set to the current time. CXF simply ignore the lifetime if either expires 
> or created is not present. (The same also for the other direction - lifetime 
> can be also specified without expires, which is ignored as well)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7831) SocketTimeoutException when previous response was exactly chunk length bytes

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7831.


> SocketTimeoutException when previous response was exactly chunk length bytes
> 
>
> Key: CXF-7831
> URL: https://issues.apache.org/jira/browse/CXF-7831
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Jan Hallonsten
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
> Attachments: Check_endOfStream_before_suspending_input.patch, 
> asyncbugtest.zip
>
>
> When using the Asynchronous Client HTTP Transport we get a SocketTimeout 
> exception when the previous response was exactly the same length as the chunk 
> length by default 16320 bytes.
> After some investigation we have found that the problem is that when the http 
> connection is returned to PoolingNHttpClientConnectionManager the 
> SelectionKey's interestOps does not contain OP_READ. The input gets suspended 
> in SharedInputBuffer when the buffer is full (16320 bytes by default) if this 
> happens at the same time as the endOfStream is reached more input is never 
> requested. We have fixed it locally by adding an endOfStream check before 
> suspending input in SharedInputBuffer. This might not be the correct place to 
> fix it since you could argue that it should not be the responsibility of the 
> user of PoolingNHttpClientConnectionManager to return the http connection in 
> the correct state.
>  
> An example project to reproduce the problem is attached in asyncbugtest.zip 
> and a patch with our fix is in Check_endOfStream_before_suspending_input.patch
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7871) WS-A RelatesTo headers missing in MAPCodec::getUnderstoodHeaders()

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7871.


> WS-A RelatesTo headers missing in MAPCodec::getUnderstoodHeaders()
> --
>
> Key: CXF-7871
> URL: https://issues.apache.org/jira/browse/CXF-7871
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> The getUnderstoodHeaders() methods of MAPCodec returns a static list of 
> headers that is created when loading 
> org.apache.cxf.ws.addressing.soap.VersionTransformer. Such list does not 
> include the RelatesTo headers.
> This issue is actually exposed by having recently applied the fix 
> [https://github.com/apache/cxf/commit/a63a36bc4e151ab9c555304fab383a4624191f51]
> An exception as below ends up being logged in case of required ws-addressing 
> and RelatesTo headers being used:
> {noformat}
> 2018-10-10 23:16:22,252 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] 
> (default-workqueue-1) Interceptor for 
> {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationParticipantService#{http://schemas.arjuna.com/ws/2005/10/wsarjtx}FaultOperation
>  has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: 
> MustUnderstand headers: [{http://www.w3.org/2005/08/addressing}RelatesTo] are 
> not understood.
>     at 
> org.apache.cxf.impl//org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$MustUnderstandEndingInterceptor.handleMessage(MustUnderstandInterceptor.java:282)
>     at 
> org.apache.cxf.impl//org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$MustUnderstandEndingInterceptor.handleMessage(MustUnderstandInterceptor.java:259)
>     at 
> org.apache.cxf@3.2.6//org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>     at 
> org.apache.cxf@3.2.6//org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
>     at 
> org.apache.cxf.impl//org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:319)
>     at 
> org.apache.cxf@3.2.6//org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:421)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>     at 
> org.apache.cxf@3.2.6//org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:346)
>     at java.base/java.lang.Thread.run(Thread.java:834){noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7833) Jetty session manager does not invalidate sessions

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7833.


> Jetty session manager does not invalidate sessions
> --
>
> Key: CXF-7833
> URL: https://issues.apache.org/jira/browse/CXF-7833
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Ales Dolecek
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
> Attachments: test.txt, test.zip
>
>
> When using embedded Jetty with sesssion 
> support:true
> sessions NEVER expire. This creates memory leak that will lead to 
> OutOfMemoryError if the application runs long enough.
> There is also no way to configure Jetty SessionManager - for example set the 
> session timeout.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7775) embedded jetty websocket gets ClassCastException: org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to org.eclipse.jetty.webapp.WebAppContext$Context

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7775.


> embedded jetty websocket gets ClassCastException: 
> org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to 
> org.eclipse.jetty.webapp.WebAppContext$Context
> --
>
> Key: CXF-7775
> URL: https://issues.apache.org/jira/browse/CXF-7775
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.5
>Reporter: Bin
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> After upgrade from jetty 9.2.5.v20141112 to 9.4.11.v20180605 and cxf from 
> v3.1.5 to v3.2.5, the websocket server code used to work, now getting 
> ClassCastException:
>  
> 17:08:07.810 [qtp1128117613-31] WARN  org.eclipse.jetty.server.HttpChannel 
> [HttpChannel.java:573] [] - /websocket/
> java.lang.ClassCastException: 
> org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to 
> org.eclipse.jetty.webapp.WebAppContext$Context
>     at 
> org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.getServer(Jetty9WebSocketDestination.java:125)
>     at 
> org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.getWebSocketFactory(Jetty9WebSocketDestination.java:132)
>     at 
> org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.invoke(Jetty9WebSocketDestination.java:102)
>     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:216)
>     at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
>     at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
>     at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
>     at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at org.eclipse.jetty.server.Server.handle(Server.java:531)
>     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
>     at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>     at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
>     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
>     at 
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291)
>     at 
> org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151)
>     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
>     at 
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>     at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>     at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>     at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>     at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>     at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>     at 
> org.eclipse.jetty.util.thread.QueuedThrea

[jira] [Closed] (CXF-7860) JAX-RS @FormParam parameters are not updated when form content is modified

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7860.


> JAX-RS @FormParam parameters are not updated when form content is modified
> --
>
> Key: CXF-7860
> URL: https://issues.apache.org/jira/browse/CXF-7860
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> The JAX-RS community noticed a difference in behavior between CXF and 
> Jersey/RESTEasy where form data in the HTTP body is modified prior to 
> invoking the resource method.  There are two differences noted:
> 1) CXF does not invoke a MessageBodyReader (or any ReaderInterceptors) when 
> there is no entity parameter.  I believe that this is proper behavior - or at 
> least an appropriate optimization since there is no parameter, why bother 
> creating one with a MBR (and it's associated ReaderInterceptors)?  
> 2) When the resource method contains both a Form parameter (entity) _and_ a 
> parameter annotated with `@FormParam`, and a Filter or interceptor, etc. has 
> modified the content of of the HTTP body, the value injected for the 
> `@FormParam` parameter does not reflect those modifications, but the Form 
> entity parameter does.  This seems inconsistent, and (IMO) violates the 
> spirit of the spec - note that there is no TCK test for this case, so CXF is 
> still compliant - but it differs from other implementations.  Here is an 
> example:
>  
>  
> {code:java}
> @Provider
> public class FormReaderInterceptor implements ReaderInterceptor {
>     private static final Logger LOG = 
> LogUtils.getL7dLogger(FormReaderInterceptor.class);
>     @Override
>     public Object aroundReadFrom(ReaderInterceptorContext ctx) throws 
> IOException, WebApplicationException {
>         BufferedReader br = new BufferedReader(new 
> InputStreamReader(ctx.getInputStream()));
>         String line;
>         while ((line = br.readLine()) != null) {
>             LOG.info("readLine: " + line);
>         }
>         ByteArrayInputStream bais = new 
> ByteArrayInputStream("value=MODIFIED".getBytes());
>         ctx.setInputStream(bais);
>         return ctx.proceed();
>     }
> }
> {code}
>  
> {code:java}
>     @POST
>     public Response processForm(@FormParam("value") String value, Form form) 
> {...
>  {code}
>  
> If the HTTP request body contains "value=ORIGINAL", then when CXF invokes the 
> processForm method, it will pass "ORIGINAL" to the String value, but will 
> pass a Form object that contains a MultivaluedMap with entry 
> "value=MODIFIED".  To be consistent with Jersey and RESTEasy, CXF should 
> inject MODIFIED as the String value.
>  
> See JAX-RS API [Issue 
> 659|https://github.com/eclipse-ee4j/jaxrs-api/issues/659] for more details.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7836) Stax2 version conflict

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7836.


> Stax2 version conflict
> --
>
> Key: CXF-7836
> URL: https://issues.apache.org/jira/browse/CXF-7836
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.2.6
>Reporter: Michal Sabo
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> There is a version conflict in transitive dependencies of cxf regarding the 
> stax2 api.
> cxf-rt-ws-policy uses the org.apache.neethi library, which is dependant on a 
> version *3.1.1* of stax2 api, however cxf-core and its dependency 
> com.fasterxml.woodstox uses a version *4.1* of stax2 api. Unfortunately, 
> these versions are not compatible - java.lang.NoSuchMethodError: 
> org.codehaus.stax2.ri.EmptyIterator.getInstance()Lorg/codehaus/stax2/ri/EmptyIterator;
> Dependency resolution and the conflicting part on the last line.
> {code:java}
> +--- org.apache.cxf:cxf-rt-frontend-jaxws:3.2.6
> | +--- xml-resolver:xml-resolver:1.2
> | +--- org.ow2.asm:asm:5.2
> | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | +--- org.apache.cxf:cxf-rt-bindings-soap:3.2.6
> | | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | | +--- org.apache.cxf:cxf-rt-wsdl:3.2.6
> | | | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | | | +--- wsdl4j:wsdl4j:1.6.3
> | | | \--- org.ow2.asm:asm:5.2
> | | \--- org.apache.cxf:cxf-rt-databinding-jaxb:3.2.6
> | | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | | \--- org.apache.cxf:cxf-rt-wsdl:3.2.6 (*)
> | +--- org.apache.cxf:cxf-rt-bindings-xml:3.2.6
> | | \--- org.apache.cxf:cxf-core:3.2.6 (*)
> | +--- org.apache.cxf:cxf-rt-frontend-simple:3.2.6
> | | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | | +--- org.apache.cxf:cxf-rt-bindings-soap:3.2.6 (*)
> | | \--- org.apache.cxf:cxf-rt-wsdl:3.2.6 (*)
> | \--- org.apache.cxf:cxf-rt-ws-addr:3.2.6
> | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | +--- org.apache.cxf:cxf-rt-bindings-soap:3.2.6 (*)
> | \--- org.apache.cxf:cxf-rt-ws-policy:3.2.6
> | +--- wsdl4j:wsdl4j:1.6.3
> | +--- org.apache.cxf:cxf-core:3.2.6 (*)
> | \--- org.apache.neethi:neethi:3.1.1
> | \--- org.codehaus.woodstox:woodstox-core-asl:4.4.1
> | +--- javax.xml.stream:stax-api:1.0-2
> | \--- org.codehaus.woodstox:stax2-api:3.1.4 -> 4.1
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7854) Refactor RxJava2 Flowable and Observable Rx Invokers to not use internal APIs.

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7854.


> Refactor RxJava2 Flowable and Observable Rx Invokers to not use internal APIs.
> --
>
> Key: CXF-7854
> URL: https://issues.apache.org/jira/browse/CXF-7854
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6
>Reporter: John Koehler
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Customers wanting to use reactive extensions may want to package their own 
> version of RxJava2 with their application.  The use of internal APIs may 
> cause class loading problems.  
>  Caused by: java.lang.NoClassDefFoundError: 
> org/apache/cxf/jaxrs/client/SyncInvokerImpl
> at 
> org.apache.cxf.jaxrs.rx2.client.FlowableRxInvokerProvider.getRxInvoker(FlowableRxInvokerProvider.java:37)
>   at 
> org.apache.cxf.jaxrs.rx2.client.FlowableRxInvokerProvider.getRxInvoker(FlowableRxInvokerProvider.java:29)
>   at org.apache.cxf.jaxrs.client.WebClient.rx(WebClient.java:1286)
>   at 
> org.apache.cxf.jaxrs.client.spec.InvocationBuilderImpl.rx(InvocationBuilderImpl.java:402)
>  
> FlowableRxInvokerProvider uses org.apache.cxf.jaxrs.client.SyncInvokerImpl. 
> FlowableRxInvokerImpl uses org.apache.cxf.jaxrs.client.WebClient.
> ObservableRxInvokerProvider uses org.apache.cxf.jaxrs.client.SyncInvokerImpl.
> ObservableRxInvokerImpl uses org.apache.cxf.jaxrs.client.WebClient.
> These classes need to be refactored. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7868) MP Rest Client does not honor providers registered via MP Config

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7868.


> MP Rest Client does not honor providers registered via MP Config
> 
>
> Key: CXF-7868
> URL: https://issues.apache.org/jira/browse/CXF-7868
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> The MP Rest Client spec says that I should be able to specify providers via 
> MP Config using comma-separated provider class names with the config key of 
> {{/mp-rest/providers}}. It also specifies that provider 
> priorities can be set using MP Config with the config key of 
> {{/mp-rest/providers//priority}}.
> Neither of these properties have any effect in CXF.
> Note that the MP Rest Client spec mentions this requirement for implementors, 
> but does not currently test it in the TCK - this is being addressed in MP 
> Rest Client Issue 
> [126|https://github.com/eclipse/microprofile-rest-client/issues/126].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7838) Remove illegal reflective access in ReflectionUtil

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7838.


> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
>  Issue Type: Task
>Reporter: Tim Allison
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache 
> Tika, and we're still getting the following when we run our unit tests with 
> Java 11.
> {quote}Illegal reflective access by 
> org.apache.cxf.common.util.ReflectionUtil$11 
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
>  to field java.net.Authenticator.theAuthenticator
>  WARNING: Please consider reporting this to the maintainers of 
> org.apache.cxf.common.util.ReflectionUtil$11
>  WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> {quote}
> Let us know if you need more info to solve this.  Thank you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7829) Use Spring Boot autoconfigure-processor to optimize auto-configurations

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7829.


> Use Spring Boot autoconfigure-processor to optimize auto-configurations
> ---
>
> Key: CXF-7829
> URL: https://issues.apache.org/jira/browse/CXF-7829
> Project: CXF
>  Issue Type: Improvement
>Reporter: Stephane Nicoll
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> As explained in [the its reference 
> documentation|https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc#autoconfigure-module],
>  Spring Boot provides a {{spring-boot-autoconfigure-processor}}.
> This should be added as an optional dependency to each module that contains 
> AutoConfiguration classes (and the `spring.factories` file declaring them).
> Once configured, this annotation processor will generate metadata at compile 
> time and will help Spring Boot process those auto-configurations without 
> loading the actual classes in some cases.
> In this project, {{cxf-spring-boot-autoconfigure}} looks the only candidate. 
> Could you add it to the pom?
> {code:xml}
> 
>  org.springframework.boot
>  spring-boot-autoconfigure-processor
>  true
> 
> {code}
> Once added, this should generate a 
> {{spring-autoconfigure-metadata.properties}} file in the 
> {{target/classes/META-INF}} folder of earch module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-5077) Provide a way to define a specific SSLContext to be used by HTTPConduit implementations

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-5077.


> Provide a way to define a specific SSLContext to be used by HTTPConduit 
> implementations
> ---
>
> Key: CXF-5077
> URL: https://issues.apache.org/jira/browse/CXF-5077
> Project: CXF
>  Issue Type: New Feature
>  Components: Configuration, Transports
>Affects Versions: 2.7.5
>Reporter: Aymeric Levaux
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> For HTTPConduit impl it would be useful to have the possibility to use a 
> specific SSLContext. It's specifically useful for the AsynHttpConduit where a 
> specific SSLSocketFactory cannot be used. 
> See CXF-5071 for context.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7827) shouldn't log JMS password from JMS address when using JMS transport

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7827.


> shouldn't log JMS password from JMS address when using JMS transport
> 
>
> Key: CXF-7827
> URL: https://issues.apache.org/jira/browse/CXF-7827
> Project: CXF
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> some times when users configure JMS address with password, we can see log like
> {code}
> Setting the server's publish address to be 
> jms:queue:soapRequestQueue?username=admin&password=admin123.
> {code}
> we better not print out password in the log



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7332) JAXRS Client API doesnt support lambda

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7332.


> JAXRS Client API doesnt support lambda
> --
>
> Key: CXF-7332
> URL: https://issues.apache.org/jira/browse/CXF-7332
> Project: CXF
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> {code}
> final Client client = ClientBuilder.newClient()
> .register(new ClientRequestFilter() {
> @Override
> public void filter(final ClientRequestContext 
> requestContext) throws IOException {
> requestContext.getHeaders().put("Authorization", 
> singletonList(""));
> }
> });
> {code}
> this code works but if you migrate as allowed by java 8 to filter to a lambda 
> then cxf doesnt identify the type properly and bypass it



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7883.


> Handle connectionRequestTimeout in AsyncHTTPConduitFactory
> --
>
> Key: CXF-7883
> URL: https://issues.apache.org/jira/browse/CXF-7883
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Györgyey Tamás
>Assignee: Freeman Fang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.2.7, 3.3.0
>
>
> This issue is a follow-up to CXF-7878.
> If connections are contended towards a slow target, it may make sense
>  to set connectionTimeout and connectionRequestTimeout to values much lower 
> than
>  the receiveTimeout. Expected client behavior is to receive an error if a 
> connection
>  does not become available within connectionRequestTimeout. Current behavior 
> however
>  is that the error is only received after up to receiveTimeout has passed, 
> when a
>  current request to the target has finished and the connection is released or 
> returned
>  to the pool.
> This causes a possible build-up of pending requests in memory for the 
> duration of receiveTimeout instead of connectionRequestTimeout.
> See github PR: [https://github.com/apache/cxf/pull/466]
> The reference solution in the PR works well, but it may not be the most 
> elegant one due to my currently limited understanding of the overall design 
> of the connection handling code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7832) WrappedMessageContext containsKey not consistent with get/put

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7832.


> WrappedMessageContext containsKey not consistent with get/put
> -
>
> Key: CXF-7832
> URL: https://issues.apache.org/jira/browse/CXF-7832
> Project: CXF
>  Issue Type: Bug
>Reporter: Jimmy Praet
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0, 3.1.18
>
>
> In {{WrappedMessageContext.get()}} and {{put()}} some extra key translations 
> happen, that are not applied in {{WrappedMessageContext.containsKey()}}.
> For example {{MessageContext.HTTP_REQUEST_HEADERS}} is translated to 
> {{Message.PROTOCOL_HEADERS}} 
> [here|https://github.com/apache/cxf/blob/782d565f896bc996631c2b092580a116bd65c1e2/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/context/WrappedMessageContext.java#L238],
>  but not in {{containsKey()}}.
> So {{context.get(MessageContext.HTTP_REQUEST_HEADERS)}} may return a map with 
> headers, while {{context.containsKey(MessageContext.HTTP_REQUEST_HEADERS)}} 
> returns false.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7870) JAXRSUtils referenced in AbstractBraveClientProvider

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7870.


> JAXRSUtils referenced in AbstractBraveClientProvider
> 
>
> Key: CXF-7870
> URL: https://issues.apache.org/jira/browse/CXF-7870
> Project: CXF
>  Issue Type: Bug
>  Components: Tracing Brave
>Affects Versions: 3.2.6
>Reporter: sarasota7
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.2.7, 3.3.0, 3.1.18
>
>
> Hello, 
> We are using cxf for its web service (WS) components (not RS), along with 
> brave tracing, i.e., 
> cxf-rt-frontend-jaxws
> cxf-rt-transports-http
> cxf-core
> cxf-rt-ws-policy . and
> cxf-integration-tracing-brave.
> When the call stack references AbstractBraveClientProvider (from  an 
> instantiation of BraveClientFeature, which is used on the WS side), a 
> "java.lang.NoClassDefFoundError" error is thrown because of a missing  
> org/apache/cxf/jaxrs/utils/JAXRSUtils.  
> If we include a jar that has JAXRSUtils, then we run into a bunch of catch 22 
> situations with the whole RS side of things.  Did you really intend to 
> include JAXRSUtils in the AbstractBraveClientProvider class?  From the 
> documentation, it looks like BraveClientFeature is only to be used on the WS 
> side, and not the RS side, unless I'm missing something.
> [http://cxf.apache.org/docs/using-openzipkin-brave.html]
>  
> Thanks
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7820) CXF BOM (cxf-parent) references non existing artifact (io.netty:netty:4.x)

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7820.


> CXF BOM (cxf-parent) references non existing artifact (io.netty:netty:4.x)
> --
>
> Key: CXF-7820
> URL: https://issues.apache.org/jira/browse/CXF-7820
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.2.5, 3.2.6
>Reporter: Erik Godding Boye
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>  Labels: maven
> Fix For: 3.2.7
>
>
> The cxf parent (cxf-parent) includes dependency management for 
> io.netty:netty. This artifact was moved/relocated to io.netty:netty-all in 
> version 4 of Netty. So the io.netty:netty artifact does not exist in version 
> > 4. Still the dependency management entry refers to the version property 
> cxf.netty.version, with version > 4.
> This bug makes cxf-parent invalid as a BOM (ref CXF-7750).
> I see two potential solutions to this:
>  # Delete the dependency management for io.netty:netty
>  # Change version of io.netty:netty to the version property cxf.netty3.version



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7869) Infinite loop in rest client

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7869.


> Infinite loop in rest client
> 
>
> Key: CXF-7869
> URL: https://issues.apache.org/jira/browse/CXF-7869
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6, 3.1.17
>Reporter: François Courtault
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> Hello,
> During stress tests, we found several threads with this pattern:
>       java.lang.Thread.State: RUNNABLE
>           at java.util.WeakHashMap.put(WeakHashMap.java:453)
>           at java.util.Collections$SetFromMap.add(Collections.java:5461)
>           at 
> org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.initTargetClientIfNeeded(ClientImpl.java:358)
> This same issue has been found by others:
> [http://www.adam-bien.com/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap]
> Best regards.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7853) Spring Boot autoconfiguration should automatically set OpenApiCustomizer if OpenApiFeature is configured

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7853.


> Spring Boot autoconfiguration should automatically set OpenApiCustomizer if 
> OpenApiFeature is configured
> 
>
> Key: CXF-7853
> URL: https://issues.apache.org/jira/browse/CXF-7853
> Project: CXF
>  Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Adding *OpenApiAutoConfiguration* to automatically provide instance of the 
> *OpenApiCustomizer* (with *dynamicBasePath* set to *true*). This instance is 
> being injected into every discovered *OpenApiFeature* bean (in case it has no 
> customizer specified) by *OpenApiFeatureBeanPostProcessor*. For typical 
> Spring Boot project, this is what you may need most of the time.
> In case there is an instance of the *OpenApiCustomizer* bean, it is going to 
> be used for injection. If *OpenApiFeature* bean already has a customizer, the 
> auto-cofiguration has no effect.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7882) FailoverTargetSelector uses the Exchange as the key in the inProgress map

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7882.


> FailoverTargetSelector uses the Exchange as the key in the inProgress map
> -
>
> Key: CXF-7882
> URL: https://issues.apache.org/jira/browse/CXF-7882
> Project: CXF
>  Issue Type: Task
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> The FailoverTargetSelector uses the Exchange as the key in the inProgress 
> map. However this is unnecessary as we can instead just use the 
> System.identityHashCode of the exchange instead as the key, meaning that we 
> are only using a String as the key in the map instead of the entire exchange.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7824) CacheMap may have spurious null keys

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7824.


> CacheMap may have spurious null keys
> 
>
> Key: CXF-7824
> URL: https://issues.apache.org/jira/browse/CXF-7824
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.2.6
>Reporter: Michał Pachucki
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Hello,
> I was debugging a bug in my code and by accident I found a bug in CacheMap.
>  
> The function updateMainDataMap copies elements from extraKeyMap to 
> mainDataMap but does not make sure that keys are not null.
> It is possible that entrySet of WeakIdentityHashMap will return null keys.
> {code:java}
> public Set> entrySet() {
> reap();
> Set> ret = new HashSet>();
> for (Map.Entry ref : backingStore.entrySet()) {
> final K key = ref.getKey().get(); //possible null here
> final V value = ref.getValue();
> Map.Entry entry = new Map.Entry() {
> public K getKey() {
> return key;
> }
> public V getValue() {
> return value;
> }
> public V setValue(V value) {
> throw new UnsupportedOperationException();
> }
> };
> ret.add(entry);
> }
> return Collections.unmodifiableSet(ret);
> }{code}
> On entrance the function clears all null keys (in the reap() functon) and 
> then iterates over backingStore. But it is possible that after reap() a key 
> is garbage collected and its WeakReference will return null 
> (ref.getKey().get()).
> This causes a spurious null key.
>  
> I gave this case a Major priority because this class is used by 
> WSDLManagerImpl, and spurious null keys cause serious problems there. I can 
> reproduce this problem in a few minutes of testing. The testcase consists of 
> creating generated service over and over again by multiple threads. 
> Unfortunately the testcase itself is too big to share.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7847) DOMUtils init failed with IBM JDK

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7847.


> DOMUtils init failed with IBM JDK 
> --
>
> Key: CXF-7847
> URL: https://issues.apache.org/jira/browse/CXF-7847
> Project: CXF
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7858) Base64 empty string encoding issue

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7858.


> Base64 empty string encoding issue
> --
>
> Key: CXF-7858
> URL: https://issues.apache.org/jira/browse/CXF-7858
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.2.6
>Reporter: Andriy Mahats
>Assignee: Colm O hEigeartaigh
>Priority: Blocker
> Fix For: 3.2.7, 3.1.18
>
>
> {code:java}
> char[] chunk = Base64Utility.encodeChunk("".getBytes(), 0, 0, true); // chunk 
>  = null after evaluation
> {code}
> According to [https://tools.ietf.org/html/rfc4648#section-10]
> h2. [10|https://tools.ietf.org/html/rfc4648#section-10]. Test Vectors
>  
>  BASE64("") = ""
>  
> {code:java}
> // later it evaluates to null
> //org.apache.cxf.common.util.Base64UrlUtility#encodeChunk
>  public static String encodeChunk(byte[] id, int offset, int length) {
> char[] chunk = Base64Utility.encodeChunk(id, offset, length, true);
> return chunk != null ? new String(chunk) : null;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7808) Ensure org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod logs an error

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7808.


> Ensure org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod logs an 
> error
> --
>
> Key: CXF-7808
> URL: https://issues.apache.org/jira/browse/CXF-7808
> Project: CXF
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.2.7
>
>
> Currently org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod 
> doesn't log an error message which means you have a 500 and a big stack trace 
> but not the cause so it is very hard for end users to understand what happens 
> without debugging the internals.
> Would be great to have a log error happening in such a case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7826) Make it possible to configure Swagger UI features

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7826.


> Make it possible to configure Swagger UI features
> -
>
> Key: CXF-7826
> URL: https://issues.apache.org/jira/browse/CXF-7826
> Project: CXF
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Markus Svensson
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.2.7, 3.3.0
>
>
> I use the Swagger2Feature in Apache CXF to provide Swagger documentation for 
> our API. Swagger UI is provided as a Maven dependency via WebJars.
> I would like to configure some Swagger UI properties (as documented 
> [here|https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/configuration.md]),
>  for example validatiorUrl.
> It would be neat to be able to configure these settings via the 
> OpenApiFeature and/or Swagger2Feature configuration.
>  
> The current workaround for me is to build my own Swagger UI dependency 
> including the configuration options I need.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7875) ServiceList doesn't use proper bus to query if swagger/wadl is available.

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7875.


> ServiceList doesn't use proper bus to query if swagger/wadl is available.
> -
>
> Key: CXF-7875
> URL: https://issues.apache.org/jira/browse/CXF-7875
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Daniel Kulp
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.2.7
>
>
> The FormattedServiceListWriter always uses the bus of the service list to 
> query if swagger and wadl are available.  However, for swagger in particular, 
> those could be features registered on the bus that created the service 
> itself.   Thus, the links do not show properly. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7878) ClientPolicyCalculator ignores ConnectionRequestTimeout property

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7878.


> ClientPolicyCalculator ignores ConnectionRequestTimeout property
> 
>
> Key: CXF-7878
> URL: https://issues.apache.org/jira/browse/CXF-7878
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Györgyey Tamás
>Assignee: Colm O hEigeartaigh
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.2.7
>
>
> ClientPolicyCalculator#intersect() drops the value set with 
> setConnectionRequestTimeout() from the returned policy. As a result, 
> AsyncHttpConduit always uses the default value even if it is explicitly set 
> by the user through a HTTPClientPolicy.
> PR on GitHub: https://github.com/apache/cxf/pull/460



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7076) Intermittent failure in WSDL cache

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7076.


> Intermittent failure in WSDL cache
> --
>
> Key: CXF-7076
> URL: https://issues.apache.org/jira/browse/CXF-7076
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime, Services
>Affects Versions: 3.1.1
> Environment: Oracle JDK 1.8.0_91
> Tomcat 8.0.23
>Reporter: Marco Stettler
>Priority: Blocker
> Fix For: 3.2.7, 3.3.0
>
>
> We have an error in the production environment that we can't reproduce 
> locally. The error:
> {quote}
> Caused by: org.apache.cxf.wsdl11.WSDLRuntimeException: Part parameters 
> defined as element http://mynamespace MyService which is not in the schema.
>   at 
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.java:886)
>   at 
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServiceBuilder.java:615)
>   at 
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder.java:593)
>   at 
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:353)
>   at 
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:209)
>   at 
> org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:162)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:405)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:525)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
>   at 
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
>   at 
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
>   at 
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:157)
>   at 
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
>   at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:493)
>   at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:359)
>   at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:350)
>   at javax.xml.ws.Service.getPort(Service.java:119)
>   at ch.mynamespace.MyService.getMyService()
> {quote}
> It looks like the WSDLManagerImpl gives not the correct cached 
> SchemaCollection for the Service. Following the code for creating the client:
> {quote}
> private static final URL WSDL_RESOURCE = 
> MyTest.class.getClassLoader().getResource("/wsdl/MyService.wsdl");
> ...
>   MyServicePort  myServicePort = new 
> MyService(WSDL_RESOURCE).getMyService();
> {quote}
> This runs per invocation. We are on a webservice intermediate, so its 
> possible to run in some sort of concurrency problem. As mentioned before, the 
> error occours intermittent (about every 2 weeks). We are speaking about some 
> load, but not that heavy (about 15k requests per day).
> I think it could be the same as there:
> https://issues.jboss.org/browse/JBWS-3973
> I'll inform if I have updates. As the production environment is involved, i 
> have to investigate and must have a solution as quick as possible.
> Thanks
> Marco



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7810) SAML Assertion Cookie persistence - configurable to not persist across browser restarts

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7810.


> SAML Assertion Cookie persistence - configurable to not persist across 
> browser restarts
> ---
>
> Key: CXF-7810
> URL: https://issues.apache.org/jira/browse/CXF-7810
> Project: CXF
>  Issue Type: Test
>  Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Ramprasad
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
> Attachments: cxf-config.xml, output.txt
>
>
> In AbstractSSOSpHandler -> createCookie ->
> There is specific code to have cookie persist across browser restarts.
> Pasted Below: 
> 
> // Keep the cookie across the browser restarts until it actually expires.
> // Note that the Expires property has been deprecated but apparently 
> is
> // supported better than 'max-age' property by different browsers
> // (Firefox, IE, etc)
> Instant expires = Instant.ofEpochMilli(System.currentTimeMillis() + 
> stateTimeToLive);
> String cookieExpires =
> 
> HttpUtils.getHttpDateFormat().format(Date.from(expires.atZone(ZoneOffset.UTC).toInstant()));
> contextCookie += ";Expires=" + cookieExpires;
> 
> We are using Apache CXF for web sso to integrate with our IDP and have a 
> security issue with having the cookie persist when browser exits. Is there a 
> configuration or different way to remove cookie when the browser is closed? 
> Not all of our users will use logout to sign-off, they will just close the 
> browser.
> Please let me know.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7874) JAX-RS SSE Leaking SSESink (s)

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7874.


> JAX-RS SSE Leaking SSESink (s)
> --
>
> Key: CXF-7874
> URL: https://issues.apache.org/jira/browse/CXF-7874
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6
> Environment: Observed on karaf (jetty).
> Reproduced on jetty by modifying cxf SSE tests.
>Reporter: Lukasz Wysocki
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
> Attachments: cxf-7874.reproduce.patch
>
>
> Closing of SSE connection by client is not detected and handled on the server 
> part.
> This results in server leaking resources when it is the clients 
> responsibility for deciding on the lifetime of SSE connection.
> My particular scenario is:
> Status notifications for devices manged by the server are sent to the client 
> (browser), this is a continues stream. That stream lives until browser 
> tab/window is closed, which results in client closing the underlying SSE 
> connection.
> SseSinkImpl is not informed of connection being closed. 
> At the same time the exception set in  
> org.apache.cxf.jaxrs.sse.SseEventSinkImpl#dequeue 
> {code}future.completeExceptionally(ex);{code} in case of channel being closed 
> is not acted upon internally within SseSinkImpl.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7656) Add jackson in the cxf-jaxrs feature

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7656.


> Add jackson in the cxf-jaxrs feature
> 
>
> Key: CXF-7656
> URL: https://issues.apache.org/jira/browse/CXF-7656
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS, OSGi
>Reporter: Jean-Baptiste Onofré
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> For convenience,  it would be great that the {{cxf-jaxrs}} feature installs 
> jackson bundles. It's a classic use case to  define the Jackson provider when 
> using JAXRS.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CXF-7865) Enable default ciphersuites exclusion filter

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-7865.


> Enable default ciphersuites exclusion filter
> 
>
> Key: CXF-7865
> URL: https://issues.apache.org/jira/browse/CXF-7865
> Project: CXF
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7
>
>
> The default ciphersuites exclusion filter is not working properly. From 3.2.7 
> it will exclude NULL, anon and EXPORT ciphersuites by default, if no 
> exclusion filter is specified.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (CXF-7576) ws-security enonce ecache einstance data not found

2018-10-30 Thread Vinay Khatri (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinay Khatri updated CXF-7576:
--
Comment: was deleted

(was: This is mostly on multiple server instances. Where request is initiated 
by a server instance(and some file is stored in tmp folder), and due to load 
balancing the response is handled by another server instance. Since a file 
stored on initiator node is not available here fileNotFoundException occurs.)

> ws-security enonce ecache einstance data not found
> --
>
> Key: CXF-7576
> URL: https://issues.apache.org/jira/browse/CXF-7576
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 3.1.6
>Reporter: Soumya Panda
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> _Hi Team,
> We are seeing a weird issue. It was working fine and nothing change but now 
> it started failing with  below error :
> _
> _{color:red}net.sf.ehcache.CacheException: java.io.FileNotFoundException: 
> /tmp/cxf745201861/ws-security%002enonce%002ecache%002einstance-
> {color}_1663277296.data (No such file or directory)
> at 
> net.sf.ehcache.store.disk.DiskStorageFactory.(DiskStorageFactory.java:146)
> at net.sf.ehcache.store.disk.DiskStore.create(DiskStore.java:154)
> at 
> net.sf.ehcache.store.disk.DiskStore.createCacheStore(DiskStore.java:182)
> at net.sf.ehcache.Cache.initialise(Cache.java:1199)
> at 
> net.sf.ehcache.CacheManager.initializeEhcache(CacheManager.java:1370)
> at net.sf.ehcache.CacheManager.addCacheNoCheck(CacheManager.java:1436)
> at 
> net.sf.ehcache.CacheManager.addCacheIfAbsent(CacheManager.java:1936)
> at 
> org.apache.wss4j.common.cache.EHCacheReplayCache.(EHCacheReplayCache.java:54)
> at 
> org.apache.cxf.ws.security.cache.CXFEHCacheReplayCache.(CXFEHCacheReplayCache.java:37)
> at 
> org.apache.cxf.ws.security.wss4j.WSS4JUtils.getReplayCache(WSS4JUtils.java:124)
> at 
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getReplayCache(WSS4JInInterceptor.java:776)
> at 
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.configureReplayCaches(WSS4JInInterceptor.java:413)
> at 
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:249)
> at 
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:184)
> at 
> com.sbc.cc.clarify.api.util.cxf.interceptors.security.WebInInterceptor.handleMessage(WebInInterceptor.java:60)
> at 
> com.sbc.cc.clarify.api.util.cxf.interceptors.security.WebInInterceptor.handleMessage(WebInInterceptor.java:19)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
> at 
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:234)
> at 
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1065)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:798)
> _{color:red}Caused by:
> java.io.FileNotFoundException: 
> /tmp/cxf745201861/ws-security%002enonce%002ecache%002einstance-1663277296.data
>  (No such file or directory){color}_
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(RandomAccessFile.java:253)
> at 
> net.sf.ehcache.store.disk.DiskStorageFactory.allocateRandomAccessFiles(DiskStorageFactory.java:207)
> at 
> net.sf.ehcache.store.disk.DiskStorageFactory.(DiskStorageFactory.java

[jira] [Commented] (CXF-7838) Remove illegal reflective access in ReflectionUtil

2018-10-30 Thread Tim Allison (JIRA) 


[ 
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668782#comment-16668782
 ] 

Tim Allison commented on CXF-7838:
--

Thank you for fixing this!

> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
>  Issue Type: Task
>Reporter: Tim Allison
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.7, 3.3.0
>
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache 
> Tika, and we're still getting the following when we run our unit tests with 
> Java 11.
> {quote}Illegal reflective access by 
> org.apache.cxf.common.util.ReflectionUtil$11 
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
>  to field java.net.Authenticator.theAuthenticator
>  WARNING: Please consider reporting this to the maintainers of 
> org.apache.cxf.common.util.ReflectionUtil$11
>  WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> {quote}
> Let us know if you need more info to solve this.  Thank you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CXF-7869) Infinite loop in rest client

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated CXF-7869:
-
Fix Version/s: 3.1.18

> Infinite loop in rest client
> 
>
> Key: CXF-7869
> URL: https://issues.apache.org/jira/browse/CXF-7869
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6, 3.1.17
>Reporter: François Courtault
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7, 3.1.18
>
>
> Hello,
> During stress tests, we found several threads with this pattern:
>       java.lang.Thread.State: RUNNABLE
>           at java.util.WeakHashMap.put(WeakHashMap.java:453)
>           at java.util.Collections$SetFromMap.add(Collections.java:5461)
>           at 
> org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.initTargetClientIfNeeded(ClientImpl.java:358)
> This same issue has been found by others:
> [http://www.adam-bien.com/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap]
> Best regards.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CXF-7869) Infinite loop in rest client

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


[ 
https://issues.apache.org/jira/browse/CXF-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668997#comment-16668997
 ] 

Colm O hEigeartaigh commented on CXF-7869:
--

It's fixed for 3.1.18 now as well. CXF 3.2.7 is released - I'm not sure when we 
will release CXF 3.1.18.

> Infinite loop in rest client
> 
>
> Key: CXF-7869
> URL: https://issues.apache.org/jira/browse/CXF-7869
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.6, 3.1.17
>Reporter: François Courtault
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.7, 3.1.18
>
>
> Hello,
> During stress tests, we found several threads with this pattern:
>       java.lang.Thread.State: RUNNABLE
>           at java.util.WeakHashMap.put(WeakHashMap.java:453)
>           at java.util.Collections$SetFromMap.add(Collections.java:5461)
>           at 
> org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.initTargetClientIfNeeded(ClientImpl.java:358)
> This same issue has been found by others:
> [http://www.adam-bien.com/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap]
> Best regards.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory

2018-10-30 Thread ASF GitHub Bot (JIRA) 


[ 
https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669137#comment-16669137
 ] 

ASF GitHub Bot commented on CXF-7883:
-

coheigea commented on issue #466: [CXF-7883] fix: handle 
connectionRequestTimeout in AsyncHTTPConduitFactory
URL: https://github.com/apache/cxf/pull/466#issuecomment-434410504
 
 
   @gyoetam We just released 3.2.7, so 3.2.8 will about 2 months away probably. 
We hope to release 3.3.0 before then though, maybe in around 5/6 weeks.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Handle connectionRequestTimeout in AsyncHTTPConduitFactory
> --
>
> Key: CXF-7883
> URL: https://issues.apache.org/jira/browse/CXF-7883
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Györgyey Tamás
>Assignee: Freeman Fang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.2.7, 3.3.0
>
>
> This issue is a follow-up to CXF-7878.
> If connections are contended towards a slow target, it may make sense
>  to set connectionTimeout and connectionRequestTimeout to values much lower 
> than
>  the receiveTimeout. Expected client behavior is to receive an error if a 
> connection
>  does not become available within connectionRequestTimeout. Current behavior 
> however
>  is that the error is only received after up to receiveTimeout has passed, 
> when a
>  current request to the target has finished and the connection is released or 
> returned
>  to the pool.
> This causes a possible build-up of pending requests in memory for the 
> duration of receiveTimeout instead of connectionRequestTimeout.
> See github PR: [https://github.com/apache/cxf/pull/466]
> The reference solution in the PR works well, but it may not be the most 
> elegant one due to my currently limited understanding of the overall design 
> of the connection handling code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated CXF-7883:
-
Fix Version/s: (was: 3.2.7)
   3.2.8

> Handle connectionRequestTimeout in AsyncHTTPConduitFactory
> --
>
> Key: CXF-7883
> URL: https://issues.apache.org/jira/browse/CXF-7883
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.6
>Reporter: Györgyey Tamás
>Assignee: Freeman Fang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.3.0, 3.2.8
>
>
> This issue is a follow-up to CXF-7878.
> If connections are contended towards a slow target, it may make sense
>  to set connectionTimeout and connectionRequestTimeout to values much lower 
> than
>  the receiveTimeout. Expected client behavior is to receive an error if a 
> connection
>  does not become available within connectionRequestTimeout. Current behavior 
> however
>  is that the error is only received after up to receiveTimeout has passed, 
> when a
>  current request to the target has finished and the connection is released or 
> returned
>  to the pool.
> This causes a possible build-up of pending requests in memory for the 
> duration of receiveTimeout instead of connectionRequestTimeout.
> See github PR: [https://github.com/apache/cxf/pull/466]
> The reference solution in the PR works well, but it may not be the most 
> elegant one due to my currently limited understanding of the overall design 
> of the connection handling code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CXF-7838) Remove illegal reflective access in ReflectionUtil

2018-10-30 Thread Colm O hEigeartaigh (JIRA) 


 [ 
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated CXF-7838:
-
Fix Version/s: (was: 3.2.7)
   3.2.8

> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
>  Issue Type: Task
>Reporter: Tim Allison
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.0, 3.2.8
>
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache 
> Tika, and we're still getting the following when we run our unit tests with 
> Java 11.
> {quote}Illegal reflective access by 
> org.apache.cxf.common.util.ReflectionUtil$11 
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
>  to field java.net.Authenticator.theAuthenticator
>  WARNING: Please consider reporting this to the maintainers of 
> org.apache.cxf.common.util.ReflectionUtil$11
>  WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> {quote}
> Let us know if you need more info to solve this.  Thank you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)