Sent from my iPhone
On Mar 28, 2013, at 6:45 AM, Jason Greene <jgreene(a)redhat.com> wrote:
On Mar 28, 2013, at 6:32 AM, Kabir Khan <kabir.khan(a)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(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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev