This is the AMX home page:
https://glassfish.dev.java.net/javaee5/amx/index.html
There has been sample code there for years:
https://glassfish.dev.java.net/javaee5/amx/index.html#SampleCode
The info is not up to date for V3, but is largely correct.
However, the RMI connector is still not functional due to a JNDI bug
in V3.
Lloyd
..............................................
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish team, LSARC member
On Sep 12, 2008, at 9:24 AM, Ludovic Champenois wrote:
> Lloyd Chambers wrote:
>> The API for this already exists: AMX. It can be used a POJOs (the
>> same way GUI uses it).
>>
>> Let's not invent some other API for modifying configuration.
> Make sense.
> I guess people need code samples, tutorials or blogs on amx at this
> point.
> Googling V3 amx gives me a fisheye link:
> http://fisheye5.atlassian.com/browse/~raw,r=1.3/glassfish/www/v3/
> admin/planning/V3Changes/V3_AMX.html
>
> Any sample of a Java main program (with correct jar file names to
> use in the classpath) that would point to a server domain area and
> achieve what Vivek is looking for:
> addJdbcResource(); or createJdbcConnectionPool(); ?
> Also, what is the redistribution mechanism of amx-api and amx-impl
> jar into other products that would rely on amx?
> Thanks,
> Ludo
>>
>>
>> On Sep 12, 2008, at 8:58 AM, Vivek Pandey wrote:
>>
>>> With embedded API, we definitely want something like,
>>> GlassfishConfigurator or something like that which can be used by
>>> the users of embedded API,
>>>
>>> for example:
>>>
>>> AppServer as = new AppServer() //BTW, why did we change the name
>>> from GlassFish to AppServer?
>>>
>>> as.configurator().addJdbcResource();
>>> as.configurator().createJdbcConnectionPool();
>>> ...
>>>
>>> Without such API embedded API can not be considered complete.
>>> Specially, glassfish gem for Rails app, need such API access. I am
>>> not sure if I can use the admin RESTful webservice to create JDBC
>>> connection pool or create JDBC resource.
>>>
>>> -vivek.
>>> Jerome Dochez wrote:
>>>>
>>>> On Sep 10, 2008, at 6:52 PM, Kedar Mhaswade wrote:
>>>>
>>>>>
>>>>>> Spawning scripts via java, that start a java command has some
>>>>>> issues related to in/out processing ( password echo, log file
>>>>>> content streamed to an IDE output area,..) and process control
>>>>>> (you get the script process, not the spawned java process).
>>>>>
>>>>> Hmmm. So you want to control the process handle for GlassFish so
>>>>> you can
>>>>> control its life cycle from within NetBeans?
>>>>>
>>>>>> I can dig into the NetBeans list archive to find more info but
>>>>>> this has caused hell situations at some point of time...
>>>>>
>>>>> Please do.
>>>>> At any rate, your reasons seem to be different from Bill's
>>>>> "perceived
>>>>> simplicity of a Java command".
>>>>>
>>>>> I agree, there were quirks with "asadmin start-domain", but
>>>>> switching to
>>>>> java -jar because of that is rather inexplicable.
>>>> it's about choice. For instance, in general, you always choose
>>>> completeness over simplicity.
>>>>
>>>> but why is it inexplicable to you that more than 5 millions users
>>>> of Java are used to a java command line and might find it closer
>>>> to their comfort zone when using it with GF.
>>>> you do not have to feel diminished by their choices, because it's
>>>> theirs, just like you have yours.
>>>>
>>>> Overall, there is a still an embedded use case which is not
>>>> covered by the embedded API today which is the ability to run GF
>>>> embedded in another VM yet using the OSGi facilities. I think
>>>> that people can use the Main-Class as specified in the manifest
>>>> file to do that.
>>>>
>>>> it's also a feature which has been identified and documented for
>>>> V3.
>>>>
>>>>>
>>>>>
>>>>> BTW, NB bundles with GF V2 -- do we not have "asadmin start-
>>>>> domain" there?
>>>>> Are there bugs currently unsolved on NB Issue Tracker because of
>>>>> that?
>>>> why switching the debate ? it's not because asadmin has not bug
>>>> (and it shouldn't) that you cannot have java -jar invocations.
>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>