Mark Hansen wrote:
> Cool. Thanks for the explanation about AMX.
>
> To clarify ... are you saying that it is not possible to do portable
> deployment using JSR-88?
I sure hope he isn't.
> My interpretation of your comments is that, even with JSR-88, it is
> not possible to write a generic deploy/undeploy utility that will work
> for all Java EE 5 app servers vis JSR-88.
http://java.sun.com/javaee/5/docs/api/javax/enterprise/deploy/spi/DeploymentManager.html
has distribute and undeploy...
> Am I understanding this correctly?
Again: I sure hope not.
> Would this be because of platform specific descriptors (e.g.,
> sun-web.xml), or is there more to it than that?
I will let Kedar answer this.
>
> Kedar Mhaswade wrote:
>
>> (Posting rather long response, but subject matter mandates it).
>>
>> Accessing/Invoking "MBeans" is way to administer systems that
>> have an implementation of instrumentation and agent
>> level of standard JMX: http://java.sun.com/jmx.
>>
>> There is a standard way to connect to these MBeans so as
>> to manage them programmatically. This is much like standard
>> ways to invoke the Java EE server side entities using HTTP,
>> RMI/IIOP etc. An example of such a "standard" JMX Connector
>> is JConsole that's distributed with Java SE 5.0+ distribution.
>>
>> MBeans are just like Java Beans although there are flavors
>> that make more flexible and powerful management possible using
>> rather complex structures. GlassFish uses such complex MBeans
>> called "Dynamic MBeans". The "standard" way to invoke these
>> MBeans is rather non object oriented. Thus, if an MBean had a
>> "management" method like "start(int timeout)", you'll need to
>> invoke it as
>>
>> anMBeanRegistrar.invoke(mbeanId, "start", params, signature);
>>
>> (names are chosen for sake of brevity).
>>
>> What I am getting at is the concept of "proxied" Objects
>> so that you could write client programs just like any other
>> program. Unfortunately, pure JMX does not provide these proxies
>> over the MBeans that might be arbitrarily complex.
>>
>> Hence, GlassFish goes one step further than other JMX enabled
>> systems like JBoss in that it uses a programmatic Java "API"
>> for you to able to do what other admin tools like "asadmin"
>> or "admin GUI" do. Deployment is just a part of it. You'd need
>> to for example "programmatically" create certain JVM options that
>> would be required by the GlassFish runtime. This comprehensive
>> API is called "AMX".
>>
>> All this and more is documented at:
>>
>> https://glassfish.dev.java.net/nonav/javaee5/amx/index.html
>>
>> There are quite a few examples there, for example:
>>
>> https://glassfish.dev.java.net/nonav/javaee5/amx/samples/javadoc/index.html
>>
>>
>> *Note*
>> This is the only official "programmatic" API to manage
>> GlassFish. Other ways suggested are just hacks.
MANAGE is a key word here.
>>
>> The specific case of "deployment" is an interesting one because
>> Java EE "spec" tells users how to deploy apps to a server compliant
>> with JSR 88. So, in theory, you could be a JSR 88 client and do
>> *only* deployment that is Java EE standard compliant. But unfortunately,
>> you don't need to *only* deploy. A lot of configuration comes
>> along with it and you would need a more sophisticated way to do it.
>> That's what AMX tries to do.
My interpretation of what Kedar has said:
You can write a client to JSR-88 that deploys stuff to GlassFish.
Deployment is one aspect of MANAGING an application server instance.
AMX can be used for deployment (non-portably) and it allows the user to
write a fuller MANAGEMENT client.
My opinion:
Using standard API's may be a good choice for writing a maven plugin to
deploy to ALL J2EE 1.4 and Java EE 5 server implementations. The
vendor's non-portable api's are probably better for writing a client
that deploys to a specific implementation.
>>
>> While using AMX, on the client side all you need is a simple file
>> named "appserv-ext.jar" and not the entire GlassFish installation.
>>
>> Regards,
>> Kedar
>>