[jira] [Created] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values

[Andy McCright (JIRA)]

Andy McCright created CXF-7059:
--

 Summary: ClientImpl.getBooleanValue() will return null for String 
values
 Key: CXF-7059
 URL: https://issues.apache.org/jira/browse/CXF-7059
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.1.7
Reporter: Andy McCright
Priority: Minor


The getBooleanValue(Object o) method looks like this:

private static Boolean getBooleanValue(Object o) {
return o instanceof Boolean ? (Boolean)o : o instanceof Boolean ? 
Boolean.valueOf(o.toString()) : null;
}

If o is not an instance of Boolean, it checks to see if it is a Boolean again.  
Instead, it should get to see if it is an instance of String like the 
getIntValue method:

private static Integer getIntValue(Object o) {
return o instanceof Integer ? (Integer)o : o instanceof String ? 
Integer.valueOf(o.toString()) : null;
}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance

[Andy McCright (JIRA)]

Andy McCright created CXF-7075:
--

 Summary: Remove unnecessary string.length() and 
map.containsKey(...) calls to improve performance
 Key: CXF-7075
 URL: https://issues.apache.org/jira/browse/CXF-7075
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS
Affects Versions: 3.1.7
Reporter: Andy McCright


Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around 
string.length() and map.containsKey(...) calls that could be optimized.  
Initial testing with the proposed changes yielded about a 2-3% improvement.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance

[Andy McCright (JIRA)]

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

Andy McCright updated CXF-7075:
---
Attachment: JAXRSUtils-parseMediaType-perfTest.zip

Here is the performance test case I used.  The test just parses some of the 
default media types.  It tests parsing one media type (no comma separation), 
two media types (one comma), three media types, and 12 media types.

I ran the original code then the proposed code and back and forth a few times 
to try to filter out anything else that is running on my machine (still not the 
cleanest for a true performance test, but it's what I have to work with... :) 
), and here are my results:
Original Code Test
Time to parse one type: 138693018 nanoseconds
Time to parse two types: 77448126 nanoseconds
Time to parse three types: 78393247 nanoseconds
Time to parse twelve types: 392029699 nanoseconds
Proposed Change Test
Time to parse one type: 137286698 nanoseconds
Time to parse two types: 69548647 nanoseconds
Time to parse three types: 71362712 nanoseconds
Time to parse twelve types: 408572018 nanoseconds
Original Code Test
Time to parse one type: 139692204 nanoseconds
Time to parse two types: 72788203 nanoseconds
Time to parse three types: 79289730 nanoseconds
Time to parse twelve types: 439972027 nanoseconds
Proposed Change Test
Time to parse one type: 137032626 nanoseconds
Time to parse two types: 69043698 nanoseconds
Time to parse three types: 77564601 nanoseconds
Time to parse twelve types: 385392535 nanoseconds
Original Code Test
Time to parse one type: 148664661 nanoseconds
Time to parse two types: 73345793 nanoseconds
Time to parse three types: 79363398 nanoseconds
Time to parse twelve types: 412479763 nanoseconds
Proposed Change Test
Time to parse one type: 139838947 nanoseconds
Time to parse two types: 73356785 nanoseconds
Time to parse three types: 76625311 nanoseconds
Time to parse twelve types: 383566071 nanoseconds


> Remove unnecessary string.length() and map.containsKey(...) calls to improve 
> performance
> 
>
> Key: CXF-7075
> URL: https://issues.apache.org/jira/browse/CXF-7075
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Andy McCright
> Attachments: JAXRSUtils-parseMediaType-perfTest.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around 
> string.length() and map.containsKey(...) calls that could be optimized.  
> Initial testing with the proposed changes yielded about a 2-3% improvement.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7075:


Hi Sergey,

Thanks for the commits.  I did some more digging (in a Java SE environment), 
and it looks like there really isn't a huge gain in using str.split() vs the 
current approach.  I'll attach the test case I used and the results.  Using 
str.split() did seem faster when parsing more media types, but the difference 
is minor.

Thanks, Andy

> Remove unnecessary string.length() and map.containsKey(...) calls to improve 
> performance
> 
>
> Key: CXF-7075
> URL: https://issues.apache.org/jira/browse/CXF-7075
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Andy McCright
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around 
> string.length() and map.containsKey(...) calls that could be optimized.  
> Initial testing with the proposed changes yielded about a 2-3% improvement.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7075:


Interestingly, when I bump up the TIMES_TO_RUN from 500k to 1 million, then the 
proposed fix looks a bit slower:
Original Code Test
Time to parse one type: 146873609 nanoseconds
Time to parse two types: 119980999 nanoseconds
Time to parse three types: 158751189 nanoseconds
Time to parse twelve types: 792077205 nanoseconds
Proposed Change Test
Time to parse one type: 166478348 nanoseconds
Time to parse two types: 135731365 nanoseconds
Time to parse three types: 163320358 nanoseconds
Time to parse twelve types: 758674187 nanoseconds
Original Code Test
Time to parse one type: 157246321 nanoseconds
Time to parse two types: 129763922 nanoseconds
Time to parse three types: 164354449 nanoseconds
Time to parse twelve types: 840647904 nanoseconds
Proposed Change Test
Time to parse one type: 162607531 nanoseconds
Time to parse two types: 123097493 nanoseconds
Time to parse three types: 165173994 nanoseconds
Time to parse twelve types: 768583383 nanoseconds
Original Code Test
Time to parse one type: 143968053 nanoseconds
Time to parse two types: 133924033 nanoseconds
Time to parse three types: 161509309 nanoseconds
Time to parse twelve types: 809422872 nanoseconds
Proposed Change Test
Time to parse one type: 157101703 nanoseconds
Time to parse two types: 135634786 nanoseconds
Time to parse three types: 158294707 nanoseconds
Time to parse twelve types: 781427304 nanoseconds

I tried re-implementing another way which looks like it might be a little 
faster...
public static List parseMediaTypes(String types) {
List acceptValues = new ArrayList();

if (types != null) {
int x = 0;
int y = types.indexOf(',');
while (y > 0) {
acceptValues.add(toMediaType(types.substring(x, y)));
x = y + 2;
y = types.indexOf(',', x);
}
acceptValues.add(toMediaType(types.substring(x)));

} else {
acceptValues.add(ALL_TYPES);
}

return acceptValues;
}

With that code, I get these results (new code is labeled as Proposed):
Original Code Test
Time to parse one type: 162089550 nanoseconds
Time to parse two types: 121634212 nanoseconds
Time to parse three types: 164150901 nanoseconds
Time to parse twelve types: 1027082012 nanoseconds
Proposed Change Test
Time to parse one type: 147992281 nanoseconds
Time to parse two types: 118361681 nanoseconds
Time to parse three types: 154465943 nanoseconds
Time to parse twelve types: 744372633 nanoseconds
Original Code Test
Time to parse one type: 171457432 nanoseconds
Time to parse two types: 123348169 nanoseconds
Time to parse three types: 163685283 nanoseconds
Time to parse twelve types: 759016041 nanoseconds
Proposed Change Test
Time to parse one type: 147617428 nanoseconds
Time to parse two types: 118008933 nanoseconds
Time to parse three types: 153649110 nanoseconds
Time to parse twelve types: 756229153 nanoseconds
Original Code Test
Time to parse one type: 151245814 nanoseconds
Time to parse two types: 122917357 nanoseconds
Time to parse three types: 159188030 nanoseconds
Time to parse twelve types: 843513510 nanoseconds
Proposed Change Test
Time to parse one type: 145248903 nanoseconds
Time to parse two types: 118914505 nanoseconds
Time to parse three types: 155509909 nanoseconds
Time to parse twelve types: 767379270 nanoseconds

I haven't run this change on the simple JAX-RS benchmark, but I can do that -- 
I'll be on vacation the next couple of days, so I may not have results until 
next week.

Thanks, Andy



> Remove unnecessary string.length() and map.containsKey(...) calls to improve 
> performance
> 
>
> Key: CXF-7075
> URL: https://issues.apache.org/jira/browse/CXF-7075
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Andy McCright
> Attachments: JAXRSUtils-parseMediaType-perfTest.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around 
> string.length() and map.containsKey(...) calls that could be optimized.  
> Initial testing with the proposed changes yielded about a 2-3% improvement.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7075:


Hi Sergey,

The results from the benchmark are in and the new code does not have any impact 
on performance.  Let's pull out the changes to JAXRSUtils.  Then I think we can 
close out this JIRA.

Thanks again,
Andy

> Remove unnecessary string.length() and map.containsKey(...) calls to improve 
> performance
> 
>
> Key: CXF-7075
> URL: https://issues.apache.org/jira/browse/CXF-7075
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.7
>Reporter: Andy McCright
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
> Attachments: JAXRSUtils-parseMediaType-perfTest.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around 
> string.length() and map.containsKey(...) calls that could be optimized.  
> Initial testing with the proposed changes yielded about a 2-3% improvement.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7046) java.lang.ArrayIndexOutOfBoundsException: 1 AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7046:


It looks like this issue may have been resolved by CXF-6492 which was released 
in 3.0.9 and 3.1.6.  The affected versions shows 3.1.7, but if that is the 
case, the stack trace is no longer accurate.  Can you try running this test on 
3.1.7 to see if the problem still occurs?  If so, can you post the updated 
stack trace?

Thanks, Andy

> java.lang.ArrayIndexOutOfBoundsException: 1 
> AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)
> ---
>
> Key: CXF-7046
> URL: https://issues.apache.org/jira/browse/CXF-7046
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 2.7.17, 3.1.7
>Reporter: Ranjeeth
>
> When the authorization header is basic and does not contain userinfo cxf 
> thorws exception
>  example header authorization header [ Authorization:Basic ]
> {code:title=ArrayIndexOutOfBoundsException: 1|borderStyle=solid}
> java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.setupMessage(AbstractHTTPDestination.java:349)
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:222)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:163)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137)
>   at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:168)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219)
>   at 
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl$LegacyServlet.service(HttpServiceRuntimeImpl.java:1271)
>   at 
> org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:162)
>   at 
> org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:63)
>   at 
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:413)
>   at 
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:358)
>   at 
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:204)
>   at 
> org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.processAlias(ProxyServlet.java:91)
>   at 
> org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.service(ProxyServlet.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:816)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1121)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1055)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:118)
>   at org.eclipse.jetty.server.Server.handle(Server.java:515)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:291)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.ja

[jira] [Commented] (CXF-7041) Observed Memory leak under high traffic condition while using Apache CXF libraries SSL communication

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7041:


Would it be possible for you to provide an example that could be used to 
reproduce the issue?  If not, could you provide heap dumps after you have 
reproduced the problem?

Thanks, Andy

> Observed Memory leak under high traffic condition while using Apache CXF 
> libraries SSL communication
> 
>
> Key: CXF-7041
> URL: https://issues.apache.org/jira/browse/CXF-7041
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.1.2
> Environment: Machine : SunOS lava 5.10 Generic_137137-09 sun4v sparc 
> SUNW,Sun-Fire-T200
>Reporter: Savita
>Priority: Critical
>  Labels: patch, security
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> We are using Apache CXF libraries for SSL client implementation in a Spring 
> based application. The client behavior is not stable. We are observing 2 
> issue:
> a) When the load is increased to 20-25 TPS the application processing time 
> increases by 2-3 time. 
> b) We are experiencing memory leak. Basically the memory consumption is not 
> going down. In the heap dump, we could see lot of Apache CXF Objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-7121) Need to log a warning when async method returns a non-void type

[Andy McCright (JIRA)]

Andy McCright created CXF-7121:
--

 Summary: Need to log a warning when async method returns a 
non-void type
 Key: CXF-7121
 URL: https://issues.apache.org/jira/browse/CXF-7121
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.1.8, 3.1.7
Reporter: Andy McCright
Priority: Minor
 Fix For: 3.2.0, 3.1.9


According to the javadoc for the @Suspended annotation ( 
http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html ), the 
JAX-RS runtime should be logging a warning message when a user's resource 
contains an async method (method with a @Suspended-annotated parameter) that 
returns a non-void type.

Currently, CXF will log a FINE trace message, but it ought to be a WARNING so 
that it highlighted in the log output under normal logging settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-7140) Multiple calls to AsyncResponse.cancel() returns different values

[Andy McCright (JIRA)]

Andy McCright created CXF-7140:
--

 Summary: Multiple calls to AsyncResponse.cancel() returns 
different values
 Key: CXF-7140
 URL: https://issues.apache.org/jira/browse/CXF-7140
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.1.8
Reporter: Andy McCright


When we incorporated CXF 3.1.8 into our builds, our CTS testing team found some 
failures related to the AsyncResponse.cancel(...) methods.  According to the 
spec, once the AsyncResponse has been canceled, subsequent calls to cancel 
should return true.

It looks like one of the changes in CXF-7037 changed the order of things in the 
doCancel method -- and those changes result in false getting returned when 
calling cancel(...) a second time.

I have written some tests that demonstrate the expected CTS behavior - and they 
fail with the current code, but pass when reverting the order change in 
doCancel().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-7174) NullPointerException when Content-Type is not specified in the http request

[Andy McCright (JIRA)]

Andy McCright created CXF-7174:
--

 Summary: NullPointerException when Content-Type is not specified 
in the http request
 Key: CXF-7174
 URL: https://issues.apache.org/jira/browse/CXF-7174
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.1.8
Reporter: Andy McCright


When the Content-Type header is not specified in the HttpServletRequest, a null 
pointer is possible when calling Headers.copyFromRequest(...) followed by 
Headers.determineContentType().  This scenario is possible when using 
non-traditional clients like curl.

Here is an example (snippet) of the NPE:
2016-12-09T09:29:47.24-0600 [APP/0]  ERR Caused by: 
java.lang.NullPointerException
2016-12-09T09:29:47.24-0600 [APP/0]  ERRat 
org.apache.cxf.transport.http.Headers.determineContentType(Headers.java:374)
2016-12-09T09:29:47.24-0600 [APP/0]  ERRat 
org.apache.cxf.transport.http.Headers.setProtocolHeadersInConnection(Headers.java:363)
2016-12-09T09:29:47.24-0600 [APP/0]  ERRat 
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setProtocolHeaders(URLConnectionHTTPConduit.java:279)
2016-12-09T09:29:47.24-0600 [APP/0]  ERRat 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1301)
2016-12-09T09:29:47.24-0600 [APP/0]  ERRat 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1337)
2016-12-09T09:29:47.24-0600 [APP/0]  ERR... 56 more

The failing line of code is:
if (ctList != null && ctList.size() == 1) {
ct = ctList.get(0).toString();  // <--- here

The reason it fails is that copyFromRequest(...) will create a singleton list 
and wrap the request's content-type value in it.  If the content-type from the 
request is null, then ctList will be a singleton list with a null value in it, 
so the call to toString() will be on a null value.

Instead, the code should be:
if (ctList != null && ctList.size() == 1 && ctList.get(0) != null) {
ct = ctList.get(0).toString(); 
...

This ensures that a default content type of text/xml is returned when no 
content-type is specified in the request -- or whatever was specified in the 
Message.

This approach is preferable to just setting ctList (via the 
headers.get(Message.CONTENT_TYPE) field) to null because other places in the 
code depend on that list to be non-null.

I have a patch and test case to be delivered shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-7262) JAXRS: ClientConfig lost when using templates in the path method

[Andy McCright (JIRA)]

Andy McCright created CXF-7262:
--

 Summary: JAXRS: ClientConfig lost when using templates in the path 
method
 Key: CXF-7262
 URL: https://issues.apache.org/jira/browse/CXF-7262
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.1.8
Reporter: Andy McCright


The ClientConfiguration (not to be confused with the JAXRS Configuration) is 
lost when a user of the JAXRS Client APIs calls path(...) on a WebTarget with a 
template.  The ClientConfiguration contains important pieces like Interceptors, 
etc. that would be lost when the user tries to invoke the method on the 
WebTarget returned from the path(...) method.

For example, we create an out interceptor and add it to the 
ClientConfiguration, and we would expect that interceptor to be executed on 
every outbound request, but the following example shows that it is not:

Client client = ClientBuilder.newClient();
WebTarget target = client.target("http://localhost:8080/myRoot";);
target.request().get(); // works - invokes the interceptor
WebTarget target2 = target.path("/path/{key}").resolveTemplate("key", "value");
target2.request().get(); // fails - request is sent without invoking the 
interceptor



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7262) JAXRS: ClientConfig lost when using templates in the path method

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7262:


