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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
