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
>