[jira] [Commented] (CXF-8305) WSDL2Java generates java code that won't compile for array of byte arrays
[
https://issues.apache.org/jira/browse/CXF-8305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142705#comment-17142705
]
Andrei Ivanov commented on CXF-8305:
I assume it's https://github.com/eclipse-ee4j/jaxb-ri
> WSDL2Java generates java code that won't compile for array of byte arrays
> -
>
> Key: CXF-8305
> URL: https://issues.apache.org/jira/browse/CXF-8305
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.3.6
>Reporter: Steve Armstrong
>Priority: Critical
> Attachments: test.zip
>
>
> I am using a wsdl snippet that looks like the following:
> {code:xml}
>
>
>
> Defines the results of a caCertificateLDAPGet
> operation
>
>
>
> nillable="true">
>
>
> Indicates whether the returns attribute is
> string data or binary data.
> True if the attribute is binary.
>
>
>
> minOccurs="0" type="xsd:string" nillable="true" >
>
>
> A list of the strings found at a string
> attribute.
>
>
>
> minOccurs="0" type="xsd:base64Binary"
> nillable="true" >
>
>
> A list of the base64 encoded data found at a
> binary attribute.
>
>
>
>
>
> {code}
> In is the BinaryAttribute above that is of interest.
> When this gets compiled using WSDL2Java and Java 8 with
> collectionType="indexed", the following code snipped is produced.
>
> {code:java}
> /**
> *
> *
> * @param values
> * allowed objects are
> * byte[]
> */
> public void setBinaryAttribute(byte[][] values) {
> int len = values.length;
> this.binaryAttribute = ((byte[][]) new byte[][len] );
> for (int i = 0; (i this.binaryAttribute[i] = ((byte[]) values[i]);
> }
> }
> {code}
> Clearly, this is invalid Java since you need to set len on the first
> dimension of the array, not the second.
> Java can't compile the code generated by WSDL2Java so that's the end of
> things.
> If you know of any work-around (other than *not* using
> collectionType="indexed", please let me know. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8216) Support optional path params in wadl2java
[
https://issues.apache.org/jira/browse/CXF-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Ivanov updated CXF-8216:
---
Description:
After reading
[https://nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/],
I tried to define my own:
{code:xml}
Scan code
{code}
The problem seems to be that the generator treats *path* params as
[required|https://github.com/apache/cxf/blob/5ed6310b1621f8a61172c3be85ab66af0310af67/tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L1246].
I was actually trying to define it as a *matrix* param, but it seems that a
matrix param isn't really supported by JAX-RS at the end of the URL, not in
middle path segments.
was:
After reading
https://nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/,
I tried to define my own:
{code:xml}
Scan code
{code}
The problem seems to be that the generator treats *path* params as
[required|https://github.com/apache/cxf/blob/5ed6310b1621f8a61172c3be85ab66af0310af67/tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L1246].
> Support optional path params in wadl2java
> -
>
> Key: CXF-8216
> URL: https://issues.apache.org/jira/browse/CXF-8216
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.3.5
>Reporter: Andrei Ivanov
>Priority: Major
>
> After reading
> [https://nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/],
> I tried to define my own:
> {code:xml}
>
>
> required="false"/>
>
>
> Scan code
>
>
>
>
> element="ns:SalesTransaction"/>
> element="ns:SalesTransaction"/>
>
>
>
> {code}
> The problem seems to be that the generator treats *path* params as
> [required|https://github.com/apache/cxf/blob/5ed6310b1621f8a61172c3be85ab66af0310af67/tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L1246].
> I was actually trying to define it as a *matrix* param, but it seems that a
> matrix param isn't really supported by JAX-RS at the end of the URL, not in
> middle path segments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8216) Support optional path params in wadl2java
Andrei Ivanov created CXF-8216:
--
Summary: Support optional path params in wadl2java
Key: CXF-8216
URL: https://issues.apache.org/jira/browse/CXF-8216
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 3.3.5
Reporter: Andrei Ivanov
After reading
https://nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/,
I tried to define my own:
{code:xml}
Scan code
{code}
The problem seems to be that the generator treats *path* params as
[required|https://github.com/apache/cxf/blob/5ed6310b1621f8a61172c3be85ab66af0310af67/tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L1246].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8026) Support @BeanParam in wadl2java
[
https://issues.apache.org/jira/browse/CXF-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988710#comment-16988710
]
Andrei Ivanov commented on CXF-8026:
[~amarkevich] Since I saw you had courage to work in this area with CXF-8168,
any chance you could look at this one too? 😁
> Support @BeanParam in wadl2java
> ---
>
> Key: CXF-8026
> URL: https://issues.apache.org/jira/browse/CXF-8026
> Project: CXF
> Issue Type: Improvement
>Reporter: Andrei Ivanov
>Priority: Minor
>
> Having a resource with many parameters, the generated Java method is getting
> difficult to use and adding one more parameter means updating all the calling
> code.
> It would be nice to be able to mark it with a parameter (like {{async}}) so
> that the generator would create a separate {{@BeanParam}} class with all
> those parameters inside it.
> I realize this will problably will not get fixed since {{wadl2java}} seems
> abandoned :(
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8026) Support @BeanParam in wadl2java
Andrei Ivanov created CXF-8026:
--
Summary: Support @BeanParam in wadl2java
Key: CXF-8026
URL: https://issues.apache.org/jira/browse/CXF-8026
Project: CXF
Issue Type: Improvement
Reporter: Andrei Ivanov
Having a resource with many parameters, the generated Java method is getting
difficult to use and adding one more parameter means updating all the calling
code.
It would be nice to be able to mark it with a parameter (like {{async}}) so
that the generator would create a separate {{@BeanParam}} class with all those
parameters inside it.
I realize this will problably will not get fixed since {{wadl2java}} seems
abandoned :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-6817) Provide an easy way to set authentication for JAXRS client
[
https://issues.apache.org/jira/browse/CXF-6817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651312#comment-16651312
]
Andrei Ivanov commented on CXF-6817:
Ugh, no activity :(
And I was going to ask about any sort of standardization for the client runtime
proxy generation, but I don't think there's a chance for that either
> Provide an easy way to set authentication for JAXRS client
> --
>
> Key: CXF-6817
> URL: https://issues.apache.org/jira/browse/CXF-6817
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Dennis Kieselhorst
>Priority: Major
>
> CXF should provide an easy way to configure the basic authentication for a
> JAXRS client programmatically, e.g.:
> {code:java}
> Client client = ClientBuilder.newClient().register(new
> java.net.Authenticator() {
> @Override
> protected PasswordAuthentication getPasswordAuthentication() {
> return new PasswordAuthentication("myuser",
> "mypassword".toCharArray());
> }
> });
> {code}
> See also:
> http://stackoverflow.com/questions/25155017/client-side-authentication-with-jax-rs-and-cxf
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-6817) Provide an easy way to set authentication for JAXRS client
[
https://issues.apache.org/jira/browse/CXF-6817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650437#comment-16650437
]
Andrei Ivanov commented on CXF-6817:
Any answers from the EG? :)
> Provide an easy way to set authentication for JAXRS client
> --
>
> Key: CXF-6817
> URL: https://issues.apache.org/jira/browse/CXF-6817
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Dennis Kieselhorst
>Priority: Major
>
> CXF should provide an easy way to configure the basic authentication for a
> JAXRS client programmatically, e.g.:
> {code:java}
> Client client = ClientBuilder.newClient().register(new
> java.net.Authenticator() {
> @Override
> protected PasswordAuthentication getPasswordAuthentication() {
> return new PasswordAuthentication("myuser",
> "mypassword".toCharArray());
> }
> });
> {code}
> See also:
> http://stackoverflow.com/questions/25155017/client-side-authentication-with-jax-rs-and-cxf
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612738#comment-16612738
]
Andrei Ivanov edited comment on CXF-7825 at 9/12/18 9:13 PM:
-
One other thing that I don't understand very clearly in CXF-3797, the
discussion about multiple request representations was with multiple types or
representations (A and B) and the same media type (XML), and I can understand
that the server runtime might have issues matching a request to a single method.
But this ticket is about a single type/representation (A) with multiple media
types (XML and JSON).
As far as I see in the JAX-RS API, this scenario should be supported fine.
What do you think?
was (Author: shadow):
One other thing that I don't understand very clearly in CXF-3797, the
discussion about multiple request representations was with multiple types (A
and B) and the same media type (XML), and I can understand that the server
runtime might have issues matching a request to a single method.
But this ticket is about a single type (A) with multiple media types (XML and
JSON).
As far as I see in the JAX-RS API, this scenario should be supported fine.
What do you think?
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612738#comment-16612738
]
Andrei Ivanov commented on CXF-7825:
One other thing that I don't understand very clearly in CXF-3797, the
discussion about multiple request representations was with multiple types (A
and B) and the same media type (XML), and I can understand that the server
runtime might have issues matching a request to a single method.
But this ticket is about a single type (A) with multiple media types (XML and
JSON).
As far as I see in the JAX-RS API, this scenario should be supported fine.
What do you think?
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610525#comment-16610525
]
Andrei Ivanov commented on CXF-7825:
Got it :)
It's going to be tricky to be done as the code already is complicated enough,
but I hope I'll be able to do it.
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610453#comment-16610453
]
Andrei Ivanov commented on CXF-7825:
I'm still not sure about the problem you mention as my code seems to work fine.
The same generated interface is used for both server endpoints and for the
client runtime proxies, which seem to use the 1st media type defined in the
{{@Produces}} annotation.
Maybe it's something specific to CXF?
I forgot to mention that we use Jersey for the JAX-RS runtime.
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610422#comment-16610422
]
Andrei Ivanov commented on CXF-7825:
Yes, indeed, it's normally generating 2 methods.
But if you take one more look at the description above, you can see that it is
possible to make it generate 1 method with 2 media types and the client proxy
with that interface is happy and choses the 1st media type in the list :)
My problem is that the way I defined the representations might not actually be
valid.
That's why I was hoping to get some guidance from you.
# Should I try to update the generator to generate 1 method with multiple
media types if the XML element is the same in all cases?
{color:#654982}As I said before, the client proxy is happy with that kind of
Java interface and chooses the 1st media type in the list.{color}
# Should I try to update the generator for the 2nd way of defining the
representations (which I'm not sure they are correct) to detect the element
type and generate the {{@Value}} for them
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610327#comment-16610327
]
Andrei Ivanov commented on CXF-7825:
Hmm, my problem is with the request, not with the response, as those
definitions are accepted fine by the generator.
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609701#comment-16609701
]
Andrei Ivanov commented on CXF-7825:
[~sergey_beryozkin] I know you're retired :), but maybe you can spare a couple
minutes to tell me how it would be best to proceed?
Thank you
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608512#comment-16608512
]
Andrei Ivanov commented on CXF-7825:
I was thinking of trying to implement the required changes myself, but I'm not
even sure if the WADLs I've mentioned are correct :(
Any thoughts?
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
> @PUT
> @Consumes({"application/json", "application/xml" })
> @Produces({"application/json", "application/xml" })
> @Path("/transaction/{uuid}")
> Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
> }
> {code}
> The problem with this approach is that now I'm trying to enable _bean
> validation_, but the generator ignores this 2nd approach representations
> because it doesn't find an {{element}} attribute on the representations.
> Not sure what the solution is, maybe just update the generator to handle the
> 1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7825) wadl2java: support multiple representations of the same element
[
https://issues.apache.org/jira/browse/CXF-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Ivanov updated CXF-7825:
---
Description:
Hi,
I have little experience using WADL and I'm trying to define a resource which
accepts a request parameter with multiple representations (JSON and XML):
{code:xml}
Store a Payment corresponding to the specified transaction
Returns the newly stored payment
Storing of the payment failed
{code}
As far as I see, after CXF-3797, the generator doesn't handle this scenario,
considering them as different types.
I've also tried this way, which I'm not even sure is correct, but the generator
seems to generate correct code, which is a single method which consumes the 2
media types:
{code:xml}
{code}
{code:java}
@Path("/paymentmanagement")
public interface PaymentManagementService {
/**
* @return Returns the newly stored payment
*/
@PUT
@Consumes({"application/json", "application/xml" })
@Produces({"application/json", "application/xml" })
@Path("/transaction/{uuid}")
Payment storePayment(@PathParam("uuid") String uuid, Payment payment);
}
{code}
The problem with this approach is that now I'm trying to enable _bean
validation_, but the generator ignores this 2nd approach representations
because it doesn't find an {{element}} attribute on the representations.
Not sure what the solution is, maybe just update the generator to handle the
1st approach properly.
was:
Hi,
I have little experience using WADL and I'm trying to define a resource which
accepts a request parameter with multiple representations (JSON and XML):
{code:xml}
Store a Payment corresponding to the specified transaction
Returns the newly stored payment
Storing of the payment failed
{code}
As far as I see, after CXF-3797, the generator doesn't handle this scenario,
considering them as different types.
I've also tried this way, which I'm not even sure are correct, but the
generator seems to generate correct code, which is a single method which
consumes the 2 media types:
{code:xml}
{code}
The problem with this approach is that now I'm trying to enable _bean
validation_, but the generator ignores this 2nd approach representations
because it doesn't find an {{element}} attribute on the representations.
Not sure what the solution is, maybe just update the generator to handle the
1st approach properly.
> wadl2java: support multiple representations of the same element
> ---
>
> Key: CXF-7825
> URL: https://issues.apache.org/jira/browse/CXF-7825
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.2.6
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hi,
> I have little experience using WADL and I'm trying to define a resource
> which accepts a request parameter with multiple representations (JSON and
> XML):
> {code:xml}
>
>
> Store a Payment corresponding to the specified transaction
>
>
>
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Returns the newly stored payment
> element="ns:Payment" />
> element="ns:Payment" />
>
>
> Storing of the payment failed
> element="ns:ExceptionDetails" />
> element="ns:ExceptionDetails" />
>
>
>
>
> {code}
> As far as I see, after CXF-3797, the generator doesn't handle this scenario,
> considering them as different types.
> I've also tried this way, which I'm not even sure is correct, but the
> generator seems to generate correct code, which is a single method which
> consumes the 2 media types:
> {code:xml}
>
>
>
>
>
>
> {code}
> {code:java}
> @Path("/paymentmanagement")
> public interface PaymentManagementService {
> /**
> * @return Returns the newly stored payment
> */
[jira] [Created] (CXF-7825) wadl2java: support multiple representations of the same element
Andrei Ivanov created CXF-7825:
--
Summary: wadl2java: support multiple representations of the same
element
Key: CXF-7825
URL: https://issues.apache.org/jira/browse/CXF-7825
Project: CXF
Issue Type: Bug
Components: JAX-RS, Tooling
Affects Versions: 3.2.6
Reporter: Andrei Ivanov
Hi,
I have little experience using WADL and I'm trying to define a resource which
accepts a request parameter with multiple representations (JSON and XML):
{code:xml}
Store a Payment corresponding to the specified transaction
Returns the newly stored payment
Storing of the payment failed
{code}
As far as I see, after CXF-3797, the generator doesn't handle this scenario,
considering them as different types.
I've also tried this way, which I'm not even sure are correct, but the
generator seems to generate correct code, which is a single method which
consumes the 2 media types:
{code:xml}
{code}
The problem with this approach is that now I'm trying to enable _bean
validation_, but the generator ignores this 2nd approach representations
because it doesn't find an {{element}} attribute on the representations.
Not sure what the solution is, maybe just update the generator to handle the
1st approach properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7814) wadl2java: support the JAX-RS 2.1 reactive results
Andrei Ivanov created CXF-7814:
--
Summary: wadl2java: support the JAX-RS 2.1 reactive results
Key: CXF-7814
URL: https://issues.apache.org/jira/browse/CXF-7814
Project: CXF
Issue Type: New Feature
Components: Tooling
Affects Versions: 3.2.5
Reporter: Andrei Ivanov
As far as I understand, JAX-RS 2.1 added support for reactive results, but I
don't see how to generate Java interfaces from a WADL file with these.
I assume that some parameters similar to {{-async}} should be added to indicate
which methods should return one of the supported reactive results, like
{{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7673) Implement MicroProfile Rest Client 1.1
[
https://issues.apache.org/jira/browse/CXF-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530059#comment-16530059
]
Andrei Ivanov commented on CXF-7673:
Any updates? :)
> Implement MicroProfile Rest Client 1.1
> --
>
> Key: CXF-7673
> URL: https://issues.apache.org/jira/browse/CXF-7673
> Project: CXF
> Issue Type: New Feature
>Reporter: John D. Ament
>Assignee: Andy McCright
>Priority: Major
>
> Implement MP Rest Client 1.1
> * Async support
> * baseUri vs baseUrl
> * {{ProviderRegistrar}} support
>
> FYI [~andymc]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7725) ensure all tests on master can pass with java10
[
https://issues.apache.org/jira/browse/CXF-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16480491#comment-16480491
]
Andrei Ivanov edited comment on CXF-7725 at 5/18/18 11:06 AM:
--
{code:java}
catch (NoSuchFieldException e) {
//best effort to try, do nothing if NoSuchMethodException
{code}
The comment doesn't match the code, not sure if it's on purpose :)
Also ASM 6.1.1 is the latest version
(https://mail.ow2.org/wws/arc/asm/2018-03/msg5.html)
was (Author: shadow):
{code}
catch (NoSuchFieldException e) {
//best effort to try, do nothing if NoSuchMethodException
{code}
The comment doesn't match the code, not sure if it's on purpose :)
> ensure all tests on master can pass with java10
> ---
>
> Key: CXF-7725
> URL: https://issues.apache.org/jira/browse/CXF-7725
> Project: CXF
> Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Attachments: CXF-7725.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7725) ensure all tests on master can pass with java10
[
https://issues.apache.org/jira/browse/CXF-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16480491#comment-16480491
]
Andrei Ivanov commented on CXF-7725:
{code}
catch (NoSuchFieldException e) {
//best effort to try, do nothing if NoSuchMethodException
{code}
The comment doesn't match the code, not sure if it's on purpose :)
> ensure all tests on master can pass with java10
> ---
>
> Key: CXF-7725
> URL: https://issues.apache.org/jira/browse/CXF-7725
> Project: CXF
> Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Attachments: CXF-7725.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7620) 3.0.11 cxf-xjc-plugin generate goal wont generate .java files
[
https://issues.apache.org/jira/browse/CXF-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339070#comment-16339070
]
Andrei Ivanov commented on CXF-7620:
Can you try with latest version(s)?
There's a chance this was already fixed.
> 3.0.11 cxf-xjc-plugin generate goal wont generate .java files
> -
>
> Key: CXF-7620
> URL: https://issues.apache.org/jira/browse/CXF-7620
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.0.11
> Environment: Maven home: C:\maven\maven333
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: C:\Java\jdk1.8\jre
>Reporter: Martin Gainty
>Priority: Major
>
>
> org.apache.cxf
> cxf-xjc-plugin
>
>
> xsd-generate-java
> generate-sources
>
> xsdtojava
>
>
>
>
>
> -XautoNameResolution
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics:0.6.4
>
>
>
> ${basedir}/po.xsd
> ${basedir}/bindings.xjb
>
> -XtoString
> -XhashCode
> -Xequals
>
> -Xequals-equalsStrategyClass=org.apache.activemq.plugin.jaxb2_commons.ElementAwareEqualsStrategy
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7322) Response.StatusType.getReasonPhrase not working
[
https://issues.apache.org/jira/browse/CXF-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961751#comment-15961751
]
Andrei Ivanov commented on CXF-7322:
Btw, Tomcat 9 will not send a reason phrase and for 8.5 is just optional, after
a lot of people insisted: https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
> Response.StatusType.getReasonPhrase not working
> ---
>
> Key: CXF-7322
> URL: https://issues.apache.org/jira/browse/CXF-7322
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Vjacheslav Borisov
>Priority: Minor
>
> I have custom Response.StatusType class
> {code}
> public class CustomResponseStatus implements Response.StatusType {
>
> private final int statusCode;
> private final String reasonPhrase;
> public CustomResponseStatus(int statusCode, String reasonPhrase) {
> this.statusCode = statusCode;
> this.reasonPhrase = reasonPhrase;
> }
> @Override
> public int getStatusCode() {
> return statusCode;
> }
> @Override
> public Response.Status.Family getFamily() {
> return Response.Status.Family.familyOf(statusCode);
> }
> @Override
> public String getReasonPhrase() {
> return reasonPhrase;
> }
> }
> {code}
> Usage:
> Response.StatusType status=new CustomResponseStatus(453,"custom
> reasonPhrase ");
> return Response.status(status).entity("Hello " + a + ", Welcome to
> CXF RS Spring Boot World!!!").build();
> I do not see method getReasonPhrase() gets called and reasonPhrase in
> response not filled:
> curl -v
> 'http://localhost:8080/services/helloservice/sayHello/reason/ApacheCxfUser'
> * Hostname was NOT found in DNS cache
> * Trying ::1...
> * Connected to localhost (::1) port 8080 (#0)
> > GET /services/helloservice/sayHello/reason/ApacheCxfUser HTTP/1.1
> > User-Agent: curl/7.37.0
> > Host: localhost:8080
> > Accept: */*
> >
> < HTTP/1.1 453
> E.g. there should be
> HTTP/1.1 453 custom reasonPhrase
> Example project
> https://github.com/slavb18/spring_boot_scan
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CXF-7259) LoggingOutInterceptor filtering
[ https://issues.apache.org/jira/browse/CXF-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880391#comment-15880391 ] Andrei Ivanov commented on CXF-7259: Trivial question: would a Set perform better in this case? > LoggingOutInterceptor filtering > --- > > Key: CXF-7259 > URL: https://issues.apache.org/jira/browse/CXF-7259 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.10 >Reporter: Aliaksei Masevich >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.0.13, 3.1.11 > > > As a user I want to have a possibility to hide payloads of some messages > logged by LoggingOutInterceptor. Binary content media types already can be > filtered, however it's not available for user to customize filtered content > types. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7231) Java HttpUrlConnection Reflection Fix to support custom verbs does not work with HTTPS
[
https://issues.apache.org/jira/browse/CXF-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839512#comment-15839512
]
Andrei Ivanov commented on CXF-7231:
Is the {{t.printStackTrace()}} intentional?
> Java HttpUrlConnection Reflection Fix to support custom verbs does not work
> with HTTPS
> --
>
> Key: CXF-7231
> URL: https://issues.apache.org/jira/browse/CXF-7231
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.9
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.10
>
>
> Java HTTPUrlConnection does not support custom HTTP verbs however CXF does
> the best effort at getting such methods supported by reflectively updating
> HTTPUrlConnection during the request.
> It does work with plain HTTP but still fails if HTTPS is used.
> More reflection fixes are needed.
> Note CXF does support such methods OOB with the Apache HttpClient based
> conduit which can be run in the async or sync modes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[
https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571451#comment-15571451
]
Andrei Ivanov edited comment on CXF-6798 at 10/13/16 9:49 AM:
--
Well, it seemed weird just because I was under the assumption that the support
is complete :)
Any thoughts about my suggestion with ParamConverters for some usual types?
was (Author: shadow):
Well, it seemed weird just because I was under the assumption that the support
is complete :)
Any thoughts about my suggestion with {{ParamConverter}}s for some usual types?
> JAXRS 2.0 Clients do not support ParamConverters
>
>
> Key: CXF-6798
> URL: https://issues.apache.org/jira/browse/CXF-6798
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[
https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571451#comment-15571451
]
Andrei Ivanov commented on CXF-6798:
Well, it seemed weird just because I was under the assumption that the support
is complete :)
Any thoughts about my suggestion with {{ParamConverter}}s for some usual types?
> JAXRS 2.0 Clients do not support ParamConverters
>
>
> Key: CXF-6798
> URL: https://issues.apache.org/jira/browse/CXF-6798
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[
https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569681#comment-15569681
]
Andrei Ivanov commented on CXF-6798:
Seemed weird to still have missing functionalities for 2.0 after all this time
:)
But I've learned about {{ParamConverter}} only recently, when trying to use a
Joda DateTime as param and I didn't understand how this doesn't work in 2016 :-/
I actually thought the {{jackson-datatype-joda}} module would take care of the
conversion, but it seems I just misunderstood how these things work.
Maybe CXF should provide some {{ParamConverters}} for usual types, like dates
(both Joda and JSR 310)?
> JAXRS 2.0 Clients do not support ParamConverters
>
>
> Key: CXF-6798
> URL: https://issues.apache.org/jira/browse/CXF-6798
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[ https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565875#comment-15565875 ] Andrei Ivanov commented on CXF-6798: Seeing that CXF devs started work on the 2.1 API, I noticed that there are still 2.0 parts missing :) Do you know of any plans to fix this? Are there any other parts missing from 2.0? > JAXRS 2.0 Clients do not support ParamConverters > > > Key: CXF-6798 > URL: https://issues.apache.org/jira/browse/CXF-6798 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6891) IOUtils.isEmpty() doesn't reinclude byte in stream.
[
https://issues.apache.org/jira/browse/CXF-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270858#comment-15270858
]
Andrei Ivanov commented on CXF-6891:
Trivial improvement suggestion:
{code:java}
Long len = Long.valueOf(value);
return len <= 0;
{code}
Switch to {{long len = Long.parseLong(value);}} in {{HttpUtils.isPayloadEmpty}}.
> IOUtils.isEmpty() doesn't reinclude byte in stream.
> ---
>
> Key: CXF-6891
> URL: https://issues.apache.org/jira/browse/CXF-6891
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.1.6
>Reporter: Luca Tabone
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: cxf-bug.zip
>
>
> While trying to integrate Katharsis with CXF I faced a problem related to
> IOUtils.isEmpty() method.
> When isEmpty is invoked with an InputStream that:
> 1. Is not 'mark supported' and
> 2. The 'available()' method returns '0'.
> The byte that is read from the stream (used to determine whether the stream
> is empty or not) is not re-included back to the stream. When I explored the
> code inside PushbackInputStream class, I found that the byte is only being
> included inside the PushbackInputStream.buf (using unread(byte[], int, int)
> method).
> Find attached Maven Project containing 2 test cases.
> References:
> > IOUtils:
> https://cxf.apache.org/javadoc/latest/org/apache/cxf/helpers/IOUtils.html
> > PushbackInputStream:
> https://docs.oracle.com/javase/7/docs/api/java/io/PushbackInputStream.html
> > Katharsis.io: http://katharsis.io
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264614#comment-15264614
]
Andrei Ivanov edited comment on CXF-6833 at 4/29/16 7:42 PM:
-
Cool :)
The ugly surprise I had earlier with the Retrofit client was to discover that
the annotations they use are not the jax-rs ones, but their own with the same
name, so my attempt to reuse the service interfaces failed.
Would be nice to get a JAX-RS client usable on Android with reactive support.
was (Author: shadow):
Cool :)
The ugly surprise I had earlier with the Retrofit client was to discover that
the annotations they use are not the jax-rs ones, but their own with the same
name, so my attempt to reuse the service interfaces failed.
Would be nice to get a JAX-RS client usable on Android with reactive support.
What about {{CompletableFuture}}?
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-RS
>Reporter: james strachan
> Fix For: 3.2.0
>
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264614#comment-15264614
]
Andrei Ivanov commented on CXF-6833:
Cool :)
The ugly surprise I had earlier with the Retrofit client was to discover that
the annotations they use are not the jax-rs ones, but their own with the same
name, so my attempt to reuse the service interfaces failed.
Would be nice to get a JAX-RS client usable on Android with reactive support.
What about {{CompletableFuture}}?
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-RS
>Reporter: james strachan
> Fix For: 3.2.0
>
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263891#comment-15263891
]
Andrei Ivanov commented on CXF-6833:
On other standard web projects I used to create a separate module with the REST
API (service interfaces and model classes) which would be shared by the server
and client modules.
Now I'm actually trying to use the RxJava / Retrofit combination on Android and
tried to use the same approach, but now it seems I have to use either the
Retrofit {{Call}}, which I don't really want since it's very specific to it, or
use call adapters as the standard JDK {{CompletableFuture}} or RxJava's
{{Observable}}.
As I would like to try to use RxJava for other things
(http://blog.danlew.net/2014/10/08/grokking-rxjava-part-4/), {{Observable}}
seems to be a nice choice.
Now I have the problem with the server side.
Is there a quick way to make CXF work with this, even in a synchronous way?
Maybe just handle result conversion somehow?
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-RS
>Reporter: james strachan
> Fix For: 3.2.0
>
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6746) CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
[
https://issues.apache.org/jira/browse/CXF-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15098145#comment-15098145
]
Andrei Ivanov commented on CXF-6746:
I don't know if this matters, but Spring will not be compatible with Jackson
2.7 until 4.3 in March.
https://jira.spring.io/browse/SPR-13853
> CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
> -
>
> Key: CXF-6746
> URL: https://issues.apache.org/jira/browse/CXF-6746
> Project: CXF
> Issue Type: Bug
> Components: Integration, JAX-RS
>Affects Versions: 3.1.4
> Environment: java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> 3.1.4
>
> com.fasterxml.jackson.jaxrs
> jackson-jaxrs-json-provider
> 2.6.4
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxws
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-transports-http
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-transports-http-jetty
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-rs-extension-providers
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-rs-client
> ${version.cxf}
>
>Reporter: Artiom
>Assignee: Sergey Beryozkin
>
> I observe some poblem during using JacksonJsonProvider.
> Firstly we have CXF v. 2.7.15 and using default Jettison provider.
> From some reasons (Jettison convert POJO String field to "json-number" if
> it's possible,
> http://stackoverflow.com/questions/22379082/jettison-string-returned-as-integer-when-marshalling)
> we decide change provider on JacksonJsonProvider.
> I change Jettison on JacksonJsonProvider v. 2.6.4 and observe some problem,
> application frozen after some time if we active use new provider.
> Because CXF v. 2.7.15 is too older, we decide change CXF version on latest
> 3.1.4
> After change version of CXF I observe that CXF use default Jettison proveder
> insted of JacksonJsonProvider despite the fact that in I configurate CXF for
> using JacksonJsonProvider. If I only change version of JacksonJsonProvider on
> 2.0.0 all works fine.
> Result:
> *CXF v.2.7.15 with Jackson v.2.6.4 work, but have some bug (don't descride
> them because v.2.7.15 is too old).*
> *CXF v.3.1.4 with Jackson v.2.6.4 doesn't work, CXF use default Jettison.*
> *CXF v.3.1.4 with Jackson v.2.0.0 work fine.*
> If you need some additional information please write here, thank you.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
