dev@javaserverfaces.java.net

RE: issue 1655 (Groovy support)

From: Manfred Riem <mriem_at_manorrock.org>
Date: Sun, 11 Jul 2010 09:39:13 -0600

Mmmm,

 

OK that to me seems awkward, putting something into another class loader to

make it work. I wonder what kind of other issues that would/could trigger
with

other deployed applications and or parts of the Glassfish runtime.

 

Note in Ryan's example you have the choice of copying it into the lib
directory

of the application server, or to ship in in the WEB-INF/lib directory. I
prefer

the WEB-INF/lib directory since that keeps it isolated from other
applications.

 

So please test that scenario as well.

 

Thanks,

Manfred

 

From: Sheetal Vartak [mailto:sheetal.vartak_at_oracle.com]
Sent: Sunday, July 11, 2010 9:33 AM
To: moritzthielcke2_at_dev.java.net
Cc: dev_at_javaserverfaces.dev.java.net
Subject: issue 1655 (Groovy support)

 

Hello,

 

I am trying to fix the above issue 1655 where it has been reported that
Groovy support with Mojarra is currently broken. I have written a simple
devtest which I am attaching here. I have'nt yet checked in the code. But I
will appreciate if you can try out this test by simply deploying it to you
application server install. I have tried this with Glassfish and it seems to
work for me. Please share your findings with us.

 

Here's what I did to get this working :

 

1> added the asm related jars and groovy*.jar from Groovy 1.7.3 to the
<glassfish-install-dir>/lib

2> added an ant task "groovyc" to the systest-per-webapp/build.xml in order
to compile the .groovy files (This according to Ryan is not necessary since
Groovy supports dynamic loading)

3> converted my managedbean java class into a groovy script
(HelloBean.groovy)

4> modified the web.xml to include what Ryan has pointed out in his blog
http://blogs.sun.com/rlubke/entry/groovy_mojarra

This step takes care of the classloading issue that could crop up.

 

Attaching the war as well as the sources.