geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Date Sat, 18 Oct 2008 00:13:15 GMT
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.


> 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  
>>>>> < <>> 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

View raw message