Good catch Sergey!  I missed the scenario where the initial WebClient was null. 
 This would be the case when the unresolved template is part of the initial 
target() call.  I'll update my patch with a fix shortly.

Thanks, Andy

> JAXRS: ClientConfig lost when using templates in the path method
> 
>
> Key: CXF-7262
> URL: https://issues.apache.org/jira/browse/CXF-7262
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: Andy McCright
>
> The ClientConfiguration (not to be confused with the JAXRS Configuration) is 
> lost when a user of the JAXRS Client APIs calls path(...) on a WebTarget with 
> a template.  The ClientConfiguration contains important pieces like 
> Interceptors, etc. that would be lost when the user tries to invoke the 
> method on the WebTarget returned from the path(...) method.
> For example, we create an out interceptor and add it to the 
> ClientConfiguration, and we would expect that interceptor to be executed on 
> every outbound request, but the following example shows that it is not:
> Client client = ClientBuilder.newClient();
> WebTarget target = client.target("http://localhost:8080/myRoot";);
> target.request().get(); // works - invokes the interceptor
> WebTarget target2 = target.path("/path/{key}").resolveTemplate("key", 
> "value");
> target2.request().get(); // fails - request is sent without invoking the 
> interceptor



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CXF-7262) JAXRS: ClientConfig lost when using templates in the path method

[Andy McCright (JIRA)]

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

Andy McCright edited comment on CXF-7262 at 3/2/17 8:54 PM:


Good catch Sergey!  I missed the scenario where the initial WebClient was null. 
 This would be the case when the unresolved template is part of the initial 
target() call.  I've updated my patch with a fix that keeps the targetClient 
field null if it was previously null, but preserves it in all other cases - 
preserving the config.  That passes the original test and yours (which I added 
to the new test class).

Thanks, Andy


was (Author: andymc):
Good catch Sergey!  I missed the scenario where the initial WebClient was null. 
 This would be the case when the unresolved template is part of the initial 
target() call.  I'll update my patch with a fix shortly.

Thanks, Andy

> JAXRS: ClientConfig lost when using templates in the path method
> 
>
> Key: CXF-7262
> URL: https://issues.apache.org/jira/browse/CXF-7262
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: Andy McCright
>
> The ClientConfiguration (not to be confused with the JAXRS Configuration) is 
> lost when a user of the JAXRS Client APIs calls path(...) on a WebTarget with 
> a template.  The ClientConfiguration contains important pieces like 
> Interceptors, etc. that would be lost when the user tries to invoke the 
> method on the WebTarget returned from the path(...) method.
> For example, we create an out interceptor and add it to the 
> ClientConfiguration, and we would expect that interceptor to be executed on 
> every outbound request, but the following example shows that it is not:
> Client client = ClientBuilder.newClient();
> WebTarget target = client.target("http://localhost:8080/myRoot";);
> target.request().get(); // works - invokes the interceptor
> WebTarget target2 = target.path("/path/{key}").resolveTemplate("key", 
> "value");
> target2.request().get(); // fails - request is sent without invoking the 
> interceptor



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7262) JAXRS: ClientConfig lost when using templates in the path method

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7262:


Thanks Sergey, and sorry for the extra work.  I have a new system, and didn't 
install Java 7 on it, so I guess I need to configure it to use Java 7 
compilation settings...

Thanks again,
Andy

> JAXRS: ClientConfig lost when using templates in the path method
> 
>
> Key: CXF-7262
> URL: https://issues.apache.org/jira/browse/CXF-7262
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: Andy McCright
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.11
>
>
> The ClientConfiguration (not to be confused with the JAXRS Configuration) is 
> lost when a user of the JAXRS Client APIs calls path(...) on a WebTarget with 
> a template.  The ClientConfiguration contains important pieces like 
> Interceptors, etc. that would be lost when the user tries to invoke the 
> method on the WebTarget returned from the path(...) method.
> For example, we create an out interceptor and add it to the 
> ClientConfiguration, and we would expect that interceptor to be executed on 
> every outbound request, but the following example shows that it is not:
> Client client = ClientBuilder.newClient();
> WebTarget target = client.target("http://localhost:8080/myRoot";);
> target.request().get(); // works - invokes the interceptor
> WebTarget target2 = target.path("/path/{key}").resolveTemplate("key", 
> "value");
> target2.request().get(); // fails - request is sent without invoking the 
> interceptor



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7339) NPE in org.apache.cxf.common.util.CacheMap.remove

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7339:


Hi Alessio,

This is a legitimate bug, but instead of using a null check JAXBContextCache 
code, could we redo the logic in CacheMap's remove method?  Prior to the change 
in CXF-5407, this map implementation was able to handle null keys, and (though 
I have not done a check to verify) it is possible that other places in code 
rely on the ability of CacheMap to handle null keys.  

If you'd rather I made the changes, please let me know.  Thanks for reporting 
this - and for the proposed fix.

Andy

> NPE in org.apache.cxf.common.util.CacheMap.remove
> -
>
> Key: CXF-7339
> URL: https://issues.apache.org/jira/browse/CXF-7339
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
> Fix For: 3.2.0, 3.1.12
>
>
> {noformat}
> 2017-04-17 19:12:28,910 INFO  
> [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (MSC 
> service thread 1-6) Creating Service 
> {http://org.jboss.ws/jaxws/context}EndpointService from class 
> org.jboss.test.ws.jaxws.samples.context.EndpointJSE
> 2017-04-17 19:12:28,915 ERROR [org.jboss.msc.service.fail] (MSC service 
> thread 1-6) MSC01: Failed to start service 
> jboss.deployment.unit."jaxws-samples-context-jse.war".INSTALL: 
> org.jboss.msc.service.StartException in service 
> jboss.deployment.unit."jaxws-samples-context-jse.war".INSTALL: WFLYSRV0153: 
> Failed to process phase INSTALL of deployment "jaxws-samples-context-jse.war"
>   at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.ws.WebServiceException: java.lang.NullPointerException
>   at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:375)
>   at 
> org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
>   at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
>   at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
>   at 
> org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:235)
>   at 
> org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
>   at 
> org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
>   at 
> org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
>   at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>   ... 5 more
> Caused by: java.lang.NullPointerException
>   at org.apache.cxf.common.util.CacheMap.remove(CacheMap.java:126)
>   at 
> org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:232)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:472)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:327)
>   at 
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:470)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:696)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
>   at 
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
>   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.ServerFactoryBean.create(ServerFactoryBean.java:168)
>   at 
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
>   at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
>   at org.apache.

[jira] [Created] (CXF-7349) NPE in ClassLoaderUtils

[Andy McCright (JIRA)]

Andy McCright created CXF-7349:
--

 Summary: NPE in ClassLoaderUtils
 Key: CXF-7349
 URL: https://issues.apache.org/jira/browse/CXF-7349
 Project: CXF
  Issue Type: Bug
  Components: Core
Affects Versions: 3.1.11
Reporter: Andy McCright
 Fix For: 3.2.0, 3.1.12


A NullPointerException can be thrown when the JVM's boot classloader is set as 
the thread's context classloader.  Ex:

URL url = 
Thread.currentThread().getContextClassLoader().getResource(resourceName);

The call to getContextClassLoader() could return null - that is a valid return 
from that method.  In that case, we should use 
ClassLoader.getSystemClassLoader() instead.

This issue was reported on in the users mailing list:
http://cxf.547215.n5.nabble.com/NPE-in-cxf-core-ClassLoaderUtils-possible-bug-td5780007.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CXF-7926) MicroProfile Rest Client 1.2

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7926.

Resolution: Fixed

