geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Date Sat, 11 Oct 2008 00:07:16 GMT
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 <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
>


Mime
View raw message