August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13814: ----------------------------------------- Based on the last comment I've changed this to a Bug. > Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13814 > URL: https://issues.redhat.com/browse/WFLY-13814 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Priority: Major > > Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency. > To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13814: ------------------------------------ Issue Type: Bug (was: Enhancement) > Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13814 > URL: https://issues.redhat.com/browse/WFLY-13814 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Priority: Major > > Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency. > To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13814: --------------------------------------- Assignee: Emmanuel Hugonnet (was: Brian Stansberry) > Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13814 > URL: https://issues.redhat.com/browse/WFLY-13814 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Priority: Major > > Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency. > To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13814: ----------------------------------------- I misread; the messaging subsystem class is invoking the superclass. So there's a bit more code to copy over. The existing impl is somewhat buggy though. It invokes the superclass, which then updates the response with an 'accept header'. But then the override code does more analysis and may return 'false', i.e. indicate the upgrade should not happen. But the response already includes the 'accept header'. > Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13814 > URL: https://issues.redhat.com/browse/WFLY-13814 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency. > To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5108) SimpleHttpUpgradeHandshake should use undertow-core's FlexBase64.

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-5108: ---------------------------------------- Summary: SimpleHttpUpgradeHandshake should use undertow-core's FlexBase64. Key: WFCORE-5108 URL: https://issues.redhat.com/browse/WFCORE-5108 Project: WildFly Core Issue Type: Enhancement Components: Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry SimpleHttpUpgradeHandshake is an impl of an interface from undertow-core, but it includes a copy of the FlexBase64 class that's a public class in undertow-core. Why duplicate? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13814: --------------------------------------- Summary: Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting Key: WFLY-13814 URL: https://issues.redhat.com/browse/WFLY-13814 Project: WildFly Issue Type: Enhancement Components: JMS Reporter: Brian Stansberry Assignee: Brian Stansberry Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency. To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5107) Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" capability

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-5107?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-5107: ------------------------------------- Summary: Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" capability (was: Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector") > Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" capability > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-5107 > URL: https://issues.redhat.com/browse/WFCORE-5107 > Project: WildFly Core > Issue Type: Enhancement > Components: Remoting > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo. > RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated. > For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13813) Use a capability to get information about a remoting connector; drop EJB3 dep on org.jboss.as.remoting module

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13813: --------------------------------------- Summary: Use a capability to get information about a remoting connector; drop EJB3 dep on org.jboss.as.remoting module Key: WFLY-13813 URL: https://issues.redhat.com/browse/WFLY-13813 Project: WildFly Issue Type: Enhancement Components: EJB Reporter: Brian Stansberry Assignee: Brian Stansberry Once WFCORE-5107 is done, take advantage of it and remote the EJB3 subsystem module's dependency on org.jboss.as.remoting. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13812) RemoteNamingAdd should use a capability to access the remoting Endpoint

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13812: --------------------------------------- Summary: RemoteNamingAdd should use a capability to access the remoting Endpoint Key: WFLY-13812 URL: https://issues.redhat.com/browse/WFLY-13812 Project: WildFly Issue Type: Bug Components: Naming Reporter: Brian Stansberry Assignee: Brian Stansberry RemoteNamingAdd itself provides a capability, and the remoting Endpoint is exposed by a capability, but RemoteNamingAdd is not using the capability to get the endpoint. This results in an unnecessary dependency on the org.jboss.as.remoting module. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5107) Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector"

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-5107: ---------------------------------------- Summary: Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" Key: WFCORE-5107 URL: https://issues.redhat.com/browse/WFCORE-5107 Project: WildFly Core Issue Type: Enhancement Components: Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo. RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated. For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 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 August 2020