> MicroProfile Rest Client 1.2
> 
>
> Key: CXF-7926
> URL: https://issues.apache.org/jira/browse/CXF-7926
> Project: CXF
>  Issue Type: New Feature
>  Components: JAX-RS
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.3.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> MicroProfile Rest Client 1.2 adds a lot of new function that should improve 
> developer experience and third-party product integration.  
>  
> The complete list of issues in the new spec are available here:
> [https://github.com/eclipse/microprofile-rest-client/milestone/4?closed=1]
>  
> Some of the highlights are:
>  * the ability to specify the base URI in the `@RegisterRestClient` 
> annotation.
>  * `removeContext` method in `AsyncInvocationInterceptor` interface allowing 
> cleanup of contexts transferred from the calling thread.
>  * new `RestClientListener` SPI interface for intercepting Rest Client 
> instances.
>  * portable timeout properties.
>  
> The official release of MP Rest Client 1.2 will be some time in late January 
> or early February 2019.  There is a 1.2-m2 (milestone 2) early access release 
> of the API and TCK that we can build on for the CXF 3.3.0 release.  Once the 
> official release of the API/TCK occurs in early 2019, we can update the maven 
> dependencies to use the official release as part of 3.3.1 or 3.3.2.



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

[jira] [Commented] (CXF-7978) Support for Microprofile Rest client 1.2.1

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7978:


Hi Ivan,

 

CXF 3.3.0 supports MP Rest Client 1.2.0 which should work for you.  The only 
changes between 1.2.0 and 1.2.1 were TCK clarifications, and I have verified 
that CXF 3.3.0 passes both the 1.2.0 and 1.2.1 TCKs.

And there is a systest that verifies that headers inbound to a JAX-RS resource 
method are propagated to an outbound MP Rest Client request: 
[https://github.com/apache/cxf/tree/master/systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client]

 

Please give this a try and let me know if you run into any problems.  Thanks!

> Support for Microprofile Rest client 1.2.1
> --
>
> Key: CXF-7978
> URL: https://issues.apache.org/jira/browse/CXF-7978
> Project: CXF
>  Issue Type: Bug
>Reporter: Ivan Junckes Filho
>Priority: Major
>
> Is it possible that apache cxf has support for microprofile rest client 1.2.1?
> I am looking for @RegisterClientHeaders feature that will propagate the 
> headers between services,  that would make a lot easier to propagate a JWT 
> token.
> https://download.eclipse.org/microprofile/microprofile-rest-client-1.2.1/microprofile-rest-client-1.2.1.html
> Thank you.



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

[jira] [Created] (CXF-7992) MP Rest Client leaks async interceptors

[Andy McCright (JIRA)]

Andy McCright created CXF-7992:
--

 Summary: MP Rest Client leaks async interceptors
 Key: CXF-7992
 URL: https://issues.apache.org/jira/browse/CXF-7992
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.3.1, 3.3.0
Reporter: Andy McCright
Assignee: Andy McCright


Every async method request on the MP Rest Client results in new 
MPAsyncInvocationInterceptorPostAsyncImpl and 
MPAsyncInvocationInterceptorRemoveAsyncImpl interceptors applied to the 
ClientConfiguration associated with the proxy impl.  This can quickly lead to 
OOM conditions.

 

The following heap dump info was observed using CXF 3.3.0 in WebSphere Liberty:
25,967,912 (42.9%) [56] 9 
org/apache/cxf/microprofile/client/proxy/MicroProfileClientProxyImpl 0xe0bcbba8
|- 25,963,672 (42.9%) [56] 8 org/apache/cxf/jaxrs/client/ClientConfiguration 
0xe0bcbcf8
|- 23,894,672 (39.48%) [24] 3 
org/apache/cxf/common/util/ModCountCopyOnWriteArrayList 0xe12602b0
|- 23,894,552 (39.48%) [853,360] 213,341 array of java/lang/Object 0xf8a61090
|- 312 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe12db1a0
|- 296 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorRemoveContextImpl
 0xe12db218
|- 272 (0%) [32] 6 
org/apache/cxf/jaxrs/client/ClientProxyImpl$ClientAsyncResponseInterceptor 
0xe12db140
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1bdd300
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe16a8eb8
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc2d8
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1e34c28
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc3b0
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1f17e88
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc488
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1e34d00
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc560
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1aaef68
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc638
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1e34dd8
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc710
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1f17f60
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc7e8
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1e34eb0
|- 120 (0%) [32] 5 
org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
 0xe1dfc8c0
|- There are 213,321 more children



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

[jira] [Commented] (CXF-7992) MP Rest Client leaks async interceptors

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7992:


Resolving with 
https://github.com/apache/cxf/commit/eccb71ea477a36747914d7f17908cc6d591d390b

> MP Rest Client leaks async interceptors
> ---
>
> Key: CXF-7992
> URL: https://issues.apache.org/jira/browse/CXF-7992
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.3.0, 3.3.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
>
> Every async method request on the MP Rest Client results in new 
> MPAsyncInvocationInterceptorPostAsyncImpl and 
> MPAsyncInvocationInterceptorRemoveAsyncImpl interceptors applied to the 
> ClientConfiguration associated with the proxy impl.  This can quickly lead to 
> OOM conditions.
>  
> The following heap dump info was observed using CXF 3.3.0 in WebSphere 
> Liberty:
> 25,967,912 (42.9%) [56] 9 
> org/apache/cxf/microprofile/client/proxy/MicroProfileClientProxyImpl 
> 0xe0bcbba8
> |- 25,963,672 (42.9%) [56] 8 org/apache/cxf/jaxrs/client/ClientConfiguration 
> 0xe0bcbcf8
> |- 23,894,672 (39.48%) [24] 3 
> org/apache/cxf/common/util/ModCountCopyOnWriteArrayList 0xe12602b0
> |- 23,894,552 (39.48%) [853,360] 213,341 array of java/lang/Object 0xf8a61090
> |- 312 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe12db1a0
> |- 296 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorRemoveContextImpl
>  0xe12db218
> |- 272 (0%) [32] 6 
> org/apache/cxf/jaxrs/client/ClientProxyImpl$ClientAsyncResponseInterceptor 
> 0xe12db140
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1bdd300
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe16a8eb8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc2d8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34c28
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc3b0
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1f17e88
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc488
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34d00
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc560
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1aaef68
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc638
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34dd8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc710
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1f17f60
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc7e8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34eb0
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc8c0
> |- There are 213,321 more children



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

[jira] [Resolved] (CXF-7992) MP Rest Client leaks async interceptors

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7992.

   Resolution: Fixed
Fix Version/s: 3.3.2

> MP Rest Client leaks async interceptors
> ---
>
> Key: CXF-7992
> URL: https://issues.apache.org/jira/browse/CXF-7992
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.3.0, 3.3.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.3.2
>
>
> Every async method request on the MP Rest Client results in new 
> MPAsyncInvocationInterceptorPostAsyncImpl and 
> MPAsyncInvocationInterceptorRemoveAsyncImpl interceptors applied to the 
> ClientConfiguration associated with the proxy impl.  This can quickly lead to 
> OOM conditions.
>  
> The following heap dump info was observed using CXF 3.3.0 in WebSphere 
> Liberty:
> 25,967,912 (42.9%) [56] 9 
> org/apache/cxf/microprofile/client/proxy/MicroProfileClientProxyImpl 
> 0xe0bcbba8
> |- 25,963,672 (42.9%) [56] 8 org/apache/cxf/jaxrs/client/ClientConfiguration 
> 0xe0bcbcf8
> |- 23,894,672 (39.48%) [24] 3 
> org/apache/cxf/common/util/ModCountCopyOnWriteArrayList 0xe12602b0
> |- 23,894,552 (39.48%) [853,360] 213,341 array of java/lang/Object 0xf8a61090
> |- 312 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe12db1a0
> |- 296 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorRemoveContextImpl
>  0xe12db218
> |- 272 (0%) [32] 6 
> org/apache/cxf/jaxrs/client/ClientProxyImpl$ClientAsyncResponseInterceptor 
> 0xe12db140
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1bdd300
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe16a8eb8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc2d8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34c28
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc3b0
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1f17e88
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc488
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34d00
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc560
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1aaef68
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc638
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34dd8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc710
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1f17f60
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc7e8
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1e34eb0
> |- 120 (0%) [32] 5 
> org/apache/cxf/microprofile/client/proxy/MPAsyncInvocationInterceptorPostAsyncImpl
>  0xe1dfc8c0
> |- There are 213,321 more children



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

[jira] [Created] (CXF-8033) MicroProfile Rest Client 1.3 implementation

[Andy McCright (JIRA)]

Andy McCright created CXF-8033:
--

 Summary: MicroProfile Rest Client 1.3 implementation
 Key: CXF-8033
 URL: https://issues.apache.org/jira/browse/CXF-8033
 Project: CXF
  Issue Type: New Feature
Reporter: Andy McCright
Assignee: Andy McCright


The new MP Rest Client 1.3 spec adds the following new features:
 * Spec-defined SSL methods/properties
 * Allow client proxies to be cast to `Closeable`/`AutoCloseable`.
 * Simpler configuration using configKeys.
 * Defined `application/json` to be the default MediaType if none is specified 
in `@Produces`/`@Consumes`.

 

More info from the 1.3-RC1 release candidate page:

https://github.com/eclipse/microprofile-rest-client/releases/tag/1.3-RC1



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

[jira] [Created] (CXF-8080) MP Rest Client CompletionStages from async methods are never completed

[Andy McCright (JIRA)]

Andy McCright created CXF-8080:
--

 Summary: MP Rest Client CompletionStages from async methods are 
never completed
 Key: CXF-8080
 URL: https://issues.apache.org/jira/browse/CXF-8080
 Project: CXF
  Issue Type: Bug
Affects Versions: 3.3.2
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.3.3


[Manish Kumar|https://twitter.com/manish2aug] first reported this issue in a 
[Twitter post|[https://twitter.com/manish2aug/status/118627593379842]] and 
then opened issue 
[208|https://github.com/eclipse/microprofile-rest-client/issues/208] on the MP 
Rest Client spec page.

 

He provided an example that shows that the CompletionStage never completes, 
leaving his test case hung.  See the example here:

[https://gist.github.com/manish2aug/b4133b9fbedc2175e15b303a0682b552]

 

It should be possible to fix this with a change to the MPRestClientCallback.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (CXF-8080) MP Rest Client CompletionStages from async methods are never completed

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-8080.

Resolution: Fixed

> MP Rest Client CompletionStages from async methods are never completed
> --
>
> Key: CXF-8080
> URL: https://issues.apache.org/jira/browse/CXF-8080
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.3.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [Manish Kumar|https://twitter.com/manish2aug] first reported this issue in a 
> [Twitter post|[https://twitter.com/manish2aug/status/118627593379842]] 
> and then opened issue 
> [208|https://github.com/eclipse/microprofile-rest-client/issues/208] on the 
> MP Rest Client spec page.
>  
> He provided an example that shows that the CompletionStage never completes, 
> leaving his test case hung.  See the example here:
> [https://gist.github.com/manish2aug/b4133b9fbedc2175e15b303a0682b552]
>  
> It should be possible to fix this with a change to the MPRestClientCallback.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (CXF-7996) Jakarta EE TCKs and compatibility

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-7996:


OpenLiberty has passed the Jakarta JAX-RS TCK (using a forked version of CXF 
3.3.3, I think...).  I know that we have made a few changes in our fork, and 
possibly some of them were for TCK compliance.  

 

Is there a list of the failing tests somewhere?  I may be able to help.

 

Also, Adam Anderson from my team has set up the Oracle-based TCK to run for us. 
 It is pretty similar to the Jakarta-based TCK, so he may be able to help with 
this effort too.  Unfortunately, he is on vacation this coming week, but I will 
let him know about this effort.

 

 

> Jakarta EE TCKs and compatibility
> -
>
> Key: CXF-7996
> URL: https://issues.apache.org/jira/browse/CXF-7996
> Project: CXF
>  Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Attachments: JTreport-26-December-2019.zip, JTwork- 
> 26-December-2019.zip
>
>
> Mail thread: 
> [https://mail-archives.apache.org/mod_mbox/cxf-dev/201901.mbox/%3C6edd1da6-d651-]
>  e2a3-8092-59bdc7a54...@apache.org%3E
> Jakarta EE TCK: 
> [https://projects.eclipse.org/proposals/eclipse-jakarta-ee-tck]
>  Github Repo: [https://github.com/eclipse-ee4j/jakartaee-tck]
> Latest updates from [jakarta.ee-spec] TCK information, June 2019, the 
> excerpts: 
>  * {color:#00}We have summed up some information about how the TCK can be 
> built (or {color}
>  {color:#00}grabbed pre-built), configured, and run [1].{color}
>  * {color:#00}This is assumed to be run against a Glassfish with the 
> latest API {color}
>  {color:#00}integrated (replacing the original API in the 
> Glassfish).{color}
>  * {color:#00}We have created a recording of a presentation of the 
> Jenkins jobs that {color}
>  {color:#00}manage all that [2].{color}
>  * {color:#00}We have created 3 Jenkins files for pipeline job (as an 
> example for {color}
>  {color:#00}JSON-B TCK) to a) properly set the ts.jte configuration file, 
> b) to grab {color}
>  {color:#00}the API artifact built by a Jenkins build job and integrate 
> it to a {color}
>  {color:#00}Glassfish and c) to grab the pre-built TCK bundle from 
> Eclipse Download, {color}
>  {color:#00}grab the configured ts.jte file, grab the Glassfish with new 
> API {color}
>  {color:#00}integrated, and run the TCK [3].{color}
> {color:#00}For the complete information, please allow me to mention the 
> list of the {color}
>  {color:#00}TCK tasks needed to be done before the Jakarta EE release can 
> be {color}
>  {color:#00}finished [4].{color}
> {color:#00}The [5] is the example how to run Jakarta EE TCKs with 
> Tomcat.{color}
> {color:#00}{color:#00}The{color} [6] is the official list of the 
> instructions.{color}
>  
> {color:#00}[1] 
> {color}+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run]+
> {color:#00}[2] {color}+[https://youtu.be/nnD1KMvh0to]+
> {color:#00}[3] {color}
>  
> +[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run#Jenkins_Pipelines]+
> {color:#00}[4] {color}+[https://github.com/orgs/eclipse-ee4j/projects/14]+
> [5] [https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs]
> [6]
> +[https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Instructions-for-building-and-running-JakartaEE-TCK-bundle]+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8188) MP Rest Client 2.0: Inject into ClientHeadersFactory

[Andy McCright (Jira)]

Andy McCright created CXF-8188:
--

 Summary: MP Rest Client 2.0: Inject into ClientHeadersFactory
 Key: CXF-8188
 URL: https://issues.apache.org/jira/browse/CXF-8188
 Project: CXF
  Issue Type: New Feature
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright


MicroProfile Rest Client 2.0 is adding injection support into 
ClientHeadersFactory instances - see [Support for injection in 
ClientHeadersFactory|https://github.com/eclipse/microprofile-rest-client/issues/234]
 for more details.

 

This feature must implement `@Context` injection when the rest client is 
invoked in the context of a JAX-RS resource and/or `@Inject` injection when the 
ClientHeadersFactory is managed by CDI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-7996) Jakarta EE TCKs and compatibility

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-7996:


I recognize some of those failures.  I'll plan to open up separate pull 
requests for them unless you'd prefer a single PR with multiple commits for the 
different classes of failures.

 

I have one ready to go that should fix ~4 FormParam-related failures.  I also 
have one that should fix at least one SSE-related failure (possibly more), but 
that ends up causing some of the unit tests to fail - I'll need to investigate 
those more before submitting them. 

 

> Jakarta EE TCKs and compatibility
> -
>
> Key: CXF-7996
> URL: https://issues.apache.org/jira/browse/CXF-7996
> Project: CXF
>  Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Attachments: JTreport-26-December-2019.zip, JTwork- 
> 26-December-2019.zip
>
>
> Mail thread: 
> [https://mail-archives.apache.org/mod_mbox/cxf-dev/201901.mbox/%3C6edd1da6-d651-]
>  e2a3-8092-59bdc7a54...@apache.org%3E
> Jakarta EE TCK: 
> [https://projects.eclipse.org/proposals/eclipse-jakarta-ee-tck]
>  Github Repo: [https://github.com/eclipse-ee4j/jakartaee-tck]
> Latest updates from [jakarta.ee-spec] TCK information, June 2019, the 
> excerpts: 
>  * {color:#00}We have summed up some information about how the TCK can be 
> built (or {color}
>  {color:#00}grabbed pre-built), configured, and run [1].{color}
>  * {color:#00}This is assumed to be run against a Glassfish with the 
> latest API {color}
>  {color:#00}integrated (replacing the original API in the 
> Glassfish).{color}
>  * {color:#00}We have created a recording of a presentation of the 
> Jenkins jobs that {color}
>  {color:#00}manage all that [2].{color}
>  * {color:#00}We have created 3 Jenkins files for pipeline job (as an 
> example for {color}
>  {color:#00}JSON-B TCK) to a) properly set the ts.jte configuration file, 
> b) to grab {color}
>  {color:#00}the API artifact built by a Jenkins build job and integrate 
> it to a {color}
>  {color:#00}Glassfish and c) to grab the pre-built TCK bundle from 
> Eclipse Download, {color}
>  {color:#00}grab the configured ts.jte file, grab the Glassfish with new 
> API {color}
>  {color:#00}integrated, and run the TCK [3].{color}
> {color:#00}For the complete information, please allow me to mention the 
> list of the {color}
>  {color:#00}TCK tasks needed to be done before the Jakarta EE release can 
> be {color}
>  {color:#00}finished [4].{color}
> {color:#00}The [5] is the example how to run Jakarta EE TCKs with 
> Tomcat.{color}
> {color:#00}{color:#00}The{color} [6] is the official list of the 
> instructions.{color}
>  
> {color:#00}[1] 
> {color}+[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run]+
> {color:#00}[2] {color}+[https://youtu.be/nnD1KMvh0to]+
> {color:#00}[3] {color}
>  
> +[https://wiki.eclipse.org/TCK:Build_From_Jakarta_EE_TCK_Repo_And_Run#Jenkins_Pipelines]+
> {color:#00}[4] {color}+[https://github.com/orgs/eclipse-ee4j/projects/14]+
> [5] [https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs]
> [6]
> +[https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Instructions-for-building-and-running-JakartaEE-TCK-bundle]+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (CXF-8188) MP Rest Client 1.4: Inject into ClientHeadersFactory

[Andy McCright (Jira)]

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

Andy McCright updated CXF-8188:
---
Summary: MP Rest Client 1.4: Inject into ClientHeadersFactory  (was: MP 
Rest Client 2.0: Inject into ClientHeadersFactory)

> MP Rest Client 1.4: Inject into ClientHeadersFactory
> 
>
> Key: CXF-8188
> URL: https://issues.apache.org/jira/browse/CXF-8188
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MicroProfile Rest Client 2.0 is adding injection support into 
> ClientHeadersFactory instances - see [Support for injection in 
> ClientHeadersFactory|https://github.com/eclipse/microprofile-rest-client/issues/234]
>  for more details.
>  
> This feature must implement `@Context` injection when the rest client is 
> invoked in the context of a JAX-RS resource and/or `@Inject` injection when 
> the ClientHeadersFactory is managed by CDI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8194) MicroProfile Rest Client 1.4 Implementation

[Andy McCright (Jira)]

Andy McCright created CXF-8194:
--

 Summary: MicroProfile Rest Client 1.4 Implementation
 Key: CXF-8194
 URL: https://issues.apache.org/jira/browse/CXF-8194
 Project: CXF
  Issue Type: New Feature
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0, 3.3.6


Implement MicroProfile Rest Client 1.4.  This includes the following new 
features (taken from the MP Rest Client 1.4-RC1 release page[1] ):
 * Injection into ClientHeadersFactory (Implemented in CXF-8188 [2]).
 * Adding `@Target` annotation to `@RestClient` - API change - should not 
require CXF change.
 * Removed recursive classloader check when resolving service loader for Rest 
Client SPI - API/SPI change - should not require CXF change - but should be 
tested.
 * TCK changes - should not require CXF changes, but should be tested.
 * Javadoc fixes - should not require CXF changes.

 

Everything should be implemented now except for actually switching to the new 
level of the API and TCK.  Due to some of the TCK changes, this will also 
require updates to the unit tests (some unit tests re-use TCK classes that have 
been changed in the 1.4 release).

 

[1] [https://github.com/eclipse/microprofile-rest-client/releases/tag/1.4-RC1]
[2] https://issues.apache.org/jira/browse/CXF-8188



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8188) MP Rest Client 1.4: Inject into ClientHeadersFactory

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8188.

Fix Version/s: 3.4.0
   Resolution: Fixed

> MP Rest Client 1.4: Inject into ClientHeadersFactory
> 
>
> Key: CXF-8188
> URL: https://issues.apache.org/jira/browse/CXF-8188
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.4.0, 3.3.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MicroProfile Rest Client 2.0 is adding injection support into 
> ClientHeadersFactory instances - see [Support for injection in 
> ClientHeadersFactory|https://github.com/eclipse/microprofile-rest-client/issues/234]
>  for more details.
>  
> This feature must implement `@Context` injection when the rest client is 
> invoked in the context of a JAX-RS resource and/or `@Inject` injection when 
> the ClientHeadersFactory is managed by CDI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8188) MP Rest Client 1.4: Inject into ClientHeadersFactory

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8188:


[~coheigea], sorry I missed this earlier, but yes, it can be resolved.  I'm 
planning to update the POM to use the newly released MP Rest Client 1.4.0 
dependency now.  Thanks!

> MP Rest Client 1.4: Inject into ClientHeadersFactory
> 
>
> Key: CXF-8188
> URL: https://issues.apache.org/jira/browse/CXF-8188
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.4.0, 3.3.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MicroProfile Rest Client 2.0 is adding injection support into 
> ClientHeadersFactory instances - see [Support for injection in 
> ClientHeadersFactory|https://github.com/eclipse/microprofile-rest-client/issues/234]
>  for more details.
>  
> This feature must implement `@Context` injection when the rest client is 
> invoked in the context of a JAX-RS resource and/or `@Inject` injection when 
> the ClientHeadersFactory is managed by CDI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8194) MicroProfile Rest Client 1.4 Implementation

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8194.

Resolution: Fixed

> MicroProfile Rest Client 1.4 Implementation
> ---
>
> Key: CXF-8194
> URL: https://issues.apache.org/jira/browse/CXF-8194
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.4.0, 3.3.6
>
>
> Implement MicroProfile Rest Client 1.4.  This includes the following new 
> features (taken from the MP Rest Client 1.4-RC1 release page[1] ):
>  * Injection into ClientHeadersFactory (Implemented in CXF-8188 [2]).
>  * Adding `@Target` annotation to `@RestClient` - API change - should not 
> require CXF change.
>  * Removed recursive classloader check when resolving service loader for Rest 
> Client SPI - API/SPI change - should not require CXF change - but should be 
> tested.
>  * TCK changes - should not require CXF changes, but should be tested.
>  * Javadoc fixes - should not require CXF changes.
>  
> Everything should be implemented now except for actually switching to the new 
> level of the API and TCK.  Due to some of the TCK changes, this will also 
> require updates to the unit tests (some unit tests re-use TCK classes that 
> have been changed in the 1.4 release).
>  
> [1] [https://github.com/eclipse/microprofile-rest-client/releases/tag/1.4-RC1]
> [2] https://issues.apache.org/jira/browse/CXF-8188



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8262) Implement MicroProfile Rest Client 2.0

[Andy McCright (Jira)]

Andy McCright created CXF-8262:
--

 Summary: Implement MicroProfile Rest Client 2.0
 Key: CXF-8262
 URL: https://issues.apache.org/jira/browse/CXF-8262
 Project: CXF
  Issue Type: New Feature
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


The MicroProfile Rest Client 2.0 API is scheduled for release in June 2020.  
The milestone plan for the 2.0 release is available here:

[https://github.com/eclipse/microprofile-rest-client/milestone/6]

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8263) Support Server Sent Events in MP Rest Client

[Andy McCright (Jira)]

Andy McCright created CXF-8263:
--

 Summary: Support Server Sent Events in MP Rest Client
 Key: CXF-8263
 URL: https://issues.apache.org/jira/browse/CXF-8263
 Project: CXF
  Issue Type: Sub-task
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


Part of the MP Rest Client 2.0 feature is reactive support for Server Sent 
Events.  

The spec issue is: 
[https://github.com/eclipse/microprofile-rest-client/issues/11]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8263) Support Server Sent Events in MP Rest Client

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8263.

Resolution: Fixed

> Support Server Sent Events in MP Rest Client
> 
>
> Key: CXF-8263
> URL: https://issues.apache.org/jira/browse/CXF-8263
> Project: CXF
>  Issue Type: Sub-task
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Part of the MP Rest Client 2.0 feature is reactive support for Server Sent 
> Events.  
> The spec issue is: 
> [https://github.com/eclipse/microprofile-rest-client/issues/11]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8294) MP Rest Client 2.0: Add spec-defined proxy server support

[Andy McCright (Jira)]

Andy McCright created CXF-8294:
--

 Summary: MP Rest Client 2.0: Add spec-defined proxy server support
 Key: CXF-8294
 URL: https://issues.apache.org/jira/browse/CXF-8294
 Project: CXF
  Issue Type: Sub-task
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


MP Rest Client 2.0 defines a portable method of specifying proxy server. This 
issue should be used to implement that (basically map the new method to 
existing CXF proxy server properties).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8295) MP Rest Client 2.0: Spec-defined followRedirect

[Andy McCright (Jira)]

Andy McCright created CXF-8295:
--

 Summary: MP Rest Client 2.0: Spec-defined followRedirect
 Key: CXF-8295
 URL: https://issues.apache.org/jira/browse/CXF-8295
 Project: CXF
  Issue Type: Sub-task
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


MP Rest Client 2.0 creates a portable method for specifying whether a rest 
client instance should automatically follow redirect responses (usually 30X 
HTTP response codes).  Since CXF already has support to automatically follow 
redirects, this issue should be used to map the spec methods to the existing 
CXF properties.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8299) MP Rest Client 2.0: Handle different Query Parameter types

[Andy McCright (Jira)]

Andy McCright created CXF-8299:
--

 Summary: MP Rest Client 2.0: Handle different Query Parameter types
 Key: CXF-8299
 URL: https://issues.apache.org/jira/browse/CXF-8299
 Project: CXF
  Issue Type: Sub-task
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


See MP Rest Client Issue [217|[MP Rest Client overlooks Collection handling in 
params|https://github.com/eclipse/microprofile-rest-client/issues/217]]

 

Users would like to configure how the MP Rest Client will format query 
parameters when multiple values are specified for the same parameter key. 
Styles include the normal/expanded format like 
{color:#505f79}foo=v1&foo=v2&foo-v3{color} vs comma-separated like 
{color:#505f79}foo=v1,v2,v3{color} vs array syntax (which is heavily used in 
PHP servers) like {color:#505f79}foo[]=v1&foo[]=v2&foo[]=v3{color}.

 

CXF already covers the first two cases.  This issue should add array syntax and 
should update the MP Rest Client implementation to allow users to select 
between the different styles.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8294) MP Rest Client 2.0: Add spec-defined proxy server support

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8294.

Resolution: Fixed

> MP Rest Client 2.0: Add spec-defined proxy server support
> -
>
> Key: CXF-8294
> URL: https://issues.apache.org/jira/browse/CXF-8294
> Project: CXF
>  Issue Type: Sub-task
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> MP Rest Client 2.0 defines a portable method of specifying proxy server. This 
> issue should be used to implement that (basically map the new method to 
> existing CXF proxy server properties).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8295) MP Rest Client 2.0: Spec-defined followRedirect

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8295.

Resolution: Fixed

> MP Rest Client 2.0: Spec-defined followRedirect
> ---
>
> Key: CXF-8295
> URL: https://issues.apache.org/jira/browse/CXF-8295
> Project: CXF
>  Issue Type: Sub-task
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> MP Rest Client 2.0 creates a portable method for specifying whether a rest 
> client instance should automatically follow redirect responses (usually 30X 
> HTTP response codes).  Since CXF already has support to automatically follow 
> redirects, this issue should be used to map the spec methods to the existing 
> CXF properties.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8075) Plan for CXF 3.4.0 release

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8075:


Just FYI - The plans for JAX-RS 2.2 have changed.  The agreement with Oracle 
won't allow new APIs under the `javax.*` package space, so the Jakarta 
community decided that all projects must release a new major release (under 
Jakarta EE 9) that uses the `jakarta.*` package space.  The Jakarta community 
also decided that the package rename should be the only functional change to go 
in to the next release.  

The JAX-RS (now called Jakarta RESTful Web Services) community decided that it 
will release JAX-RS 3.0 (a milestone build is available in Maven Central) that 
only includes the package rename (it also includes clarifications in the spec 
and javadoc, but no changes to the API other than the package).  Soon after 3.0 
is released, the community will release 3.1 which will include the features 
previously targeted for 2.2 and possibly more.  

I mention this for two reasons: (1) without any new 2.2 release, there may not 
be much reason to wait on the 3.4.0 release, and (2) we had previously 
discussed that CXF 4.0 might implement the latest Jakarta EE 9 specs (with the 
package rename) since it is a breaking change.  I'm fine with whatever is 
decided (3.5.0 or 4.0), but just wanted to make sure we all had the same info.

 

One other thing going into 3.4.0 is MicroProfile Rest Client 2.0.  That's 
another tricky thing... the MP community is halting GA releases until they can 
setup the Working Group within the Eclipse community.  They are looking for 
other vendors to join, so if your company's are interested, let me know - I 
don't have a lot of details, but I can connect you with people who do.  But 
what that means at this moment is that the MP Rest Client 2.0 work (most of 
which is integrated into master) is all based on release candidate builds, not 
GA builds.  I've heard predictions that we should be able to GA in August, but 
that is not a concrete date...   

 

Sorry to be the bearer of (mostly) bad news... If there's anything I can help 
with on these issues, please let me know.  Thanks!

> Plan for CXF 3.4.0 release
> --
>
> Key: CXF-8075
> URL: https://issues.apache.org/jira/browse/CXF-8075
> Project: CXF
>  Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0
>
>
> There are multiple goals targeted for 3.4.0:
>  - align with Jakarta EE (switch to new artifacts / packages)
>  - JAX-RS 2.2, snapshots already available 
> (https://headcrashing.wordpress.com/2019/06/25/jax-rs-2-2-nightly-builds-available/)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (CXF-8075) Plan for CXF 3.4.0 release

[Andy McCright (Jira)]

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

Andy McCright edited comment on CXF-8075 at 6/11/20, 2:53 AM:
--

Just FYI - The plans for JAX-RS 2.2 have changed.  The agreement with Oracle 
won't allow new APIs under the `javax.*`* package space, so the Jakarta 
community decided that all projects must release a new major release (under 
Jakarta EE 9) that uses the `jakarta.` package space.  The Jakarta community 
also decided that the package rename should be the only functional change to go 
in to the next release.  

The JAX-RS (now called Jakarta RESTful Web Services) community decided that it 
will release JAX-RS 3.0 (a milestone build is available in Maven Central) that 
only includes the package rename (it also includes clarifications in the spec 
and javadoc, but no changes to the API other than the package).  Soon after 3.0 
is released, the community will release 3.1 which will include the features 
previously targeted for 2.2 and possibly more.  

I mention this for two reasons: (1) without any new 2.2 release, there may not 
be much reason to wait on the 3.4.0 release, and (2) we had previously 
discussed that CXF 4.0 might implement the latest Jakarta EE 9 specs (with the 
package rename) since it is a breaking change.  I'm fine with whatever is 
decided (3.5.0 or 4.0), but just wanted to make sure we all had the same info.

 

One other thing going into 3.4.0 is MicroProfile Rest Client 2.0.  That's 
another tricky thing... the MP community is halting GA releases until they can 
setup the Working Group within the Eclipse community.  They are looking for 
other vendors to join, so if your company's are interested, let me know - I 
don't have a lot of details, but I can connect you with people who do.  But 
what that means at this moment is that the MP Rest Client 2.0 work (most of 
which is integrated into master) is all based on release candidate builds, not 
GA builds.  I've heard predictions that we should be able to GA in August, but 
that is not a concrete date...   

 

Sorry to be the bearer of (mostly) bad news... If there's anything I can help 
with on these issues, please let me know.  Thanks!


was (Author: amccright):
Just FYI - The plans for JAX-RS 2.2 have changed.  The agreement with Oracle 
won't allow new APIs under the `javax.*` package space, so the Jakarta 
community decided that all projects must release a new major release (under 
Jakarta EE 9) that uses the `jakarta.*` package space.  The Jakarta community 
also decided that the package rename should be the only functional change to go 
in to the next release.  

The JAX-RS (now called Jakarta RESTful Web Services) community decided that it 
will release JAX-RS 3.0 (a milestone build is available in Maven Central) that 
only includes the package rename (it also includes clarifications in the spec 
and javadoc, but no changes to the API other than the package).  Soon after 3.0 
is released, the community will release 3.1 which will include the features 
previously targeted for 2.2 and possibly more.  

I mention this for two reasons: (1) without any new 2.2 release, there may not 
be much reason to wait on the 3.4.0 release, and (2) we had previously 
discussed that CXF 4.0 might implement the latest Jakarta EE 9 specs (with the 
package rename) since it is a breaking change.  I'm fine with whatever is 
decided (3.5.0 or 4.0), but just wanted to make sure we all had the same info.

 

One other thing going into 3.4.0 is MicroProfile Rest Client 2.0.  That's 
another tricky thing... the MP community is halting GA releases until they can 
setup the Working Group within the Eclipse community.  They are looking for 
other vendors to join, so if your company's are interested, let me know - I 
don't have a lot of details, but I can connect you with people who do.  But 
what that means at this moment is that the MP Rest Client 2.0 work (most of 
which is integrated into master) is all based on release candidate builds, not 
GA builds.  I've heard predictions that we should be able to GA in August, but 
that is not a concrete date...   

 

Sorry to be the bearer of (mostly) bad news... If there's anything I can help 
with on these issues, please let me know.  Thanks!

> Plan for CXF 3.4.0 release
> --
>
> Key: CXF-8075
> URL: https://issues.apache.org/jira/browse/CXF-8075
> Project: CXF
>  Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0
>
>
> There are multiple goals targeted for 3.4.0:
>  - align with Jakarta EE (switch to new artifacts / packages)
>  - JAX-RS 2.2, snapshots already available 
> (https://headcrashing.wordpress.com/2019/06/25/jax-rs-2-2-nightly-builds-avai

[jira] [Created] (CXF-8304) MP Rest Client 2.0: Use CDI-managed providers

[Andy McCright (Jira)]

Andy McCright created CXF-8304:
--

 Summary: MP Rest Client 2.0: Use CDI-managed providers
 Key: CXF-8304
 URL: https://issues.apache.org/jira/browse/CXF-8304
 Project: CXF
  Issue Type: Sub-task
  Components: MicroProfile
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.4.0


In MP Rest Client [issue 
256|https://github.com/eclipse/microprofile-rest-client/issues/256] 
(implemented by [PR 
277|https://github.com/eclipse/microprofile-rest-client/pull/277], 
implementations are required to check (1) if CDI exists in the runtime and (2) 
if CDI is managing an instance of the provider class specified by the client 
interface - and if so, then use the CDI-managed provider instead of creating 
one using newInstance().  This applies for cases where the provider _class_ is 
registered, not a pre-created _instance_ of the provider.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8299) MP Rest Client 2.0: Handle different Query Parameter types

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8299.

Resolution: Fixed

> MP Rest Client 2.0: Handle different Query Parameter types
> --
>
> Key: CXF-8299
> URL: https://issues.apache.org/jira/browse/CXF-8299
> Project: CXF
>  Issue Type: Sub-task
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> See MP Rest Client Issue [217|[MP Rest Client overlooks Collection handling 
> in params|https://github.com/eclipse/microprofile-rest-client/issues/217]]
>  
> Users would like to configure how the MP Rest Client will format query 
> parameters when multiple values are specified for the same parameter key. 
> Styles include the normal/expanded format like 
> {color:#505f79}foo=v1&foo=v2&foo-v3{color} vs comma-separated like 
> {color:#505f79}foo=v1,v2,v3{color} vs array syntax (which is heavily used in 
> PHP servers) like {color:#505f79}foo[]=v1&foo[]=v2&foo[]=v3{color}.
>  
> CXF already covers the first two cases.  This issue should add array syntax 
> and should update the MP Rest Client implementation to allow users to select 
> between the different styles.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8304) MP Rest Client 2.0: Use CDI-managed providers

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8304.

Resolution: Fixed

> MP Rest Client 2.0: Use CDI-managed providers
> -
>
> Key: CXF-8304
> URL: https://issues.apache.org/jira/browse/CXF-8304
> Project: CXF
>  Issue Type: Sub-task
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> In MP Rest Client [issue 
> 256|https://github.com/eclipse/microprofile-rest-client/issues/256] 
> (implemented by [PR 
> 277|https://github.com/eclipse/microprofile-rest-client/pull/277], 
> implementations are required to check (1) if CDI exists in the runtime and 
> (2) if CDI is managing an instance of the provider class specified by the 
> client interface - and if so, then use the CDI-managed provider instead of 
> creating one using newInstance().  This applies for cases where the provider 
> _class_ is registered, not a pre-created _instance_ of the provider.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8262) Implement MicroProfile Rest Client 2.0

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8262.

Resolution: Fixed

> Implement MicroProfile Rest Client 2.0
> --
>
> Key: CXF-8262
> URL: https://issues.apache.org/jira/browse/CXF-8262
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> The MicroProfile Rest Client 2.0 API is scheduled for release in June 2020.  
> The milestone plan for the 2.0 release is available here:
> [https://github.com/eclipse/microprofile-rest-client/milestone/6]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8262) Implement MicroProfile Rest Client 2.0

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8262:


[~coheigea] - Sorry for not responding earlier - this is effectively done now, 
but due to issues with MicroProfile Working Group, they cannot release a GA 
version of the MP Rest Client APIs until August at the earliest.

The implementation in CXF is done though (using the latest release candidate of 
the APIs) and I don't anticipate any changes to the API between RC2 and GA, so 
I'll mark this as resolved.

Thanks!

> Implement MicroProfile Rest Client 2.0
> --
>
> Key: CXF-8262
> URL: https://issues.apache.org/jira/browse/CXF-8262
> Project: CXF
>  Issue Type: New Feature
>  Components: MicroProfile
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.0
>
>
> The MicroProfile Rest Client 2.0 API is scheduled for release in June 2020.  
> The milestone plan for the 2.0 release is available here:
> [https://github.com/eclipse/microprofile-rest-client/milestone/6]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8345) Improve Performance by avoiding MessageImpl resizing

[Andy McCright (Jira)]

Andy McCright created CXF-8345:
--

 Summary: Improve Performance by avoiding MessageImpl resizing
 Key: CXF-8345
 URL: https://issues.apache.org/jira/browse/CXF-8345
 Project: CXF
  Issue Type: Improvement
Affects Versions: 3.4.0
Reporter: Andy McCright
Assignee: Andy McCright


The IBM performance team noticed that a significant amount of time is spent 
resizing the underlying data store of MessageImpl when using CXF in Open 
Liberty, and that a lot of time/resources can be saved by specifying an initial 
size of 16 and a load factor of 1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8346) JAX-RS TCK: Resolve test cases where empty entities are checked

[Andy McCright (Jira)]

Andy McCright created CXF-8346:
--

 Summary: JAX-RS TCK: Resolve test cases where empty entities are 
checked
 Key: CXF-8346
 URL: https://issues.apache.org/jira/browse/CXF-8346
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.4.0
Reporter: Andy McCright
Assignee: Andy McCright


In Open Liberty's "fork" of CXF, we made some changes to better handle cases 
where an entity is empty.  IIRC (and we made this change a while back, so my 
memory is a little fuzzy), the TCK checks things where the entity stream is 
null and when the entity stream is non-null but empty - in both cases the 
"hasEntity" method should return false.  I believe that the changes that we 
made affected multiple similar test cases to this one:
com/sun/ts/tests/jaxrs/ee/rs/container/requestcontext/JAXRSClient.java#hasEntityWhenNoEntityTest_from_standalone:
  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8347) URL/URI Handling issues

[Andy McCright (Jira)]

Andy McCright created CXF-8347:
--

 Summary: URL/URI Handling issues
 Key: CXF-8347
 URL: https://issues.apache.org/jira/browse/CXF-8347
 Project: CXF
  Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Andy McCright


There have been a few cases where IBM has made changes to the Open Liberty 
"fork" of CXF to resolve issues with URLs/URIs, including:
* EndpointInfo can occasionally be set to null in multithreaded environments 
causing NPEs on subsequent lookups.
* URITemplate needs better handling of parameter resolution.
* URITemplate is expensive and many times the same URI is re-generated - a 
cache should speed up performance and CPU utilization.
* FormUtils.isFormPostRequest() does not take into account charset parameters 
or sub-types, etc.
* HttpUtils base URI processing can be optimized for better performance
* Lifecycle methods (PostConstruct/PreDestroy) need to be able to be invoked 
even if they are package/protected.
* Async Resource methods are not required to be void return types
* Need to be able to handle CDI constructor injection into resources/providers
* A few doPrivs needed for environments running with a Java 2 security manager
* Need a way to "wrap" the runnable used by the workqueue in HTTPConduit - Open 
Liberty basically needs a way to transfer contexts (like Java EE metadata, 
security contexts, etc.)
* 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8347) URL/URI Handling issues

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8347:


also TCK test 
com/sun/ts/tests/jaxrs/servlet3/rs/applicationpath/JAXRSClient.java#applicationPathAnnotationEncodedTest_from_standalone
 failed without the UriEncoder class change.

> URL/URI Handling issues
> ---
>
> Key: CXF-8347
> URL: https://issues.apache.org/jira/browse/CXF-8347
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Andy McCright
>Priority: Major
>
> There have been a few cases where IBM has made changes to the Open Liberty 
> "fork" of CXF to resolve issues with URLs/URIs, including:
> * EndpointInfo can occasionally be set to null in multithreaded environments 
> causing NPEs on subsequent lookups.
> * URITemplate needs better handling of parameter resolution.
> * URITemplate is expensive and many times the same URI is re-generated - a 
> cache should speed up performance and CPU utilization.
> * FormUtils.isFormPostRequest() does not take into account charset parameters 
> or sub-types, etc.
> * HttpUtils base URI processing can be optimized for better performance
> * Lifecycle methods (PostConstruct/PreDestroy) need to be able to be invoked 
> even if they are package/protected.
> * Async Resource methods are not required to be void return types
> * Need to be able to handle CDI constructor injection into resources/providers
> * A few doPrivs needed for environments running with a Java 2 security manager
> * Need a way to "wrap" the runnable used by the workqueue in HTTPConduit - 
> Open Liberty basically needs a way to transfer contexts (like Java EE 
> metadata, security contexts, etc.)
> * 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8345) Improve Performance by avoiding MessageImpl resizing

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8345.

Fix Version/s: 3.4.1
   Resolution: Fixed

> Improve Performance by avoiding MessageImpl resizing
> 
>
> Key: CXF-8345
> URL: https://issues.apache.org/jira/browse/CXF-8345
> Project: CXF
>  Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.1
>
>
> The IBM performance team noticed that a significant amount of time is spent 
> resizing the underlying data store of MessageImpl when using CXF in Open 
> Liberty, and that a lot of time/resources can be saved by specifying an 
> initial size of 16 and a load factor of 1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8346) JAX-RS TCK: Resolve test cases where empty entities are checked

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8346.

Fix Version/s: 3.4.1
   Resolution: Fixed

> JAX-RS TCK: Resolve test cases where empty entities are checked
> ---
>
> Key: CXF-8346
> URL: https://issues.apache.org/jira/browse/CXF-8346
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.4.0
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.4.1
>
>
> In Open Liberty's "fork" of CXF, we made some changes to better handle cases 
> where an entity is empty.  IIRC (and we made this change a while back, so my 
> memory is a little fuzzy), the TCK checks things where the entity stream is 
> null and when the entity stream is non-null but empty - in both cases the 
> "hasEntity" method should return false.  I believe that the changes that we 
> made affected multiple similar test cases to this one:
> com/sun/ts/tests/jaxrs/ee/rs/container/requestcontext/JAXRSClient.java#hasEntityWhenNoEntityTest_from_standalone:
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8353) MediaTypeProviderFactory not handling all invalid media types

[Andy McCright (Jira)]

Andy McCright created CXF-8353:
--

 Summary: MediaTypeProviderFactory not handling all invalid media 
types
 Key: CXF-8353
 URL: https://issues.apache.org/jira/browse/CXF-8353
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.4.0
Reporter: Andy McCright
Assignee: Andy McCright


According to https://tools.ietf.org/html/rfc2045#section-5.1 there are a lot of 
characters that are not allowed in the type or subtype fields of a MIME 
/MediaType.  Currently, CXF only checks for '/' in the subtype.

Instead it should be checking for:
 tspecials :=  "(" / ")" / "<" / ">" / "@" /
   "," / ";" / ":" / "\" / <">
   "/" / "[" / "]" / "?" / "="
   ; Must be in quoted-string,
   ; to use within parameter values



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (CXF-8353) MediaTypeHeaderProvider not handling all invalid media types

[Andy McCright (Jira)]

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

Andy McCright updated CXF-8353:
---
Summary: MediaTypeHeaderProvider not handling all invalid media types  
(was: MediaTypeProviderFactory not handling all invalid media types)

> MediaTypeHeaderProvider not handling all invalid media types
> 
>
> Key: CXF-8353
> URL: https://issues.apache.org/jira/browse/CXF-8353
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.4.0
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
>
> According to https://tools.ietf.org/html/rfc2045#section-5.1 there are a lot 
> of characters that are not allowed in the type or subtype fields of a MIME 
> /MediaType.  Currently, CXF only checks for '/' in the subtype.
> Instead it should be checking for:
>  tspecials :=  "(" / ")" / "<" / ">" / "@" /
>"," / ";" / ":" / "\" / <">
>"/" / "[" / "]" / "?" / "="
>; Must be in quoted-string,
>; to use within parameter values



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8401) "tried to access protected method" exception after updating Java 14 to 15

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8401:


[~reta] This looks like the same issue we ran into with Open Liberty (see 
https://github.com/OpenLiberty/open-liberty/pull/14543 ) - our fix was to make 
the compareCustomStatus method public.  If you'd like, I could do the same fix 
here.

> "tried to access protected method" exception after updating Java 14 to 15
> -
>
> Key: CXF-8401
> URL: https://issues.apache.org/jira/browse/CXF-8401
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS, MicroProfile
>Affects Versions: 3.4.1, 3.4.2
>Reporter: Flavio Donzé
>Assignee: Andriy Redko
>Priority: Major
>
> After updaten Java From Version 14 to 15 the following exception is thrown in 
> the client application: 
> java.lang.IllegalAccessError: class 
> org.apache.cxf.microprofile.client.MicroProfileClientProviderFactory$$Lambda$171/0x000800f595f8
>  tried to access protected method 'int 
> org.apache.cxf.jaxrs.provider.ProviderFactory.compareCustomStatus(org.apache.cxf.jaxrs.model.ProviderInfo,
>  org.apache.cxf.jaxrs.model.ProviderInfo)' 
> (org.apache.cxf.microprofile.client.MicroProfileClientProviderFactory$$Lambda$171/0x000800f595f8
>  is in unnamed module of loader 
> org.eclipse.osgi.internal.loader.EquinoxClassLoader @1bc49bc5; 
> org.apache.cxf.jaxrs.provider.ProviderFactory is in unnamed module of loader 
> org.eclipse.osgi.internal.loader.EquinoxClassLoader @50756c76)
>   at 
> org.apache.cxf.microprofile.client.ContractComparator.compare(ContractComparator.java:41)
>   at 
> org.apache.cxf.microprofile.client.ContractComparator.compare(ContractComparator.java:29)
>   at 
> java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
>   at java.base/java.util.TimSort.sort(TimSort.java:220)
>   at java.base/java.util.Arrays.sort(Arrays.java:1306)
>   at java.base/java.util.ArrayList.sort(ArrayList.java:1721)
>   at 
> org.apache.cxf.jaxrs.provider.ProviderFactory.doCustomSort(ProviderFactory.java:779)
>   at 
> org.apache.cxf.jaxrs.provider.ProviderFactory.sortReaders(ProviderFactory.java:735)
>   at 
> org.apache.cxf.jaxrs.provider.ProviderFactory.setProviderComparator(ProviderFactory.java:1477)
>   at 
> org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.setupFactory(AbstractJAXRSFactoryBean.java:330)
>   at 
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.initClient(JAXRSClientFactoryBean.java:383)
>   at 
> org.apache.cxf.microprofile.client.MicroProfileClientFactoryBean.initClient(MicroProfileClientFactoryBean.java:99)
>   at 
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.createWithValues(JAXRSClientFactoryBean.java:311)
>   at 
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.create(JAXRSClientFactoryBean.java:264)
>   at 
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilder.build(CxfTypeSafeClientBuilder.java:149)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8408) Response.getLocation() returns null after update from CXF 3.3.6 to 3.4.1

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8408:


Hi [~hohwille], [~reta],

The 3.3.6 behavior was wrong from the start.  I made the original change to put 
the request's URI in the Response's location property when I implemented 
MicroProfile Rest Client 1.1[1], but this change violated the JAX-RS 
specification so I reverted that change in a subsequent change[2].

Per the JAX-RS TCK [3 and 4], the Response's location property corresponds to 
the HTTP response's `Location` header - so it should not be used for the 
request URI - it should only be non-null if the HTTP response contains a 
non-null value in the `Location` header. 

I certainly see the value of getting the request URI from the Response object.  
Perhaps a solution here would be to add a new getRequestUri() method to 
ResponseImpl that would return the request URI?  

Hope this helps!


[1] https://github.com/apache/cxf/pull/396
[2] https://github.com/apache/cxf/pull/697
[3] 
https://github.com/eclipse-ee4j/jakartaee-tck/blob/c457c40af61d307b0dea0e0489fed7ab4c3e8490/src/com/sun/ts/tests/jaxrs/ee/rs/core/response/JAXRSClient.java#L766
[4] 
https://github.com/eclipse-ee4j/jakartaee-tck/blob/c457c40af61d307b0dea0e0489fed7ab4c3e8490/src/com/sun/ts/tests/jaxrs/ee/rs/core/response/JAXRSClient.java#L783

> Response.getLocation() returns null after update from CXF 3.3.6 to 3.4.1
> 
>
> Key: CXF-8408
> URL: https://issues.apache.org/jira/browse/CXF-8408
> Project: CXF
>  Issue Type: Improvement
>Affects Versions: 3.4.1
>Reporter: Jörg Hohwiller
>Priority: Major
>
> javax.ws.rs.core.Response.getLocation() used to return the URL of the service 
> invoked. We used this information to enhance the error handling via a custom 
> org.apache.cxf.jaxrs.client.ResponseExceptionMapper since CXF lacks to 
> provide contextual information in error scenarios making it hard to use in 
> productive environments when service client invocations fail without 
> contextual information available.
> After we now updated from 3.3.6 to 3.4.1 one of our tests failed with an NPE 
> since response.getLocation() now returns null instead of the correct URL and 
> we were doing url.toString() on that without checking for null.
> I am working on ugly workarounds (casting to ResponseImpl and getting the 
> Conduit to retrieve at least the base URL) but it would be great if CXF could 
> fix this regression bug at the root.
> [https://github.com/devonfw/devon4j/pull/310/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CXF-8427) Response exception mappers not invoked on MP async methods

[Andy McCright (Jira)]

Andy McCright created CXF-8427:
--

 Summary: Response exception mappers not invoked on MP async methods
 Key: CXF-8427
 URL: https://issues.apache.org/jira/browse/CXF-8427
 Project: CXF
  Issue Type: Bug
  Components: MicroProfile
Affects Versions: 3.4.2
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.5.0, 3.4.3


MP Async methods have a return type of CompletionStage and the exception 
processing should occur via the CS, not on the actual invocation of the method. 
 So if a response exception mapper is registered with a MP Rest Client 
interface, the associated exception should be on the throws clause for 
synchronous methods, but not necessarily for asynchronous methods.

Here's and example:

{code:java}
public interface MyClient {
  @GET 
  @Path("sync")
  String getSync() throws MyCustomException;

  @GET 
  @Path("async")
  CompletionStage getAync();
{code}

{code:java}
public class MyCustomExceptionResponseMapper implements 
ResponseExceptionMapper {
@Override
public boolean handles(int status, MultivaluedMap headers) {
return status == 499;
}
@Override
public MyCustomException toThrowable(Response response) {
return new MyCustomException();
}
}
{code}

For sync invocation, we would expect the invocation to throw the exception:
{code:java}
try {
myClient.getSync();
} catch (MyCustomException ex) {
//...
}
{code}

But for async invocation, we would expect the exception to be throw from the 
CompletionStage, like:

{code:java}
CompletionStage cs = myClient.getAsync();
cs.exceptionally(ex -> {
Throwable cause = ex.getCause(); // ex should be a CompletionException
if (cause instanceof MyCustomException) {
// ...
}
});
// or
try {
cs.toCompletableFuture().get();
} catch (ExecutionException ex) {
Throwable cause = ex.getCause();
if (cause instanceof MyCustomException) {
//...
}
}
{code}

Currently, the async flow fails because CXF is checking that the exception type 
is listed in the throws clause of the interface method signature.  So instead 
of throwing a MyCustomException wrapped in a CompletionException (or 
ExecutionException), it is throwing a wrapped WebApplicationException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CXF-8427) Response exception mappers not invoked on MP async methods

[Andy McCright (Jira)]

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

Andy McCright commented on CXF-8427:


Resolved with commit 01106a1171fd53c5077cbae74143e1421977d91e [1]

[1] 
https://github.com/apache/cxf/commit/a84f6e203940e93d81406031d571052ccb4e3fef

> Response exception mappers not invoked on MP async methods
> --
>
> Key: CXF-8427
> URL: https://issues.apache.org/jira/browse/CXF-8427
> Project: CXF
>  Issue Type: Bug
>  Components: MicroProfile
>Affects Versions: 3.4.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.5.0, 3.4.3
>
>
> MP Async methods have a return type of CompletionStage and the exception 
> processing should occur via the CS, not on the actual invocation of the 
> method.  So if a response exception mapper is registered with a MP Rest 
> Client interface, the associated exception should be on the throws clause for 
> synchronous methods, but not necessarily for asynchronous methods.
> Here's and example:
> {code:java}
> public interface MyClient {
>   @GET 
>   @Path("sync")
>   String getSync() throws MyCustomException;
>   @GET 
>   @Path("async")
>   CompletionStage getAync();
> {code}
> {code:java}
> public class MyCustomExceptionResponseMapper implements 
> ResponseExceptionMapper {
> @Override
> public boolean handles(int status, MultivaluedMap 
> headers) {
> return status == 499;
> }
> @Override
> public MyCustomException toThrowable(Response response) {
> return new MyCustomException();
> }
> }
> {code}
> For sync invocation, we would expect the invocation to throw the exception:
> {code:java}
> try {
> myClient.getSync();
> } catch (MyCustomException ex) {
> //...
> }
> {code}
> But for async invocation, we would expect the exception to be throw from the 
> CompletionStage, like:
> {code:java}
> CompletionStage cs = myClient.getAsync();
> cs.exceptionally(ex -> {
> Throwable cause = ex.getCause(); // ex should be a CompletionException
> if (cause instanceof MyCustomException) {
> // ...
> }
> });
> // or
> try {
> cs.toCompletableFuture().get();
> } catch (ExecutionException ex) {
> Throwable cause = ex.getCause();
> if (cause instanceof MyCustomException) {
> //...
> }
> }
> {code}
> Currently, the async flow fails because CXF is checking that the exception 
> type is listed in the throws clause of the interface method signature.  So 
> instead of throwing a MyCustomException wrapped in a CompletionException (or 
> ExecutionException), it is throwing a wrapped WebApplicationException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (CXF-8427) Response exception mappers not invoked on MP async methods

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8427.

Resolution: Fixed

> Response exception mappers not invoked on MP async methods
> --
>
> Key: CXF-8427
> URL: https://issues.apache.org/jira/browse/CXF-8427
> Project: CXF
>  Issue Type: Bug
>  Components: MicroProfile
>Affects Versions: 3.4.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.5.0, 3.4.3
>
>
> MP Async methods have a return type of CompletionStage and the exception 
> processing should occur via the CS, not on the actual invocation of the 
> method.  So if a response exception mapper is registered with a MP Rest 
> Client interface, the associated exception should be on the throws clause for 
> synchronous methods, but not necessarily for asynchronous methods.
> Here's and example:
> {code:java}
> public interface MyClient {
>   @GET 
>   @Path("sync")
>   String getSync() throws MyCustomException;
>   @GET 
>   @Path("async")
>   CompletionStage getAync();
> {code}
> {code:java}
> public class MyCustomExceptionResponseMapper implements 
> ResponseExceptionMapper {
> @Override
> public boolean handles(int status, MultivaluedMap 
> headers) {
> return status == 499;
> }
> @Override
> public MyCustomException toThrowable(Response response) {
> return new MyCustomException();
> }
> }
> {code}
> For sync invocation, we would expect the invocation to throw the exception:
> {code:java}
> try {
> myClient.getSync();
> } catch (MyCustomException ex) {
> //...
> }
> {code}
> But for async invocation, we would expect the exception to be throw from the 
> CompletionStage, like:
> {code:java}
> CompletionStage cs = myClient.getAsync();
> cs.exceptionally(ex -> {
> Throwable cause = ex.getCause(); // ex should be a CompletionException
> if (cause instanceof MyCustomException) {
> // ...
> }
> });
> // or
> try {
> cs.toCompletableFuture().get();
> } catch (ExecutionException ex) {
> Throwable cause = ex.getCause();
> if (cause instanceof MyCustomException) {
> //...
> }
> }
> {code}
> Currently, the async flow fails because CXF is checking that the exception 
> type is listed in the throws clause of the interface method signature.  So 
> instead of throwing a MyCustomException wrapped in a CompletionException (or 
> ExecutionException), it is throwing a wrapped WebApplicationException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (CXF-8462) jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright reassigned CXF-8462:
--

Assignee: Andy McCright

> jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest 
> 
>
> Key: CXF-8462
> URL: https://issues.apache.org/jira/browse/CXF-8462
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Assignee: Andy McCright
>Priority: Major
> Attachments: 
> JAXRSClient_formParamEntityWithEncodedTest_from_standalone.jtr, javatest.log, 
> test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> ParamParamEntityWithConstructor=DefaultParamValueParamParamEntityWithFromString=!ParamParamEntityWithValueOf=DefaultParamValueParamSetParamEntityWithFromString=DefaultParamValueParamSortedSetParamEntityWithFromString=DefaultParamValueParamListParamEntityWithFromString=DefaultParamValueInnerParamParamEntityWithConstructor=DefaultParamValueInnerParamParamEntityWithFromString=!InnerParamParamEntityWithValueOf=DefaultParamValueInnerParamSetParamEntityWithFromString=DefaultParamValueInnerParamSortedSetParamEntityWithFromString=DefaultParamValueInnerParamListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.paramEntityWithEncodedTest(JaxrsParamClient.java:183)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formParamEntityWithEncodedTest(JAXRSClient.java:194)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  [JAXRSCommonClient] Test cleanup OK
> [javatest.batch] STATUS:Failed.Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] Apr 15, 2021 9:23:21 PM Finished executing all tests, wait 
> for cleanup...
> [javatest.batch] Apr 15, 2021 9:23:21 PM Harness done with cleanup from test 
> run.
> [javatest

[jira] [Resolved] (CXF-8462) jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8462.

Fix Version/s: 3.5.0
   Resolution: Fixed

Should be resolved by https://github.com/apache/cxf/pull/778

> jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest 
> 
>
> Key: CXF-8462
> URL: https://issues.apache.org/jira/browse/CXF-8462
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.5.0
>
> Attachments: 
> JAXRSClient_formParamEntityWithEncodedTest_from_standalone.jtr, javatest.log, 
> test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> ParamParamEntityWithConstructor=DefaultParamValueParamParamEntityWithFromString=!ParamParamEntityWithValueOf=DefaultParamValueParamSetParamEntityWithFromString=DefaultParamValueParamSortedSetParamEntityWithFromString=DefaultParamValueParamListParamEntityWithFromString=DefaultParamValueInnerParamParamEntityWithConstructor=DefaultParamValueInnerParamParamEntityWithFromString=!InnerParamParamEntityWithValueOf=DefaultParamValueInnerParamSetParamEntityWithFromString=DefaultParamValueInnerParamSortedSetParamEntityWithFromString=DefaultParamValueInnerParamListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.paramEntityWithEncodedTest(JaxrsParamClient.java:183)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formParamEntityWithEncodedTest(JAXRSClient.java:194)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  [JAXRSCommonClient] Test cleanup OK
> [javatest.batch] STATUS:Failed.Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] Apr 15, 2021 9:23:21 PM Finished executing all tests, wait 
> for

[jira] [Resolved] (CXF-8461) jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright resolved CXF-8461.

Fix Version/s: 3.5.0
   Resolution: Fixed

Should be resolved by https://github.com/apache/cxf/pull/778

> jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest 
> -
>
> Key: CXF-8461
> URL: https://issues.apache.org/jira/browse/CXF-8461
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Priority: Major
> Fix For: 3.5.0
>
> Attachments: 
> JAXRSClient_formFieldParamEntityWithEncodedTest_from_standalone.jtr, 
> javatest.log, test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] WARNING: HttpConnectionManager is null.  Connection cannot 
> be released.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: [WebValidatorBase] Unable to 
> find the following search string in the server's response: 
> 'FieldParamEntityWithFromString=%21' at index: 0
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> FieldParamEntityWithConstructor=DefaultParamValueFieldParamEntityWithFromString=!FieldParamEntityWithValueOf=DefaultParamValueFieldSetParamEntityWithFromString=DefaultParamValueFieldSortedSetParamEntityWithFromString=DefaultParamValueFieldListParamEntityWithFromString=DefaultParamValueInnerFieldParamEntityWithConstructor=DefaultParamValueInnerFieldParamEntityWithFromString=!InnerFieldParamEntityWithValueOf=DefaultParamValueInnerFieldSetParamEntityWithFromString=DefaultParamValueInnerFieldSortedSetParamEntityWithFromString=DefaultParamValueInnerFieldListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.fieldEntityWithEncodedTest(JaxrsParamClient.java:192)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formFieldParamEntityWithEncodedTest(JAXRSClient.java:205)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.bat

[jira] [Assigned] (CXF-8461) jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright reassigned CXF-8461:
--

Assignee: Andy McCright

> jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest 
> -
>
> Key: CXF-8461
> URL: https://issues.apache.org/jira/browse/CXF-8461
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.5.0
>
> Attachments: 
> JAXRSClient_formFieldParamEntityWithEncodedTest_from_standalone.jtr, 
> javatest.log, test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] WARNING: HttpConnectionManager is null.  Connection cannot 
> be released.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: [WebValidatorBase] Unable to 
> find the following search string in the server's response: 
> 'FieldParamEntityWithFromString=%21' at index: 0
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> FieldParamEntityWithConstructor=DefaultParamValueFieldParamEntityWithFromString=!FieldParamEntityWithValueOf=DefaultParamValueFieldSetParamEntityWithFromString=DefaultParamValueFieldSortedSetParamEntityWithFromString=DefaultParamValueFieldListParamEntityWithFromString=DefaultParamValueInnerFieldParamEntityWithConstructor=DefaultParamValueInnerFieldParamEntityWithFromString=!InnerFieldParamEntityWithValueOf=DefaultParamValueInnerFieldSetParamEntityWithFromString=DefaultParamValueInnerFieldSortedSetParamEntityWithFromString=DefaultParamValueInnerFieldListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.fieldEntityWithEncodedTest(JaxrsParamClient.java:192)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formFieldParamEntityWithEncodedTest(JAXRSClient.java:205)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:22:37:  [JAXRSCommonClie

[jira] [Updated] (CXF-8461) jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright updated CXF-8461:
---
Fix Version/s: 3.4.4

> jaxrs.ee.rs.beanparam.form.plain formFieldParamEntityWithEncodedTest 
> -
>
> Key: CXF-8461
> URL: https://issues.apache.org/jira/browse/CXF-8461
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.5.0, 3.4.4
>
> Attachments: 
> JAXRSClient_formFieldParamEntityWithEncodedTest_from_standalone.jtr, 
> javatest.log, test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] WARNING: HttpConnectionManager is null.  Connection cannot 
> be released.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: [WebValidatorBase] Unable to 
> find the following search string in the server's response: 
> 'FieldParamEntityWithFromString=%21' at index: 0
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> FieldParamEntityWithConstructor=DefaultParamValueFieldParamEntityWithFromString=!FieldParamEntityWithValueOf=DefaultParamValueFieldSetParamEntityWithFromString=DefaultParamValueFieldSortedSetParamEntityWithFromString=DefaultParamValueFieldListParamEntityWithFromString=DefaultParamValueInnerFieldParamEntityWithConstructor=DefaultParamValueInnerFieldParamEntityWithFromString=!InnerFieldParamEntityWithValueOf=DefaultParamValueInnerFieldSetParamEntityWithFromString=DefaultParamValueInnerFieldSortedSetParamEntityWithFromString=DefaultParamValueInnerFieldListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:22:37:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.fieldEntityWithEncodedTest(JaxrsParamClient.java:192)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formFieldParamEntityWithEncodedTest(JAXRSClient.java:205)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:22:37:  [JAXRSCommonClient]

[jira] [Updated] (CXF-8462) jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest

[Andy McCright (Jira)]

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

Andy McCright updated CXF-8462:
---
Fix Version/s: 3.4.4

> jaxrs.ee.rs.beanparam.form.plain formParamEntityWithEncodedTest 
> 
>
> Key: CXF-8462
> URL: https://issues.apache.org/jira/browse/CXF-8462
> Project: CXF
>  Issue Type: Sub-task
>Affects Versions: 3.4.3
>Reporter: David Blevins
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.5.0, 3.4.4
>
> Attachments: 
> JAXRSClient_formParamEntityWithEncodedTest_from_standalone.jtr, javatest.log, 
> test.txt
>
>
> Full test name:
> {code}
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> Running it locally:
> {code}
> git clone g...@github.com:tckwork/cxf.git
> cd cxf
> ./runtests 
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formParamEntityWithEncodedTest_from_standalone
> {code}
> At the time this issue was filed, the test failed with the following output.
> {code}
> [javatest.batch] [WebValidatorBase] Server's response:
> [javatest.batch] ---
> [javatest.batch] 
> ParamParamEntityWithConstructor=DefaultParamValueParamParamEntityWithFromString=!ParamParamEntityWithValueOf=DefaultParamValueParamSetParamEntityWithFromString=DefaultParamValueParamSortedSetParamEntityWithFromString=DefaultParamValueParamListParamEntityWithFromString=DefaultParamValueInnerParamParamEntityWithConstructor=DefaultParamValueInnerParamParamEntityWithFromString=!InnerParamParamEntityWithValueOf=DefaultParamValueInnerParamSetParamEntityWithFromString=DefaultParamValueInnerParamSortedSetParamEntityWithFromString=DefaultParamValueInnerParamListParamEntityWithFromString=DefaultParamValue
> [javatest.batch] ---
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: Exception at:  
> [javatest.batch] 04-15-2021 21:23:19:  ERROR: 
> com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED!
> [javatest.batch]  at 
> com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:180)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.common.JAXRSCommonClient.invoke(JAXRSCommonClient.java:307)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.invoke(BeanParamCommonClient.java:114)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.buildRequestAndInvoke(BeanParamCommonClient.java:122)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.paramEntity(BeanParamCommonClient.java:95)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.BeanParamCommonClient.fieldOrParamEncodedTest(BeanParamCommonClient.java:81)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.JaxrsParamClient.paramEntityWithEncodedTest(JaxrsParamClient.java:183)
> [javatest.batch]  at 
> com.sun.ts.tests.jaxrs.ee.rs.beanparam.form.plain.JAXRSClient.formParamEntityWithEncodedTest(JAXRSClient.java:194)
> [javatest.batch]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [javatest.batch]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch]  at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> [javatest.batch]  at 
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> [javatest.batch]  at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> [javatest.batch]  at 
> com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> [javatest.batch] 
> [javatest.batch] 04-15-2021 21:23:19:  [JAXRSCommonClient] Test cleanup OK
> [javatest.batch] STATUS:Failed.Test case throws exception: 
> [JAXRSCommonClient] null failed! Check output for cause of failure.
> [javatest.batch] Apr 15, 2021 9:23:21 PM Finished executing all tests, wait 
> for cleanup...
> [javatest.batch] Apr 15, 2021 9:23:21 PM Harness done with cleanup f

[jira] [Commented] (CXF-7349) NPE in ClassLoaderUtils

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7349:


Merged to master and 3.1.x-fixes

> NPE in ClassLoaderUtils
> ---
>
> Key: CXF-7349
> URL: https://issues.apache.org/jira/browse/CXF-7349
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.11
>Reporter: Andy McCright
> Fix For: 3.2.0, 3.1.12
>
>
> A NullPointerException can be thrown when the JVM's boot classloader is set 
> as the thread's context classloader.  Ex:
> URL url = 
> Thread.currentThread().getContextClassLoader().getResource(resourceName);
> The call to getContextClassLoader() could return null - that is a valid 
> return from that method.  In that case, we should use 
> ClassLoader.getSystemClassLoader() instead.
> This issue was reported on in the users mailing list:
> http://cxf.547215.n5.nabble.com/NPE-in-cxf-core-ClassLoaderUtils-possible-bug-td5780007.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CXF-7349) NPE in ClassLoaderUtils

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7349.

Resolution: Fixed

> NPE in ClassLoaderUtils
> ---
>
> Key: CXF-7349
> URL: https://issues.apache.org/jira/browse/CXF-7349
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.11
>Reporter: Andy McCright
> Fix For: 3.2.0, 3.1.12
>
>
> A NullPointerException can be thrown when the JVM's boot classloader is set 
> as the thread's context classloader.  Ex:
> URL url = 
> Thread.currentThread().getContextClassLoader().getResource(resourceName);
> The call to getContextClassLoader() could return null - that is a valid 
> return from that method.  In that case, we should use 
> ClassLoader.getSystemClassLoader() instead.
> This issue was reported on in the users mailing list:
> http://cxf.547215.n5.nabble.com/NPE-in-cxf-core-ClassLoaderUtils-possible-bug-td5780007.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7447) Java 2 security issues

[Andy McCright (JIRA)]

Andy McCright created CXF-7447:
--

 Summary: Java 2 security issues 
 Key: CXF-7447
 URL: https://issues.apache.org/jira/browse/CXF-7447
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.0
Reporter: Andy McCright


We discovered the following Java 2 security issues when a security manager was 
in use:

ERROR: Caught exception attempting to call test method 
testCompletionStageRxInvokerSynchronousFunction on servlet 
web.jaxrstest.JAXRSExecutorTestServlet
java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: 
java.lang.RuntimeException: RuntimeException invoking 
http://localhost:8011/jaxrsapp/testapp/test/info: 
java.security.AccessControlException: Access denied 
("java.net.SocketPermission" "localhost" "resolve")
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:368)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1926)
at 
web.jaxrstest.JAXRSExecutorTestServlet.testCompletionStageRxInvokerSynchronousFunction(JAXRSExecutorTestServlet.java:151)
at componenttest.app.FATServlet.doGet(FATServlet.java:63)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1255)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:743)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:440)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1131)
at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:76)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:922)
at 
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:279)
at 
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:966)
at 
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:358)
at 
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:317)
at 
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:475)
at 
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:409)
at 
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:289)
at 
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:260)
at 
com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:165)
at 
com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:74)
at 
com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:503)
at 
com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:573)
at 
com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:928)
at 
com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1017)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:785)
Caused by: javax.ws.rs.ProcessingException: java.lang.RuntimeException: 
RuntimeException invoking http://localhost:8011/jaxrsapp/testapp/test/info: 
java.security.AccessControlException: Access denied 
("java.net.SocketPermission" "localhost" "resolve")
at 
org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractClient.java:632)
at 
org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient.java:608)
at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1115)
at 
org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1052)
at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:897)
at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:866)
at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:431)
at org.apache.cxf.jaxrs.client.SyncInvokerImpl.method(SyncInvokerImpl.java:135)
at 
org.apache.cxf.jaxrs.client.CompletionStageRxInvokerImpl.lambda$method$4(CompletionStageRxInvokerImpl.java:165)
at 
org.apache.cxf.jaxrs.client.CompletionStageRxInvokerImpl$$Lambda$6.9C382370.get(Unknown
 Source)
at 
java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1601)
Caused by: java.lang.RuntimeException: RuntimeException invoking 
http://localhost:8011/jaxrsapp/testapp/test/info: 
java.security.AccessControlException: Access denied 
("java.net.SocketPermission" "localhost" "resolve")
at java.lang.reflect.Constructor.n

[jira] [Created] (CXF-7448) Enable use of reflection in JAX-RS client by default

[Andy McCright (JIRA)]

Andy McCright created CXF-7448:
--

 Summary: Enable use of reflection in JAX-RS client by default
 Key: CXF-7448
 URL: https://issues.apache.org/jira/browse/CXF-7448
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS
Affects Versions: 3.2.0
Reporter: Andy McCright
 Fix For: 3.2.0


Per discussion on the dev list, we should enable the use of reflection for 
"non-standard" HTTP methods in the JAX-RS client.  By default, the 
HttpURLConnection will only allow "standard" HTTP methods, such as GET, PUT, 
POST, DELETE, OPTIONS and HEAD.  It does not include PATCH or other 
user-defined methods and will throw an exception when a user attempts to use 
one of these methods.

CXF already works around this issue by using reflection to set HTTP method when 
a system property or message property is set.  This bypasses the check and 
allows the method to process.  For CXF 3.2, I would like to make this property 
enabled by default, so that these "non-standard" HTTP methods will work by 
default.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7462) OutboundSseEventImpl could use some minor tweaks

[Andy McCright (JIRA)]

Andy McCright created CXF-7462:
--

 Summary: OutboundSseEventImpl could use some minor tweaks
 Key: CXF-7462
 URL: https://issues.apache.org/jira/browse/CXF-7462
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS
Affects Versions: 3.2.0
Reporter: Andy McCright
Priority: Minor
 Fix For: 3.2.0


The OutboundSseEventImpl class could use some minor tweaks, including:
1) Make the fields final to reflect that the event is immutable.
2) Use defaults for the data type (String.class) and media type 
(SERVER_SENT_EVENT_TYPE).
3) Restrict the constructor's visibility.

I also plan to add some tests for these changes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CXF-7448) Enable use of reflection in JAX-RS client by default

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7448.

Resolution: Fixed

> Enable use of reflection in JAX-RS client by default
> 
>
> Key: CXF-7448
> URL: https://issues.apache.org/jira/browse/CXF-7448
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.2.0
>Reporter: Andy McCright
> Fix For: 3.2.0
>
>
> Per discussion on the dev list, we should enable the use of reflection for 
> "non-standard" HTTP methods in the JAX-RS client.  By default, the 
> HttpURLConnection will only allow "standard" HTTP methods, such as GET, PUT, 
> POST, DELETE, OPTIONS and HEAD.  It does not include PATCH or other 
> user-defined methods and will throw an exception when a user attempts to use 
> one of these methods.
> CXF already works around this issue by using reflection to set HTTP method 
> when a system property or message property is set.  This bypasses the check 
> and allows the method to process.  For CXF 3.2, I would like to make this 
> property enabled by default, so that these "non-standard" HTTP methods will 
> work by default.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CXF-7448) Enable use of reflection in JAX-RS client by default

[Andy McCright (JIRA)]

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

Andy McCright closed CXF-7448.
--

> Enable use of reflection in JAX-RS client by default
> 
>
> Key: CXF-7448
> URL: https://issues.apache.org/jira/browse/CXF-7448
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.2.0
>Reporter: Andy McCright
> Fix For: 3.2.0
>
>
> Per discussion on the dev list, we should enable the use of reflection for 
> "non-standard" HTTP methods in the JAX-RS client.  By default, the 
> HttpURLConnection will only allow "standard" HTTP methods, such as GET, PUT, 
> POST, DELETE, OPTIONS and HEAD.  It does not include PATCH or other 
> user-defined methods and will throw an exception when a user attempts to use 
> one of these methods.
> CXF already works around this issue by using reflection to set HTTP method 
> when a system property or message property is set.  This bypasses the check 
> and allows the method to process.  For CXF 3.2, I would like to make this 
> property enabled by default, so that these "non-standard" HTTP methods will 
> work by default.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7537) Java 2 security failures - doPrivs needed to run with Java 2 security mgr

[Andy McCright (JIRA)]

Andy McCright created CXF-7537:
--

 Summary: Java 2 security failures - doPrivs needed to run with 
Java 2 security mgr
 Key: CXF-7537
 URL: https://issues.apache.org/jira/browse/CXF-7537
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.0, 3.1.11
Reporter: Andy McCright


While doing some Java 2 security testing, I found the following stacks that 
should be wrapped in doPriv blocks:

Caused by: java.security.AccessControlException: Access denied 
("java.util.PropertyPermission" "org.apache.cxf.io.CachedOutputStream.MaxSize" 
"read")
at java.security.AccessController.throwACE(AccessController.java:157)
at 
java.security.AccessController.checkPermissionHelper(AccessController.java:217)
at 
java.security.AccessController.checkPermission(AccessController.java:349)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
at 
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
at java.lang.System.getProperty(System.java:443)
at 
org.apache.cxf.io.CachedOutputStream.setDefaultMaxSize(CachedOutputStream.java:572)
at 
org.apache.cxf.io.CachedOutputStream.(CachedOutputStream.java:70)

java.security.AccessControlException: Access denied 
("java.lang.RuntimePermission" "accessDeclaredMembers")
at java.security.AccessController.throwACE(AccessController.java:157)
at 
java.security.AccessController.checkPermissionHelper(AccessController.java:217)
at 
java.security.AccessController.checkPermission(AccessController.java:349)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
at java.lang.Class.checkMemberAccess(Class.java:200)
at java.lang.Class.getDeclaredMethods(Class.java:992)
at 
org.apache.cxf.jaxrs.utils.ResourceUtils.findPreDestroyMethod(ResourceUtils.java:186)
at 
org.apache.cxf.jaxrs.utils.ResourceUtils.findPreDestroyMethod(ResourceUtils.java:179)
at 
org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.(PerRequestResourceProvider.java:63)

Caused by: java.lang.RuntimeException: java.security.AccessControlException: 
Access denied ("java.net.SocketPermission" "127.0.0.1:8010" "connect,resolve")
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1503)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1489)
at 
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:3034)
at 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:500)
at 
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:370)
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1586)
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1615)
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1559)
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
... 47 more

More may be exposed after resolving these...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7553) selectVariant doesn't take into account quality factors in Accept header

[Andy McCright (JIRA)]

Andy McCright created CXF-7553:
--

 Summary: selectVariant doesn't take into account quality factors 
in Accept header
 Key: CXF-7553
 URL: https://issues.apache.org/jira/browse/CXF-7553
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.1, 3.1.14
Reporter: Andy McCright
Priority: Minor
 Fix For: 3.1.15, 3.2.2


We've got a customer moving from Apache Wink (JAX-RS 1.1) to CXF 3.1.X (JAX-RS 
2.0) and they are seeing subtle differences in the behavior of the 
javax.ws.rs.core.Request.selectVariant method.  According to the spec, the 
returned Variant should be one of the Variants passed in to the selectVariant 
method that is the closest match to the request (based not the Accept, 
Accept-Language, and Accept-Encoding headers).  They see this behavior in Wink, 
but in CXF, they see that the first Variant in the passed-in list that matches 
the request's headers is chosen.

For example, a request with "Accept: a/b, c/d; q=0.5" will return a response 
with "Content-Type: a/b" - assuming that the resource method produces a/b and 
c/d.  However, when the user calls:
List list = new ArrayList();
Variant v1 = new Variant("a/b", (Locale) null, null);
Variant v2 = new Variant("c/d", (Locale) null, null);
Variant v3 = new Variant("not/used", (Locale) null, null);
list.add(v3);
list.add(v2);
list.add(v1);
assertSame(v1, Request.selectVariant(list));

the assertion fails.  Even though the user prefers a/b over c/d by a quality 
factor of 1 vs 0.5, the selectVariant method returns the Variant with c/d.  
This is because the RequestImpl's implementation of the selectVariant method 
only checks the request headers when intersecting the Mime (Media)Types.  

To match Wink's implementation (and my understanding of the spec, though to be 
fair, the spec is somewhat ambiguous...), I think CXF should take the request 
header's quality factors into account when determining which Variant to return. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CXF-7553) selectVariant doesn't take into account quality factors in Accept header

[Andy McCright (JIRA)]

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

Andy McCright reassigned CXF-7553:
--

Assignee: Andy McCright

> selectVariant doesn't take into account quality factors in Accept header
> 
>
> Key: CXF-7553
> URL: https://issues.apache.org/jira/browse/CXF-7553
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.1.15, 3.2.2
>
>
> We've got a customer moving from Apache Wink (JAX-RS 1.1) to CXF 3.1.X 
> (JAX-RS 2.0) and they are seeing subtle differences in the behavior of the 
> javax.ws.rs.core.Request.selectVariant method.  According to the spec, the 
> returned Variant should be one of the Variants passed in to the selectVariant 
> method that is the closest match to the request (based not the Accept, 
> Accept-Language, and Accept-Encoding headers).  They see this behavior in 
> Wink, but in CXF, they see that the first Variant in the passed-in list that 
> matches the request's headers is chosen.
> For example, a request with "Accept: a/b, c/d; q=0.5" will return a response 
> with "Content-Type: a/b" - assuming that the resource method produces a/b and 
> c/d.  However, when the user calls:
> List list = new ArrayList();
> Variant v1 = new Variant("a/b", (Locale) null, null);
> Variant v2 = new Variant("c/d", (Locale) null, null);
> Variant v3 = new Variant("not/used", (Locale) null, null);
> list.add(v3);
> list.add(v2);
> list.add(v1);
> assertSame(v1, Request.selectVariant(list));
> the assertion fails.  Even though the user prefers a/b over c/d by a quality 
> factor of 1 vs 0.5, the selectVariant method returns the Variant with c/d.  
> This is because the RequestImpl's implementation of the selectVariant method 
> only checks the request headers when intersecting the Mime (Media)Types.  
> To match Wink's implementation (and my understanding of the spec, though to 
> be fair, the spec is somewhat ambiguous...), I think CXF should take the 
> request header's quality factors into account when determining which Variant 
> to return. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7527:


Hi [~sergey_beryozkin], this looks like a bug to me.  I modified the test app a 
little and deployed it to Liberty - when I invoked GET 
{{http://localhost:9080/CXF7527/my/resource/aValue/subresource}} , I got 
{{/my/resource/aValue/subresource/,/my/resource/aValue/subresource,/my/resource/aValue}}

When I ran in the EE8 RI (Glassfish 5 - keep in mind that this is JAX-RS 2.1, 
not 2.0, but I don't recall anything changing in the 2.1 spec wrt UriInfo), I 
got {{my/resource/aValue/subresource,my/resource/aValue}}

I did a little debugging of UriInfoImpl and it looks like it adds _essentially_ 
the same path twice.  It loops through the MethodInvocationInfos on the stack - 
there are two (one for the method on Resource, and one for the SubResource).  
The first time through the loop it adds {{/my/resource/aValue}} as the CRI's 
URI template - then it adds {{/my/resource/aValue/subresource}} as the ORI's 
URI template - it also sets that as the sumPath.  The second time through (the 
MethodInvocationInfo for SubResource's method), there is no CRI URI template 
(so nothing added), but it finds an ORI URI template of "/" (implicit?) that it 
appends to the sumPath and then adds it to the List.  I think that is wrong - 
it should not add the URI that basically is the previous URI plus a "/".

I can try to code up a fix for it.

Thanks, Andy


> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI 
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=> 
> {{testMatchedUrisFromSubResource()}}) 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7527:


[~nlenoire] I merged the changes in PR 
[https://github.com/apache/cxf/pull/337].  Is it possible for you to verify 
that this resolves the problem for you?

> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI 
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=> 
> {{testMatchedUrisFromSubResource()}}) 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CXF-7553) selectVariant doesn't take into account quality factors in Accept header

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7553.

Resolution: Fixed

> selectVariant doesn't take into account quality factors in Accept header
> 
>
> Key: CXF-7553
> URL: https://issues.apache.org/jira/browse/CXF-7553
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.1.15, 3.2.2
>
>
> We've got a customer moving from Apache Wink (JAX-RS 1.1) to CXF 3.1.X 
> (JAX-RS 2.0) and they are seeing subtle differences in the behavior of the 
> javax.ws.rs.core.Request.selectVariant method.  According to the spec, the 
> returned Variant should be one of the Variants passed in to the selectVariant 
> method that is the closest match to the request (based not the Accept, 
> Accept-Language, and Accept-Encoding headers).  They see this behavior in 
> Wink, but in CXF, they see that the first Variant in the passed-in list that 
> matches the request's headers is chosen.
> For example, a request with "Accept: a/b, c/d; q=0.5" will return a response 
> with "Content-Type: a/b" - assuming that the resource method produces a/b and 
> c/d.  However, when the user calls:
> List list = new ArrayList();
> Variant v1 = new Variant("a/b", (Locale) null, null);
> Variant v2 = new Variant("c/d", (Locale) null, null);
> Variant v3 = new Variant("not/used", (Locale) null, null);
> list.add(v3);
> list.add(v2);
> list.add(v1);
> assertSame(v1, Request.selectVariant(list));
> the assertion fails.  Even though the user prefers a/b over c/d by a quality 
> factor of 1 vs 0.5, the selectVariant method returns the Variant with c/d.  
> This is because the RequestImpl's implementation of the selectVariant method 
> only checks the request headers when intersecting the Mime (Media)Types.  
> To match Wink's implementation (and my understanding of the spec, though to 
> be fair, the spec is somewhat ambiguous...), I think CXF should take the 
> request header's quality factors into account when determining which Variant 
> to return. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7527.

   Resolution: Fixed
 Assignee: Andy McCright
Fix Version/s: 3.2.2
   3.1.15

> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
>Assignee: Andy McCright
> Fix For: 3.1.15, 3.2.2
>
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI 
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=> 
> {{testMatchedUrisFromSubResource()}}) 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7604) Change to "Error occurred during error handling, give up!" message

[Andy McCright (JIRA)]

Andy McCright created CXF-7604:
--

 Summary: Change to "Error occurred during error handling, give 
up!" message
 Key: CXF-7604
 URL: https://issues.apache.org/jira/browse/CXF-7604
 Project: CXF
  Issue Type: Bug
  Components: Core
Affects Versions: 3.2.1, 3.1.14
Reporter: Andy McCright
Priority: Minor


One of our users complained about the message "Error occurred during error 
handling, give up!" that is output from AbstractFaultChainInitiatorObserver.  
The complaint is that it sounds like the message is telling the user to give 
up, rather than alerting them that error handling process is aborting due to an 
unexpected failure.  

It looks like that message is hardcoded into the Java source instead of loaded 
from the Messages.properties file, so this should probably change to.  I'd like 
to suggest that we change the message to something like this:

_An unexpected error occurred during error handling.  No further error 
processing will occur._

Please comment if you have strong opinions on the proposed wording or have 
other suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CXF-7604) Change to "Error occurred during error handling, give up!" message

[Andy McCright (JIRA)]

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

Andy McCright reassigned CXF-7604:
--

Assignee: Andy McCright

> Change to "Error occurred during error handling, give up!" message
> --
>
> Key: CXF-7604
> URL: https://issues.apache.org/jira/browse/CXF-7604
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
>
> One of our users complained about the message "Error occurred during error 
> handling, give up!" that is output from AbstractFaultChainInitiatorObserver.  
> The complaint is that it sounds like the message is telling the user to give 
> up, rather than alerting them that error handling process is aborting due to 
> an unexpected failure.  
> It looks like that message is hardcoded into the Java source instead of 
> loaded from the Messages.properties file, so this should probably change to.  
> I'd like to suggest that we change the message to something like this:
> _An unexpected error occurred during error handling.  No further error 
> processing will occur._
> Please comment if you have strong opinions on the proposed wording or have 
> other suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CXF-7604) Change to "Error occurred during error handling, give up!" message

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7604.

   Resolution: Fixed
Fix Version/s: 3.2.2
   3.1.15

> Change to "Error occurred during error handling, give up!" message
> --
>
> Key: CXF-7604
> URL: https://issues.apache.org/jira/browse/CXF-7604
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.1.15, 3.2.2
>
>
> One of our users complained about the message "Error occurred during error 
> handling, give up!" that is output from AbstractFaultChainInitiatorObserver.  
> The complaint is that it sounds like the message is telling the user to give 
> up, rather than alerting them that error handling process is aborting due to 
> an unexpected failure.  
> It looks like that message is hardcoded into the Java source instead of 
> loaded from the Messages.properties file, so this should probably change to.  
> I'd like to suggest that we change the message to something like this:
> _An unexpected error occurred during error handling.  No further error 
> processing will occur._
> Please comment if you have strong opinions on the proposed wording or have 
> other suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CXF-7625) JAX-RS 2.1 TCK: UriBuilder doesn't handle case where "port" is not an integer

[Andy McCright (JIRA)]

Andy McCright created CXF-7625:
--

 Summary: JAX-RS 2.1 TCK: UriBuilder doesn't handle case where 
"port" is not an integer
 Key: CXF-7625
 URL: https://issues.apache.org/jira/browse/CXF-7625
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.1
Reporter: Andy McCright
Assignee: Andy McCright


The JAX-RS 2.1 TCK (which isn't public in EE4J yet, but once it is, I'll post a 
link) has a test that checks the String content of a call to URI.toString().  
The URI contains what looks like an HTTP URL, but does not specify an integer 
for the port - it uses a string instead.  While debugging this, the "host" and 
"port" portion of the URI is passed in as scheme specific part, and the host 
field is null and the port field is -1.  

{{The UriBuilderImpl creates the URI object, this scheme specific part is lost, 
so when the user (test) calls uri.toString(), they do not see that info.  Here 
is an example:}}

{{String uriString = "myscheme://not.really.a.host:fakePort/";}}{{URI uri = 
UriBuilder.fromUri(uriString).build();}}{{assertEquals(uriString, 
uri.toString());}}

 

 



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

[jira] [Resolved] (CXF-7625) JAX-RS 2.1 TCK: UriBuilder doesn't handle case where "port" is not an integer

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7625.

   Resolution: Fixed
Fix Version/s: 3.2.2

> JAX-RS 2.1 TCK: UriBuilder doesn't handle case where "port" is not an integer
> -
>
> Key: CXF-7625
> URL: https://issues.apache.org/jira/browse/CXF-7625
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.2
>
>
> The JAX-RS 2.1 TCK (which isn't public in EE4J yet, but once it is, I'll post 
> a link) has a test that checks the String content of a call to 
> URI.toString().  The URI contains what looks like an HTTP URL, but does not 
> specify an integer for the port - it uses a string instead.  While debugging 
> this, the "host" and "port" portion of the URI is passed in as scheme 
> specific part, and the host field is null and the port field is -1.  
> {{The UriBuilderImpl creates the URI object, this scheme specific part is 
> lost, so when the user (test) calls uri.toString(), they do not see that 
> info.  Here is an example:}}
> {{String uriString = "myscheme://not.really.a.host:fakePort/";}}{{URI uri = 
> UriBuilder.fromUri(uriString).build();}}{{assertEquals(uriString, 
> uri.toString());}}
>  
>  



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

[jira] [Created] (CXF-7638) JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

Andy McCright created CXF-7638:
--

 Summary: JAXRS CTS/TCK issue:  register(...) should ignore 
components when invalid contracts are passed in
 Key: CXF-7638
 URL: https://issues.apache.org/jira/browse/CXF-7638
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.2
Reporter: Andy McCright
Assignee: Andy McCright
 Fix For: 3.2.3


We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
around the register method. The javadoc states that the implementation MUST 
ignore the component if the call to register specifies a contract (interface) 
that the component does not implement.

So, for example, suppose somebody calls code like this:

 

public class MyProvider implements MessageBodyWriter ...

 

Client c = ClientBuilder.newClient();

c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore

c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class); // 
should ignore

Map contractPriorityMap = new HashMap<>();

contractPriorityMap.put(ClientResponseFilter.class, 20);

c.register(MyProvider.class, contractPriorityMap); // should ignore

c.register(new MyProvider.class, contractPriorityMap); // should ignore

 

The TCK tests basically check that nothing gets registered when a passed-in 
contract is not assignable to the provider class.  And scenarios like the four 
mentioned above are failing.

 



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

[jira] [Commented] (CXF-7638) JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7638:


A secondary but related issue is that the isEnabled method is not returning the 
results according to the javadoc [1]; in the case where the Feature instance is 
passed in, we should be returning whether that instance has ever been enabled.  
In the case where the Class is passed in, we should be returning true if any 
instance of that feature has been enabled.

 

[1] 
https://jax-rs.github.io/apidocs/2.1/javax/ws/rs/core/Configuration.html#isEnabled-javax.ws.rs.core.Feature-

> JAXRS CTS/TCK issue:  register(...) should ignore components when invalid 
> contracts are passed in
> -
>
> Key: CXF-7638
> URL: https://issues.apache.org/jira/browse/CXF-7638
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.3
>
>
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> So, for example, suppose somebody calls code like this:
>  
> public class MyProvider implements MessageBodyWriter ...
>  
> Client c = ClientBuilder.newClient();
> c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore
> c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class); 
> // should ignore
> Map contractPriorityMap = new HashMap<>();
> contractPriorityMap.put(ClientResponseFilter.class, 20);
> c.register(MyProvider.class, contractPriorityMap); // should ignore
> c.register(new MyProvider.class, contractPriorityMap); // should ignore
>  
> The TCK tests basically check that nothing gets registered when a passed-in 
> contract is not assignable to the provider class.  And scenarios like the 
> four mentioned above are failing.
>  



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

[jira] [Commented] (CXF-7638) JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7638:


[~johndament] My understanding for that case (registering a component with one 
good and one bad interface) is that we should ignore the whole register call - 
and log a message indicating the problem.  I think the spec is taking a hard 
line and saying that if a user specifies the contracts for a given component, 
then it must not contain any contracts not implemented by the component (or a 
superclass of the component).  So the only advantage for specifying contracts 
(that I can see) would be to limit the component - i.e. a component implements 
MBW and MBR, but for a given case, we only want it registered as MBR.

> JAXRS CTS/TCK issue:  register(...) should ignore components when invalid 
> contracts are passed in
> -
>
> Key: CXF-7638
> URL: https://issues.apache.org/jira/browse/CXF-7638
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.3
>
>
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> So, for example, suppose somebody calls code like this:
>  
> public class MyProvider implements MessageBodyWriter ...
>  
> Client c = ClientBuilder.newClient();
> c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore
> c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class); 
> // should ignore
> Map contractPriorityMap = new HashMap<>();
> contractPriorityMap.put(ClientResponseFilter.class, 20);
> c.register(MyProvider.class, contractPriorityMap); // should ignore
> c.register(new MyProvider.class, contractPriorityMap); // should ignore
>  
> The TCK tests basically check that nothing gets registered when a passed-in 
> contract is not assignable to the provider class.  And scenarios like the 
> four mentioned above are failing.
>  



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

[jira] [Resolved] (CXF-7639) Support Servlet 4.0 API in OSGI manifest

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7639.

   Resolution: Fixed
 Assignee: Andy McCright
Fix Version/s: 3.2.3

> Support Servlet 4.0 API in OSGI manifest
> 
>
> Key: CXF-7639
> URL: https://issues.apache.org/jira/browse/CXF-7639
> Project: CXF
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: 3.2.2
>Reporter: Arnaud MERGEY
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.3
>
>
> Our OSGI application cannot be deployed on top of tomcat 9, because tomcat 9 
> exposes javax.servlet.xxx packages in V 4.0, and various bundles from cxf who 
> depends of javax.servlet exclude 4.0 from their osgi manifest.
> It seems Servlet 4.0 is already supported, so the simple fix for this only 
> seems to include servlet 4.0 in range of supported version ( ** [0,4.1) 
> instead of [0,4.0) in Import-Package)



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

[jira] [Resolved] (CXF-7638) JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7638.

Resolution: Fixed

> JAXRS CTS/TCK issue:  register(...) should ignore components when invalid 
> contracts are passed in
> -
>
> Key: CXF-7638
> URL: https://issues.apache.org/jira/browse/CXF-7638
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.3
>
>
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> So, for example, suppose somebody calls code like this:
>  
> public class MyProvider implements MessageBodyWriter ...
>  
> Client c = ClientBuilder.newClient();
> c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore
> c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class); 
> // should ignore
> Map contractPriorityMap = new HashMap<>();
> contractPriorityMap.put(ClientResponseFilter.class, 20);
> c.register(MyProvider.class, contractPriorityMap); // should ignore
> c.register(new MyProvider.class, contractPriorityMap); // should ignore
>  
> The TCK tests basically check that nothing gets registered when a passed-in 
> contract is not assignable to the provider class.  And scenarios like the 
> four mentioned above are failing.
>  



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

[jira] [Created] (CXF-7644) TCK/CTS: JAX-RS async client requests should invoke interceptor chain on separate thread

[Andy McCright (JIRA)]

Andy McCright created CXF-7644:
--

 Summary: TCK/CTS: JAX-RS async client requests should invoke 
interceptor chain on separate thread
 Key: CXF-7644
 URL: https://issues.apache.org/jira/browse/CXF-7644
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.2.2
Reporter: Andy McCright


The JAX-RS 2.1 TCK is using ClientRequestFilters to verify that it is on a 
separate thread than the main client thread.  Although it is not specific in 
the spec that providers like filters must be invoked on a new thread, I believe 
this line from the spec (section 8.4) is what they base this test on:
_Note that in this example, the call to get after calling async returns 
immediately without blocking the caller’s thread._

 

Currently, we call WebClient.doInvokeAsync(...) which calls 
prepareAsyncClient(...) which calls doRunInterceptorChain(...) - all on the 
main client thread. As a result the filters on the outbound chain get executed 
on the same thread which breaks the test.

I wrote a simpler test case that similarly breaks, but could use some help with 
how to implement the fix:

 

    public static class ThreadCheckFilter implements ClientRequestFilter {

        @Override

        public void filter(ClientRequestContext context) throws IOException {

            final Thread currentThread = Thread.currentThread();

            context.abortWith(Response.ok(currentThread.getName())

                                       .header("ThreadID", 
currentThread.getId())

                                       .build());

        }

    }

 

    @Test

    public void 
testClientRequestFilterRunsOnSepaarateThreadWhenInvokedAsynchronously() throws 
Exception {

        final Thread currentThread = Thread.currentThread();

        Client client = ClientBuilder.newClient();

        client.register(ThreadCheckFilter.class);

        WebTarget target = client.target("http://localhost:8080/notReal";);

        AsyncInvoker invoker = target.request().async();

        Future future = invoker.get();

        Response response = future.get();

        assertNotEquals(currentThread.getName(), 
response.readEntity(String.class));

        assertNotEquals(currentThread.getId(), 
Long.parseLong(response.getHeaderString("ThreadID")));

    }



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

[jira] [Commented] (CXF-7644) TCK/CTS: JAX-RS async client requests should invoke interceptor chain on separate thread

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7644:


Thanks [~sergey_beryozkin] - that is what I'm thinking too.  I've asked our CTS 
team to challenge this and related tests.  I agree that the spec is silent on 
this - so IMO, either the TCK test needs to be rewritten - if it tested against 
a real remote resource and then checked that the response was on a different 
thread, I would think that would be sufficient - or the spec needs to be 
updated to clarify that the outbound interceptors must run on a separate thread.

 

Thanks, Andy

> TCK/CTS: JAX-RS async client requests should invoke interceptor chain on 
> separate thread
> 
>
> Key: CXF-7644
> URL: https://issues.apache.org/jira/browse/CXF-7644
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Andy McCright
>Priority: Major
>
> The JAX-RS 2.1 TCK is using ClientRequestFilters to verify that it is on a 
> separate thread than the main client thread.  Although it is not specific in 
> the spec that providers like filters must be invoked on a new thread, I 
> believe this line from the spec (section 8.4) is what they base this test on:
> _Note that in this example, the call to get after calling async returns 
> immediately without blocking the caller’s thread._
>  
> Currently, we call WebClient.doInvokeAsync(...) which calls 
> prepareAsyncClient(...) which calls doRunInterceptorChain(...) - all on the 
> main client thread. As a result the filters on the outbound chain get 
> executed on the same thread which breaks the test.
> I wrote a simpler test case that similarly breaks, but could use some help 
> with how to implement the fix:
>  
>     public static class ThreadCheckFilter implements ClientRequestFilter {
>         @Override
>         public void filter(ClientRequestContext context) throws IOException {
>             final Thread currentThread = Thread.currentThread();
>             context.abortWith(Response.ok(currentThread.getName())
>                                        .header("ThreadID", 
> currentThread.getId())
>                                        .build());
>         }
>     }
>  
>     @Test
>     public void 
> testClientRequestFilterRunsOnSepaarateThreadWhenInvokedAsynchronously() 
> throws Exception {
>         final Thread currentThread = Thread.currentThread();
>         Client client = ClientBuilder.newClient();
>         client.register(ThreadCheckFilter.class);
>         WebTarget target = client.target("http://localhost:8080/notReal";);
>         AsyncInvoker invoker = target.request().async();
>         Future future = invoker.get();
>         Response response = future.get();
>         assertNotEquals(currentThread.getName(), 
> response.readEntity(String.class));
>         assertNotEquals(currentThread.getId(), 
> Long.parseLong(response.getHeaderString("ThreadID")));
>     }



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

[jira] [Assigned] (CXF-7673) Implement MicroProfile Rest Client 1.1

[Andy McCright (JIRA)]

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

Andy McCright reassigned CXF-7673:
--

Assignee: Andy McCright

> Implement MicroProfile Rest Client 1.1
> --
>
> Key: CXF-7673
> URL: https://issues.apache.org/jira/browse/CXF-7673
> Project: CXF
>  Issue Type: New Feature
>Reporter: John D. Ament
>Assignee: Andy McCright
>Priority: Major
>
> Implement MP Rest Client 1.1
>  * Async support
>  * baseUri vs baseUrl
>  * {{ProviderRegistrar}} support
>  
> FYI [~andymc]



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

[jira] [Commented] (CXF-7713) CLONE - JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7713:


The patch looks good to me.  I'll merge it, since I introduced the problem in 
the first place.  Thanks Dennis (for the review) and Mark (for catching this 
issue and for the patch)!

> CLONE - JAXRS CTS/TCK issue:  register(...) should ignore components when 
> invalid contracts are passed in
> -
>
> Key: CXF-7713
> URL: https://issues.apache.org/jira/browse/CXF-7713
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Mark Struberg
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.5
>
> Attachments: 
> 0001-CXF-7713-fix-interface-contract-detection-for-Filter.patch
>
>
> --- original ticket --
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> ---
> The original fix improved checks but did not properly detect all the nested 
> Interfaces.
> This can now lead to not picking up Filters properly but ignoring them.



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

[jira] [Commented] (CXF-7713) CLONE - JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright commented on CXF-7713:


Merged - thanks again!

> CLONE - JAXRS CTS/TCK issue:  register(...) should ignore components when 
> invalid contracts are passed in
> -
>
> Key: CXF-7713
> URL: https://issues.apache.org/jira/browse/CXF-7713
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Mark Struberg
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.5
>
> Attachments: 
> 0001-CXF-7713-fix-interface-contract-detection-for-Filter.patch
>
>
> --- original ticket --
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> ---
> The original fix improved checks but did not properly detect all the nested 
> Interfaces.
> This can now lead to not picking up Filters properly but ignoring them.



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

[jira] [Resolved] (CXF-7713) CLONE - JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7713.

Resolution: Fixed

> CLONE - JAXRS CTS/TCK issue:  register(...) should ignore components when 
> invalid contracts are passed in
> -
>
> Key: CXF-7713
> URL: https://issues.apache.org/jira/browse/CXF-7713
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Mark Struberg
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.5
>
> Attachments: 
> 0001-CXF-7713-fix-interface-contract-detection-for-Filter.patch
>
>
> --- original ticket --
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> ---
> The original fix improved checks but did not properly detect all the nested 
> Interfaces.
> This can now lead to not picking up Filters properly but ignoring them.



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

[jira] [Resolved] (CXF-7673) Implement MicroProfile Rest Client 1.1

[Andy McCright (JIRA)]

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

Andy McCright resolved CXF-7673.

Resolution: Fixed

> Implement MicroProfile Rest Client 1.1
> --
>
> Key: CXF-7673
> URL: https://issues.apache.org/jira/browse/CXF-7673
> Project: CXF
>  Issue Type: New Feature
>  Components: JAX-RS
>Reporter: John D. Ament
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.6, 3.3.0
>
>
> Implement MP Rest Client 1.1
>  * Async support
>  * baseUri vs baseUrl
>  * {{ProviderRegistrar}} support
>  
> FYI [~andymc]



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

[jira] [Updated] (CXF-7673) Implement MicroProfile Rest Client 1.1

[Andy McCright (JIRA)]

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

Andy McCright updated CXF-7673:
---
Fix Version/s: 3.3.0
   3.2.6
  Component/s: JAX-RS

> Implement MicroProfile Rest Client 1.1
> --
>
> Key: CXF-7673
> URL: https://issues.apache.org/jira/browse/CXF-7673
> Project: CXF
>  Issue Type: New Feature
>  Components: JAX-RS
>Reporter: John D. Ament
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.6, 3.3.0
>
>
> Implement MP Rest Client 1.1
>  * Async support
>  * baseUri vs baseUrl
>  * {{ProviderRegistrar}} support
>  
> FYI [~andymc]



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

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

[Andy McCright (JIRA)]

Andy McCright created CXF-7860:
--

 Summary: 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


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)