Right now Anissa has most examples since the GUI uses AMX extensively.
On Sep 12, 2008, at 1:51 PM, Ludovic Champenois wrote:
> Lloyd Chambers wrote:
>> Actually, if you're running the sample code, it hasn't been updated
>> for V3.
>>
>> Lots of AMX is missing for V3, and some (like deployment) has gone
>> away.
> Ha ok...Fair enough.
>
> I would love to see a V3 amx sample on how to achieve what Vivek is
> looking for, say adding a jdbcresource or a connectionpool...
> Simple samples kinda tutorial oriented, but very effective for
> people to start playing with the APIs.
> Who would have cycles to do that? Vivek?
> Thanks,
> Ludo
>>
>> Lloyd
>>
>> On Sep 12, 2008, at 1:37 PM, Lloyd Chambers wrote:
>>
>>> You're using a V3 jar against V2 or V2 jar against V3.
>>>
>>>
>>> On Sep 12, 2008, at 1:29 PM, Ludovic Champenois wrote:
>>>
>>>> Lloyd Chambers wrote:
>>>>> javaee.jar is not required for AMX in Prelude; JSR 77 support
>>>>> has been removed for Prelude.
>>>>>
>>>>> The required jar for AMX is:
>>>>> amx-api-10.0-SNAPSHOT.jar
>>>> Just tried with NetBeans with amx api from b24 ...I have 97
>>>> errors for compilation.
>>>>
>>>>
>>>> For example:
>>>>
>>>>
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/DeployNotificationListener.java:14: package
>>>> com.sun.appserv.management.deploy does not exist
>>>> [javac] import com.sun.appserv.management.deploy.DeploymentStatus;
>>>> .......
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/Samples.java:70: cannot find symbol
>>>> [javac] symbol : class MonitoringDottedNames
>>>> [javac] location: package com.sun.appserv.management.monitor
>>>> [javac] import
>>>> com.sun.appserv.management.monitor.MonitoringDottedNames;
>>>> [javac] ^
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/Samples.java:78: cannot find symbol
>>>> [javac] symbol : class ConfigDottedNames
>>>> [javac] location: package com.sun.appserv.management.config
>>>> [javac] import com.sun.appserv.management.config.ConfigDottedNames;
>>>>
>>>> .......
>>>>
>>>>
>>>> [javac]
>>>> getDomainConfig().removeStandaloneServerConfig( name );
>>>> [javac] ^
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/Demo.java:151: cannot find symbol
>>>> [javac] symbol : method getStandaloneServerConfigMap()
>>>> [javac] location: interface
>>>> com.sun.appserv.management.config.DomainConfig
>>>> [javac] if
>>>> ( getDomainConfig
>>>> ().getStandaloneServerConfigMap().get( instanceName ) != null )
>>>> [javac] ^
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/Demo.java:157: cannot find symbol
>>>> [javac] symbol : method getNodeAgentConfigMap()
>>>> [javac] location: interface
>>>> com.sun.appserv.management.config.DomainConfig
>>>> [javac] if
>>>> ( getDomainConfig
>>>> ().getNodeAgentConfigMap().get( nodeAgentName )== null )
>>>> [javac] ^
>>>> [javac] /Users/ludo/acvs/glassfish/www/javaee5/amx/samples/
>>>> amxsamples/Demo.java:170: cannot find symbol
>>>> [javac] symbol : method getConfigConfigMap()
>>>> [javac] location: interface
>>>> com.sun.appserv.management.config.DomainConfig
>>>> [javac] ConfigConfig config =
>>>> getDomainConfig().getConfigConfigMap().get( configName );
>>>> ...
>>>>
>>>>>
>>>>> Presumably we want an "amx-api.jar" named one at some point.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sep 12, 2008, at 1:14 PM, Ludovic Champenois wrote:
>>>>>
>>>>>> Lloyd Chambers wrote:
>>>>>>> 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.
>>>>>> Thanks for the links.
>>>>>> We need to update with correct V3 jars.
>>>>>> Regarding dependency to javaee.jar, what is the redistribution
>>>>>> rule there? Which splitted jar available in V3 can be used and
>>>>>> redistributed in a standalone product using AMX?
>>>>>> Thanks,
>>>>>> Ludo
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>