[jboss-as7-dev] HTTP Upgrade for AS8 Management

Thu Mar 28 07:48:15 EDT 2013

Sent from my iPhone

On Mar 28, 2013, at 6:45 AM, Jason Greene <jgreene at redhat.com> wrote:

> 
> On Mar 28, 2013, at 6:32 AM, Kabir Khan <kabir.khan at jboss.com> 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
>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
>> ---------------------------------------
>> Kabir Khan
>> Prinicipal Software Engineer
>> JBoss by Red Hat
>> 
>> 
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev