[jira] [Created] (CXF-6810) Oneway with jms-transport not working
Tobias Schöneberg created CXF-6810: -- Summary: Oneway with jms-transport not working Key: CXF-6810 URL: https://issues.apache.org/jira/browse/CXF-6810 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.0.8, 3.1.5, 3.1.4 Reporter: Tobias Schöneberg I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header plan a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayReques" not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Schöneberg updated CXF-6810: --- Attachment: cxf-jms-oneway-issue.zip the tests as announced in the issue description > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header plan a role. However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayReques" not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Schöneberg updated CXF-6810: --- Description: I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header play a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayRequest not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias was: I'm trying to call a jax-rs service interface in a one-way fashion, using jms transport. I think this should work because of this documentation: http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations There, i read that both the Oneway annotation and the "OnewayRequest" client header plan a role. However, I didn't get it to work. I'm attaching junit tests where i basically iterate through these threee variables: * header "OnewayRequest" set/not set * calling a method anotated/not annotated with "Oneway" * calling a method returning Result vs. calling a void method => i.e. 8 individual tests >From those scenarios, only the two ones with "OnewayReques" not set" that call >a not-annotated method work as i would have expeced. Basically with "Oneway" i get a java.lang.NullPointerException at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) and with the header being set i eventually get a client timeout. So there might be two issues, or i'm getting something wrong with the config, but probably there is something to fix here.. Best regards, Tobias > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6809) SAMLRequest ID must not start with a Number
[ https://issues.apache.org/jira/browse/CXF-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Bernhardt resolved CXF-6809. Resolution: Fixed > SAMLRequest ID must not start with a Number > --- > > Key: CXF-6809 > URL: https://issues.apache.org/jira/browse/CXF-6809 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 2.7.18, 3.1.5, 3.0.8 >Reporter: Jan Bernhardt >Assignee: Jan Bernhardt > Fix For: 3.2.0, 3.1.6 > > > According to the XML Standard a xs:ID Element must not start with a number, > but with a character or underscore instead. > http://www.datypic.com/sc/xsd/t-xsd_ID.html > Current ID generation in SAMLRequestBuilder is based on UUID generation only > and can produce IDs that start with a number. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6810) Oneway with jms-transport not working
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173415#comment-15173415 ] Tobias Schöneberg edited comment on CXF-6810 at 3/1/16 8:47 AM: adding the tests as announced in the issue description was (Author: t.schoeneberg): the tests as announced in the issue description > Oneway with jms-transport not working > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-156) SAMLRequest ID must not start with a Number
[ https://issues.apache.org/jira/browse/FEDIZ-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Bernhardt resolved FEDIZ-156. - Resolution: Fixed Fix Version/s: (was: 1.2.3) > SAMLRequest ID must not start with a Number > --- > > Key: FEDIZ-156 > URL: https://issues.apache.org/jira/browse/FEDIZ-156 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Jan Bernhardt > Fix For: 1.3.0 > > > According to the XML Standard a xs:ID Element must not start with a number, > but with a character or underscore instead. > http://www.datypic.com/sc/xsd/t-xsd_ID.html > Current ID generation produces also IDs that start with a number. This causes > interoperability issues for example with the Siemens Entitlement Service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6682) NullpointerException in LinkBuilderImpl#getResolvedUri when only baseUri is set
[
https://issues.apache.org/jira/browse/CXF-6682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6682.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.1.5
> NullpointerException in LinkBuilderImpl#getResolvedUri when only baseUri is
> set
> ---
>
> Key: CXF-6682
> URL: https://issues.apache.org/jira/browse/CXF-6682
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4
>Reporter: Christoph Berg
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5
>
>
> The {{LinkBuilderImpl}} does not initialize its {{UriBuilder}} property with
> a non null value causing a NullPointerException if calling its `build` method
> after object construction.
> We have a testcase, which just calls {{baseUri}} followed by {{build}}.
> Previously we used Jersey as JAX-RS implementation where this test works.
> Looking at the code, Jersey initialises its property by just constructing
> their implementation of `UriBuilder`.
> I would assume, that changing the line
> {code}
> private UriBuilder ub;
> {code}
> to
> {code}
> private UriBuilder ub = new UriBuilderImpl();
> {code}
> would suffice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6810: -- Priority: Minor (was: Major) Summary: JAX-RS Client one way requests do not work with jms-transport (was: Oneway with jms-transport not working) Thanks for experimenting, I've updated the JIRA description a bit. Originally, only the server JAX-RS code could receive JMS requests - the idea was simply to let people reuse the same code in multi-transport servers. Next there was a contribution made to make the client code work with JMS, mainly with Camel CXFRS I believe. So now we have WebClient and proxies being able to use HTTP Api to send the messages over JMS which is unusual :-). I've had a single one way test so far and there JMS API is used, never tried to do one way JMS with WebClient. That said, the fix is trivial > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Priority: Minor > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173671#comment-15173671 ] Sergey Beryozkin commented on CXF-6810: --- http://git-wip-us.apache.org/repos/asf/cxf/commit/bb21c666 Note, WebClient needs a REQUEST_URI hint as it can not get it from a JMS URI > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6810. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.0.9 3.1.6 3.2.0 > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6656) [Regression] Inheritance of exceptions produces marshalling problems
[
https://issues.apache.org/jira/browse/CXF-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Mähr updated CXF-6656:
---
Affects Version/s: 3.1.5
> [Regression] Inheritance of exceptions produces marshalling problems
>
>
> Key: CXF-6656
> URL: https://issues.apache.org/jira/browse/CXF-6656
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.3, 3.1.5
>Reporter: Bernhard Mähr
>
> We have services throwing exceptions inherited from super classes.
> For example:
> {code}
> public class MyException extends org.springframework.dao.DataAccessException
> { .. }
> {code}
> Throwing this exception leads to
> Caused by: javax.xml.bind.JAXBException: java.lang.Throwable is not known to
> this context
> at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:613)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getBeanInfo(UnmarshallerImpl.java:599)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:394)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallException(JAXBEncoderDecoder.java:582)
> The problem is the method getMostSpecificCause returning an object of type
> Throwable.
> In older versions (2.4.10) the superclasses of the exception were not
> processed by JAXBEncoderDecoder.marshallException, only the getters of the
> actual class.
> Now the method Utils.getGetters is used to get the list of getters and it
> returns also getters of superclasses.
> It is not possible to avoid marshalling of the method getMostSpecificCause
> with XmlTransient because even if it is overidden in the actual class,
> Utils.getGetters returns the method off the superclass. This is because only
> annotations of the method of the superclass are checked.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173694#comment-15173694 ] Tobias Schöneberg commented on CXF-6810: Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seem to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6810) JAX-RS Client one way requests do not work with jms-transport
[ https://issues.apache.org/jira/browse/CXF-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173694#comment-15173694 ] Tobias Schöneberg edited comment on CXF-6810 at 3/1/16 12:42 PM: - Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seems to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. was (Author: t.schoeneberg): Great, thanks a lot for the quick reply&fix. I suspected that this might be a rather exotic application of cxf-rs, but to me, it seem to be the best idea. However, now I think I'm going to outline the use case in the mailing list the mailing list and ask for comments ..maybe there is a much better practice for my situation. Again, thx for the fix. > JAX-RS Client one way requests do not work with jms-transport > - > > Key: CXF-6810 > URL: https://issues.apache.org/jira/browse/CXF-6810 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.4, 3.1.5, 3.0.8 >Reporter: Tobias Schöneberg >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: cxf-jms-oneway-issue.zip > > > I'm trying to call a jax-rs service interface in a one-way fashion, using jms > transport. > I think this should work because of this documentation: > http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations > There, i read that both the Oneway annotation and the "OnewayRequest" client > header play a role. > However, I didn't get it to work. > I'm attaching junit tests where i basically iterate through these threee > variables: > * header "OnewayRequest" set/not set > * calling a method anotated/not annotated with "Oneway" > * calling a method returning Result vs. calling a void method > => i.e. 8 individual tests > From those scenarios, only the two ones with "OnewayRequest not set" that > call a not-annotated method work as i would have expeced. > Basically with "Oneway" i get a java.lang.NullPointerException at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:398) > and with the header being set i eventually get a client timeout. > So there might be two issues, or i'm getting something wrong with the config, > but probably there is something to fix here.. > Best regards, Tobias -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6811) org.apache.cxf.common.util.ClassHelper.getJavaVersion() method will fail on JDK9
Richard Opalka created CXF-6811:
---
Summary: org.apache.cxf.common.util.ClassHelper.getJavaVersion()
method will fail on JDK9
Key: CXF-6811
URL: https://issues.apache.org/jira/browse/CXF-6811
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 3.1.5
Reporter: Richard Opalka
JDK9 will come with new versioning scheme, see:
http://openjdk.java.net/jeps/223
We identified the following snippet of code to be problematic for JDK9 adoption:
org.apache.cxf.common.util.ClassHelper
public static double getJavaVersion() {
String version = System.getProperty("java.version");
return Double.parseDouble(version.substring(0, 3));
}
ATM this code fails on:
Exception in thread "main" java.lang.NumberFormatException: For input string:
"9-e"
at
jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:539)
at
org.apache.cxf.common.util.ClassHelper.getJavaVersion(ClassHelper.java:90)
with Early access JDK9.
Once official JDK9 is released this code will fail on
StringIndexOutOfBoundsException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6811) org.apache.cxf.common.util.ClassHelper.getJavaVersion() method will fail on JDK9
[
https://issues.apache.org/jira/browse/CXF-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Opalka updated CXF-6811:
Description:
JDK9 will come with new versioning scheme, see:
http://openjdk.java.net/jeps/223
We identified the following snippet of code to be problematic for JDK9 adoption:
org.apache.cxf.common.util.ClassHelper
{code}
public static double getJavaVersion() {
String version = System.getProperty("java.version");
return Double.parseDouble(version.substring(0, 3));
}
{code}
ATM this code fails on:
Exception in thread "main" java.lang.NumberFormatException: For input string:
"9-e"
at
jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:539)
at
org.apache.cxf.common.util.ClassHelper.getJavaVersion(ClassHelper.java:90)
with Early access JDK9.
Once official JDK9 is released this code will fail on
StringIndexOutOfBoundsException.
was:
JDK9 will come with new versioning scheme, see:
http://openjdk.java.net/jeps/223
We identified the following snippet of code to be problematic for JDK9 adoption:
org.apache.cxf.common.util.ClassHelper
public static double getJavaVersion() {
String version = System.getProperty("java.version");
return Double.parseDouble(version.substring(0, 3));
}
ATM this code fails on:
Exception in thread "main" java.lang.NumberFormatException: For input string:
"9-e"
at
jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:539)
at
org.apache.cxf.common.util.ClassHelper.getJavaVersion(ClassHelper.java:90)
with Early access JDK9.
Once official JDK9 is released this code will fail on
StringIndexOutOfBoundsException.
> org.apache.cxf.common.util.ClassHelper.getJavaVersion() method will fail on
> JDK9
>
>
> Key: CXF-6811
> URL: https://issues.apache.org/jira/browse/CXF-6811
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.5
>Reporter: Richard Opalka
>
> JDK9 will come with new versioning scheme, see:
> http://openjdk.java.net/jeps/223
> We identified the following snippet of code to be problematic for JDK9
> adoption:
> org.apache.cxf.common.util.ClassHelper
> {code}
> public static double getJavaVersion() {
> String version = System.getProperty("java.version");
> return Double.parseDouble(version.substring(0, 3));
> }
> {code}
> ATM this code fails on:
> Exception in thread "main" java.lang.NumberFormatException: For input string:
> "9-e"
> at
> jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
> at
> jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:539)
> at
> org.apache.cxf.common.util.ClassHelper.getJavaVersion(ClassHelper.java:90)
> with Early access JDK9.
> Once official JDK9 is released this code will fail on
> StringIndexOutOfBoundsException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FEDIZ-74) Support Google Login for Trusted IDP
[ https://issues.apache.org/jira/browse/FEDIZ-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-74. -- Resolution: Fixed > Support Google Login for Trusted IDP > > > Key: FEDIZ-74 > URL: https://issues.apache.org/jira/browse/FEDIZ-74 > Project: CXF-Fediz > Issue Type: Sub-task > Components: IDP >Affects Versions: 1.1.0 >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6085) JWE JSON Serialization
[ https://issues.apache.org/jira/browse/CXF-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6085: -- Fix Version/s: 3.0.9 > JWE JSON Serialization > -- > > Key: CXF-6085 > URL: https://issues.apache.org/jira/browse/CXF-6085 > Project: CXF > Issue Type: New Feature > Components: JAX-RS, JAX-RS Security >Reporter: Daniel Torkian >Assignee: Sergey Beryozkin > Labels: jose, jwe, patch, serialization > Fix For: 3.2.0, 3.1.6, 3.0.9 > > Attachments: initJSONJWE.txt > > > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#section-7.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6085) JWE JSON Serialization
[ https://issues.apache.org/jira/browse/CXF-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6085. --- Resolution: Fixed > JWE JSON Serialization > -- > > Key: CXF-6085 > URL: https://issues.apache.org/jira/browse/CXF-6085 > Project: CXF > Issue Type: New Feature > Components: JAX-RS, JAX-RS Security >Reporter: Daniel Torkian >Assignee: Sergey Beryozkin > Labels: jose, jwe, patch, serialization > Fix For: 3.2.0, 3.1.6 > > Attachments: initJSONJWE.txt > > > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#section-7.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6812) Cxf webTargetImpl should always check if client is closed frist
Jim Ma created CXF-6812:
---
Summary: Cxf webTargetImpl should always check if client is closed
frist
Key: CXF-6812
URL: https://issues.apache.org/jira/browse/CXF-6812
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.5
Reporter: Jim Ma
Fix For: 3.2.0, 3.1.6
org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map templatesMap) method should always check if client is closed first. If
the input templatesMap is empty , even the client is closed it still returns
this object:
@Override
public WebTarget resolveTemplatesFromEncoded(Map
templatesMap) {
checkClosed();
checkNullMap(templatesMap);
if (templatesMap.isEmpty()) {
return this;
}
return
newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6812) Cxf webTargetImpl should always check if client is closed first
[
https://issues.apache.org/jira/browse/CXF-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6812:
Summary: Cxf webTargetImpl should always check if client is closed first
(was: Cxf webTargetImpl should always check if client is closed frist)
> Cxf webTargetImpl should always check if client is closed first
> ---
>
> Key: CXF-6812
> URL: https://issues.apache.org/jira/browse/CXF-6812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.2.0, 3.1.6
>
>
> org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map Object> templatesMap) method should always check if client is closed first.
> If the input templatesMap is empty , even the client is closed it still
> returns this object:
>
> @Override
> public WebTarget resolveTemplatesFromEncoded(Map
> templatesMap) {
> checkClosed();
> checkNullMap(templatesMap);
> if (templatesMap.isEmpty()) {
> return this;
> }
> return
> newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6812) Cxf webTargetImpl should always check if client is closed frist
[
https://issues.apache.org/jira/browse/CXF-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma reassigned CXF-6812:
---
Assignee: Jim Ma
> Cxf webTargetImpl should always check if client is closed frist
> ---
>
> Key: CXF-6812
> URL: https://issues.apache.org/jira/browse/CXF-6812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.2.0, 3.1.6
>
>
> org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map Object> templatesMap) method should always check if client is closed first.
> If the input templatesMap is empty , even the client is closed it still
> returns this object:
>
> @Override
> public WebTarget resolveTemplatesFromEncoded(Map
> templatesMap) {
> checkClosed();
> checkNullMap(templatesMap);
> if (templatesMap.isEmpty()) {
> return this;
> }
> return
> newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6812) WebTargetImpl should always check if client is closed first
[
https://issues.apache.org/jira/browse/CXF-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6812:
Summary: WebTargetImpl should always check if client is closed first (was:
Cxf webTargetImpl should always check if client is closed first)
> WebTargetImpl should always check if client is closed first
> ---
>
> Key: CXF-6812
> URL: https://issues.apache.org/jira/browse/CXF-6812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.2.0, 3.1.6
>
>
> org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map Object> templatesMap) method should always check if client is closed first.
> If the input templatesMap is empty , even the client is closed it still
> returns this object:
> {code}
> @Override
> public WebTarget resolveTemplatesFromEncoded(Map
> templatesMap) {
> checkClosed();
> checkNullMap(templatesMap);
> if (templatesMap.isEmpty()) {
> return this;
> }
> return
> newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6812) Cxf webTargetImpl should always check if client is closed first
[
https://issues.apache.org/jira/browse/CXF-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ma updated CXF-6812:
Description:
org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map templatesMap) method should always check if client is closed first. If
the input templatesMap is empty , even the client is closed it still returns
this object:
{code}
@Override
public WebTarget resolveTemplatesFromEncoded(Map
templatesMap) {
checkClosed();
checkNullMap(templatesMap);
if (templatesMap.isEmpty()) {
return this;
}
return
newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
}
{code}
was:
org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map templatesMap) method should always check if client is closed first. If
the input templatesMap is empty , even the client is closed it still returns
this object:
@Override
public WebTarget resolveTemplatesFromEncoded(Map
templatesMap) {
checkClosed();
checkNullMap(templatesMap);
if (templatesMap.isEmpty()) {
return this;
}
return
newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
}
> Cxf webTargetImpl should always check if client is closed first
> ---
>
> Key: CXF-6812
> URL: https://issues.apache.org/jira/browse/CXF-6812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.2.0, 3.1.6
>
>
> org.apache.cxf.jaxrs.client.spec.Clientimpl$WebClientImpl#resolveTemplatesFromEncoded(Map Object> templatesMap) method should always check if client is closed first.
> If the input templatesMap is empty , even the client is closed it still
> returns this object:
> {code}
> @Override
> public WebTarget resolveTemplatesFromEncoded(Map
> templatesMap) {
> checkClosed();
> checkNullMap(templatesMap);
> if (templatesMap.isEmpty()) {
> return this;
> }
> return
> newWebTarget(getUriBuilder().resolveTemplatesFromEncoded(templatesMap));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6784) WS-Notification subscription should support renew
[
https://issues.apache.org/jira/browse/CXF-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-6784.
---
Resolution: Fixed
Fix Version/s: 3.1.6
3.2.0
commit fix
http://git-wip-us.apache.org/repos/asf/cxf/commit/cb36642a for master
http://git-wip-us.apache.org/repos/asf/cxf/commit/15e4db96 for 3.1.x-fixes
branch
> WS-Notification subscription should support renew
> -
>
> Key: CXF-6784
> URL: https://issues.apache.org/jira/browse/CXF-6784
> Project: CXF
> Issue Type: New Feature
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.0, 3.1.6
>
>
> currently it's
> {code}
> @Override
> protected void renew(XMLGregorianCalendar terminationTime) throws
> UnacceptableTerminationTimeFault {
> UnacceptableTerminationTimeFaultType fault = new
> UnacceptableTerminationTimeFaultType();
> throw new UnacceptableTerminationTimeFault("TerminationTime is not
> supported", fault);
> }
> {code}
> and also the subscription.start should support to specify the terminationTime
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
