May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12779) Incorporate MicroProfile Config in RESTEasy

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-12779?page=com.atlassian.jira.plugi... ] James Perkins commented on WFLY-12779: -------------------------------------- I went ahead and resolved it Ron. It looks like the EAP7 JIRA needed to be resolved and proposal needed to be merged anyway. > Incorporate MicroProfile Config in RESTEasy > ------------------------------------------- > > Key: WFLY-12779 > URL: https://issues.redhat.com/browse/WFLY-12779 > Project: WildFly > Issue Type: Feature Request > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > Fix For: 20.0.0.Beta1 > > > Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources: > * servlet init-params (ordinal 60) > * filter init-params (ordinal 50) > * servlet context-params (ordinal 40) > In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x. > -In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".- \[Ignore that.\] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12779) Incorporate MicroProfile Config in RESTEasy

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-12779?page=com.atlassian.jira.plugi... ] James Perkins resolved WFLY-12779. ---------------------------------- Fix Version/s: 20.0.0.Beta1 Resolution: Done > Incorporate MicroProfile Config in RESTEasy > ------------------------------------------- > > Key: WFLY-12779 > URL: https://issues.redhat.com/browse/WFLY-12779 > Project: WildFly > Issue Type: Feature Request > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > Fix For: 20.0.0.Beta1 > > > Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources: > * servlet init-params (ordinal 60) > * filter init-params (ordinal 50) > * servlet context-params (ordinal 40) > In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x. > -In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".- \[Ignore that.\] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13445) Upgrade RESTEasy to 3.12.0.Final

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-13445?page=com.atlassian.jira.plugi... ] Ronald Sigal commented on WFLY-13445: ------------------------------------- Hi [~ivassile], Here's the Release Notes for RESTEasy 3.12.0.Final: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12310560&vers... There's one Feature Request, https://issues.redhat.com/browse/RESTEASY-2406, in 3.12.0.Final. I'm not really sure what the rules are about backporting a feature, but I'm guessing it's ... problematic. As for FasterXML jackson, I was asked to include the upgrade with the RESTEasy upgrade because 1) FaxterXML jackson was upgraded in RESTEasy, and 2) RESTEasy is the main consumer of jackson in WildFly. As for WFLY-12779, it's complete by way of the upgrade of RESTEasy to 3.12.0.Final. I'm not sure who is supposed to resolve the issue. Anyway, I ran the RESTEasy 3.11.2.Final testsuite with jackson FasterXml set to 2.10.4, and it didn't make any difference. -Ron > Upgrade RESTEasy to 3.12.0.Final > -------------------------------- > > Key: WFLY-13445 > URL: https://issues.redhat.com/browse/WFLY-13445 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > > Upgrade from 3.11.2.Final to 3.12.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13499) WildFly 20 Release Graphic

by James Cobb (Jira)

[ https://issues.redhat.com/browse/WFLY-13499?page=com.atlassian.jira.plugi... ] James Cobb commented on WFLY-13499: ----------------------------------- Added mockups to the design JIRA. > WildFly 20 Release Graphic > -------------------------- > > Key: WFLY-13499 > URL: https://issues.redhat.com/browse/WFLY-13499 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Brian Stansberry > Assignee: James Perkins > Priority: Blocker > Fix For: 20.0.0.Final > > > Get a graphic for wildfly.org for the WF 20 release. > This won't be needed if we will have cut over to the new site by the release date, but I think there's a good chance that will not be done. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13538) Add Java 9+ version of ConcurrentDirectDeque

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13538?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13538: -------------------------------- Description: The clustering code uses ConcurrentDirectDeque for its local scheduler implementation. While a portable implementation exists, a faster implementation that relies on sun.misc.Unsafe will be used when running with a compatible JVM. Now that jboss-parent includes profiles for multi-release jars, we can add a fast implementation (ported from Undertow) that uses VarHandle that will work on all Java9+ JVMs. was: The clustering code uses ConcurrentDirectDeque for its local scheduler implementation. While a portable implementation exists, there is also a faster version that relies on sun.misc.Unsafe. However, this only works in Java 8. Now that jboss-parent includes profiles for multi-release jars, we can add a variant (found in Undertow) that uses VarHandle to use on Java9+. > Add Java 9+ version of ConcurrentDirectDeque > -------------------------------------------- > > Key: WFLY-13538 > URL: https://issues.redhat.com/browse/WFLY-13538 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The clustering code uses ConcurrentDirectDeque for its local scheduler implementation. While a portable implementation exists, a faster implementation that relies on sun.misc.Unsafe will be used when running with a compatible JVM. > Now that jboss-parent includes profiles for multi-release jars, we can add a fast implementation (ported from Undertow) that uses VarHandle that will work on all Java9+ JVMs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13433: -------------------------------------------- [~dlofthouse] good point, thanks. > Improve capability support in EJB3 subsystem > -------------------------------------------- > > Key: WFLY-13433 > URL: https://issues.redhat.com/browse/WFLY-13433 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 20.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > > Survey all external subsystem dependencies and introduce capability based dependencies where required. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12779) Incorporate MicroProfile Config in RESTEasy

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-12779?page=com.atlassian.jira.plugi... ] Ronald Sigal commented on WFLY-12779: ------------------------------------- Who should resolve this issue? Me? > Incorporate MicroProfile Config in RESTEasy > ------------------------------------------- > > Key: WFLY-12779 > URL: https://issues.redhat.com/browse/WFLY-12779 > Project: WildFly > Issue Type: Feature Request > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > > Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources: > * servlet init-params (ordinal 60) > * filter init-params (ordinal 50) > * servlet context-params (ordinal 40) > In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x. > -In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".- \[Ignore that.\] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5364) Test scenario reports data type change during creation

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5364?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5364: ------------------------------- Story Points: 1 > Test scenario reports data type change during creation > ------------------------------------------------------ > > Key: DROOLS-5364 > URL: https://issues.redhat.com/browse/DROOLS-5364 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.38.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.39.0.Final > > Attachments: Screenshot from 2020-05-25 08-04-44.png, sample_abcd.zip > > > There is warning about data type change even when a test scenario is just created. The spotted behavior would be expected if user is reopening a a scenario but not creating a new one. > h2. Acceptance test > https://github.com/jboss-integration/bxms-qe-tests/pull/3283 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5364) Test scenario reports data type change during creation

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5364?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5364: ------------------------------- Fix Version/s: 7.39.0.Final > Test scenario reports data type change during creation > ------------------------------------------------------ > > Key: DROOLS-5364 > URL: https://issues.redhat.com/browse/DROOLS-5364 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.38.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.39.0.Final > > Attachments: Screenshot from 2020-05-25 08-04-44.png, sample_abcd.zip > > > There is warning about data type change even when a test scenario is just created. The spotted behavior would be expected if user is reopening a a scenario but not creating a new one. > h2. Acceptance test > https://github.com/jboss-integration/bxms-qe-tests/pull/3283 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13132: ----------------------------------- [~rachmato] The ejb-client part has been merged. Does this issue still have WildFly part of changes to be merged to WF? I just set the status back to Dev in Progress in case there is. > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Cheng Fang > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020