December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12913?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-12913: ------------------------------------ Description: The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents: {code} <module name="com.github.relaxng" export="true" /> <module name="com.sun.istack" export="true" /> <module name="com.sun.xml.txw2" export="true" /> <module name="com.sun.xsom" export="true" /> {code} Task is to: 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules. 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules. 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules. was: The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents: {code} <module name="com.github.relaxng" export="true" /> <module name="com.sun.istack" export="true" /> <module name="com.sun.xml.txw2" export="true" /> <module name="com.sun.xsom" export="true" /> {code} Task is to: 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules. 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules. 3) Assuming no positive responses, make the artifacts from the above four direct artifacts of the com.sun.xml.bind module, > Rationalize com.sum.xml.bind module dependencies > ------------------------------------------------ > > Key: WFLY-12913 > URL: https://issues.redhat.com/browse/WFLY-12913 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate, REST, Web Services > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > > The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents: > {code} > <module name="com.github.relaxng" export="true" /> > <module name="com.sun.istack" export="true" /> > <module name="com.sun.xml.txw2" export="true" /> > <module name="com.sun.xsom" export="true" /> > {code} > Task is to: > 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules. > 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules. > 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12913: --------------------------------------- Summary: Rationalize com.sum.xml.bind module dependencies Key: WFLY-12913 URL: https://issues.redhat.com/browse/WFLY-12913 Project: WildFly Issue Type: Task Components: JPA / Hibernate, REST, Web Services Reporter: Brian Stansberry Assignee: Scott Marlow -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-218?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-218: ---------------------------------------- [~simkam] [~ochaloup] Should this be moved to another tracker, i.e. WFLY? It sounds like it is not about an unmerged feature. > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.redhat.com/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall edited comment on WFLY-9641 at 12/27/19 11:31 AM: --------------------------------------------------------------- This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. modcluster has been removed since we're using nginx load balancer in ip_hash mode. There are other timeout issues when nginx fails over to a different node despite the cluster view updating. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred and attempts to bind either the 172 or 10 ifc are failing to allow external access. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. was (Author: gregoryhall994): This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall edited comment on WFLY-9641 at 12/27/19 11:27 AM: --------------------------------------------------------------- This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. was (Author: gregoryhall994): I'm trying to cluster keycloak 6.0.1 based on Wildfly 16 in a docker container and having this issue. I've been setting external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall commented on WFLY-9641: ------------------------------------ I'm trying to cluster keycloak 6.0.1 based on Wildfly 16 in a docker container and having this issue. I've been setting external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12912) Upgrade RESTEasy to 3.10.0.Final

by Ronald Sigal (Jira)

Ronald Sigal created WFLY-12912: ----------------------------------- Summary: Upgrade RESTEasy to 3.10.0.Final Key: WFLY-12912 URL: https://issues.redhat.com/browse/WFLY-12912 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Ivo Studensky Assignee: Alessio Soldano Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12912) Upgrade RESTEasy to 3.10.0.Final

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-12912?page=com.atlassian.jira.plugi... ] Ronald Sigal closed WFLY-12912. ------------------------------- Resolution: Duplicate Issue > Upgrade RESTEasy to 3.10.0.Final > -------------------------------- > > Key: WFLY-12912 > URL: https://issues.redhat.com/browse/WFLY-12912 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 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: ------------------------------------- Additional information about https://github.com/resteasy/Resteasy/pull/2250 is given on the analysis document pull request (https://github.com/wildfly/wildfly-proposals/pull/262). > 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". -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2374?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2374: --------------------------- Fix Version/s: 4.1.9 (was: 5.1) > TCP/TCP_NIO2: add TLS > --------------------- > > Key: JGRP-2374 > URL: https://issues.redhat.com/browse/JGRP-2374 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.9 > > > Add TLS to the TCP and TCP_NIO2 transports. Look into wildfly-openssl [1] for the impl. > [1] https://github.com/wildfly-security/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2019