HTTP Upgrade for AS8 Management

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

HTTP Upgrade for AS8 Management

Stuart Douglas
Hi everyone,

Now that we are using Undertow as the domain management HTTP server it
is now possible to use a HTTP upgrade for the native management and
remote-jmx protocols. This will allow us to run all management protocols
over port 9990, and allow us to remove 9999 from our default config. The
idea is significantly reduce the ports that are open in our default
config, ideally eventually we will just have a management and
application HTTP ports and that will be it (although some technologies
such as CORBA are not compatible with HTTP Upgrade).

With this in mind I have started working on a series of patches[1] to
implement this, that I am hoping will be ready to merge early next week.
(These patches are still a work in progress, but the core functionality
works).

For those of you who are not familiar with HTTP upgrade it is a
mechanism where a client makes a HTTP request to the client with the
Upgrade: header set, the server will then respond with a HTTP 101
response. In our implementation the server then hands the channel over
to JBoss Remoting which then performs its normal handshake, including
authentication.

The upshot of all this will be:

- We no longer have port 9999 open by default, which will break older
clients that attempt to talk to a default AS8 instance (it will still be
possible to add a native interface to allow it to work with older clients).

- 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://

I have not touched domain management yet, and these patches are not yet
ready for merging, but because this is a fairly big change I thought I
would get peoples thoughts before I finish it off and submit a PR.

Stuart

[1]
https://github.com/stuartwdouglas/xnio/compare/http-upgrade
https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
_______________________________________________
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

Dimitris Andreadis
Nice work :)

On 28/03/2013 11:15, Stuart Douglas wrote:

> Hi everyone,
>
> Now that we are using Undertow as the domain management HTTP server it
> is now possible to use a HTTP upgrade for the native management and
> remote-jmx protocols. This will allow us to run all management protocols
> over port 9990, and allow us to remove 9999 from our default config. The
> idea is significantly reduce the ports that are open in our default
> config, ideally eventually we will just have a management and
> application HTTP ports and that will be it (although some technologies
> such as CORBA are not compatible with HTTP Upgrade).
>
> With this in mind I have started working on a series of patches[1] to
> implement this, that I am hoping will be ready to merge early next week.
> (These patches are still a work in progress, but the core functionality
> works).
>
> For those of you who are not familiar with HTTP upgrade it is a
> mechanism where a client makes a HTTP request to the client with the
> Upgrade: header set, the server will then respond with a HTTP 101
> response. In our implementation the server then hands the channel over
> to JBoss Remoting which then performs its normal handshake, including
> authentication.
>
> The upshot of all this will be:
>
> - We no longer have port 9999 open by default, which will break older
> clients that attempt to talk to a default AS8 instance (it will still be
> possible to add a native interface to allow it to work with older clients).
>
> - 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://
>
> I have not touched domain management yet, and these patches are not yet
> ready for merging, but because this is a fairly big change I thought I
> would get peoples thoughts before I finish it off and submit a PR.
>
> Stuart
>
> [1]
> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

http://dandreadis.blogspot.com/
_______________________________________________
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
In reply to this post by Stuart Douglas
Sounds good, just one point before it reaches a point people are using
it - Is 'remote' really a suitable protocol name?

Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
that it was JMX over Remoting.

RMI is also considered remote so I think having a protocol of 'remote'
is ambiguous.

Regards,
Darran Lofthouse.


On 28/03/13 10:15, Stuart Douglas wrote:

