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

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 >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev