dev@glassfish.java.net

Re: lopsidedness of domaindir usage?

From: Lloyd Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Fri, 12 Sep 2008 13:18:44 -0700

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

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
>