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
>