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
>