HTTP Upgrade for AS8 Management

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Darran Lofthouse


On 28/03/13 15:38, David M. Lloyd wrote:

> On 03/28/2013 09:46 AM, Rémy Maucherat wrote:
>> On 03/28/2013 03:32 PM, Jason Greene wrote:
>>> Hmm not sure I follow. We are talking about the implementation of our ejb client library (or any other existing remoting client). How it communicates to the server (via upgrade, web sockets, socket, etc) is just an implementation detail of the client/server implementation. The user isn't exposed to those APIs to do it.
>> Yes, I know it is about the remoting component (and it's the same for
>> websockets as well - the user uses the websocket JSR, not the API used
>> for the implementation). But you can still choose between proprietary or
>> Servlet 3.1 for the implementation since they are supposed to be able to
>> do the same thing.
>
> One of Undertow's specific capabilities is to upgrade a connection
> directly into a raw XNIO connection with very low (basically no)
> overhead, which Remoting can consume directly.  Also, the Undertow
> implementation is simper and faster by quite a lot.  Finally, Servlet
> may not always be available.

In the case of domain management it isn't available.

>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Stuart Douglas
In reply to this post by Brian Stansberry
Ok, in that case I will name the protocol http-upgrade and https-upgrade.

I think we should probably also use this name in JMX, EJB client etc as
well for consistency.

Stuart

Brian Stansberry wrote:

> On 3/28/13 8:31 AM, David M. Lloyd wrote:
>> On 03/28/2013 06:27 AM, Stuart Douglas wrote:
>>>
>>> Darran Lofthouse wrote:
>>>> On 28/03/13 11:04, Stuart Douglas wrote:
>>>>> This is what we have been using to represent JBoss remoting URI's so
>>>>> far. I do agree that is is a bit ambiguous.
>>>> I am not sure if that has been a deliberate decision but apart from
>>>> naming it has not really been that visible so far.
>>>>
>>>> I think what happened was the Remoting test suite had tests that had
>>>> local and remote connection providers registered and then these names
>>>> have stuck as new communication libraries have followed the test suite.
>>>>
>>>> So those names work when using the remoting APIs directly but are not so
>>>> good once you are using an alternative API that is wrapping Remoting.
>>>>
>>>> I think whatever set of protocol names we choose they are going to need
>>>> to be ones we can live with long term. The suggestions for Remoting JMX
>>>> I think are fine, if we ever wanted pure http for JMX that could be a
>>>> new library with a completely different protocol in the Service URL.
>>>>
>>>> However another question for 'ModelControllerClient' are we also sure we
>>>> will never want to add support for pure HTTP invocations?
>>> That is also a question that will need to be answered for EJB. I know
>>> work is being done on a pure HTTP client, so we need to make sure that
>>> there is no ambiguity there.
>>>
>>> Also if we have HTTP upgrade, why would we need a pure HTTP client
>>> library? The only reason that I can think of is that if there are some
>>> firewalls that block HTTP upgrade, but I am not really sure if that is
>>> really a thing.
>> It would be useful for thin (e.g. JS in the browser) clients which
>> cannot do upgrade.
>>
>
> I haven't heard of any proposal to remove the existing REST-ish HTTP API
> though.
>
> I do think it makes sense to be less ambiguous about the protocol names
> for ModelControllerClient.Factory. Call them http-upgrade/https-upgrade
> and that removes the ambiguity and leaves http/https available for the
> future. It's just clearer anyway; otherwise people will incorrectly
> assume "http" results in the client using the REST-ish API.
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Darran Lofthouse
On 01/04/13 03:20, Stuart Douglas wrote:
> Ok, in that case I will name the protocol http-upgrade and https-upgrade.

Just thinking would http-remoting and https-remoting be better names?

After all we know we are upgrading from http / https but what are we
upgrading to?

Taking the JMX example if you have 'http-remoting-jmx' this is JMX over
Remoting, over HTTP.  If we decided to do JMX with a http upgrade but
something different to Remoting we could just switch out the 'remoting'
part from the name.

> I think we should probably also use this name in JMX, EJB client etc as
> well for consistency.

I agree - whatever we pick should be consistent across them all.