> Hi everyone,
>
> Now that we are using Undertow as the domain management HTTP server it
> is now possible to use a HTTP upgrade for the native management and
> remote-jmx protocols. This will allow us to run all management protocols
> over port 9990, and allow us to remove 9999 from our default config. The
> idea is significantly reduce the ports that are open in our default
> config, ideally eventually we will just have a management and
> application HTTP ports and that will be it (although some technologies
> such as CORBA are not compatible with HTTP Upgrade).
>
> With this in mind I have started working on a series of patches[1] to
> implement this, that I am hoping will be ready to merge early next week.
> (These patches are still a work in progress, but the core functionality
> works).
>
> For those of you who are not familiar with HTTP upgrade it is a
> mechanism where a client makes a HTTP request to the client with the
> Upgrade: header set, the server will then respond with a HTTP 101
> response. In our implementation the server then hands the channel over
> to JBoss Remoting which then performs its normal handshake, including
> authentication.
>
> The upshot of all this will be:
>
> - We no longer have port 9999 open by default, which will break older
> clients that attempt to talk to a default AS8 instance (it will still be
> possible to add a native interface to allow it to work with older clients).
>
> - 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://
>
> I have not touched domain management yet, and these patches are not yet
> ready for merging, but because this is a fairly big change I thought I
> would get peoples thoughts before I finish it off and submit a PR.
>
> Stuart
>
> [1]
> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
> _______________________________________________
> 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

Stuart Douglas
This is what we have been using to represent JBoss remoting URI's so
far. I do agree that is is a bit ambiguous.

Stuart

Darran Lofthouse wrote:

> Sounds good, just one point before it reaches a point people are using
> it - Is 'remote' really a suitable protocol name?
>
> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
> that it was JMX over Remoting.
>
> RMI is also considered remote so I think having a protocol of 'remote'
> is ambiguous.
>
> Regards,
> Darran Lofthouse.
>
>
> On 28/03/13 10:15, Stuart Douglas wrote:
>> Hi everyone,
>>
>> Now that we are using Undertow as the domain management HTTP server it
>> is now possible to use a HTTP upgrade for the native management and
>> remote-jmx protocols. This will allow us to run all management protocols
>> over port 9990, and allow us to remove 9999 from our default config. The
>> idea is significantly reduce the ports that are open in our default
>> config, ideally eventually we will just have a management and
>> application HTTP ports and that will be it (although some technologies
>> such as CORBA are not compatible with HTTP Upgrade).
>>
>> With this in mind I have started working on a series of patches[1] to
>> implement this, that I am hoping will be ready to merge early next week.
>> (These patches are still a work in progress, but the core functionality
>> works).
>>
>> For those of you who are not familiar with HTTP upgrade it is a
>> mechanism where a client makes a HTTP request to the client with the
>> Upgrade: header set, the server will then respond with a HTTP 101
>> response. In our implementation the server then hands the channel over
>> to JBoss Remoting which then performs its normal handshake, including
>> authentication.
>>
>> The upshot of all this will be:
>>
>> - We no longer have port 9999 open by default, which will break older
>> clients that attempt to talk to a default AS8 instance (it will still be
>> possible to add a native interface to allow it to work with older
>> clients).
>>
>> - 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://
>>
>> I have not touched domain management yet, and these patches are not yet
>> ready for merging, but because this is a fairly big change I thought I
>> would get peoples thoughts before I finish it off and submit a PR.
>>
>> Stuart
>>
>> [1]
>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>> _______________________________________________
>> 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

Darran Lofthouse
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?

> Stuart
>
> Darran Lofthouse wrote:
>> Sounds good, just one point before it reaches a point people are using
>> it - Is 'remote' really a suitable protocol name?
>>
>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
>> that it was JMX over Remoting.
>>
>> RMI is also considered remote so I think having a protocol of 'remote'
>> is ambiguous.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 28/03/13 10:15, Stuart Douglas wrote:
>>> Hi everyone,
>>>
>>> Now that we are using Undertow as the domain management HTTP server it
>>> is now possible to use a HTTP upgrade for the native management and
>>> remote-jmx protocols. This will allow us to run all management protocols
>>> over port 9990, and allow us to remove 9999 from our default config. The
>>> idea is significantly reduce the ports that are open in our default
>>> config, ideally eventually we will just have a management and
>>> application HTTP ports and that will be it (although some technologies
>>> such as CORBA are not compatible with HTTP Upgrade).
>>>
>>> With this in mind I have started working on a series of patches[1] to
>>> implement this, that I am hoping will be ready to merge early next week.
>>> (These patches are still a work in progress, but the core functionality
>>> works).
>>>
>>> For those of you who are not familiar with HTTP upgrade it is a
>>> mechanism where a client makes a HTTP request to the client with the
>>> Upgrade: header set, the server will then respond with a HTTP 101
>>> response. In our implementation the server then hands the channel over
>>> to JBoss Remoting which then performs its normal handshake, including
>>> authentication.
>>>
>>> The upshot of all this will be:
>>>
>>> - We no longer have port 9999 open by default, which will break older
>>> clients that attempt to talk to a default AS8 instance (it will still be
>>> possible to add a native interface to allow it to work with older
>>> clients).
>>>
>>> - 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://
>>>
>>> I have not touched domain management yet, and these patches are not yet
>>> ready for merging, but because this is a fairly big change I thought I
>>> would get peoples thoughts before I finish it off and submit a PR.
>>>
>>> Stuart
>>>
>>> [1]
>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>>> _______________________________________________
>>> 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

