jboss-jira May 2020

jboss-jira@lists.jboss.org

1 participants
1533 discussions

[JBoss JIRA] (WFLY-13422) Make org.jboss.as.remoting optional from naming extension module; others too if possible

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13422?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13422: ------------------------------------ Summary: Make org.jboss.as.remoting optional from naming extension module; others too if possible (was: Make org.jboss.as.remoting optional; others too if possible) > Make org.jboss.as.remoting optional from naming extension module; others too if possible > ---------------------------------------------------------------------------------------- > > Key: WFLY-13422 > URL: https://issues.redhat.com/browse/WFLY-13422 > Project: WildFly > Issue Type: Enhancement > Components: Naming > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > > The org.jboss.as.naming module's dependency on org.jboss.as.remoting is only needed if the "service=remote-naming" child resource is used. So it should be made optional with RemoteNamingResourceDefinition registering an additional package. > This is part of an overall effort to eliminate non-optional dependencies on the org.jboss.as.remoting module. Both because depending on extension modules has a code smell but specifically because org.jboss.as.remoting module brings in fairly large dependency tree. > I believe there may be other module dependencies that could be made optional as part of this same work, e.g. org.jboss.remoting and org.wildfly.http-client.naming. Maybe others. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13422) Make org.jboss.as.remoting optional; others too if possible

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13422: --------------------------------------- Summary: Make org.jboss.as.remoting optional; others too if possible Key: WFLY-13422 URL: https://issues.redhat.com/browse/WFLY-13422 Project: WildFly Issue Type: Enhancement Components: Naming Reporter: Brian Stansberry Assignee: Yeray Borges Santana The org.jboss.as.naming module's dependency on org.jboss.as.remoting is only needed if the "service=remote-naming" child resource is used. So it should be made optional with RemoteNamingResourceDefinition registering an additional package. This is part of an overall effort to eliminate non-optional dependencies on the org.jboss.as.remoting module. Both because depending on extension modules has a code smell but specifically because org.jboss.as.remoting module brings in fairly large dependency tree. I believe there may be other module dependencies that could be made optional as part of this same work, e.g. org.jboss.remoting and org.wildfly.http-client.naming. Maybe others. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4955) Create a wildfly-network OutboundConnection interface from AbstractOutboundConnectionService; expose via capabilities

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4955: ---------------------------------------- Summary: Create a wildfly-network OutboundConnection interface from AbstractOutboundConnectionService; expose via capabilities Key: WFCORE-4955 URL: https://issues.redhat.com/browse/WFCORE-4955 Project: WildFly Core Issue Type: Enhancement Components: Management, Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry This is part of an overall effort to eliminate non-optional dependencies on the org.jboss.as.remoting module. Both because depending on extension modules has a code smell but specifically because org.jboss.as.remoting module brings in fairly large dependency tree. In the EJB subsystem there's deployment descriptor parsing that isn't limited to any particular subset of the EJB3 resource tree and that requires AbstractOutboundConnectionService, and hence the org.jboss.as.remoting module. Better if that code uses an interface from wildfly-network so there is no hard dependency on org.jboss.as.remoting from the root ejb subsystem resource. If the deployment actually specified an outbound connection, then the connection resource would have to be configured for deployment to succeed, but that's already the case. AbstractOutboundConnectionService doesn't require any dependencies not already needed by wildfly-network so creating the interface doesn't expand the footprint of its module. Exposing the AbstractOutboundConnectionService impls via a capability is general best practice -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

← Newer
1
...
151
152
153
154
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020