Jerome Dochez wrote:
> 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.
Well, from gem perspective, we want ability to provide easier
configuration file that can be used by the Rails developer to configure
the gem instance they would deploy their application on. It will be
better to approach this with minimalistic approach - where things that
we really want to expose is exposed to them.
The Ruby code that wires this configuration to start/restart the v3 gem
is done thru the API. I am not talking in terms of API that is specific
to AMX, it could very well be hidden behind embedded API or maybe
exposed depending upon how generic it is in terms of configuring a v3
server.
>
> 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.
Yes, we need to do this.
-vivek
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>