Stuart Douglas


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.

Stuart

>
>> Stuart
>>
>> Darran Lofthouse wrote:
>>> Sounds good, just one point before it reaches a point people are using
>>> it - Is 'remote' really a suitable protocol name?
>>>
>>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
>>> that it was JMX over Remoting.
>>>
>>> RMI is also considered remote so I think having a protocol of 'remote'
>>> is ambiguous.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 28/03/13 10:15, Stuart Douglas wrote:
>>>> Hi everyone,
>>>>
>>>> Now that we are using Undertow as the domain management HTTP server it
>>>> is now possible to use a HTTP upgrade for the native management and
>>>> remote-jmx protocols. This will allow us to run all management
>>>> protocols
>>>> over port 9990, and allow us to remove 9999 from our default config.
>>>> The
>>>> idea is significantly reduce the ports that are open in our default
>>>> config, ideally eventually we will just have a management and
>>>> application HTTP ports and that will be it (although some technologies
>>>> such as CORBA are not compatible with HTTP Upgrade).
>>>>
>>>> With this in mind I have started working on a series of patches[1] to
>>>> implement this, that I am hoping will be ready to merge early next
>>>> week.
>>>> (These patches are still a work in progress, but the core functionality
>>>> works).
>>>>
>>>> For those of you who are not familiar with HTTP upgrade it is a
>>>> mechanism where a client makes a HTTP request to the client with the
>>>> Upgrade: header set, the server will then respond with a HTTP 101
>>>> response. In our implementation the server then hands the channel over
>>>> to JBoss Remoting which then performs its normal handshake, including
>>>> authentication.
>>>>
>>>> The upshot of all this will be:
>>>>
>>>> - We no longer have port 9999 open by default, which will break older
>>>> clients that attempt to talk to a default AS8 instance (it will
>>>> still be
>>>> possible to add a native interface to allow it to work with older
>>>> clients).
>>>>
>>>> - 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://
>>>>
>>>> I have not touched domain management yet, and these patches are not yet
>>>> ready for merging, but because this is a fairly big change I thought I
>>>> would get peoples thoughts before I finish it off and submit a PR.
>>>>
>>>> Stuart
>>>>
>>>> [1]
>>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>>>> _______________________________________________
>>>> 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


Sent from my iPhone

On Mar 28, 2013, at 6:28 AM, Stuart Douglas <[hidden email]> wrote:

> 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.

The pure http client is a solution created for EAP 6.x since it doesn't have upgrade ability. I don't think we need to merge it.
_______________________________________________
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

kkhan
In reply to this post by Stuart Douglas

On 28 Mar 2013, at 11:27, 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.

I think a pure http client library would open up nice possibilities for porting the cli to android, afaik remoting/xnio will not work there (although my impression there is based on rumours). Perhaps that isn't so important, but it sounds like fun to me :-)

