[JBoss JIRA] (JBEE-155) Javadoc for WebSocketContainer.connectToServer mentions ServerEndpoint instead of ClientEndpoint
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/JBEE-155?page=com.atlassian.jira.plugin.s... ]
Flavia Rainone reassigned JBEE-155:
-----------------------------------
Assignee: Flavia Rainone (was: Shelly McGowan)
> Javadoc for WebSocketContainer.connectToServer mentions ServerEndpoint instead of ClientEndpoint
> ------------------------------------------------------------------------------------------------
>
> Key: JBEE-155
> URL: https://issues.jboss.org/browse/JBEE-155
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-websocket-api
> Affects Versions: JavaEE 7 Spec APIs 1.0.0.Final
> Reporter: Ron Šmeral
> Assignee: Flavia Rainone
> Priority: Major
>
> In {{javax.websocket.WebSocketContainer}}, the javadoc for two connectToServer method signatures contains an incorrect statement:
> {{connectToServer(Object annotatedEndpointInstance, URI path)}}
> {{connectToServer(Class<?> annotatedEndpointClass, URI path)}}
> {quote}
> The supplied object must be a class decorated with the class level \{@link javax.websocket.server.*ServerEndpoint*\} annotation.
> {quote}
> which should point to {{javax.websocket.ClientEndpoint}} instead of the ServerEndpoint.
> Also, in case of {{connectToServer(Object annotatedEndpointInstance, URI path)}}, that sentence should read _...supplied object must be *an instance of* a class..._
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Ronald Sigal commented on WFLY-8584:
------------------------------------
As for the "the problem with Resteasy not creating HTTP pools", I'd like to know more. [~mkopecky], what kind of failure did you see when you ran your example in WF 11?
> Unite Jackson behavior with other application servers for JAX-RS client
> -----------------------------------------------------------------------
>
> Key: WFLY-8584
> URL: https://issues.jboss.org/browse/WFLY-8584
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Pavel Pscheidl
> Assignee: Weinan Li
> Priority: Optional
>
> Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.
> h3. Unrecognized properties
> UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties
> {code:java}
> public class SomeDTO{
> private String property1;
> //Getters and setters
> }
> {code}
> {code:json}
> {
> "property1": "This one will not cause any troubles",
> "property2": "This one causes UnrecognizedPropertyException istead of being ignored"
> }
> {code}
> To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.
> {code:java}
> @JsonIgnoreProperties(ignoreUnknown = true)
> public class SomeDTO {
> private String property1;
> //Getters and setters
> }
> {code}
> Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.
> h3. Property naming
> Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.
> This code will not work
> {code:java}
> public class Rates {
> private BigDecimal AUD;
> }
> {code}
> for this JSON:
> {code:json}
> {
> "AUD": 1.334523
> }
> {code}
> The resulting error is:
> {code:text}
> Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....
> {code}
> However, when @JsonProperty annotation is used on the field, things suddenly work:
> {code:java}
> public class Rates {
> @JsonProperty("AUD")
> private BigDecimal AUD;
> }
> {code}
> Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:
> {code:xml}
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-annotations</artifactId>
> <version>2.8.6</version>
> <scope>provided</scope>
> </dependency>
> {code}
> h3. Behavior of other application servers
> There is a sample JAX-RS client/sever application [on GitHub|https://github.com/Pscheidl/jax-rs-application-server-test]. When deployed without Jackson annotations, it works perfectly in:
> # Glassfish 4
> # Payara 171 /obviously, should be the same as Glassfish/
> # TomEE
> # Websphere Liberty
> Other AS were not tested.
> Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.
> h3. Proposal summary
> I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (SWSQE-708) Build kiali operator only when needed
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-708?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-708.
---------------------------------
Resolution: Done
https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/pr-jobs/job/ki... job contains following check:
if git diff --quiet ..origin/master operator
then
echo "No chagnes in operator dir"
export BUILD_KIALI_OPERATOR=false
else
echo "Detected chagnes in operator dir"
export BUILD_KIALI_OPERATOR=true
fi
Which checks if there are any changes in operator directory compared with master branch. When true, operator will be built from given PR and use it to deploy kiali, otherwise it will use the latest from quay.
> Build kiali operator only when needed
> -------------------------------------
>
> Key: SWSQE-708
> URL: https://issues.jboss.org/browse/SWSQE-708
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Minor
> Labels: infrastructure
>
> When building and installing kiali it's possible to use the latest kiali operator from quay or build current operator and use it for deploying the kiali. It only make sense to do this when there is some change in operator in given PR.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Ronald Sigal commented on WFLY-8584:
------------------------------------
Hi [~mkopecky],
I see that the JSON-B spec explicitly says
{code}
3.18 Must Ignore policy
When JSON Binding implementation during deserialization encounters key in key/value pair that it does not recognize, it should treat the rest
of the JSON document as if the element simply did not appear, and in particular, the implementation MUST NOT treat this as an error condition.
{code}
Since Jackson doesn't implement a spec, I would say that, in general, it would make sense to have Jackson's behavior conform to the JSON-B spec. But I don't think it makes sense to change existing behavior if it isn't a bug.
On the other hand, maybe it makes sense to change that behavior in RESTEasy 4.x. [~asoldano], WDYT?
-Ron
> Unite Jackson behavior with other application servers for JAX-RS client
> -----------------------------------------------------------------------
>
> Key: WFLY-8584
> URL: https://issues.jboss.org/browse/WFLY-8584
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Pavel Pscheidl
> Assignee: Weinan Li
> Priority: Optional
>
> Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.
> h3. Unrecognized properties
> UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties
> {code:java}
> public class SomeDTO{
> private String property1;
> //Getters and setters
> }
> {code}
> {code:json}
> {
> "property1": "This one will not cause any troubles",
> "property2": "This one causes UnrecognizedPropertyException istead of being ignored"
> }
> {code}
> To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.
> {code:java}
> @JsonIgnoreProperties(ignoreUnknown = true)
> public class SomeDTO {
> private String property1;
> //Getters and setters
> }
> {code}
> Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.
> h3. Property naming
> Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.
> This code will not work
> {code:java}
> public class Rates {
> private BigDecimal AUD;
> }
> {code}
> for this JSON:
> {code:json}
> {
> "AUD": 1.334523
> }
> {code}
> The resulting error is:
> {code:text}
> Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....
> {code}
> However, when @JsonProperty annotation is used on the field, things suddenly work:
> {code:java}
> public class Rates {
> @JsonProperty("AUD")
> private BigDecimal AUD;
> }
> {code}
> Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:
> {code:xml}
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-annotations</artifactId>
> <version>2.8.6</version>
> <scope>provided</scope>
> </dependency>
> {code}
> h3. Behavior of other application servers
> There is a sample JAX-RS client/sever application [on GitHub|https://github.com/Pscheidl/jax-rs-application-server-test]. When deployed without Jackson annotations, it works perfectly in:
> # Glassfish 4
> # Payara 171 /obviously, should be the same as Glassfish/
> # TomEE
> # Websphere Liberty
> Other AS were not tested.
> Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.
> h3. Proposal summary
> I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Ronald Sigal commented on WFLY-8584:
------------------------------------
Hi [~mkopecky],
I see that the JSON-B explicitly says
{code}
> Unite Jackson behavior with other application servers for JAX-RS client
> -----------------------------------------------------------------------
>
> Key: WFLY-8584
> URL: https://issues.jboss.org/browse/WFLY-8584
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Pavel Pscheidl
> Assignee: Weinan Li
> Priority: Optional
>
> Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.
> h3. Unrecognized properties
> UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties
> {code:java}
> public class SomeDTO{
> private String property1;
> //Getters and setters
> }
> {code}
> {code:json}
> {
> "property1": "This one will not cause any troubles",
> "property2": "This one causes UnrecognizedPropertyException istead of being ignored"
> }
> {code}
> To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.
> {code:java}
> @JsonIgnoreProperties(ignoreUnknown = true)
> public class SomeDTO {
> private String property1;
> //Getters and setters
> }
> {code}
> Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.
> h3. Property naming
> Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.
> This code will not work
> {code:java}
> public class Rates {
> private BigDecimal AUD;
> }
> {code}
> for this JSON:
> {code:json}
> {
> "AUD": 1.334523
> }
> {code}
> The resulting error is:
> {code:text}
> Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....
> {code}
> However, when @JsonProperty annotation is used on the field, things suddenly work:
> {code:java}
> public class Rates {
> @JsonProperty("AUD")
> private BigDecimal AUD;
> }
> {code}
> Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:
> {code:xml}
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-annotations</artifactId>
> <version>2.8.6</version>
> <scope>provided</scope>
> </dependency>
> {code}
> h3. Behavior of other application servers
> There is a sample JAX-RS client/sever application [on GitHub|https://github.com/Pscheidl/jax-rs-application-server-test]. When deployed without Jackson annotations, it works perfectly in:
> # Glassfish 4
> # Payara 171 /obviously, should be the same as Glassfish/
> # TomEE
> # Websphere Liberty
> Other AS were not tested.
> Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.
> h3. Proposal summary
> I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Ronald Sigal updated WFLY-8584:
-------------------------------
Comment: was deleted
(was: Hi [~mkopecky],
I see that the JSON-B explicitly says
{code})
> Unite Jackson behavior with other application servers for JAX-RS client
> -----------------------------------------------------------------------
>
> Key: WFLY-8584
> URL: https://issues.jboss.org/browse/WFLY-8584
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Pavel Pscheidl
> Assignee: Weinan Li
> Priority: Optional
>
> Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.
> h3. Unrecognized properties
> UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties
> {code:java}
> public class SomeDTO{
> private String property1;
> //Getters and setters
> }
> {code}
> {code:json}
> {
> "property1": "This one will not cause any troubles",
> "property2": "This one causes UnrecognizedPropertyException istead of being ignored"
> }
> {code}
> To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.
> {code:java}
> @JsonIgnoreProperties(ignoreUnknown = true)
> public class SomeDTO {
> private String property1;
> //Getters and setters
> }
> {code}
> Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.
> h3. Property naming
> Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.
> This code will not work
> {code:java}
> public class Rates {
> private BigDecimal AUD;
> }
> {code}
> for this JSON:
> {code:json}
> {
> "AUD": 1.334523
> }
> {code}
> The resulting error is:
> {code:text}
> Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....
> {code}
> However, when @JsonProperty annotation is used on the field, things suddenly work:
> {code:java}
> public class Rates {
> @JsonProperty("AUD")
> private BigDecimal AUD;
> }
> {code}
> Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:
> {code:xml}
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-annotations</artifactId>
> <version>2.8.6</version>
> <scope>provided</scope>
> </dependency>
> {code}
> h3. Behavior of other application servers
> There is a sample JAX-RS client/sever application [on GitHub|https://github.com/Pscheidl/jax-rs-application-server-test]. When deployed without Jackson annotations, it works perfectly in:
> # Glassfish 4
> # Payara 171 /obviously, should be the same as Glassfish/
> # TomEE
> # Websphere Liberty
> Other AS were not tested.
> Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.
> h3. Proposal summary
> I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months