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
>