[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15497692#comment-15497692
]
Andriy Redko commented on CXF-7045:
---
Hi Sergey,
I think on a second thought it probably makes sense. So let us:
- introduce a standalone feature *cxf-jackson*
- change *cxf-rt-rs-service-description-swagger* to depend on it
- update sample's README to remove additional steps as all the bundles should
be installed
Sounds like a good plan? :-)
Thanks!
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15497328#comment-15497328
]
Sergey Beryozkin commented on CXF-7045:
---
Hi Andriy,
I see what your concern is, why would CXF worry about facilitating installing
Jackson.
Jackson's only concern, as far as OSGI is concerned, is to have each of those
5+ jars OSGI-friendly.
But even so, we haven't had any specific Jackson support till now.
I guess all the features that we ship with CXF enable something atomically. So
if we have a swagger2 feature that does not actually enable Swagger unless a
user manually pre-installs Jackson then I'd say the feature is incomplete.
But Swagger2 OSGI feature actually has an indirect support for Jackson right
now. So we can make it work with Option3. But we can also make it work by
introducing cxf-jackson, and as you said have the existing swagger2feature
depend on it - it will be mostly equivalent to what we right now but the extra
benefit that CXF users can use cxf-jackson on its own...
Thanks, Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496718#comment-15496718
]
Andriy Redko edited comment on CXF-7045 at 9/16/16 4:22 PM:
Hi Sergey,
I think it is feasible in general, but why would CXF provide a feature to
install just Jackson? Here is basically the concern I have. F.e. if I am
building an application and I need to install additional bundles (Jackson is
good example, like you mentioned), I do know that and I will install them. Now,
it happens that our own sample project has to include some additional bundles
as well. We could make this process easier (by pre-installing some bundles,
hopefully users will need them anyway) or ask user to do that.
I am honestly not sure about having dedicated CXF feature for Jackson, it feels
like that should not be the CXF responsibility but Jackson itself. However we
do have similar use cases, f.e. *cxf-jaxb*, so I think in general it might be
OK. So it would mean to have standalone *cxf-jackson* feature, and
*cxf-rt-rs-service-description-swagger* will depend on it as well, right?
Thanks.
Best Regards,
Andriy Redko
was (Author: reta):
Hi Sergey,
I think it is feasible in general, but why would CXF provide a feature to
install just Jackson? Here is basically the concern I have. F.e. if I am
building an application and I need to install additional bundles (Jackson is
good example, like you mentioned), I do know that and I will install them. Now,
it happens that our own sample project has to include some additional bundles
as well. We could make this process easier (by pre-installing some bundles,
hopefully users will need them anyway) or ask user to do that.
I am honestly not sure about having dedicated CXF feature for Jackson, it feels
like that should not be the CXF responsibility but Jackson itself. However we
do have similar use cases, f.e. cxf-jaxb, so I think in general it might be OK.
So it would mean to have standalone *cxf_jackson* feature, and
*cxf-rt-rs-service-description-swagger* will depend on it as well, right?
Thanks.
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496718#comment-15496718
]
Andriy Redko commented on CXF-7045:
---
Hi Sergey,
I think it is feasible in general, but why would CXF provide a feature to
install just Jackson? Here is basically the concern I have. F.e. if I am
building an application and I need to install additional bundles (Jackson is
good example, like you mentioned), I do know that and I will install them. Now,
it happens that our own sample project has to include some additional bundles
as well. We could make this process easier (by pre-installing some bundles,
hopefully users will need them anyway) or ask user to do that.
I am honestly not sure about having dedicated CXF feature for Jackson, it feels
like that should not be the CXF responsibility but Jackson itself. However we
do have similar use cases, f.e. cxf-jaxb, so I think in general it might be OK.
So it would mean to have standalone *cxf_jackson* feature, and
*cxf-rt-rs-service-description-swagger* will depend on it as well, right?
Thanks.
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496630#comment-15496630
]
Sergey Beryozkin commented on CXF-7045:
---
Hi Andriy, I'm actually thinking it will become easier for the users.
Lets take it step by step.
- Users need Jackson (without even worrying about Swagger) - they have to do
*5* install commands, see
https://github.com/apache/cxf/pull/167/files.
So having Jackson feature in its own is good IMHO - only one install command.
- Now users install Swagger 2 feature and all works.
Having Swagger2 feature forcing the install of Jackson is OK as long as this
Jackson will not interfere with other installed Jacksons.
So if we 2 swagger features, one for a case where Jackson is already installed
and one for a case where it has not been installed, then I can only see it
becoming simpler.
Where is the complexity coming from in your opinion, lets take some concrete
examples
thanks, Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496605#comment-15496605
]
Andriy Redko commented on CXF-7045:
---
Hey Sergey,
Not sure about that, really. I understand what you mean, but it sounds
complicated to me. And probably, it won't be straightforward to the users as
well. Regarding this particular use case, I think we would be safe by just
installing com.fasterxml.jackson.jaxrs bundles. The
cxf-rt-rs-service-description-swagger already dependents on quite a few core
Jackson libraries, so we would just introduce a few more which users, very
likely, will need anyway. What do you think?
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496577#comment-15496577
]
Sergey Beryozkin edited comment on CXF-7045 at 9/16/16 3:29 PM:
I've been wondering if we should support different scenarios and thus have few
features.
First we should have a helper 'jackson' feature - for all the users who prefer
to install Jackson in OSGI, this in itself not related to Swagger2.
Next we have a 'minimal' Swagger2 feature - it has all but jackson specific
dependencies.
Finally we have a current swagger2 feature which, with option3 enforced, simply
works - it will depend on a new jackson feature.
So if a user has already installed Jackson manually or with a new Jackson
feature to support JSON at the application level and Swagger is needed - then
'minimal' Swagger2 feature is installed. Otherwise - a complete swagger2
feature is installed.
Does it work ?
Sergey
was (Author: sergey_beryozkin):
I've been wondering if we should support difference scenarios and thus have few
features.
First we should have a helper 'jackson' feature - for all the users who prefer
to install Jackson in OSGI, this in itself not related to Swagger2.
Next we have a 'minimal' Swagger2 feature - it has all but jackson specific
dependencies.
Finally we have a current swagger2 feature which, with option3 enforced, simply
works - it will depend on a new jackson feature.
So if a user has already installed Jackson manually or with a new Jackson
feature to support JSON at the application level and Swagger is needed - then
'minimal' Swagger2 feature is installed. Otherwise - a complete swagger2
feature is installed.
Does it work ?
Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496577#comment-15496577
]
Sergey Beryozkin commented on CXF-7045:
---
I've been wondering if we should support difference scenarios and thus have few
features.
First we should have a helper 'jackson' feature - for all the users who prefer
to install Jackson in OSGI, this in itself not related to Swagger2.
Next we have a 'minimal' Swagger2 feature - it has all but jackson specific
dependencies.
Finally we have a current swagger2 feature which, with option3 enforced, simply
works - it will depend on a new jackson feature.
So if a user has already installed Jackson manually or with a new Jackson
feature to support JSON at the application level and Swagger is needed - then
'minimal' Swagger2 feature is installed. Otherwise - a complete swagger2
feature is installed.
Does it work ?
Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7060) Provide Karaf 4 specific features and commands
Guillaume Nodet created CXF-7060: Summary: Provide Karaf 4 specific features and commands Key: CXF-7060 URL: https://issues.apache.org/jira/browse/CXF-7060 Project: CXF Issue Type: Improvement Components: OSGi Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2.0 There are a few shortcomings when using the existing features in Karaf 4.x. Creating specific features and commands will allow: * to not depend on blueprint * to validate the feature definitions correctly * fix existing features In addition some features have a strong dependency on jetty, while Karaf 4.1 will provide a choice for the http / war provider (jetty, tomcat, undertow), so it would make sense to refactor some features to better leverage those possibilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values
[
https://issues.apache.org/jira/browse/CXF-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-7059.
--
Resolution: Fixed
> 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
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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] [Commented] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values
[
https://issues.apache.org/jira/browse/CXF-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495826#comment-15495826
]
Colm O hEigeartaigh commented on CXF-7059:
--
Thanks for the patch.
> 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
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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] [Updated] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values
[
https://issues.apache.org/jira/browse/CXF-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-7059:
-
Fix Version/s: 3.0.11
3.1.8
3.2.0
> 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
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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] [Commented] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values
[
https://issues.apache.org/jira/browse/CXF-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495818#comment-15495818
]
ASF GitHub Bot commented on CXF-7059:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/171
> 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
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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] [Assigned] (CXF-7059) ClientImpl.getBooleanValue() will return null for String values
[
https://issues.apache.org/jira/browse/CXF-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-7059:
Assignee: Colm O hEigeartaigh
> 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
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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)
