Vivek Pandey wrote:
> Jerome Dochez wrote:
>> 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.
>>
> You are missing the point. The feature I am talking about is for
> GlassFish gem not Rails developers. LoL :-)
you did say Rails developers in your initial email...
> ofcourse they (rails developers)dont need to care of such a feature.
> It is for glassfish gem which wraps v3 and provides it as deployment
> choice to Rails developers.
>
> If you support Rails application deployment, then you also need to
> support how the application server can be configured, how some of the
> Java enterprise features can be configured. For example, JDBC
> connection pool, access to JNDI etc. Without such features how else
> would you provide v3 enterprise features configuration? No, it is not
> about hacking domain.xml, rather a decent API that can be used to
> achieve it. About whether we want to expose the configuration artifact
> as an XML file or what Rails developers are comfortable with (yml) is
> obviously, yml.
that seem to be an entirely different problem. in fact, that seem to be
a problem that you - the gem provider - need to fix :), ok. ok with some
help.
now I think there are a number of different conflicting things I am
hearing about the gem...
do you want to use the embedded API and forgo the domain.xml all together ?
do you want to provide a yml way of configuring the application server ?
or finally do you want to use AMX to configure.
I think you need to spend some time deciding which way you want to go.
Each way is possible individually but it seems we don't need the three
of them. It also seems we should get some design meeting going after
prelude to see what's missing in the gem space because so far I don't
know what it means to be relevant in the programming model of rails and
we need some guidance and feature requests from you.
Jerome
>
> Jetty have jetty_rails gem just like glassfish gem and although their
> config file is an XML based but for rails applications they have
> corresponding yml file.
>
> It is about being relevant in the programming model of a framework
> that we support.
>
>
> -vivek.
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>