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