>
> Stuart
>
> Brian Stansberry wrote:
>> On 3/28/13 8:31 AM, David M. Lloyd wrote:
>>> On 03/28/2013 06:27 AM, Stuart Douglas wrote:
>>>>
>>>> Darran Lofthouse wrote:
>>>>> On 28/03/13 11:04, Stuart Douglas wrote:
>>>>>> This is what we have been using to represent JBoss remoting URI's so
>>>>>> far. I do agree that is is a bit ambiguous.
>>>>> I am not sure if that has been a deliberate decision but apart from
>>>>> naming it has not really been that visible so far.
>>>>>
>>>>> I think what happened was the Remoting test suite had tests that had
>>>>> local and remote connection providers registered and then these names
>>>>> have stuck as new communication libraries have followed the test suite.
>>>>>
>>>>> So those names work when using the remoting APIs directly but are not so
>>>>> good once you are using an alternative API that is wrapping Remoting.
>>>>>
>>>>> I think whatever set of protocol names we choose they are going to need
>>>>> to be ones we can live with long term. The suggestions for Remoting JMX
>>>>> I think are fine, if we ever wanted pure http for JMX that could be a
>>>>> new library with a completely different protocol in the Service URL.
>>>>>
>>>>> However another question for 'ModelControllerClient' are we also sure we
>>>>> will never want to add support for pure HTTP invocations?
>>>> That is also a question that will need to be answered for EJB. I know
>>>> work is being done on a pure HTTP client, so we need to make sure that
>>>> there is no ambiguity there.
>>>>
>>>> Also if we have HTTP upgrade, why would we need a pure HTTP client
>>>> library? The only reason that I can think of is that if there are some
>>>> firewalls that block HTTP upgrade, but I am not really sure if that is
>>>> really a thing.
>>> It would be useful for thin (e.g. JS in the browser) clients which
>>> cannot do upgrade.
>>>
>>
>> I haven't heard of any proposal to remove the existing REST-ish HTTP API
>> though.
>>
>> I do think it makes sense to be less ambiguous about the protocol names
>> for ModelControllerClient.Factory. Call them http-upgrade/https-upgrade
>> and that removes the ambiguity and leaves http/https available for the
>> future. It's just clearer anyway; otherwise people will incorrectly
>> assume "http" results in the client using the REST-ish API.
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Jason T. Greene

On Apr 2, 2013, at 4:42 AM, Darran Lofthouse <[hidden email]> wrote:

>
> Just thinking would http-remoting and https-remoting be better names

Sounds good to me.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Stuart Douglas
Ok, I will change this again, and this this will probably be ready for
review.

I have also added some additional headers to the handshake to make sure
both client and server are using the correct protocol, basically I took
the web socket handshake from the websocket v13 spec but with different
header names and a different magic number.

Stuart

Jason Greene wrote:
> On Apr 2, 2013, at 4:42 AM, Darran Lofthouse<[hidden email]>  wrote:
>
>> Just thinking would http-remoting and https-remoting be better names
>
> Sounds good to me.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Stuart Douglas
This is now mostly ready to go, however it will require some other
projects to release before I can submit a pull request.

There also appears to be a SSL bug in XNIO upstream which is causing a
test failure that will also need to be resolved before this can be merged.

Stuart

Stuart Douglas wrote:

> Ok, I will change this again, and this this will probably be ready for
> review.
>
> I have also added some additional headers to the handshake to make sure
> both client and server are using the correct protocol, basically I took
> the web socket handshake from the websocket v13 spec but with different
> header names and a different magic number.
>
> Stuart
>
> Jason Greene wrote:
>> On Apr 2, 2013, at 4:42 AM, Darran
>> Lofthouse<[hidden email]> wrote:
>>
>>> Just thinking would http-remoting and https-remoting be better names
>>
>> Sounds good to me.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Stuart Douglas
I have submitted a PR for this:

https://github.com/wildfly/wildfly/pull/4447

This does not attempt to address EJB and remote naming, I will get to
them in a separate PR once this one is merged.

Unfortunately there is no way to move to single port by default without
breaking JBoss tools (and all older clients) backwards compatibility,
although they will still work if you install the remote connector.



Stuart

Stuart Douglas wrote:

> This is now mostly ready to go, however it will require some other
> projects to release before I can submit a pull request.
>
> There also appears to be a SSL bug in XNIO upstream which is causing a
> test failure that will also need to be resolved before this can be merged.
>
> Stuart
>
> Stuart Douglas wrote:
>> Ok, I will change this again, and this this will probably be ready for
>> review.
>>
>> I have also added some additional headers to the handshake to make sure
>> both client and server are using the correct protocol, basically I took
>> the web socket handshake from the websocket v13 spec but with different
>> header names and a different magic number.
>>
>> Stuart
>>
>> Jason Greene wrote:
>>> On Apr 2, 2013, at 4:42 AM, Darran
>>> Lofthouse<[hidden email]> wrote:
>>>
>>>> Just thinking would http-remoting and https-remoting be better names
>>>
>>> Sounds good to me.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

