Jim,
Where are you going with this...what is your goal? That might help
in answering. Also, please clarify if you've read the AMX design
docs and perused the javadoc.
Yes, AMX follows JMX best practices naming rules *and* JSR77 structure.
Why is the J2EEDomain implementation relevant to you? Unless you're
modifying the implementation, I don't see the point of the question.
It's com.sun.enterprise.management.j2ee.J2EEDomainImpl.
For "straight" JMX, please see the Javadoc for
com.sun.appserv.management.base.Util. Use Util.getExtra() to access
things from any AMX proxy. Or, if SSL is not enabled, you can use
the standard JMXServiceURL to connect and access MBeans.
Lloyd Chambers
On Nov 21, 2006, at 9:21 AM, Jim Jiang wrote:
> Hi Lloyd and Kedar ,
>
> Thanks a lot for your info.
> I have some further questions about AMX. :-P
> 1, AMX bean is stardard JMX bean, so do they follow all the mbean
> naming rules?
> Could you give me the exactly AMX mbean implementation in following
> case: (they were captured from jconsole connecting with GF)
> /mbean name: amx:j2eeType=J2EEDomain, name=amx
> mbean java class: com.sun.appserv.management.j2ee.J2EEDomain/
>
> 2, How could the stardard JMX bean be accessed by DCP ? Following
> codes digest from amx sample, which instance is playing the DCP role?
> / AppserverConnectionSource conn = new
> AppserverConnectionSource( AppserverConnectionSource.PROTOCOL_RMI,
> host, port, user, password, null,
> null); conn.getJMXConnector( false);
> DomainRoot mDomainRoot = conn.getDomainRoot();
> final DomainConfig dcp = mDomainRoot.getDomainConfig
> (); displayMap( "J2EEApplicationConfig",
> dcp.getJ2EEApplicationConfigMap() );/
>
> Thanks,
> Jim
>
> Lloyd L Chambers wrote:
>
>> Thanks for the summary Kedar. :)
>>
>> Jim, please see the AMX GlassFish site for further information:
>>
>> https://glassfish.dev.java.net/javaee5/amx/
>>
>> Lloyd Chambers
>>
>> On Nov 20, 2006, at 10:20 PM, kedar wrote:
>>
>>> Hi Jim,
>>>
>>> JMX standard and its implementation (latest) is
>>> part of Java SE 5.0. It is not part of Java EE 5, per se.
>>>
>>> Oh no. AMX is not an implementation of JMX. An implementation of
>>> JMX exists in the Java SE platform itself. AMX stands for
>>> "Application-Server
>>> Management eXtensions". So, it is an API to manage GlassFish
>>> Application
>>> Server and other distributions based on it (or vice versa). And
>>> as such,
>>> it is a proprietary (but supported/public) API that you can
>>> depend on.
>>>
>>> JSR 160 is the old name for JSR 255. It deals with remote JMX.
>>> That too,
>>> is a part of Java SE 5.0.
>>>
>>> JSR 77 is a management standard for application servers and was
>>> introduced
>>> in J2EE 1.4. JSR 77 tries to define the object model for
>>> managing application
>>> servers and also mandates that the model is invoked in a
>>> standard manner.
>>>
>>> AMX is not an implementation of JSR 77.
>>>
>>> What Lloyd means below is the AMX MBeans are pure JMX MBeans.
>>> The client
>>> side proxies like DomainConfig are convenience classes that you
>>> can use
>>> to ease your object oriented development (methods to be invoked
>>> on classes,
>>> rather than the generic MBeanServerConnection.invoke() method, e.g.)
>>> are not required to be used. Your client can be a pure JMX client
>>> like
>>> Java SE 5.0 JConsole and you can manage application server
>>> relying only on:
>>> - Standard JMX Connector (like the one included in Java SE 5.0/RMI).
>>> - MBeanInfo and ObjectNames of AMX MBeans.
>>>
>>> If you are OK doing it this way, you need no client side library
>>> and you
>>> can be a "pure Java 5.0" client managing GlassFish Application
>>> Server.
>>> (There is a small caveat there in terms of the Statistic classes
>>> that
>>> are picked from JSR 77 and you'd need javaee.jar on client side,
>>> to manage
>>> the server completely).
>>>
>>> Hope this does not confuse you further :)
>>>
>>> Thanks,
>>> Kedar
>>> Jim Jiang wrote:
>>>
>>>> Lloyd,
>>>>
>>>> Currently, AMX is knows as sun's own implementation for JMX
>>>> for EE5.
>>>> What is it going to be?
>>>> Will it be the part of JSR 160 or JSR 77?
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>>> Lloyd L Chambers wrote:
>>>>
>>>>> Jim,
>>>>>
>>>>> AMX is JMX. You may use AMX MBeans directly or the dynamic
>>>>> proxies to them. These are public interfaces, whose
>>>>> stability is not subject to arbitrary change.
>>>>>
>>>>> Nothing else should be used as it is subject to change and are
>>>>> either implementation details, or private MBeans, many of
>>>>> which might disappear in the next release.
>>>>>
>>>>> Lloyd Chambers
>>>>> (AMX implementor)
>>>>>
>>>>> On Nov 20, 2006, at 1:14 AM, Jim Jiang wrote:
>>>>>
>>>>>>
>>>>>> As what described in the article 'AMX: Design and Use ', GF
>>>>>> use AMX to simplify the JMX using.
>>>>>> But JMX mbean's implementation still can be found in GF, I
>>>>>> tried to summarize their location in below table:
>>>>>>
>>>>>> JMX
>>>>>> AMX
>>>>>> Interface com.sun.enterprise.admin.mbeanapi
>>>>>> com.sun.appserv.management
>>>>>> Implementation com.sun.enterprise.admin
>>>>>> com.sun.enterprise.management
>>>>>>
>>>>>>
>>>>>> Could anyone explain the rules about how to choose AMX or JMX
>>>>>> for management?
>>>>>> Why not use AMX as the unique way ?
>>>>>>
>>>>>> Please correct me if anything wrong.
>>>>>>
>>>>>> Thanks,
>>>>>> Jim
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -- --
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -- -
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>