[JBoss JIRA] (WFLY-8586) Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
by Frank Langelage (JIRA)
Frank Langelage created WFLY-8586:
-------------------------------------
Summary: Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
Key: WFLY-8586
URL: https://issues.jboss.org/browse/WFLY-8586
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 11.0.0.Beta1
Reporter: Frank Langelage
Assignee: Alessio Soldano
When deploying my application (ear with a couple of jar and war files) on Wildfly 11.0.0.Beta1-SNAPSHOT I get warnings like this one for all the war files:
{noformat}
WARN [org.jboss.as.jaxrs#deploy] WFLYRS0015: No Servlet declaration found for JAX-RS application. In ws-common.war either provide a class that extends javax.ws.rs.core.Application or declare a servlet class in web.xml.
{noformat}
When deploying the same ear file on a Wildfly 10.1. this warning message does not appear.
Those war files raising the warnings do not contain RESTful Webservices, only SOAP based Webservices, and therefore do not need either servlet or class.
Only 2 sub modules contain RESTful Webservices and have a class extending javax.ws.rs.core.Application.
Following jaikiran's analysis, the existence of at least one JAX-RS subdeployment triggers the warning message for all other web modules in the war.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8584:
--------------------------------------
Component/s: REST
Assignee: Alessio Soldano (was: Jason Greene)
> 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: Alessio Soldano
> 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.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2656:
------------------------------------------
Do you see this when it passes?
2017-04-14 20:02:40,251 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /home/ehsavoie/dev/wildfly/core/testsuite/standalone/target/dummy threw Exception: java.lang.RuntimeException: WFLYDS0036: Deployment model operation failed. WFLYCTL0271: Operation cancelled
I don't have any particular theory as to why that's relevant, other than it involves a separate management client thread interacting with the system in the middle of everything.
If you stick a trace in CapabilityRegistry.publish and .rollback that may show something further.
> DeploymentTestCase.testFilesystemScannerRegistration fails intermittently
> -------------------------------------------------------------------------
>
> Key: WFCORE-2656
> URL: https://issues.jboss.org/browse/WFCORE-2656
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references.
> The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8585) /subsystem=jgroups/channel=foo/fork=bar:remove operation leaks resources
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8585?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10366 to WFLY-8585:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8585 (was: JBEAP-10366)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> /subsystem=jgroups/channel=foo/fork=bar:remove operation leaks resources
> ------------------------------------------------------------------------
>
> Key: WFLY-8585
> URL: https://issues.jboss.org/browse/WFLY-8585
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Removal of a fork channel leaves a residual fork stack registered with the fork protocol of the parent channel. Fork channel removal should remove any resources associated with any custom fork stack on the parent channel.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2505) Key store exported from legacy security domain does not work Elytron filtering-key-store
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2505?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2505:
------------------------------------
Assignee: Yeray Borges
> Key store exported from legacy security domain does not work Elytron filtering-key-store
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-2505
> URL: https://issues.jboss.org/browse/WFCORE-2505
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta6
> Reporter: Ondrej Kotek
> Assignee: Yeray Borges
> Priority: Critical
>
> It is not possible to use a key store exported from legacy security domain (i.e. {{elytron-key-store}}) in Elytron {{filtering-key-store}}. It results in:
> {noformat}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService
> Caused by: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"]
> },
> "rolled-back" => true
> }
> {noformat}
> The exported key store is announced as {{org.wildfly.security.key-store}} capability. Hence it is expected to work wherever the capability is requested.
> The same applies to {{elytron-trust-store}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Balavignesh sethupathi (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Balavignesh sethupathi commented on WFLY-4696:
----------------------------------------------
Hi [~swd847],
We have this same issue occurring in one of our production servers. We have not be able to reproduce this in our lab setup until now.
The direct buffer memory is filled up to 12gb(-Xmx) before we start to see the exceptions in the logs.
Any help on reproducing this issue to check if the https://github.com/xnio/xnio/commit/b30ac9dbeeab484f1b8a366944bba4c17357b816 fix works is appreciated.
Thanks
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR1
>
> Attachments: wfly9_0_0_final.mp4, wlfy.mp4
>
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> This is the trace for version 8.2 of WildFly:
> 17:17:16,957 ERROR [io.undertow.request] (default task-49) Undertow request failed HttpServerExchange{ GET /modulab/servlet/ShowPDFReportServlet}: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.put(ByteBuffer.java:859) [rt.jar:1.8.0_20]
> at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:166)
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:564)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
> at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:175)
> at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:194)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1829)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:565)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:581)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> 10:57:12,389 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:146) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Pavel Pscheidl (JIRA)
Pavel Pscheidl created WFLY-8584:
------------------------------------
Summary: 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
Reporter: Pavel Pscheidl
Assignee: Jason Greene
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.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2674) An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2674?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2674:
------------------------------------------
Mystery solve re: my last comment. The test wasn't failing because CI didn't test that PR. As soon as it did it failed.
> An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2674
> URL: https://issues.jboss.org/browse/WFCORE-2674
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Right now ValidateModelStepHandler checks whether all attributes a defined attribute lists in 'requires' are themselves defined. It ignore the presence of alternatives settings. However in discussion with [~jfdenise] we've concluded that allowing undefined do to any 'alternatives' isn't right either. Rather, for a 'requires' to be superceded by an 'alternatives', only alternatives that are themselves part of the same set of 'requires' are relevant.
> Imagine three scenarios:
> I.
> 1) A requires B, C
> 2) B and C are alternatives to each other
> User configures A and B is ok. Or, user configures A and C is ok. Configuring A, B, C is not ok.
> II.
> 1) A requires B, C
> 2) B and C are alternatives to each other
> 3) B and D are also alternatives
> User configures A and D and therefore must configure C, but not B. Configuring C satisfies the "requires" B.
> III.
> 1) A requires B, C
> 2) B and C are NOT alternatives to each other
> 3) B and D are alternatives
> User configures A therefore cannot configure D, must configure B and C. Configuring D does not satisfy the "requires" B.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years