>
> Stuart
>
>>
>>> Stuart
>>>
>>> Darran Lofthouse wrote:
>>>> Sounds good, just one point before it reaches a point people are using
>>>> it - Is 'remote' really a suitable protocol name?
>>>>
>>>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
>>>> that it was JMX over Remoting.
>>>>
>>>> RMI is also considered remote so I think having a protocol of 'remote'
>>>> is ambiguous.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 28/03/13 10:15, Stuart Douglas wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Now that we are using Undertow as the domain management HTTP server it
>>>>> is now possible to use a HTTP upgrade for the native management and
>>>>> remote-jmx protocols. This will allow us to run all management
>>>>> protocols
>>>>> over port 9990, and allow us to remove 9999 from our default config.
>>>>> The
>>>>> idea is significantly reduce the ports that are open in our default
>>>>> config, ideally eventually we will just have a management and
>>>>> application HTTP ports and that will be it (although some technologies
>>>>> such as CORBA are not compatible with HTTP Upgrade).
>>>>>
>>>>> With this in mind I have started working on a series of patches[1] to
>>>>> implement this, that I am hoping will be ready to merge early next
>>>>> week.
>>>>> (These patches are still a work in progress, but the core functionality
>>>>> works).
>>>>>
>>>>> For those of you who are not familiar with HTTP upgrade it is a
>>>>> mechanism where a client makes a HTTP request to the client with the
>>>>> Upgrade: header set, the server will then respond with a HTTP 101
>>>>> response. In our implementation the server then hands the channel over
>>>>> to JBoss Remoting which then performs its normal handshake, including
>>>>> authentication.
>>>>>
>>>>> The upshot of all this will be:
>>>>>
>>>>> - We no longer have port 9999 open by default, which will break older
>>>>> clients that attempt to talk to a default AS8 instance (it will
>>>>> still be
>>>>> possible to add a native interface to allow it to work with older
>>>>> clients).
>>>>>
>>>>> - 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://
>>>>>
>>>>> I have not touched domain management yet, and these patches are not yet
>>>>> ready for merging, but because this is a fairly big change I thought I
>>>>> would get peoples thoughts before I finish it off and submit a PR.
>>>>>
>>>>> Stuart
>>>>>
>>>>> [1]
>>>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>>>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>>>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>>>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>>>>> _______________________________________________
>>>>> 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

---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat


_______________________________________________
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
In reply to this post by Stuart Douglas
On 28/03/13 11:27, Stuart Douglas wrote:
> Darran Lofthouse wrote:

>> 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?

I also can't think of reason at the moment, I think the real question is
do we want to rule out the possibility that someone could find one in
the future ;-)

> 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.
>
> Stuart
_______________________________________________
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
In reply to this post by kkhan

On Mar 28, 2013, at 6:32 AM, Kabir Khan <[hidden email]> wrote:

>
> On 28 Mar 2013, at 11:27, 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.
>
> I think a pure http client library would open up nice possibilities for porting the cli to android, afaik remoting/xnio will not work there (although my impression there is based on rumours). Perhaps that isn't so important, but it sounds like fun to me :-)

Fixing it on android should be fun too!! :)


