You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2008/10/09 23:27:55 UTC
Grails, JRuby on Rails, etc... scripting languages/environments and
Geronimo integration
I think it was Kevan that originally proposed we might consider
integrating some of these scripting languages/environments in with
Geronimo ... possibly for Geronimo 2.2.
I've started to look into a few of these technologies with an eye toward
integration in Geronimo. I'm not coming into this with any first hand
experience in these technologies (beyond what I've read and experimented
with thus far) ... so any informed opinions are certainly welcome.
So far, this is my initial take on these technologies and the
feasibility of integration with Geronimo:
Grails framework - This is a self contained framework that leverages
groovy for scripting. It uses a rails like code by convention approach
to generate and host web applications. It is licensed under Apache. It
embeds Jetty for hosting the generated web applications but can also
export WAR files which can be then deployed application servers like
Geronimo. There is an article that gives a nice description on how to
utilize Grails to generate a web app and deploy it into Geronimo
(http://www.ibm.com/developerworks/opensource/library/os-ag-grails/).
As far as integration with Geronimo goes, I'm not sure that there is
much to we can do. I guess we could document this in our wiki or
perhaps generate a plugin (or whatever the Grails term is) so that the
geronimo deployment plan can be generated rather than created manually,
but I'm not sure that is worth the effort. There doesn't seem to be a
good place for programmatic integration with regard to the framework itself.
JRuby on Rails - My understanding is that this is basically a Ruby
implementation that runs on the Java VM (the JRuby portion) and
leverages the Rails framework. It is licensed under CPL/GPL/LGPL. In
many ways it is similar to Grails using an embedded web server to
facilitate a rapid application development environment ... this time
built upon the JRuby language interpreter. Here again, I suspect we can
provide some directions so that an exported war could be deployed in
Geronimo (or perhaps a plugin to generate geronimo deployment plans) but
there doesn't seem to be much in the way of direct integration that we
can provide.
There are other frameworks as well. Trails is one that I stumbled on
which is also in the same vein as Grails with a focus on definition of
the domain model and generating the rest of the app dynamically.
However, this has me thinking that perhaps I should focus more on the
language interpreters and integrating those (JRuby, Groovy, etc...)
rather than the frameworks.
Thoughts?
Any ideas on PHP and if this would be another potential area for
integration?
Joe
Re: Grails, JRuby on Rails, etc... scripting languages/environments
and Geronimo integration
Posted by Joe Bohn <jo...@earthlink.net>.
Kevan Miller wrote:
>
> On Oct 10, 2008, at 10:52 AM, Jason Dillon wrote:
>
>> On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote:
>>> Grails framework - This is a self contained framework that leverages
>>> groovy for scripting. It uses a rails like code by convention
>>> approach to generate and host web applications. It is licensed
>>> under Apache. It embeds Jetty for hosting the generated web
>>> applications but can also export WAR files which can be then deployed
>>> application servers like Geronimo. There is an article that gives a
>>> nice description on how to utilize Grails to generate a web app and
>>> deploy it into Geronimo
>>> (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/).
>>> As far as integration with Geronimo goes, I'm not sure that there is
>>> much to we can do. I guess we could document this in our wiki or
>>> perhaps generate a plugin (or whatever the Grails term is) so that
>>> the geronimo deployment plan can be generated rather than created
>>> manually, but I'm not sure that is worth the effort. There doesn't
>>> seem to be a good place for programmatic integration with regard to
>>> the framework itself.
>>
>> Um, there isn't a good place, because there isn't really any need for
>> anything. From the containers perspective its just another WAR
>> deployment.
>
> One thing I was thinking about was to create a Grails plugin (which
> contains the jars required to run a Grails web app). Thus avoiding
> having to package all of the Grails dependencies in the WAR, itself.
> Instead, they'd be declared as a dependency. Pushing wars with a bunch
> of redundant jars, didn't strike me as very desirable. Grails might need
> a bit of customization to build suitable WARS.
Interesting idea. I hadn't really thought of that ... I just was
planning to work with the war generated by Grails. I'll think about
constructing the war differently (or perhaps doing some inplace
deployment) and moving the grails jars to a plugin.
>
>>
>> I would still be interested to see something, a sample even, running
>> under Grails inside of Geronimo. AFAICT Grails is a very powerful
>> framework for whipping up apps, so we could potentially use it... say
>> for the console :-P
>
> A sample would certainly be helpful... Agreed about Grails, in general.
> I was thinking it would be interesting to see if we could make it
> simpler/more efficient to bridge between the two environments.
There is a sample of sorts in the article referenced earlier. But, this
doesn't really do anything for Geronimo/Grails integration and is a
little hard to find. We could certainly do something to provide a
sample/tutorial in our wiki ... but perhaps it would be much more
interesting if we did something with the grails gbean you proposed and
then some type of in-place deployment to make creating and running in
Geronimo quick and easy. Something more to think about. Thanks!
>
>>
>>> JRuby on Rails - My understanding is that this is basically a Ruby
>>> implementation that runs on the Java VM (the JRuby portion) and
>>> leverages the Rails framework. It is licensed under CPL/GPL/LGPL.
>>> In many ways it is similar to Grails using an embedded web server to
>>> facilitate a rapid application development environment ... this time
>>> built upon the JRuby language interpreter. Here again, I suspect we
>>> can provide some directions so that an exported war could be deployed
>>> in Geronimo (or perhaps a plugin to generate geronimo deployment
>>> plans) but there doesn't seem to be much in the way of direct
>>> integration that we can provide.
>>>
>>> There are other frameworks as well. Trails is one that I stumbled on
>>> which is also in the same vein as Grails with a focus on definition
>>> of the domain model and generating the rest of the app dynamically.
>>
>> From what I have seen, most dynamic languages which run in Java also
>> support some-sort of web/WAR integration. But don't really require
>> much else to work. So I think that simply providing samples is
>> sufficient.
>>
>> I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x
>> is a good idea, though really I've no idea how/if/why someone would
>> want to use it. Maybe someone wants to generate a web-page, or maybe
>> someone wants to get the return value of a script injected into their
>> GBean, or wants the script to be their GBean, or wants to have a chunk
>> of script executed when the server loads... who knows.
>
> Personally, I thought Grails was the best fit, but that may be because
> I've used Groovy more (which isn't saying a whole lot) and new a bit
> more about it...
>
> --kevan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Kevan Miller <ke...@gmail.com>.
On Oct 10, 2008, at 10:52 AM, Jason Dillon wrote:
> On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote:
>> Grails framework - This is a self contained framework that
>> leverages groovy for scripting. It uses a rails like code by
>> convention approach to generate and host web applications. It is
>> licensed under Apache. It embeds Jetty for hosting the generated
>> web applications but can also export WAR files which can be then
>> deployed application servers like Geronimo. There is an article
>> that gives a nice description on how to utilize Grails to generate
>> a web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/
>> ).
>> As far as integration with Geronimo goes, I'm not sure that there
>> is much to we can do. I guess we could document this in our wiki
>> or perhaps generate a plugin (or whatever the Grails term is) so
>> that the geronimo deployment plan can be generated rather than
>> created manually, but I'm not sure that is worth the effort. There
>> doesn't seem to be a good place for programmatic integration with
>> regard to the framework itself.
>
> Um, there isn't a good place, because there isn't really any need
> for anything. From the containers perspective its just another WAR
> deployment.
One thing I was thinking about was to create a Grails plugin (which
contains the jars required to run a Grails web app). Thus avoiding
having to package all of the Grails dependencies in the WAR, itself.
Instead, they'd be declared as a dependency. Pushing wars with a bunch
of redundant jars, didn't strike me as very desirable. Grails might
need a bit of customization to build suitable WARS.
>
> I would still be interested to see something, a sample even, running
> under Grails inside of Geronimo. AFAICT Grails is a very powerful
> framework for whipping up apps, so we could potentially use it...
> say for the console :-P
A sample would certainly be helpful... Agreed about Grails, in
general. I was thinking it would be interesting to see if we could
make it simpler/more efficient to bridge between the two environments.
>
>> JRuby on Rails - My understanding is that this is basically a Ruby
>> implementation that runs on the Java VM (the JRuby portion) and
>> leverages the Rails framework. It is licensed under CPL/GPL/LGPL.
>> In many ways it is similar to Grails using an embedded web server
>> to facilitate a rapid application development environment ... this
>> time built upon the JRuby language interpreter. Here again, I
>> suspect we can provide some directions so that an exported war
>> could be deployed in Geronimo (or perhaps a plugin to generate
>> geronimo deployment plans) but there doesn't seem to be much in the
>> way of direct integration that we can provide.
>>
>> There are other frameworks as well. Trails is one that I stumbled
>> on which is also in the same vein as Grails with a focus on
>> definition of the domain model and generating the rest of the app
>> dynamically.
>
> From what I have seen, most dynamic languages which run in Java also
> support some-sort of web/WAR integration. But don't really require
> much else to work. So I think that simply providing samples is
> sufficient.
>
> I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x
> is a good idea, though really I've no idea how/if/why someone would
> want to use it. Maybe someone wants to generate a web-page, or
> maybe someone wants to get the return value of a script injected
> into their GBean, or wants the script to be their GBean, or wants to
> have a chunk of script executed when the server loads... who knows.
Personally, I thought Grails was the best fit, but that may be because
I've used Groovy more (which isn't saying a whole lot) and new a bit
more about it...
--kevan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Jason Dillon <ja...@gmail.com>.
On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote:
> Grails framework - This is a self contained framework that leverages
> groovy for scripting. It uses a rails like code by convention
> approach to generate and host web applications. It is licensed
> under Apache. It embeds Jetty for hosting the generated web
> applications but can also export WAR files which can be then
> deployed application servers like Geronimo. There is an article
> that gives a nice description on how to utilize Grails to generate a
> web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/
> ).
> As far as integration with Geronimo goes, I'm not sure that there is
> much to we can do. I guess we could document this in our wiki or
> perhaps generate a plugin (or whatever the Grails term is) so that
> the geronimo deployment plan can be generated rather than created
> manually, but I'm not sure that is worth the effort. There doesn't
> seem to be a good place for programmatic integration with regard to
> the framework itself.
Um, there isn't a good place, because there isn't really any need for
anything. From the containers perspective its just another WAR
deployment.
I would still be interested to see something, a sample even, running
under Grails inside of Geronimo. AFAICT Grails is a very powerful
framework for whipping up apps, so we could potentially use it... say
for the console :-P
> JRuby on Rails - My understanding is that this is basically a Ruby
> implementation that runs on the Java VM (the JRuby portion) and
> leverages the Rails framework. It is licensed under CPL/GPL/LGPL.
> In many ways it is similar to Grails using an embedded web server to
> facilitate a rapid application development environment ... this time
> built upon the JRuby language interpreter. Here again, I suspect we
> can provide some directions so that an exported war could be
> deployed in Geronimo (or perhaps a plugin to generate geronimo
> deployment plans) but there doesn't seem to be much in the way of
> direct integration that we can provide.
>
> There are other frameworks as well. Trails is one that I stumbled
> on which is also in the same vein as Grails with a focus on
> definition of the domain model and generating the rest of the app
> dynamically.
From what I have seen, most dynamic languages which run in Java also
support some-sort of web/WAR integration. But don't really require
much else to work. So I think that simply providing samples is
sufficient.
I guess supporting the javax.script/JSR-223 stuff via Apache BSF 3.x
is a good idea, though really I've no idea how/if/why someone would
want to use it. Maybe someone wants to generate a web-page, or maybe
someone wants to get the return value of a script injected into their
GBean, or wants the script to be their GBean, or wants to have a chunk
of script executed when the server loads... who knows.
--jason
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 17/10/2008, at 12:42 AM, Joe Bohn wrote:
>
> Gianny Damour wrote:
>> Hi,
>> I also do not see a lot of room for improvement in Grails
>> integration. FWIW, in addition to the sample Grails application of
>> the IBM article, the WADI administration console, a Grails Web-
>> app, can be deployed out-of-the-box to Geronimo to introspect WADI
>> clusters.
>> I believe there is room for scripting languages in Geronimo.
>> For instance, gshell users can source command files to automate
>> some of their actions. A more powerful approach would be to
>> provide scripting capabilities to gshell users. I believe, Groovy
>> is an appropriate scripting language choice as it is very easy to
>> learn for Java people.
>> Another user case would be to use scripting to replace the
>> serialized configuration, I mean the config.ser. An xmlbean
>> serialization of configurations is way better than a native Java
>> serialization as end-users can easily see and update values of
>> serialized stuff. A YAML or even better a Groovy builder
>> serialization would be way better than a xmlbean serialization. i
>> would even go a step further and say that the geronimo DD could be
>> replaced by scripts. A programmatic way to configure GBeans would
>> be simpler. This could be a little bit like the programmatic
>> servlet component configuration mechanism defined by the upcoming
>> Servlet spec.
>
> Sorry for the delayed response. I still haven't quite gotten my
> head around this idea yet? Can you provide some more information
> on how this would look and behave? I guess I need to take a look
> at the new Servlet spec.
>
>> A third example is to provide a simpler extension of
>> configurations. The addition of a custom Tomcat valve to the
>> tomcat6 config is a use case. When a configuration is started a
>> script is executed to provide GBean overrides (add, update or
>> remove) and dependencies overrides to the pre-canned
>> configuration. In the scripting context, users have access to the
>> pre-canned configuration and are able to return an altered one if
>> they want.
>
> This too is an interesting idea. Are you thinking that the
> extensions would only live in the script and be executed each time
> the configuration is started or would they be somehow persistent in
> the configuration? It seems that this and the previous idea are
> two different approaches to the same end ... an easy way for a user
> to enhance/alter a configuration via a scripting language ... is
> that correct?
Hi Joe,
I answered your question in the thread " Re: An idea for defining
custom valves in config.xml". Hope my answer there is helpful.
Thanks,
Gianny
>
> Joe
>
>
>> Thanks,
>> Gianny
>> On 11/10/2008, at 5:42 AM, Jason Dillon wrote:
>>> IMO, language is irrelevant. What you want to consider is what
>>> you want the scripting language to do for you... that is what is
>>> important. Basically (almost) any scripting language can be
>>> integrated (bsf or direct) but what is missing is the users use-
>>> cases for what the really want scripted.
>>>
>>> But.. users't don't always tell you want they want up front, they
>>> look at what you have and then complain when its broken wrt their
>>> own needs. So it might be worthwhile doing some POC work to add
>>> more scripting support. Though I don't think that web-app
>>> scripting crapski is the best way to provide that.
>>>
>>> If you think about it, there are a few uses for scripting in the
>>> application server's context. First is that the app developers
>>> prefer the language, but they still provide JavaEE muck to
>>> install/run. So we could reduce some footprint by providing
>>> plugins, but that not really that important, as the feature will
>>> still work w/o it. The second is where the application exposes
>>> some "configuration logic" which is intended to be easily
>>> augmented when installing/running the application. In this model
>>> part of the application's behavior is configured via some
>>> scripting language, which is intended to be changed (slightly or
>>> dramatically) to fit the application installations requirements.
>>> The third is where the application wants to provide an extensible
>>> action interface, so allow such an application to "do whatever it
>>> wants". For example, if an application supports some concept of
>>> "filtering", one might desire that the filter be implemented by a
>>> script which the administrator of the application could writte/
>>> configure.
>>>
>>> I'm sure I'm missing more examples, but it should be sufficient
>>> to point these out.
>>>
>>> Scripting is a very powerful way to extend you application, and
>>> I'm certainly a proponent. But what I'm having trouble realizing
>>> is... for a JavaEE application server, what/how/why would a
>>> developer want to script?
>>>
>>> --jason
>>>
>>>
>>> On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote:
>>>
>>>> ant elder wrote:
>>>>> On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard
>>>>> <bill@wstoddard.com <ma...@wstoddard.com>> wrote:
>>>>> Joe Bohn wrote:
>>>>> Any ideas on PHP and if this would be another potential
>>>>> area for
>>>>> integration?
>>>>> Python
>>>>> Joe
>>>>> Bill
>>>>> Also JavaScript with Rhino, and that gives you the big four -
>>>>> Groovy, JRuby, Rhino, and Jython. PHP would good but i've never
>>>>> found a PHP impl with Java integration and a compatible
>>>>> license. You can also use the JSR-223 APIs (Apache BSF) and get
>>>>> easy access to lots of lesser well known script language
>>>>> engines. I've done a bit with all those in Tuscany so will be
>>>>> interested to see what happens in Geronimo.
>>>>
>>>> Thanks for the input. Yes, I thought about BSF too. Regarding
>>>> the others languages (Python, Rhino, Jython and PHP) licenses
>>>> could be issues .... have to keep an eye on that. I thought
>>>> about BSF too ... need to do some more research there.
>>>> Actually, at this point it's all just some investigation and
>>>> we'll see where it goes.
>>>>
>>>> Joe
>>>
>
Re: Grails, JRuby on Rails, etc... scripting languages/environments
and Geronimo integration
Posted by Joe Bohn <jo...@earthlink.net>.
Gianny Damour wrote:
> Hi,
>
> I also do not see a lot of room for improvement in Grails integration.
> FWIW, in addition to the sample Grails application of the IBM article,
> the WADI administration console, a Grails Web-app, can be deployed
> out-of-the-box to Geronimo to introspect WADI clusters.
>
> I believe there is room for scripting languages in Geronimo.
>
> For instance, gshell users can source command files to automate some of
> their actions. A more powerful approach would be to provide scripting
> capabilities to gshell users. I believe, Groovy is an appropriate
> scripting language choice as it is very easy to learn for Java people.
>
> Another user case would be to use scripting to replace the serialized
> configuration, I mean the config.ser. An xmlbean serialization of
> configurations is way better than a native Java serialization as
> end-users can easily see and update values of serialized stuff. A YAML
> or even better a Groovy builder serialization would be way better than a
> xmlbean serialization. i would even go a step further and say that the
> geronimo DD could be replaced by scripts. A programmatic way to
> configure GBeans would be simpler. This could be a little bit like the
> programmatic servlet component configuration mechanism defined by the
> upcoming Servlet spec.
Sorry for the delayed response. I still haven't quite gotten my head
around this idea yet? Can you provide some more information on how this
would look and behave? I guess I need to take a look at the new Servlet
spec.
>
> A third example is to provide a simpler extension of configurations. The
> addition of a custom Tomcat valve to the tomcat6 config is a use case.
> When a configuration is started a script is executed to provide GBean
> overrides (add, update or remove) and dependencies overrides to the
> pre-canned configuration. In the scripting context, users have access to
> the pre-canned configuration and are able to return an altered one if
> they want.
This too is an interesting idea. Are you thinking that the extensions
would only live in the script and be executed each time the
configuration is started or would they be somehow persistent in the
configuration? It seems that this and the previous idea are two
different approaches to the same end ... an easy way for a user to
enhance/alter a configuration via a scripting language ... is that correct?
Joe
>
> Thanks,
> Gianny
>
> On 11/10/2008, at 5:42 AM, Jason Dillon wrote:
>
>> IMO, language is irrelevant. What you want to consider is what you
>> want the scripting language to do for you... that is what is
>> important. Basically (almost) any scripting language can be
>> integrated (bsf or direct) but what is missing is the users use-cases
>> for what the really want scripted.
>>
>> But.. users't don't always tell you want they want up front, they look
>> at what you have and then complain when its broken wrt their own
>> needs. So it might be worthwhile doing some POC work to add more
>> scripting support. Though I don't think that web-app scripting
>> crapski is the best way to provide that.
>>
>> If you think about it, there are a few uses for scripting in the
>> application server's context. First is that the app developers prefer
>> the language, but they still provide JavaEE muck to install/run. So
>> we could reduce some footprint by providing plugins, but that not
>> really that important, as the feature will still work w/o it. The
>> second is where the application exposes some "configuration logic"
>> which is intended to be easily augmented when installing/running the
>> application. In this model part of the application's behavior is
>> configured via some scripting language, which is intended to be
>> changed (slightly or dramatically) to fit the application
>> installations requirements. The third is where the application wants
>> to provide an extensible action interface, so allow such an
>> application to "do whatever it wants". For example, if an application
>> supports some concept of "filtering", one might desire that the filter
>> be implemented by a script which the administrator of the application
>> could writte/configure.
>>
>> I'm sure I'm missing more examples, but it should be sufficient to
>> point these out.
>>
>> Scripting is a very powerful way to extend you application, and I'm
>> certainly a proponent. But what I'm having trouble realizing is...
>> for a JavaEE application server, what/how/why would a developer want
>> to script?
>>
>> --jason
>>
>>
>> On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote:
>>
>>> ant elder wrote:
>>>> On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard <bill@wstoddard.com
>>>> <ma...@wstoddard.com>> wrote:
>>>> Joe Bohn wrote:
>>>> Any ideas on PHP and if this would be another potential area for
>>>> integration?
>>>> Python
>>>> Joe
>>>> Bill
>>>> Also JavaScript with Rhino, and that gives you the big four -
>>>> Groovy, JRuby, Rhino, and Jython. PHP would good but i've never
>>>> found a PHP impl with Java integration and a compatible license. You
>>>> can also use the JSR-223 APIs (Apache BSF) and get easy access to
>>>> lots of lesser well known script language engines. I've done a bit
>>>> with all those in Tuscany so will be interested to see what happens
>>>> in Geronimo.
>>>
>>> Thanks for the input. Yes, I thought about BSF too. Regarding the
>>> others languages (Python, Rhino, Jython and PHP) licenses could be
>>> issues .... have to keep an eye on that. I thought about BSF too ...
>>> need to do some more research there. Actually, at this point it's
>>> all just some investigation and we'll see where it goes.
>>>
>>> Joe
>>
>
>
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Gianny Damour <gi...@optusnet.com.au>.
Great! It seems that it is not yet enabled thought.
Thanks,
Gianny
On 11/10/2008, at 4:34 PM, Jason Dillon wrote:
> On Oct 11, 2008, at 7:07 AM, Gianny Damour wrote:
>> I also do not see a lot of room for improvement in Grails
>> integration. FWIW, in addition to the sample Grails application of
>> the IBM article, the WADI administration console, a Grails Web-
>> app, can be deployed out-of-the-box to Geronimo to introspect WADI
>> clusters.
>>
>> I believe there is room for scripting languages in Geronimo.
>>
>> For instance, gshell users can source command files to automate
>> some of their actions. A more powerful approach would be to
>> provide scripting capabilities to gshell users. I believe, Groovy
>> is an appropriate scripting language choice as it is very easy to
>> learn for Java people.
>
> GShell has had a BSF-driven 'script' command for a long time now ;-)
>
> --jason
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Jason Dillon <ja...@gmail.com>.
On Oct 11, 2008, at 7:07 AM, Gianny Damour wrote:
> I also do not see a lot of room for improvement in Grails
> integration. FWIW, in addition to the sample Grails application of
> the IBM article, the WADI administration console, a Grails Web-app,
> can be deployed out-of-the-box to Geronimo to introspect WADI
> clusters.
>
> I believe there is room for scripting languages in Geronimo.
>
> For instance, gshell users can source command files to automate some
> of their actions. A more powerful approach would be to provide
> scripting capabilities to gshell users. I believe, Groovy is an
> appropriate scripting language choice as it is very easy to learn
> for Java people.
GShell has had a BSF-driven 'script' command for a long time now ;-)
--jason
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
I also do not see a lot of room for improvement in Grails
integration. FWIW, in addition to the sample Grails application of
the IBM article, the WADI administration console, a Grails Web-app,
can be deployed out-of-the-box to Geronimo to introspect WADI clusters.
I believe there is room for scripting languages in Geronimo.
For instance, gshell users can source command files to automate some
of their actions. A more powerful approach would be to provide
scripting capabilities to gshell users. I believe, Groovy is an
appropriate scripting language choice as it is very easy to learn for
Java people.
Another user case would be to use scripting to replace the serialized
configuration, I mean the config.ser. An xmlbean serialization of
configurations is way better than a native Java serialization as end-
users can easily see and update values of serialized stuff. A YAML or
even better a Groovy builder serialization would be way better than a
xmlbean serialization. i would even go a step further and say that
the geronimo DD could be replaced by scripts. A programmatic way to
configure GBeans would be simpler. This could be a little bit like
the programmatic servlet component configuration mechanism defined by
the upcoming Servlet spec.
A third example is to provide a simpler extension of configurations.
The addition of a custom Tomcat valve to the tomcat6 config is a use
case. When a configuration is started a script is executed to provide
GBean overrides (add, update or remove) and dependencies overrides to
the pre-canned configuration. In the scripting context, users have
access to the pre-canned configuration and are able to return an
altered one if they want.
Thanks,
Gianny
On 11/10/2008, at 5:42 AM, Jason Dillon wrote:
> IMO, language is irrelevant. What you want to consider is what you
> want the scripting language to do for you... that is what is
> important. Basically (almost) any scripting language can be
> integrated (bsf or direct) but what is missing is the users use-
> cases for what the really want scripted.
>
> But.. users't don't always tell you want they want up front, they
> look at what you have and then complain when its broken wrt their
> own needs. So it might be worthwhile doing some POC work to add
> more scripting support. Though I don't think that web-app
> scripting crapski is the best way to provide that.
>
> If you think about it, there are a few uses for scripting in the
> application server's context. First is that the app developers
> prefer the language, but they still provide JavaEE muck to install/
> run. So we could reduce some footprint by providing plugins, but
> that not really that important, as the feature will still work w/o
> it. The second is where the application exposes some
> "configuration logic" which is intended to be easily augmented when
> installing/running the application. In this model part of the
> application's behavior is configured via some scripting language,
> which is intended to be changed (slightly or dramatically) to fit
> the application installations requirements. The third is where the
> application wants to provide an extensible action interface, so
> allow such an application to "do whatever it wants". For example,
> if an application supports some concept of "filtering", one might
> desire that the filter be implemented by a script which the
> administrator of the application could writte/configure.
>
> I'm sure I'm missing more examples, but it should be sufficient to
> point these out.
>
> Scripting is a very powerful way to extend you application, and I'm
> certainly a proponent. But what I'm having trouble realizing is...
> for a JavaEE application server, what/how/why would a developer
> want to script?
>
> --jason
>
>
> On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote:
>
>> ant elder wrote:
>>> On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard
>>> <bill@wstoddard.com <ma...@wstoddard.com>> wrote:
>>> Joe Bohn wrote:
>>> Any ideas on PHP and if this would be another potential
>>> area for
>>> integration?
>>> Python
>>> Joe
>>> Bill
>>> Also JavaScript with Rhino, and that gives you the big four -
>>> Groovy, JRuby, Rhino, and Jython. PHP would good but i've never
>>> found a PHP impl with Java integration and a compatible license.
>>> You can also use the JSR-223 APIs (Apache BSF) and get easy
>>> access to lots of lesser well known script language engines. I've
>>> done a bit with all those in Tuscany so will be interested to see
>>> what happens in Geronimo.
>>
>> Thanks for the input. Yes, I thought about BSF too. Regarding
>> the others languages (Python, Rhino, Jython and PHP) licenses
>> could be issues .... have to keep an eye on that. I thought about
>> BSF too ... need to do some more research there. Actually, at
>> this point it's all just some investigation and we'll see where it
>> goes.
>>
>> Joe
>
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by Jason Dillon <ja...@gmail.com>.
IMO, language is irrelevant. What you want to consider is what you
want the scripting language to do for you... that is what is
important. Basically (almost) any scripting language can be
integrated (bsf or direct) but what is missing is the users use-cases
for what the really want scripted.
But.. users't don't always tell you want they want up front, they look
at what you have and then complain when its broken wrt their own
needs. So it might be worthwhile doing some POC work to add more
scripting support. Though I don't think that web-app scripting
crapski is the best way to provide that.
If you think about it, there are a few uses for scripting in the
application server's context. First is that the app developers prefer
the language, but they still provide JavaEE muck to install/run. So
we could reduce some footprint by providing plugins, but that not
really that important, as the feature will still work w/o it. The
second is where the application exposes some "configuration logic"
which is intended to be easily augmented when installing/running the
application. In this model part of the application's behavior is
configured via some scripting language, which is intended to be
changed (slightly or dramatically) to fit the application
installations requirements. The third is where the application wants
to provide an extensible action interface, so allow such an
application to "do whatever it wants". For example, if an application
supports some concept of "filtering", one might desire that the filter
be implemented by a script which the administrator of the application
could writte/configure.
I'm sure I'm missing more examples, but it should be sufficient to
point these out.
Scripting is a very powerful way to extend you application, and I'm
certainly a proponent. But what I'm having trouble realizing is...
for a JavaEE application server, what/how/why would a developer want
to script?
--jason
On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote:
> ant elder wrote:
>> On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard <bill@wstoddard.com <mailto:bill@wstoddard.com
>> >> wrote:
>> Joe Bohn wrote:
>> Any ideas on PHP and if this would be another potential area
>> for
>> integration?
>> Python
>> Joe
>> Bill
>> Also JavaScript with Rhino, and that gives you the big four -
>> Groovy, JRuby, Rhino, and Jython. PHP would good but i've never
>> found a PHP impl with Java integration and a compatible license.
>> You can also use the JSR-223 APIs (Apache BSF) and get easy access
>> to lots of lesser well known script language engines. I've done a
>> bit with all those in Tuscany so will be interested to see what
>> happens in Geronimo.
>
> Thanks for the input. Yes, I thought about BSF too. Regarding the
> others languages (Python, Rhino, Jython and PHP) licenses could be
> issues .... have to keep an eye on that. I thought about BSF
> too ... need to do some more research there. Actually, at this
> point it's all just some investigation and we'll see where it goes.
>
> Joe
Re: Grails, JRuby on Rails, etc... scripting languages/environments
and Geronimo integration
Posted by Joe Bohn <jo...@earthlink.net>.
ant elder wrote:
>
>
> On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard <bill@wstoddard.com
> <ma...@wstoddard.com>> wrote:
>
> Joe Bohn wrote:
>
>
>
> Any ideas on PHP and if this would be another potential area for
> integration?
>
> Python
>
>
> Joe
>
> Bill
>
>
> Also JavaScript with Rhino, and that gives you the big four - Groovy,
> JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl
> with Java integration and a compatible license. You can also use the
> JSR-223 APIs (Apache BSF) and get easy access to lots of lesser well
> known script language engines. I've done a bit with all those in Tuscany
> so will be interested to see what happens in Geronimo.
Thanks for the input. Yes, I thought about BSF too. Regarding the
others languages (Python, Rhino, Jython and PHP) licenses could be
issues .... have to keep an eye on that. I thought about BSF too ...
need to do some more research there. Actually, at this point it's all
just some investigation and we'll see where it goes.
Joe
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard <bi...@wstoddard.com> wrote:
> Joe Bohn wrote:
>
>>
>>
>> Any ideas on PHP and if this would be another potential area for
>> integration?
>>
> Python
>
>
>> Joe
>>
>> Bill
>
Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby,
Rhino, and Jython. PHP would good but i've never found a PHP impl with Java
integration and a compatible license. You can also use the JSR-223 APIs
(Apache BSF) and get easy access to lots of lesser well known script
language engines. I've done a bit with all those in Tuscany so will be
interested to see what happens in Geronimo.
...ant
Re: Grails, JRuby on Rails, etc... scripting languages/environments
and Geronimo integration
Posted by bill stoddard <bi...@wstoddard.com>.
Joe Bohn wrote:
>
>
> Any ideas on PHP and if this would be another potential area for
> integration?
Python
>
> Joe
>
Bill