Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=btM2GFhOT94VAkmbdXY2tz1n6xNaz3iKMPbuDYfFzWYwtvc/mpW5JlXsiz8zI1/o;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <48F744B0.9040509@earthlink.net>
Date: Thu, 16 Oct 2008 09:42:08 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Grails, JRuby on Rails, etc... scripting languages/environments
 and Geronimo integration
References: <48EE775B.10506@earthlink.net> <48EE79D6.60103@wstoddard.com>
 <71e1b5740810100645p76040ff3q25c676d2d275672a@mail.gmail.com>
 <48EF9B59.1070908@earthlink.net>
 <C92BB44D-A9FC-4B2F-BB22-770D4CDB1CB8@gmail.com>
 <F9C4AD94-5A5F-45F2-B5CB-114E3C92ED25@optusnet.com.au>
In-Reply-To: <F9C4AD94-5A5F-45F2-B5CB-114E3C92ED25@optusnet.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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