>>
>> Stuart
>>
>>>
>>>> Stuart
>>>>
>>>> Darran Lofthouse wrote:
>>>>> Sounds good, just one point before it reaches a point people are using
>>>>> it - Is 'remote' really a suitable protocol name?
>>>>>
>>>>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
>>>>> that it was JMX over Remoting.
>>>>>
>>>>> RMI is also considered remote so I think having a protocol of 'remote'
>>>>> is ambiguous.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>>
>>>>> On 28/03/13 10:15, Stuart Douglas wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> Now that we are using Undertow as the domain management HTTP server it
>>>>>> is now possible to use a HTTP upgrade for the native management and
>>>>>> remote-jmx protocols. This will allow us to run all management
>>>>>> protocols
>>>>>> over port 9990, and allow us to remove 9999 from our default config.
>>>>>> The
>>>>>> idea is significantly reduce the ports that are open in our default
>>>>>> config, ideally eventually we will just have a management and
>>>>>> application HTTP ports and that will be it (although some technologies
>>>>>> such as CORBA are not compatible with HTTP Upgrade).
>>>>>>
>>>>>> With this in mind I have started working on a series of patches[1] to
>>>>>> implement this, that I am hoping will be ready to merge early next
>>>>>> week.
>>>>>> (These patches are still a work in progress, but the core functionality
>>>>>> works).
>>>>>>
>>>>>> For those of you who are not familiar with HTTP upgrade it is a
>>>>>> mechanism where a client makes a HTTP request to the client with the
>>>>>> Upgrade: header set, the server will then respond with a HTTP 101
>>>>>> response. In our implementation the server then hands the channel over
>>>>>> to JBoss Remoting which then performs its normal handshake, including
>>>>>> authentication.
>>>>>>
>>>>>> The upshot of all this will be:
>>>>>>
>>>>>> - We no longer have port 9999 open by default, which will break older
>>>>>> clients that attempt to talk to a default AS8 instance (it will
>>>>>> still be
>>>>>> possible to add a native interface to allow it to work with older
>>>>>> clients).
>>>>>>
>>>>>> - 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://
>>>>>>
>>>>>> I have not touched domain management yet, and these patches are not yet
>>>>>> ready for merging, but because this is a fairly big change I thought I
>>>>>> would get peoples thoughts before I finish it off and submit a PR.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>>>>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>>>>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>>>>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>>>>>> _______________________________________________
>>>>>> 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
>
> ---------------------------------------
> Kabir Khan
> Prinicipal Software Engineer
> JBoss by Red Hat
>
>
> _______________________________________________
> 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


Sent from my iPhone

On Mar 28, 2013, at 6:45 AM, Jason Greene <[hidden email]> wrote:

>
> On Mar 28, 2013, at 6:32 AM, Kabir Khan <[hidden email]> wrote:
>
>>
>> On 28 Mar 2013, at 11:27, 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.
>>
>> I think a pure http client library would open up nice possibilities for porting the cli to android, afaik remoting/xnio will not work there (although my impression there is based on rumours). Perhaps that isn't so important, but it sounds like fun to me :-)
>
> Fixing it on android should be fun too!! :)

Sorry what I mean is there is no reason remoting should not work

>
>
>>>
>>> Stuart
>>>
>>>>
>>>>> Stuart
>>>>>
>>>>> Darran Lofthouse wrote:
>>>>>> Sounds good, just one point before it reaches a point people are using
>>>>>> it - Is 'remote' really a suitable protocol name?
>>>>>>
>>>>>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate
>>>>>> that it was JMX over Remoting.
>>>>>>
>>>>>> RMI is also considered remote so I think having a protocol of 'remote'
>>>>>> is ambiguous.
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>>
>>>>>>
>>>>>> On 28/03/13 10:15, Stuart Douglas wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Now that we are using Undertow as the domain management HTTP server it
>>>>>>> is now possible to use a HTTP upgrade for the native management and
>>>>>>> remote-jmx protocols. This will allow us to run all management
>>>>>>> protocols
>>>>>>> over port 9990, and allow us to remove 9999 from our default config.
>>>>>>> The
>>>>>>> idea is significantly reduce the ports that are open in our default
>>>>>>> config, ideally eventually we will just have a management and
>>>>>>> application HTTP ports and that will be it (although some technologies
>>>>>>> such as CORBA are not compatible with HTTP Upgrade).
>>>>>>>
>>>>>>> With this in mind I have started working on a series of patches[1] to
>>>>>>> implement this, that I am hoping will be ready to merge early next
>>>>>>> week.
>>>>>>> (These patches are still a work in progress, but the core functionality
>>>>>>> works).
>>>>>>>
>>>>>>> For those of you who are not familiar with HTTP upgrade it is a
>>>>>>> mechanism where a client makes a HTTP request to the client with the
>>>>>>> Upgrade: header set, the server will then respond with a HTTP 101
>>>>>>> response. In our implementation the server then hands the channel over
>>>>>>> to JBoss Remoting which then performs its normal handshake, including
>>>>>>> authentication.
>>>>>>>
>>>>>>> The upshot of all this will be:
>>>>>>>
>>>>>>> - We no longer have port 9999 open by default, which will break older
>>>>>>> clients that attempt to talk to a default AS8 instance (it will
>>>>>>> still be
>>>>>>> possible to add a native interface to allow it to work with older
>>>>>>> clients).
>>>>>>>
>>>>>>> - 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://
>>>>>>>
>>>>>>> I have not touched domain management yet, and these patches are not yet
>>>>>>> ready for merging, but because this is a fairly big change I thought I
>>>>>>> would get peoples thoughts before I finish it off and submit a PR.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade
>>>>>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
>>>>>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
>>>>>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>> ---------------------------------------
>> Kabir Khan
>> Prinicipal Software Engineer
>> JBoss by Red Hat
>>
>>
>> _______________________________________________
>> 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

