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
>