[jboss-as7-dev] Remoting issues

Kabir Khan kabir.khan at jboss.com
Mon Sep 26 16:11:57 EDT 2011


On 26 Sep 2011, at 19:19, David M. Lloyd wrote:

> Inline:
> 
> On 09/26/2011 09:38 AM, Kabir Khan wrote:
>> From chat discussions I am doing the following for servers, in the order below:
>> 
>> 1) Using 2 separate endpoints for our current configuration, i.e.
>> <management>
>>     <management-interfaces>
>>        <native-interface interface="management" port="9999" />
>>     </management-interfaces>
>> </management>
>> gives a 'management' endpoint. If there a remoting subsystem exists, that results in a 'subsystem' endpoint.
> 
> Endpoints should have names which are as unique as possible.  Perhaps 
> "${jboss.node.name}:management" for the management endpoint is a better 
> option, or make it configurable.
Yeah, that's what I am doing
> 
>> 2) Ability to choose the subsystem endpoint for management.
>> Something along the lines of this for a domain mode server which needs an endpoint to connect back to the HC:
>> <server-group>
>>     <subsystem-management-endpoint/>
>> </server-group>
>> This will cause it to use the remoting subsystem endpoint, absense of this will create the management endpoint.
> 
> This is a possible solution though like I said the endpoint name is 
Do you see there being more than two endpoints? At the moment, I'm working on the assumption that there are 2:
-'management' - Installed only if the existing config is used
-'subsystem' - Installed on creation of the remoting subsystem.
These names are created behind the scenes, I'm not sure I see any value in allowing more than 2 endpoints?

> significant.  Also one hopes that the user would be given the option to 
> register management with more than one endpoint?
Sure, I can do that.


> 
>> For a standalone server:
>> <management>
>>     <management-interfaces>
>>        <native-remoting connector="some-remoting-connector" />
>>     </management-interfaces>
>> </management>
>> This will not open the management endpoint but use the subsystem one instead. This needs a little bit more thinking to install the correct channel open listener into the connector
>> 
>> 3) Better configuration of connectors and channel open listeners in the remoting subsystem
>> 4) Meet with Darran later this week to understand the security stuff a bit better
> 
> Normally the services (channel open listeners) are configured by those 
> who register them,

At the moment this is kind of hardcoded into the remoting protocol but (I think) I get your idea. Remoting is only concerned with registering connectors, consumers such as managent, ejb, jndi etc. create the channel open listeners. From my POV that actually simplifies things a bit

> though ultimately if we (for example) want to add 
> some additional authorization checks at this level then it would make 
> more sense to do this globally.  Let's make sure that we're not 
> duplicating security or connector configuration between the management 
> endpoint and the subsystem one.
> 
> -- 
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev




More information about the jboss-as7-dev mailing list