_______________________________________________
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

kkhan

On 28 Mar 2013, at 11:48, Jason Greene wrote:

>
>
> Sent from my iPhone
>
> On Mar 28, 2013, at 6:45 AM, Jason Greene <[hidden email]> wrote:
>
>>
>> On Mar 28, 2013, at 6:32 AM, Kabir Khan <[hidden email]> wrote:
>>
>>>
>>> On 28 Mar 2013, at 11:27, Stuart Douglas wrote:
>>>>
>>>> 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.
>>>
>>> I think a pure http client library would open up nice possibilities for porting the cli to android, afaik remoting/xnio will not work there (although my impression there is based on rumours). Perhaps that isn't so important, but it sounds like fun to me :-)
>>
>> Fixing it on android should be fun too!! :)
>
> Sorry what I mean is there is no reason remoting should not work

Perhaps it does, I was really just regurgitating something someone might have said sometime :-)


_______________________________________________
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 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.

--
- DML
_______________________________________________
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

Brian Stansberry
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.

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
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
On 03/28/2013 08:49 AM, 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.

For example, I made this assumption just now.  :-)

--
- DML
_______________________________________________
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

jtgreene
Administrator
In reply to this post by Brian Stansberry

On Mar 28, 2013, at 8:49 AM, Brian Stansberry <[hidden email]> 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.

Right I took pure HTTP client library as == ejb client over http talking
to a servlet that does EJB invocation (the pending EAP 6.x change). I don't
see any reason at all to have such a thing now that we support http upgrade
to remoting.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
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

Rémy Maucherat
On 03/28/2013 03:02 PM, Jason Greene wrote:
> Right I took pure HTTP client library as == ejb client over http talking
> to a servlet that does EJB invocation (the pending EAP 6.x change). I don't
> see any reason at all to have such a thing now that we support http upgrade
> to remoting.
I understand there is a new component that people feel they have to use,
or something like it. But this is actually simply replacing standards by
proprietary APIs. Although I understand why this is tempting (faster in
the short term ?), a Servlet 3.1 has the same HTTP upgrade capabilities
and async IO as the proprietary component, and is functionally identical.

Normally, the evolution is the opposite: a proprietary API exists
initially, and some people may use it (but most wait) because there's no
standardized one yet. Ex: the async IO and upgrade capabilities of web
as available in EAP 6.1, which mimic Servlet 3.1.

Rémy

_______________________________________________
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

jtgreene
Administrator

On Mar 28, 2013, at 9:26 AM, Rémy Maucherat <[hidden email]> wrote:

> On 03/28/2013 03:02 PM, Jason Greene wrote:
>> Right I took pure HTTP client library as == ejb client over http talking
>> to a servlet that does EJB invocation (the pending EAP 6.x change). I don't
>> see any reason at all to have such a thing now that we support http upgrade
>> to remoting.
> I understand there is a new component that people feel they have to use,
> or something like it. But this is actually simply replacing standards by
> proprietary APIs. Although I understand why this is tempting (faster in
> the short term ?), a Servlet 3.1 has the same HTTP upgrade capabilities
> and async IO as the proprietary component, and is functionally identical.
>
> Normally, the evolution is the opposite: a proprietary API exists
> initially, and some people may use it (but most wait) because there's no
> standardized one yet. Ex: the async IO and upgrade capabilities of web
> as available in EAP 6.1, which mimic Servlet 3.1.


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.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
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

Rémy Maucherat
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.

Rémy

_______________________________________________
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
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.

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12