Ken,
The only legitimate concern I am aware of is small-footprint cases
where JMX itself is (apparently) considered undesirable (I don't know
that for a fact that anyone has actually proven, and AFAIK there is a
small footprint micro JMX or so I thought). From my point of view,
it's an unproven cognitive committment.
The ObjectName of JMX MBeans presents real opportunities for bypassing
long paths. (For v3, I propose simplifying 'j2eeType' to just 'type'
and stripping the "X-", which would shorten the examples below).
In many cases, type alone can bypass any long path. A "friendly"
approach need not require strict ObjectName syntax!
For example:
jmxcmd> find j2eeType=X-HTTPListenerConfig
amx:j2eeType=X-HTTPListenerConfig,name=admin-listener,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
amx:j2eeType=X-HTTPListenerConfig,name=http-listener-1,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
amx:j2eeType=X-HTTPListenerConfig,name=http-listener-2,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
jmxcmd> find -w j2eeType=*Listener* amx:
amx:j2eeType=X-HTTPListenerConfig,name=admin-listener,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
amx:j2eeType=X-HTTPListenerConfig,name=http-listener-1,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
amx:j2eeType=X-HTTPListenerConfig,name=http-listener-2,X-
ConfigConfig=server-config,X-HTTPServiceConfig=na
amx:j2eeType=X-IIOPListenerConfig,name=SSL,X-ConfigConfig=server-
config,X-IIOPServiceConfig=na
amx:j2eeType=X-IIOPListenerConfig,name=SSL_MUTUALAUTH,X-
ConfigConfig=server-config,X-IIOPServiceConfig=na
amx:j2eeType=X-IIOPListenerConfig,name=orb-listener-1,X-
ConfigConfig=server-config,X-IIOPServiceConfig=na
Proposed for V3 (and can be further shortened):
jmxcmd> find type=HTTPListenerConfig
amx:type=HTTPListenerConfig,name=admin-listener,ConfigConfig=server-
config,HTTPServiceConfig=na
amx:type=HTTPListenerConfig,name=http-listener-1,ConfigConfig=server-
config,HTTPServiceConfig=na
amx:type=HTTPListenerConfig,name=http-listener-2,ConfigConfig=server-
config,HTTPServiceConfig=na
jmxcmd> find -w type=*Listener* amx:
amx:type=HTTPListenerConfig,name=admin-listener,ConfigConfig=server-
config,HTTPServiceConfig=na
amx:type=HTTPListenerConfig,name=http-listener-1,ConfigConfig=server-
config,HTTPServiceConfig=na
amx:type=HTTPListenerConfig,name=http-listener-2,ConfigConfig=server-
config,HTTPServiceConfig=na
amx:type=IIOPListenerConfig,name=SSL,ConfigConfig=server-
config,IIOPServiceConfig=na
amx:type=IIOPListenerConfig,name=SSL_MUTUALAUTH,ConfigConfig=server-
config,IIOPServiceConfig=na
amx:type=IIOPListenerConfig,name=orb-listener-1,ConfigConfig=server-
config,IIOPServiceConfig=na
..............................................
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish team, LSARC member
On Dec 12, 2008, at 10:34 AM, Ken Cavanaugh wrote:
>
> On Dec 12, 2008, at 10:22 AM, Lloyd Chambers wrote:
>
>> I see this discussion being co-opted into a "make it work with the
>> config API and ignore MBeans".
>>
>> That approach balkanizes and devalues the integrity of the system
>> I've proposed. The system should take a comprehensive approach to
>> any MBean in the system: monitoring will certainly be of equal if
>> not greater importance. One uniform approach. Period.
>>
>> Any "bypass the navigation process" solution can apply equally to
>> MBeans, so that is not a justification for using Config API over
>> MBeans.
>>
>> MBeans provide a uniform API to be used by any Java client,
>> including the CLI. Alternatives aren't necessarily so broadly
>> applicable.
>>
>> I am concerned about code development and maintainence; a single
>> comprehensive system minimizes those issues.
>>
>> The assumption seems to be that MBeans must not be relied upon,
>> indeed not used, because certain GlassFish configurations "don't
>> want them". I'm not persuaded that's more than an assertion,
>> rather than one based on measurements.
>>
>
> I am of course very interested in this point, since gmbal targets
> AMX MBeans, and we certainly need strong
> client support for whatever we do on the server (MBean
> instrumentation) side.
>
> I don't know the background here, but why are we not using MBeans
> for configuration?
> I understand that the config info needs to be stored in domain.xml,
> but that still could rather
> easily be exposed simply as MBeans.
>
> In fact, treating a tree of MBeans simply as another expression of
> an XML infoset representing
> domain.xml seems like an obvious approach (for config, there are
> other users for MBeans as well).
> This would probably also simplify discussions
> such as the standalone vs. gfv3 config for Grizzly. Why can't these
> be almost exactly
> the same code, targeting different storage mechanisms as needed?
>
> Thanks,
>
> Ken.
>