March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-8584: ------------------------------------- *Unrecognized properties* * WF11 ** 400: Unrecognized field "b" (class com.resteasy.test.CustomObject), not marked as ignorable * WF Master Jackson: ** ./standalone.sh -Dresteasy.preferJacksonOverJsonB=true ** 400: Unrecognized field "b" (class com.resteasy.test.CustomObject), not marked as ignorable * WF Master JSON-B ** 200 * Payara with Jersey (reference jax-rs implementation) ** 200 JSON-B behaviour is the same on Payara and WF. And we probably shouldn't change default Jackson behaviour because of backward compatibility. *Property naming (ABCD, getABCD, setABCD)* * WF11 ** {"abcd":"ABCD"} * WF Master Jackson ** {"abcd":"ABCD"} * WF Master JSON-B ** {"ABCD":"ABCD"} * Payara with Jersey (reference jax-rs implementation) ** {"ABCD":"ABCD"} JSON-B behaviour is the same on Payara and WF. And we probably shouldn't change default Jackson behaviour because of backward compatibility. *Pool issue* * This looks like a bug, but github application doesn't work any more, because fixer API is changed. * Anyway, I believe I'm able to reproduce this issue on WF11 * I'm not able to reproduce this issue on WF master {code:java} @POST @Path("test") public String test(String data) { return "response" + data; } private static Client client; static { client = ClientBuilder.newClient(); } private static WebTarget target = client.target("http://127.0.0.1:8080/jaxrs-wf/hello/test"); @GET @Path("client") public String client() throws ExecutionException, InterruptedException { final int AVAILABLE_THREADS = 100; final int ITERATION_OF_EACH_THREAD = 100; ForkJoinPool forkJoinPool = new ForkJoinPool(AVAILABLE_THREADS); forkJoinPool.submit(() -> //parallel task here, for example IntStream.range(1, AVAILABLE_THREADS).parallel().forEach(i -> { for (int j = 0; j < ITERATION_OF_EACH_THREAD; j++) { logger.info("Thread " + i + " start request " + j); String data = i + " " + j; String message = target.request().buildPost(Entity.text(data)).invoke(String.class); if (!message.equals("response" + data)) { throw new RuntimeException(data); } logger.info("Thread " + i + "'s request " + j + " is done"); } } ) ).get(); return "ok"; } {code} ---- [~ron_sigal]: WDYT? What about to close this jira? [~pavelpscheidl]: Any thoughts? > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4374) security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does

by Bartosz Spyrko-Śmietanko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4374?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko edited comment on WFCORE-4374 at 3/15/19 9:37 AM: --------------------------------------------------------------------------- 'javax.management.MBeanServerPermission' fails to load in LoadedPermissionFactory because the class is not available to the security-manager module. Adding java.se module to the security-manager module would help with a lot of standard permissions was (Author: spyrkob): 'javax.management.MBeanServerPermission' fails to load in LoadedPermissionFactory because the class is not available to the security-manager module. Adding java.se module to the security-manager module will solve most of the cases, but there would still be some permissions not included. Maybe we should add a 'module' parameter on the permission element that would be used to resolve the Permission? [~jmesnil] WDYT? > security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does > ------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4374 > URL: https://issues.jboss.org/browse/WFCORE-4374 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Major > > When configuring a jdbc driver deployment jar with permissions.xml it I was able to resolve all of the needed permissions. But then when I remove the permissions.xml from the deployment and define the same permissions in the security-manager, it fails saying it requires the javax.management.MBeanServerPermission createMBeanServer even though it is defined in the subsystem. > {code} > 23:41:13,007 ERROR [stderr] (ServerService Thread Pool -- 81) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanServerPermission" "createMBeanServer")" in code source "(vfs:/Users/bmaxwell/Downloads/02291781/jboss-eap-7.3/standalone/deployments/createMBeanServer.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.createMBeanServer.jar" from Service Module Loader") > {code} > {code} > <minimum-set> > <permission class="javax.management.MBeanServerPermission" name="createMBeanServer"/> > </minimum-set> > {code} > If you put a permissions.xml in the deployment's META-INF with this below then it works fine. The other permissions I used for the jdbc driver seemed to work fine, it is just this one that seems inconsistent for some reason. > {code} > <?xml version="1.0" encoding="UTF-8"?> > <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/permissions_7.xsd" > version="7"> > <permission> > <class-name>javax.management.MBeanServerPermission</class-name> > <name>createMBeanServer</name> > </permission> > </permissions> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11852) Distributed web session expiration scheduler payload is too large

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11852: ----------------------------------- Summary: Distributed web session expiration scheduler payload is too large Key: WFLY-11852 URL: https://issues.jboss.org/browse/WFLY-11852 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro The CommandDispatcher isn't pulling in the requisite externalizers for Duration and Instant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4375) Provide ability to easily apply certain JBoss module libraries to all deployments running in a server

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFCORE-4375?page=com.atlassian.jira.plugi... ] Yeray Borges updated WFCORE-4375: --------------------------------- Description: Provide ability to configure a global directory or directories which puts the contents in the classpath for all deployments without needing to list the contents of the directory (ie not a module.xml) > Provide ability to easily apply certain JBoss module libraries to all deployments running in a server > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-4375 > URL: https://issues.jboss.org/browse/WFCORE-4375 > Project: WildFly Core > Issue Type: Feature Request > Components: Modules > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > > Provide ability to configure a global directory or directories which puts the contents in the classpath for all deployments without needing to list the contents of the directory (ie not a module.xml) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4375) Provide ability to easily apply certain JBoss module libraries to all deployments running in a server

