dev@glassfish.java.net

Re: lopsidedness of domaindir usage?

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Fri, 12 Sep 2008 15:38:15 -0700

Vivek Pandey wrote:
> 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 really don't think we should invest in such a feature. I am sure the
ruby developer would like to see GlassFish developped in Ruby so it can
call its APIs too :)

the server config is not meant to be read by ruby applications or by any
applications (do we have use cases of Java EE application mocking with
the domain.xml ?) .The ruby container gets its configuration through
POJO objects so it does not have to deal with xml.

If someone somewhere wants to hack the domain.xml in ruby, I am sure
they have some xml manipulation libraries in ruby, but otherwise it will
have to be a Jruby community driven feature.

Jerome
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>