David Lloyd-2
In reply to this post by Stuart Douglas
On 03/28/2013 05:15 AM, Stuart Douglas wrote:
> - ModelControllerClient.Factory.create() now allows you to specify a
> protocol, which can be either remote, http or https.
>
> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
> rather than the current service:jmx:remoting-jmx://

Unfortunately I missed-slash-bungled this way back when, but we need to
sort out our URI schemes.

When we have multi-layer protocol going on, the URI scheme we should use
is like this:

   outer+middle+inner://

where "outer" is the outermost protocol (e.g. "remote"), and "inner" is
the innermost (not counting layer 3 and lower *unless* that figures
directly in to the URI scheme; an example of this sub-case is
"stratum+tcp" vs "stratum+udp").

So we *should* have:

   remote://           Direct Remoting-protocol connection
   remote+http://      Remoting over HTTP upgrade
   remote+https://     Remoting over HTTPS upgrade

And (if these are even really needed; I think we dropped this
distinction though maybe I'm wrong):

   jmx+remote://       JMX over Remoting
   jmx+remote+http://  JMX over Remoting over HTTP
   jmx+remote+https:// JMX over Remoting over HTTPS

The most common "de facto" function of hyphenation in a URI scheme is to
be a separator for a two-word protocol, like "view-source" or "ms-help"
etc.  The most common "de facto" function of using "+" is as I've
described above, perhaps made most popular by Subversion's use.

You may be wondering: Why not apply this to every single protocol we
have?  And/or every single protocol in existence?  I think this goes
beyond practicality - the point is to be unambiguous and consistent, and
also align on the correct "remote" scheme name (we have a mix of
"remote" and "remoting" today which is kind of confusing).

Fixing this is not really a top priority obviously, but I would like to
eventually unify our configuration on these scheme names (still
supporting the old scheme names for compatibility of course).
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Darran Lofthouse
So just to be clear, you believe it should be 'remote' not 'remoting'?

Regards,
Darran Lofthouse.


On 02/06/14 17:42, David M. Lloyd wrote:

> On 03/28/2013 05:15 AM, Stuart Douglas wrote:
>> - ModelControllerClient.Factory.create() now allows you to specify a
>> protocol, which can be either remote, http or https.
>>
>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
>> rather than the current service:jmx:remoting-jmx://
>
> Unfortunately I missed-slash-bungled this way back when, but we need to
> sort out our URI schemes.
>
> When we have multi-layer protocol going on, the URI scheme we should use
> is like this:
>
>     outer+middle+inner://
>
> where "outer" is the outermost protocol (e.g. "remote"), and "inner" is
> the innermost (not counting layer 3 and lower *unless* that figures
> directly in to the URI scheme; an example of this sub-case is
> "stratum+tcp" vs "stratum+udp").
>
> So we *should* have:
>
>     remote://           Direct Remoting-protocol connection
>     remote+http://      Remoting over HTTP upgrade
>     remote+https://     Remoting over HTTPS upgrade
>
> And (if these are even really needed; I think we dropped this
> distinction though maybe I'm wrong):
>
>     jmx+remote://       JMX over Remoting
>     jmx+remote+http://  JMX over Remoting over HTTP
>     jmx+remote+https:// JMX over Remoting over HTTPS
>
> The most common "de facto" function of hyphenation in a URI scheme is to
> be a separator for a two-word protocol, like "view-source" or "ms-help"
> etc.  The most common "de facto" function of using "+" is as I've
> described above, perhaps made most popular by Subversion's use.
>
> You may be wondering: Why not apply this to every single protocol we
> have?  And/or every single protocol in existence?  I think this goes
> beyond practicality - the point is to be unambiguous and consistent, and
> also align on the correct "remote" scheme name (we have a mix of
> "remote" and "remoting" today which is kind of confusing).
>
> Fixing this is not really a top priority obviously, but I would like to
> eventually unify our configuration on these scheme names (still
> supporting the old scheme names for compatibility of course).
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

David Lloyd-2
Yes.

On 06/02/2014 11:46 AM, Darran Lofthouse wrote:

> So just to be clear, you believe it should be 'remote' not 'remoting'?
>
> Regards,
> Darran Lofthouse.
>
>
> On 02/06/14 17:42, David M. Lloyd wrote:
>> On 03/28/2013 05:15 AM, Stuart Douglas wrote:
>>> - ModelControllerClient.Factory.create() now allows you to specify a
>>> protocol, which can be either remote, http or https.
>>>
>>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
>>> rather than the current service:jmx:remoting-jmx://
>>
>> Unfortunately I missed-slash-bungled this way back when, but we need to
>> sort out our URI schemes.
>>
>> When we have multi-layer protocol going on, the URI scheme we should use
>> is like this:
>>
>>      outer+middle+inner://
>>
>> where "outer" is the outermost protocol (e.g. "remote"), and "inner" is
>> the innermost (not counting layer 3 and lower *unless* that figures
>> directly in to the URI scheme; an example of this sub-case is
>> "stratum+tcp" vs "stratum+udp").
>>
>> So we *should* have:
>>
>>      remote://           Direct Remoting-protocol connection
>>      remote+http://      Remoting over HTTP upgrade
>>      remote+https://     Remoting over HTTPS upgrade
>>
>> And (if these are even really needed; I think we dropped this
>> distinction though maybe I'm wrong):
>>
>>      jmx+remote://       JMX over Remoting
>>      jmx+remote+http://  JMX over Remoting over HTTP
>>      jmx+remote+https:// JMX over Remoting over HTTPS
>>
>> The most common "de facto" function of hyphenation in a URI scheme is to
>> be a separator for a two-word protocol, like "view-source" or "ms-help"
>> etc.  The most common "de facto" function of using "+" is as I've
>> described above, perhaps made most popular by Subversion's use.
>>
>> You may be wondering: Why not apply this to every single protocol we
>> have?  And/or every single protocol in existence?  I think this goes
>> beyond practicality - the point is to be unambiguous and consistent, and
>> also align on the correct "remote" scheme name (we have a mix of
>> "remote" and "remoting" today which is kind of confusing).
>>
>> Fixing this is not really a top priority obviously, but I would like to
>> eventually unify our configuration on these scheme names (still
>> supporting the old scheme names for compatibility of course).
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Upgrade for AS8 Management

Darran Lofthouse
Created the following for Remoting JMX: -

   https://issues.jboss.org/browse/REMJMX-85

Will drop the 'jmx' portion from the scheme.

Regards,
Darran Lofthouse.


On 02/06/14 19:18, David M. Lloyd wrote:

> Yes.
>
> On 06/02/2014 11:46 AM, Darran Lofthouse wrote:
>> So just to be clear, you believe it should be 'remote' not 'remoting'?
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 02/06/14 17:42, David M. Lloyd wrote:
>>> On 03/28/2013 05:15 AM, Stuart Douglas wrote:
>>>> - ModelControllerClient.Factory.create() now allows you to specify a
>>>> protocol, which can be either remote, http or https.
>>>>
>>>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
>>>> rather than the current service:jmx:remoting-jmx://
>>>
>>> Unfortunately I missed-slash-bungled this way back when, but we need to
>>> sort out our URI schemes.
>>>
>>> When we have multi-layer protocol going on, the URI scheme we should use
>>> is like this:
>>>
>>>       outer+middle+inner://
>>>
>>> where "outer" is the outermost protocol (e.g. "remote"), and "inner" is
>>> the innermost (not counting layer 3 and lower *unless* that figures
>>> directly in to the URI scheme; an example of this sub-case is
>>> "stratum+tcp" vs "stratum+udp").
>>>
>>> So we *should* have:
>>>
>>>       remote://           Direct Remoting-protocol connection
>>>       remote+http://      Remoting over HTTP upgrade
>>>       remote+https://     Remoting over HTTPS upgrade
>>>
>>> And (if these are even really needed; I think we dropped this
>>> distinction though maybe I'm wrong):
>>>
>>>       jmx+remote://       JMX over Remoting
>>>       jmx+remote+http://  JMX over Remoting over HTTP
>>>       jmx+remote+https:// JMX over Remoting over HTTPS
>>>
>>> The most common "de facto" function of hyphenation in a URI scheme is to
>>> be a separator for a two-word protocol, like "view-source" or "ms-help"
>>> etc.  The most common "de facto" function of using "+" is as I've
>>> described above, perhaps made most popular by Subversion's use.
>>>
>>> You may be wondering: Why not apply this to every single protocol we
>>> have?  And/or every single protocol in existence?  I think this goes
>>> beyond practicality - the point is to be unambiguous and consistent, and
>>> also align on the correct "remote" scheme name (we have a mix of
>>> "remote" and "remoting" today which is kind of confusing).
>>>
>>> Fixing this is not really a top priority obviously, but I would like to
>>> eventually unify our configuration on these scheme names (still
>>> supporting the old scheme names for compatibility of course).
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12