by Yeray Borges (Jira)

Yeray Borges created WFCORE-4375: ------------------------------------ Summary: Provide ability to easily apply certain JBoss module libraries to all deployments running in a server Key: WFCORE-4375 URL: https://issues.jboss.org/browse/WFCORE-4375 Project: WildFly Core Issue Type: Feature Request Components: Modules Reporter: Yeray Borges Assignee: Yeray Borges -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1160) Adding config files to AS7 is inconvenient.

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-1160?page=com.atlassian.jira.plugin.... ] Yeray Borges reassigned WFLY-1160: ---------------------------------- Assignee: Yeray Borges > Adding config files to AS7 is inconvenient. > ------------------------------------------- > > Key: WFLY-1160 > URL: https://issues.jboss.org/browse/WFLY-1160 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: All > Reporter: Paul Hinds > Assignee: Yeray Borges > Priority: Minor > Labels: regression > > This page https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath details how to put a directory on the AS7 classpath which is inconvenient and could easily be done by default. > If AS7 out of the box came with /standalone/classes or /standalone/conf (conf would introduce a bit of backwards compatability) and perhaps /standalone/lib/*.jar added to the classpath it would be as good as previous JBoss versions. > This could be implemented as a module as in the above documents and automatically added to classpaths if the dirs exists in the same way other modules are automatically added to the CP if certain criteria are met. > Ideally is should be possible to make these symlinks on win7 and nix. Since it is natural to put config in /etc per Linux file system standards. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-416) Make JBoss Medata available in Maven Central

by David Hladky (Jira)

[ https://issues.jboss.org/browse/JBMETA-416?page=com.atlassian.jira.plugin... ] David Hladky commented on JBMETA-416: ------------------------------------- I do not have permissions t move this issue to NEXUS project. But it definitely belongs there. I think it would be possible to synchronize it to Maven Central, but we need to ask the owner. > Make JBoss Medata available in Maven Central > -------------------------------------------- > > Key: JBMETA-416 > URL: https://issues.jboss.org/browse/JBMETA-416 > Project: JBoss Metadata > Issue Type: Task > Reporter: Sanne Grinovero > Priority: Major > > Hello, > we're using {{jboss-metadata-web}} in Quarkus, and we'd really appreciate if our users could build applications without having to setup their Maven configuration to find dependencies in JBoss Nexus. > Could someone please take care that releases get synched to Maven Central ? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-642) Include the Registry Puller on the Pipeline

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-642?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-642: ------------------------------------------ Description: https://github.com/knrc/registry-puller needs to be included on Pipeline > Include the Registry Puller on the Pipeline > ------------------------------------------- > > Key: SWSQE-642 > URL: https://issues.jboss.org/browse/SWSQE-642 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Labels: infrastructure > > https://github.com/knrc/registry-puller needs to be included on Pipeline -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-642) Include the Registry Puller on the Pipeline

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-642: --------------------------------------------- Summary: Include the Registry Puller on the Pipeline Key: SWSQE-642 URL: https://issues.jboss.org/browse/SWSQE-642 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-642) Include the Registry Puller on the Pipeline

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-642?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-642: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo > Include the Registry Puller on the Pipeline > ------------------------------------------- > > Key: SWSQE-642 > URL: https://issues.jboss.org/browse/SWSQE-642 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Labels: infrastructure > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019