[jira] [Commented] (CXF-6902) Problem with resource that returns Object with CXF version == 3.1.2
[
https://issues.apache.org/jira/browse/CXF-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290854#comment-15290854
]
Sergey Beryozkin commented on CXF-6902:
---
Actually, I wonder if you really have a JSON representation on the wire,
appears to me in 2.7 you had a default provider converting this Integer to
String. In 2.7 this provider was called PrimitiveTextProvider and it was
supporting all Numbers and String. In CXF 3.1.x, it was split into two, and the
provider which supports Numbers is only effective if "text/plain" Media Type is
produced - it was a TCK-related fix.
> Problem with resource that returns Object with CXF version == 3.1.2
> ---
>
> Key: CXF-6902
> URL: https://issues.apache.org/jira/browse/CXF-6902
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.1.2
>Reporter: Balarami Reddy
>
> Hello,
> We have recently migrated from 2.7 to 3.1.2 and we see a behaviour change in
> CXF which blocked us from making progress.
> The sample code below gives "No message body writer has been found for
> response class Integer" which used to work perfect in CXF 2.7
> This is just sample code only. We have in our product several rest calls
> which return integer/long/Object etc based on some calculations.
> @GET
> @Produces(MediaType.APPLICATION_JSON)
> @Path("/getinteger")
> public Response getInteger() {
> return Response.ok(4).build();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6902) Problem with resource that returns Object with CXF version == 3.1.2
[
https://issues.apache.org/jira/browse/CXF-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6902.
---
Resolution: Not A Bug
Assignee: Sergey Beryozkin
Please reopen if you have the details confirming it is a bug. Please consider
asking the questions at CXF users first, thanks
> Problem with resource that returns Object with CXF version == 3.1.2
> ---
>
> Key: CXF-6902
> URL: https://issues.apache.org/jira/browse/CXF-6902
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.1.2
>Reporter: Balarami Reddy
>Assignee: Sergey Beryozkin
>
> Hello,
> We have recently migrated from 2.7 to 3.1.2 and we see a behaviour change in
> CXF which blocked us from making progress.
> The sample code below gives "No message body writer has been found for
> response class Integer" which used to work perfect in CXF 2.7
> This is just sample code only. We have in our product several rest calls
> which return integer/long/Object etc based on some calculations.
> @GET
> @Produces(MediaType.APPLICATION_JSON)
> @Path("/getinteger")
> public Response getInteger() {
> return Response.ok(4).build();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6909) Create an JCache based OAuthDataProvider
[ https://issues.apache.org/jira/browse/CXF-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290874#comment-15290874 ] Sergey Beryozkin commented on CXF-6909: --- Thanks for this quality patch, looks good. Few comments: - can you consider getting back to a Java 7 syntax ? We can keep it as is but that will mean we will not be able to back-port it to CXF 3.1.x which is Java 7 based. I'm OK with this provider be a new CXF 3.2.0 feature, but note 3.2.0 is still a long way from being considered for a release, so it is up to you if you'd like to keep it on 3.2.0 or also merge to 3.1.x. - can you please add an extension for saving authorization codes ? For ex, DefaultEhcacheOAuthDataProvider and DefaultEhcacheCodeDataProvider, same for JPA. FYI, the reason 2 providers are there, one for most of Oauth2, and another one only adding the code persistence is that originally I thought that forcing developers to write the code persistence in cases where their servers do not support the confidential web clients and the authorization code flow was not ideal. - re 'Default' in the class name. I did name 'Default'EhcacheOAuthDataProvider that way because I thought, well, someone may prefer to implement Ehcache persistence some smarter way, etc, but since then I named a JPA provider as simply JPAOAuthDataProvider/JPACodeDataProvider. Likewise, please keep 'Default' if you'd like but JCacheOAuthDataProvider would also be fine, up to you too... Thanks, Sergey > Create an JCache based OAuthDataProvider > > > Key: CXF-6909 > URL: https://issues.apache.org/jira/browse/CXF-6909 > Project: CXF > Issue Type: New Feature >Reporter: Luca Burgazzoli >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290877#comment-15290877 ] Christian Lutz commented on CXF-6904: - Hello [~ay], your workaround works only for felix, if you switch to equinox you got the same behavior as before. Maybe this helps in finding the root cause of this problem. But anyway thank you very much. Note: If you switch to equinox please remember: It may happen that one component is complaining about a missing guava class, even if you provided it before. All you have todo is copy guava-18.jar into your deploy folder. The important part is, this needs to be done after bundle has been started and has complained about it. > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290895#comment-15290895 ] Sergey Beryozkin commented on CXF-6904: --- I wonder if it is even a CXF issue and we are looking instead at a Swagger ClassHelper limitation exposed under OSGI ? > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291003#comment-15291003 ] Akitoshi Yoshida commented on CXF-6904: --- Hi Sergey, I don't think it is an issue that CXF can solve. I am not sure if it is a Swagger issue (i.e., Swagger is using org.reflections' ClasspathHelper.fromPackage wrong) or an org.reflections ClasspathHelper's issue (i.e., not finding the right classpath url when it is looking up a resource of a java package residing in two OSGi depending bundles). Hi Christian, that is interesting. we can keep this issue to track this problem. regards, aki > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6909) Create an JCache based OAuthDataProvider
[ https://issues.apache.org/jira/browse/CXF-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291141#comment-15291141 ] Luca Burgazzoli commented on CXF-6909: -- I've re-worked the PR so: - it is java 7 compatible - it provides JCacheOAuthDataProvider and JCacheCodeDataProvider > Create an JCache based OAuthDataProvider > > > Key: CXF-6909 > URL: https://issues.apache.org/jira/browse/CXF-6909 > Project: CXF > Issue Type: New Feature >Reporter: Luca Burgazzoli >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
Freeman Fang created CXF-6910:
-
Summary: don't need setSocketTimeout when create ahc RequestConfig
Key: CXF-6910
URL: https://issues.apache.org/jira/browse/CXF-6910
Project: CXF
Issue Type: Improvement
Components: Transports
Reporter: Freeman Fang
currently when we create the ahc RequestConfig we set the socketTimeout as
setSocketTimeout((int) csPolicy.getReceiveTimeout()
this cause the created http connection controlled by the socket level timeout,
that said, if there's no data on the socket in a certain time, the connection
would be closed, this overrule the TTL value of a connection, which means the
connection timeToLive can't be managed by a connectionPoolManager, this is
really painful for heavy loaded client request as we want the
connectionPoolManager to manage the connection so that we could reuse the
connection.
Fortunately in AsyncHTTPConduit
{code}
protected synchronized HttpResponse getHttpResponse()
{code}
we already handle the timeout at application level so that we needn't set that
at socket level, so that let the connectionPoolManager can decide the
connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-6910:
-
Assignee: Freeman Fang
> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-6910.
---
Resolution: Fixed
Fix Version/s: 3.2.0
3.1.7
3.0.10
> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
