[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:
-------------------------------------
Description:
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" capability 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.
was:
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.
> 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" capability 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)
3 years, 8 months
[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:
------------------------------------
Description:
Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides its method. 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.)
was:
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.)
> 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 its method. 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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months
[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)
3 years, 8 months