Alright, assuming AMX APIs are general purpose for glassfish
configuration then we need to expose it thru GlassFish embedded API.
What I am looking here is that the persistence of such info is the
responsibility of the user of such API.
My use case is basically wrapper over v3 nucleus, in this case Glassfish
gem.
For example Rails developer would like to persist the config info in not
XML, but rather a ruby rails specific configuration (known as yml file).
In that case, glassfish gem would be persisting it based on whether user
wants to persist the info, maybe in Rails app directory and it is always
in non-XML, ruby/rails specific config files.
I dont care whether it is AMX or some other API, as long as any of such
mechanism that enables me to do the above is just fine :-)
-vivek.
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.
>
>
> 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
>