[jira] [Created] (CXF-6850) javax.ws.rs.core.Request implementation doesn't match Accept-Encoding: * for any matches any encoding value
Jim Ma created CXF-6850:
---
Summary: javax.ws.rs.core.Request implementation doesn't match
Accept-Encoding: * for any matches any encoding value
Key: CXF-6850
URL: https://issues.apache.org/jira/browse/CXF-6850
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.6
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 3.1.7, 3.2.0
When client side set accept encoding to "*" value and send request to following
operation, client always get notAcceptable .
@GET
@Path("/test")
public Response test(@Context Request req) {
List list = Variant.encodings("CP1250", "UTF-8")
...
if (null == req.selectVariant(list))
return Response.notAcceptable(list).build();
return Response.ok("entity").build();
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6850) javax.ws.rs.core.Request implementation doesn't match Accept-Encoding: * for any encoding value
[
https://issues.apache.org/jira/browse/CXF-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6850:
Summary: javax.ws.rs.core.Request implementation doesn't match
Accept-Encoding: * for any encoding value (was: javax.ws.rs.core.Request
implementation doesn't match Accept-Encoding: * for any matches any encoding
value)
> javax.ws.rs.core.Request implementation doesn't match Accept-Encoding: * for
> any encoding value
> -
>
> Key: CXF-6850
> URL: https://issues.apache.org/jira/browse/CXF-6850
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.6
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.1.7, 3.2.0
>
>
> When client side set accept encoding to "*" value and send request to
> following operation, client always get notAcceptable .
>@GET
> @Path("/test")
> public Response test(@Context Request req) {
> List list = Variant.encodings("CP1250", "UTF-8")
> ...
> if (null == req.selectVariant(list))
> return Response.notAcceptable(list).build();
> return Response.ok("entity").build();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6850) javax.ws.rs.core.Request implementation doesn't match Accept-Encoding: * for any encoding value
[
https://issues.apache.org/jira/browse/CXF-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217748#comment-15217748
]
Sergey Beryozkin commented on CXF-6850:
---
Hi Jim,
can you please merge to 3.1.x and also 3.0.x ? Thanks
> javax.ws.rs.core.Request implementation doesn't match Accept-Encoding: * for
> any encoding value
> -
>
> Key: CXF-6850
> URL: https://issues.apache.org/jira/browse/CXF-6850
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.6
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.1.7, 3.2.0
>
>
> When client side set accept encoding to "*" value and send request to
> following operation, client always get notAcceptable .
>@GET
> @Path("/test")
> public Response test(@Context Request req) {
> List list = Variant.encodings("CP1250", "UTF-8")
> ...
> if (null == req.selectVariant(list))
> return Response.notAcceptable(list).build();
> return Response.ok("entity").build();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6842) Unwrap exception nested with WebApplicationException
[ https://issues.apache.org/jira/browse/CXF-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217750#comment-15217750 ] Sergey Beryozkin commented on CXF-6842: --- Sure, can you please merge to 3.1.x and also 3.0.x ? Thanks > Unwrap exception nested with WebApplicationException > > > Key: CXF-6842 > URL: https://issues.apache.org/jira/browse/CXF-6842 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.2.0 > > > In a resource class, if an exception is thrown which is nested with > WebApplicationException, cxf can try to get the cause and create response > from WebApplicationException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6851) JAXRS 2 Feature not supported on server side?
Romain Manni-Bucau created CXF-6851: --- Summary: JAXRS 2 Feature not supported on server side? Key: CXF-6851 URL: https://issues.apache.org/jira/browse/CXF-6851 Project: CXF Issue Type: Bug Affects Versions: 3.1.5 Reporter: Romain Manni-Bucau Hi maybe I missed something but seems DynamicFeatures are supported on server side through @Provider but Features (JAXRS2 ones, not CXF ones) are not. This prevents to reuse some logic like Moxy JAXRS integration for instance which provides a hidden (for end user) ContextProvider through a Feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6837) Add cache for MessageBodyReader/Writer
[ https://issues.apache.org/jira/browse/CXF-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217813#comment-15217813 ] Neal Hu commented on CXF-6837: -- Hi Sergey, First of all, thanks for your comment. I will simplify the ProviderCache code to have combined key of Type and MediaType in one map. Secondly, it's not necessary to pass the other two parameters. Because the original doesn't use these two parameters in handleMapper and matchesReaderCriterias when select reader/writer except in isReadable/isWritable. I moved the isReadable/isWritable invocation outside of matchesReaderCriterias. As you know the customized reader/writer's isReadable/isWritable could be changed during caching(via injection, has been proved in CTS). So we cache all canditates match Type and MediaType, get from cache and invoke isReadable/isWritable. Any comment please let me know. Thanks a lot. Neal > Add cache for MessageBodyReader/Writer > -- > > Key: CXF-6837 > URL: https://issues.apache.org/jira/browse/CXF-6837 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.5, 3.0.8 > Environment: windows >Reporter: Neal Hu > Fix For: 3.2.0 > > Attachments: ProviderCache.java, ProviderFactory.patch > > > CXF selects the msgBodyReader/writer in the reader/writer list for every > request, which has big impact to the performance. Jersey also has the cache > in > org.glassfish.jersey.message.internal.MessageBodyFactory._getMessageBodyReader(...). > I have tried add the cache for CXF in ProviderFactory and been proved that > it has improved 7-8% for json requests in JMeter. Please let me know if you'd > like me to add the enhancement for CXF. Thanks. > http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-td5767091.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6837) Add cache for MessageBodyReader/Writer
[
https://issues.apache.org/jira/browse/CXF-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217819#comment-15217819
]
Sergey Beryozkin commented on CXF-6837:
---
Even though the Type is checked separately in handleMapper, it is still part of
the check.
If you have
{code:java}
public class ListAReader implements MessageBodyReader> {}
{code}
{code:java}
public class ListBReader implements MessageBodyReader> {}
{code}
then if you only use a Class (List) + MediaType then you won't get the right
provider.
> Add cache for MessageBodyReader/Writer
> --
>
> Key: CXF-6837
> URL: https://issues.apache.org/jira/browse/CXF-6837
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.5, 3.0.8
> Environment: windows
>Reporter: Neal Hu
> Fix For: 3.2.0
>
> Attachments: ProviderCache.java, ProviderFactory.patch
>
>
> CXF selects the msgBodyReader/writer in the reader/writer list for every
> request, which has big impact to the performance. Jersey also has the cache
> in
> org.glassfish.jersey.message.internal.MessageBodyFactory._getMessageBodyReader(...).
> I have tried add the cache for CXF in ProviderFactory and been proved that
> it has improved 7-8% for json requests in JMeter. Please let me know if you'd
> like me to add the enhancement for CXF. Thanks.
> http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-td5767091.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6814) ClientRequestFilter should be added with descending order of priority
[ https://issues.apache.org/jira/browse/CXF-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma resolved CXF-6814. - Resolution: Won't Fix Talked with Sergey, cxf handles this correctly and no change is needed. > ClientRequestFilter should be added with descending order of priority > - > > Key: CXF-6814 > URL: https://issues.apache.org/jira/browse/CXF-6814 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Jim Ma > > ClientRequestFilter is added with wrong priority order now, it leads to low > priority ClientRequestFilter executed first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6851) JAXRS 2 Feature not supported on server side?
[ https://issues.apache.org/jira/browse/CXF-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217830#comment-15217830 ] Sergey Beryozkin commented on CXF-6851: --- Yes, Feature was introduced while we were working on the client API, so I was not really focusing on adding it to the server, except for DynamicFeature so as a workaround, you can register Feature from within DynamicFeature. Not sure though about registering providers like ContextProvider from Feature(Context), many of those methods have priorities accepted and it only makes sense for the 2.0 filters/interceptors, it is confusing... > JAXRS 2 Feature not supported on server side? > - > > Key: CXF-6851 > URL: https://issues.apache.org/jira/browse/CXF-6851 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.5 >Reporter: Romain Manni-Bucau > > Hi > maybe I missed something but seems DynamicFeatures are supported on server > side through @Provider but Features (JAXRS2 ones, not CXF ones) are not. This > prevents to reuse some logic like Moxy JAXRS integration for instance which > provides a hidden (for end user) ContextProvider through a > Feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6852) Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating dynamic client
Lukas Vasek created CXF-6852: Summary: Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating dynamic client Key: CXF-6852 URL: https://issues.apache.org/jira/browse/CXF-6852 Project: CXF Issue Type: Bug Affects Versions: 3.1.6, 2.7.16 Environment: OSX JDK8u77 Reporter: Lukas Vasek Hello, As mentioned in this issue http://stackoverflow.com/questions/36307555/correct-java-8-setup-for-class-unloading-metaspace-cleanup-cxf-issue we are getting OOM exceptions while generating dynamic clients. Problem is that each new generated client creates new URLClassLoader which consumes memory. I don't know if this is bug in CXF or it's more related to JVM setup. I would greatly appreciate any help. Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6837) Add cache for MessageBodyReader/Writer
[ https://issues.apache.org/jira/browse/CXF-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217877#comment-15217877 ] Sergey Beryozkin commented on CXF-6837: --- But Annotations can indeed be skipped, so a key should be 'Class + Type + MediaType' > Add cache for MessageBodyReader/Writer > -- > > Key: CXF-6837 > URL: https://issues.apache.org/jira/browse/CXF-6837 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.5, 3.0.8 > Environment: windows >Reporter: Neal Hu > Fix For: 3.2.0 > > Attachments: ProviderCache.java, ProviderFactory.patch > > > CXF selects the msgBodyReader/writer in the reader/writer list for every > request, which has big impact to the performance. Jersey also has the cache > in > org.glassfish.jersey.message.internal.MessageBodyFactory._getMessageBodyReader(...). > I have tried add the cache for CXF in ProviderFactory and been proved that > it has improved 7-8% for json requests in JMeter. Please let me know if you'd > like me to add the enhancement for CXF. Thanks. > http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-td5767091.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6843) http 406 not acceptable should be returned if query parameter value can't be converted
[ https://issues.apache.org/jira/browse/CXF-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217902#comment-15217902 ] Jim Ma commented on CXF-6843: - The mapper is the exception mapper in the test , and I need to set default.wae.mapper.least.specific=true to get this test passed. I see the not found exception. Yes, the behavior is spec compliant. > http 406 not acceptable should be returned if query parameter value can't be > converted > --- > > Key: CXF-6843 > URL: https://issues.apache.org/jira/browse/CXF-6843 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.1.6, 3.2.0 > > > For query parameter conversion exception, it should return 406 http status > in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6843) http 406 not acceptable should be returned if query parameter value can't be converted
[ https://issues.apache.org/jira/browse/CXF-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217916#comment-15217916 ] Sergey Beryozkin edited comment on CXF-6843 at 3/30/16 12:50 PM: - Can you please provide more info. What does the test mapper do ? Why do you need to set "default.wae.mapper.least.specific=true", so that this test mapper is invoked ? Is this test mapper typed on WebApplicationException or RuntimeException ? was (Author: sergey_beryozkin): Can you please provide more info. What is the test mapper do ? Why do you need to set "default.wae.mapper.least.specific=true", so that this test mapper is invoked ? Is this test mapper typed on WebApplicationException or RuntimeException ? > http 406 not acceptable should be returned if query parameter value can't be > converted > --- > > Key: CXF-6843 > URL: https://issues.apache.org/jira/browse/CXF-6843 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.1.6, 3.2.0 > > > For query parameter conversion exception, it should return 406 http status > in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6843) http 406 not acceptable should be returned if query parameter value can't be converted
[ https://issues.apache.org/jira/browse/CXF-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217916#comment-15217916 ] Sergey Beryozkin commented on CXF-6843: --- Can you please provide more info. What is the test mapper do ? Why do you need to set "default.wae.mapper.least.specific=true", so that this test mapper is invoked ? Is this test mapper typed on WebApplicationException or RuntimeException ? > http 406 not acceptable should be returned if query parameter value can't be > converted > --- > > Key: CXF-6843 > URL: https://issues.apache.org/jira/browse/CXF-6843 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.1.6, 3.2.0 > > > For query parameter conversion exception, it should return 406 http status > in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6853) Support encoded value in @ApplicationPath
Jim Ma created CXF-6853:
---
Summary: Support encoded value in @ApplicationPath
Key: CXF-6853
URL: https://issues.apache.org/jira/browse/CXF-6853
Project: CXF
Issue Type: Task
Components: JAX-RS
Affects Versions: 3.0.9, 3.1.6
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 3.0.10, 3.1.7, 3.2.0
If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
this correctly.
@ApplicationPath("ApplicationPath%21")
public class MyApp extends Application {
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6843) http 406 not acceptable should be returned if query parameter value can't be converted
[ https://issues.apache.org/jira/browse/CXF-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217919#comment-15217919 ] Sergey Beryozkin commented on CXF-6843: --- So perhaps this CXF mapper should be made less specific by default... > http 406 not acceptable should be returned if query parameter value can't be > converted > --- > > Key: CXF-6843 > URL: https://issues.apache.org/jira/browse/CXF-6843 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.1.6, 3.2.0 > > > For query parameter conversion exception, it should return 406 http status > in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6843) http 406 not acceptable should be returned if query parameter value can't be converted
[ https://issues.apache.org/jira/browse/CXF-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217916#comment-15217916 ] Sergey Beryozkin edited comment on CXF-6843 at 3/30/16 12:52 PM: - Can you please provide more info. What does the test mapper do ? Why do you need to set "default.wae.mapper.least.specific=true", so that this test mapper is invoked ? Is this test mapper typed on WebApplicationException or RuntimeException ? See also: https://issues.apache.org/jira/browse/CXF-6568 was (Author: sergey_beryozkin): Can you please provide more info. What does the test mapper do ? Why do you need to set "default.wae.mapper.least.specific=true", so that this test mapper is invoked ? Is this test mapper typed on WebApplicationException or RuntimeException ? > http 406 not acceptable should be returned if query parameter value can't be > converted > --- > > Key: CXF-6843 > URL: https://issues.apache.org/jira/browse/CXF-6843 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.5 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.1.6, 3.2.0 > > > For query parameter conversion exception, it should return 406 http status > in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6852) Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating dynamic client
[ https://issues.apache.org/jira/browse/CXF-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217931#comment-15217931 ] Lukas Vasek commented on CXF-6852: -- Ok problem is following: JaxWsDynamicClientFactory.createClient creates new ClassLoader. But this ClassLoader is never closed. Simple solution which worked for me should be to add to destroy() method ClassLoader cl = Thread.currentThread().getContextClassLoader(); ClassLoader parent = cl.getParent(); Thread.currentThread().setContextClassLoader(parent); cl = null; a good solution could be to implement Autocloseable and inside it call destroy() to be backward compatible. > Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating > dynamic client > -- > > Key: CXF-6852 > URL: https://issues.apache.org/jira/browse/CXF-6852 > Project: CXF > Issue Type: Bug >Affects Versions: 2.7.16, 3.1.6 > Environment: OSX > JDK8u77 >Reporter: Lukas Vasek > > Hello, > As mentioned in this issue > http://stackoverflow.com/questions/36307555/correct-java-8-setup-for-class-unloading-metaspace-cleanup-cxf-issue > we are getting OOM exceptions while generating dynamic clients. Problem is > that each new generated client creates new URLClassLoader which consumes > memory. I don't know if this is bug in CXF or it's more related to JVM setup. > I would greatly appreciate any help. > Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6849) Form parameter names including '%' are not decoded properly
[
https://issues.apache.org/jira/browse/CXF-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217936#comment-15217936
]
Michael Schilling commented on CXF-6849:
The form parameters are encoded when they are sent in the request. I will
update the description.
> Form parameter names including '%' are not decoded properly
> ---
>
> Key: CXF-6849
> URL: https://issues.apache.org/jira/browse/CXF-6849
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michael Schilling
>
> Making a POST call that has form parameter name of {{%}} produces a
> {{BufferUnderflowException}}.
> Additionally, making a POST call with a form parameter name of {{%}} directly
> followed by any character that can't represent a hexadecimal value will
> produce a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid
> digit (radix 16): "}}.
> The source of these exceptions are from {{UrlUtils#urlDecode}} and
> {{UrlUtils#digit16}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217941#comment-15217941
]
Sergey Beryozkin commented on CXF-6853:
---
Hi Jim, I'm getting nervous with some of the commits flowing on :-)
This is not the right place to do it. For example, if you put an encoded value
in Path, it does work, please make sure the code which works for that case is
applied here too
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
> this correctly.
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6849) Form parameter names including '%' are not decoded properly
[
https://issues.apache.org/jira/browse/CXF-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Schilling updated CXF-6849:
---
Description:
Making a POST call that has form parameter name of {{%25}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%25}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
Note: The URL encoded version of {{%}} is {{%25}}. The HTTP request send has a
desired form parameter of {{{%}}.
was:
Making a POST call that has form parameter name of {{%}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
> Form parameter names including '%' are not decoded properly
> ---
>
> Key: CXF-6849
> URL: https://issues.apache.org/jira/browse/CXF-6849
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michael Schilling
>
> Making a POST call that has form parameter name of {{%25}} produces a
> {{BufferUnderflowException}}.
> Additionally, making a POST call with a form parameter name of {{%25}}
> directly followed by any character that can't represent a hexadecimal value
> will produce a {{RuntimeException}} stating {{"Invalid URL encoding: not a
> valid digit (radix 16): "}}.
> The source of these exceptions are from {{UrlUtils#urlDecode}} and
> {{UrlUtils#digit16}}.
> Note: The URL encoded version of {{%}} is {{%25}}. The HTTP request send has
> a desired form parameter of {{{%}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6849) Form parameter names including '%' are not decoded properly
[
https://issues.apache.org/jira/browse/CXF-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Schilling updated CXF-6849:
---
Description:
Making a POST call that has form parameter name of {{%25}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%25}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has a
desired form parameter of {{%}}.
was:
Making a POST call that has form parameter name of {{%25}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%25}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has a
desired form parameter of {{{%}}.
> Form parameter names including '%' are not decoded properly
> ---
>
> Key: CXF-6849
> URL: https://issues.apache.org/jira/browse/CXF-6849
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michael Schilling
>
> Making a POST call that has form parameter name of {{%25}} produces a
> {{BufferUnderflowException}}.
> Additionally, making a POST call with a form parameter name of {{%25}}
> directly followed by any character that can't represent a hexadecimal value
> will produce a {{RuntimeException}} stating {{"Invalid URL encoding: not a
> valid digit (radix 16): "}}.
> The source of these exceptions are from {{UrlUtils#urlDecode}} and
> {{UrlUtils#digit16}}.
> Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has
> a desired form parameter of {{%}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6849) Form parameter names including '%' are not decoded properly
[
https://issues.apache.org/jira/browse/CXF-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Schilling updated CXF-6849:
---
Description:
Making a POST call that has form parameter name of {{%25}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%25}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has a
desired form parameter of {{{%}}.
was:
Making a POST call that has form parameter name of {{%25}} produces a
{{BufferUnderflowException}}.
Additionally, making a POST call with a form parameter name of {{%25}} directly
followed by any character that can't represent a hexadecimal value will produce
a {{RuntimeException}} stating {{"Invalid URL encoding: not a valid digit
(radix 16): "}}.
The source of these exceptions are from {{UrlUtils#urlDecode}} and
{{UrlUtils#digit16}}.
Note: The URL encoded version of {{%}} is {{%25}}. The HTTP request send has a
desired form parameter of {{{%}}.
> Form parameter names including '%' are not decoded properly
> ---
>
> Key: CXF-6849
> URL: https://issues.apache.org/jira/browse/CXF-6849
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michael Schilling
>
> Making a POST call that has form parameter name of {{%25}} produces a
> {{BufferUnderflowException}}.
> Additionally, making a POST call with a form parameter name of {{%25}}
> directly followed by any character that can't represent a hexadecimal value
> will produce a {{RuntimeException}} stating {{"Invalid URL encoding: not a
> valid digit (radix 16): "}}.
> The source of these exceptions are from {{UrlUtils#urlDecode}} and
> {{UrlUtils#digit16}}.
> Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has
> a desired form parameter of {{{%}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6849) Form parameter names including '%' are not decoded properly
[
https://issues.apache.org/jira/browse/CXF-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217944#comment-15217944
]
Sergey Beryozkin commented on CXF-6849:
---
Just to clarify: is it a JAX-RS bug ?
> Form parameter names including '%' are not decoded properly
> ---
>
> Key: CXF-6849
> URL: https://issues.apache.org/jira/browse/CXF-6849
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michael Schilling
>
> Making a POST call that has form parameter name of {{%25}} produces a
> {{BufferUnderflowException}}.
> Additionally, making a POST call with a form parameter name of {{%25}}
> directly followed by any character that can't represent a hexadecimal value
> will produce a {{RuntimeException}} stating {{"Invalid URL encoding: not a
> valid digit (radix 16): "}}.
> The source of these exceptions are from {{UrlUtils#urlDecode}} and
> {{UrlUtils#digit16}}.
> Note: {{%25}} is the URL encoded version of {{%}}. The HTTP request send has
> a desired form parameter of {{%}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6854) Application subclass can't be injected into an application lass field
Jim Ma created CXF-6854: --- Summary: Application subclass can't be injected into an application lass field Key: CXF-6854 URL: https://issues.apache.org/jira/browse/CXF-6854 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.0.9, 3.1.6 Reporter: Jim Ma Assignee: Jim Ma Fix For: 3.0.10, 3.1.7, 3.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated CXF-6854: Attachment: injectionUtil.diff Hi Sergey, Can you please review this change ? > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217963#comment-15217963
]
Sergey Beryozkin commented on CXF-6853:
---
Hmm. I think this fix is invalid. The container (Undertow ?) must be decoding
the values ?
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
> this correctly.
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217972#comment-15217972 ] Sergey Beryozkin commented on CXF-6854: --- I don't understand what is being fixed here. Can you type some code (JAX-RS class, service code) here ? > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218006#comment-15218006 ] Sergey Beryozkin commented on CXF-6854: --- This needs to be reverted, see https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/Path.html#value(): "Matching of request URIs to URI templates is performed against encoded path values" What this means is that the container/runtime must not decode the path, and your change breaks that. Somewhere either in the Undertow or in your CXF wrapper code you are decoding too early. I'm adding a test showing that a percent encoded value in ApplicationPath is not a problem without your change. Once again, lets review/discuss sensitive changes first > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reassigned CXF-6854: - Assignee: Sergey Beryozkin (was: Jim Ma) > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Sergey Beryozkin > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6854: -- Assignee: Jim Ma (was: Sergey Beryozkin) > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reassigned CXF-6853:
-
Assignee: Sergey Beryozkin (was: Jim Ma)
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
> this correctly.
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218007#comment-15218007
]
Sergey Beryozkin commented on CXF-6853:
---
This needs to be reverted, see
https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/Path.html#value():
"Matching of request URIs to URI templates is performed against encoded path
values"
What this means is that the container/runtime must not decode the path, and
your change breaks that.
Somewhere either in the Undertow or in your CXF wrapper code you are decoding
too early.
I'm adding a test showing that a percent encoded value in ApplicationPath is
not a problem without your change.
Once again, lets review/discuss sensitive changes first
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
> this correctly.
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-6854) Application subclass can't be injected into an application lass field
[ https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6854: -- Comment: was deleted (was: This needs to be reverted, see https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/Path.html#value(): "Matching of request URIs to URI templates is performed against encoded path values" What this means is that the container/runtime must not decode the path, and your change breaks that. Somewhere either in the Undertow or in your CXF wrapper code you are decoding too early. I'm adding a test showing that a percent encoded value in ApplicationPath is not a problem without your change. Once again, lets review/discuss sensitive changes first) > Application subclass can't be injected into an application lass field > - > > Key: CXF-6854 > URL: https://issues.apache.org/jira/browse/CXF-6854 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6, 3.0.9 >Reporter: Jim Ma >Assignee: Jim Ma > Fix For: 3.0.10, 3.1.7, 3.2.0 > > Attachments: injectionUtil.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6853.
---
Resolution: Invalid
http://git-wip-us.apache.org/repos/asf/cxf/commit/e4de8e21
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
> this correctly.
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6853:
Description:
If @ApplicationPath value is an encoded value, if client send request to
http://localhost:8080/Application!/myresource and get 404 .
@ApplicationPath("ApplicationPath%21")
public class MyApp extends Application {
public java.util.Set> getClasses() {
Set> resources = new HashSet>();
resources.add(MyResource.class);
return resources;
}
}
was:
If @ApplicationPath value is an encoded value, cxf doesn't decode and handle
this correctly.
@ApplicationPath("ApplicationPath%21")
public class MyApp extends Application {
}
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6852) Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating dynamic client
[ https://issues.apache.org/jira/browse/CXF-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Vasek updated CXF-6852: - Priority: Blocker (was: Major) > Java 8 java.lang.OutOfMemoryException: Metaspace issue while generating > dynamic client > -- > > Key: CXF-6852 > URL: https://issues.apache.org/jira/browse/CXF-6852 > Project: CXF > Issue Type: Bug >Affects Versions: 2.7.16, 3.1.6 > Environment: OSX > JDK8u77 >Reporter: Lukas Vasek >Priority: Blocker > > Hello, > As mentioned in this issue > http://stackoverflow.com/questions/36307555/correct-java-8-setup-for-class-unloading-metaspace-cleanup-cxf-issue > we are getting OOM exceptions while generating dynamic clients. Problem is > that each new generated client creates new URLClassLoader which consumes > memory. I don't know if this is bug in CXF or it's more related to JVM setup. > I would greatly appreciate any help. > Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL
Stefaan Vanderheyden created CXF-6855: - Summary: ElementClass annotation is ignored on JAX-RS service interface when generating the WADL Key: CXF-6855 URL: https://issues.apache.org/jira/browse/CXF-6855 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.0.8 Reporter: Stefaan Vanderheyden For the purpose of generating a WADL, contrary to what would be dictated by best practices the "ElementClass" annotation is ignored by CXF when it is placed on the JAX-RS service interface. The annotation must be present on the service's implementation in order for the grammar section of the WADL to be generated correctly, and for the response types to be correctly linked to a grammar type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6773) Client code not generating properly
[ https://issues.apache.org/jira/browse/CXF-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218156#comment-15218156 ] Lukas Vasek commented on CXF-6773: -- Hi, how are you generating client? With cxf-codegen-plugin? If so, try to add false to your bindings. Cheers > Client code not generating properly > --- > > Key: CXF-6773 > URL: https://issues.apache.org/jira/browse/CXF-6773 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.5 >Reporter: vijay >Priority: Blocker > Attachments: order.jar, order.xml > > > Hi > When I try to generate client code from attached wsdl (shoprunner) for order > service, its not generating response beans and service method return type > also saying void, but it should be some OrderResponse. > Is there any know issue? Its very urgent, Can you please help on this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL
[ https://issues.apache.org/jira/browse/CXF-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefaan Vanderheyden updated CXF-6855: -- Attachment: ZoomitWadlBugTest.java Here is a brief test that illustrates the issue encountered when generating WADLs with "ElementClass"-annotated services. > ElementClass annotation is ignored on JAX-RS service interface when > generating the WADL > --- > > Key: CXF-6855 > URL: https://issues.apache.org/jira/browse/CXF-6855 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.8 >Reporter: Stefaan Vanderheyden > Attachments: ZoomitWadlBugTest.java > > > For the purpose of generating a WADL, contrary to what would be dictated by > best practices the "ElementClass" annotation is ignored by CXF when it is > placed on the JAX-RS service interface. > The annotation must be present on the service's implementation in order for > the grammar section of the WADL to be generated correctly, and for the > response types to be correctly linked to a grammar type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218154#comment-15218154
]
Jim Ma commented on CXF-6853:
-
OK. The description I added is probably misleading. I tried to modify a bit to
see if this is better now.
I am not sure if this a sensitive change and it totally breaks the match
request with encoded path value. But anyway, I changed your case a bit to
demonstrate this issue and you can start to look what can we do to fix this
issue.
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL
[ https://issues.apache.org/jira/browse/CXF-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218160#comment-15218160 ] Sergey Beryozkin commented on CXF-6855: --- It has to be collocated with other JAX-RS annotations on a given method. Is it how it is done in your case ? > ElementClass annotation is ignored on JAX-RS service interface when > generating the WADL > --- > > Key: CXF-6855 > URL: https://issues.apache.org/jira/browse/CXF-6855 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.8 >Reporter: Stefaan Vanderheyden > Attachments: ZoomitWadlBugTest.java > > > For the purpose of generating a WADL, contrary to what would be dictated by > best practices the "ElementClass" annotation is ignored by CXF when it is > placed on the JAX-RS service interface. > The annotation must be present on the service's implementation in order for > the grammar section of the WADL to be generated correctly, and for the > response types to be correctly linked to a grammar type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL
[ https://issues.apache.org/jira/browse/CXF-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6855: -- Comment: was deleted (was: It has to be collocated with other JAX-RS annotations on a given method. Is it how it is done in your case ?) > ElementClass annotation is ignored on JAX-RS service interface when > generating the WADL > --- > > Key: CXF-6855 > URL: https://issues.apache.org/jira/browse/CXF-6855 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.8 >Reporter: Stefaan Vanderheyden > Attachments: ZoomitWadlBugTest.java > > > For the purpose of generating a WADL, contrary to what would be dictated by > best practices the "ElementClass" annotation is ignored by CXF when it is > placed on the JAX-RS service interface. > The annotation must be present on the service's implementation in order for > the grammar section of the WADL to be generated correctly, and for the > response types to be correctly linked to a grammar type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218186#comment-15218186
]
Sergey Beryozkin commented on CXF-6853:
---
I honestly no idea how to fix or if it needs to be fixed. Your change, if
re-introduced, would break the test I added because if decode the request path
then we will not match it against the encoded Path annotation.
How do you have this Application loaded. Is it a no web.xml case ? I wonder, is
this ApplicationPath should be decoded at the moment the application path is
loaded and set as a servlet pattern ?
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-6853:
---
Reopening, though it still seems to be a non-CXF issue but the issue of the
code loading the application. CXFNonSpringJaxrsServlet will ignore the
application path by default.
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218197#comment-15218197
]
Sergey Beryozkin commented on CXF-6853:
---
If it is a no-web.xml or other auto-discovery related case, do you use CXF
rt-rs-http-sci ?
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218230#comment-15218230
]
Sergey Beryozkin commented on CXF-6853:
---
Yes, I think we are talking about something similar to
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getServletPath%28%29,
because ApplicationPath is meant to support the cases where no servlet pattern
is used
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL
[ https://issues.apache.org/jira/browse/CXF-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218309#comment-15218309 ] Stefaan Vanderheyden commented on CXF-6855: --- Hello Sergey, I uploaded a test that reproduces the problem. You will see in the test that even when the ElementClass is colocated with the rest of CXF's annotations, it also has to be on the service implementation. The test is pretty explicit. BR, Stefaan On Wed, Mar 30, 2016 at 5:35 PM Sergey Beryozkin (JIRA) > ElementClass annotation is ignored on JAX-RS service interface when > generating the WADL > --- > > Key: CXF-6855 > URL: https://issues.apache.org/jira/browse/CXF-6855 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.8 >Reporter: Stefaan Vanderheyden > Attachments: ZoomitWadlBugTest.java > > > For the purpose of generating a WADL, contrary to what would be dictated by > best practices the "ElementClass" annotation is ignored by CXF when it is > placed on the JAX-RS service interface. > The annotation must be present on the service's implementation in order for > the grammar section of the WADL to be generated correctly, and for the > response types to be correctly linked to a grammar type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6853) Support encoded value in @ApplicationPath
[
https://issues.apache.org/jira/browse/CXF-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219266#comment-15219266
]
Jim Ma commented on CXF-6853:
-
Your new added test case is the reproducer for this issue. I got the 404 error
with nearly the same configuration with the test case.
> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is an encoded value, if client send request to
> http://localhost:8080/Application!/myresource and get 404 .
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(MyResource.class);
> return resources;
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6854) Application subclass can't be injected into an application lass field
[
https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219278#comment-15219278
]
Jim Ma commented on CXF-6854:
-
Updated the description, please have a look.
> Application subclass can't be injected into an application lass field
> -
>
> Key: CXF-6854
> URL: https://issues.apache.org/jira/browse/CXF-6854
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: injectionUtil.diff
>
>
> public class MyApplication extends Application {
> @Context
> Application application;
> @Context
> UriInfo info;
> @Context
> Request request;
> @Context
> HttpHeaders headers;
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(Resource.class);
> return resources;
>}
> The application field is expected to be injected with value of MyApplication
> object(this), not a null value after this application is started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6854) Application subclass can't be injected into an application lass field
[
https://issues.apache.org/jira/browse/CXF-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6854:
Description:
public class MyApplication extends Application {
@Context
Application application;
@Context
UriInfo info;
@Context
Request request;
@Context
HttpHeaders headers;
public java.util.Set> getClasses() {
Set> resources = new HashSet>();
resources.add(Resource.class);
return resources;
}
The application field is expected to be injected with value of MyApplication
object(this), not a null value after this application is started.
> Application subclass can't be injected into an application lass field
> -
>
> Key: CXF-6854
> URL: https://issues.apache.org/jira/browse/CXF-6854
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: injectionUtil.diff
>
>
> public class MyApplication extends Application {
> @Context
> Application application;
> @Context
> UriInfo info;
> @Context
> Request request;
> @Context
> HttpHeaders headers;
> public java.util.Set> getClasses() {
> Set> resources = new HashSet>();
> resources.add(Resource.class);
> return resources;
>}
> The application field is expected to be injected with value of MyApplication
> object(this), not a null value after this application is started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
