groovy scripted nanocontainer fails in servlet context

And you are really really sure, that all jars are in correct version,
and you did not got bogus snapshot from codehaus.net ?

I'm positive. I built off the latest CVS and things work just fine if I provide a ContainerComposer class. And keep in mind that the Groovy method is found just fine the first time, so it isn't like it isn't working at all. It seems to me that it won't allow the compositionScope parameter to be different types in multiple calls. I'm really not sure???

Anyway, here's a .war file you can test things on. It has all required dependencies in WEB-INF/lib. You be the judge as to whether they are up to date. The web.xml is set up to use the "nanocontainer.groovy" context param with the goovy script. That will fail upon request of index.jsp (actually upon attempted building of the request scope container in the servlet filter). To see the app actually work, comment out the "nanocontainer.groovy" context param and uncomment the "org.nanocontainer.integrationkit.ContainerComposer" context param. That one will work just fine proving that there is nothing wrong with the application itself, just the Groovy side of things.

Jake

Ok, I've got a little more info. I put the following in GroovyContainerBuilder.createContainer()...

System.out.println("Groovy class is: " + groovyClass.getName());
System.out.println("Groovy script reader hash is: " + script);

I wanted to make sure that the class name was the same each time and that the stored script (actually a StringReader containing the contexts of the script) was the same each time. The script was the same (same hashcode every time), but the name of the class was different.

Here's the result the first time (and buildContainer() in "DemoBuilder" is found and called properly....

Groovy class is: DemoBuilder
Groovy script reader hash is: java.io.StringReader@1554233

Here's the result any time after the first time above (and I get exceptions from Groovy saying buildContainer() in "nanocontainer" can't be found)....

Groovy class is: nanocontainer
Groovy script reader hash is: java.io.StringReader@1554233

I can't quite figure out how that could be? How could the same script result in different class names? And not only that, but also (every time after the first call to createContainer()) in a generated Java class which doesn't contain the appropriate buildContainer(parent, compositionScope) signature????

I'm not sure if this is the fault of Groovy or something in Nanocontainer, but now I'm leaning more toward Groovy itself.

Thoughts?

Jake

Ok, I think I've figured it out. The problem happens because the GroovyClassLoader is newly created each time and, somehow, the second time loading, there exists a reference in the GroovyClassLoader cache, a field named "nanocontainer.groovy" which has a "main" and "run" methods. Not sure which class that is. Well, that last part is speculation, but what fixes the issue is this...

Modfy the constructor from this....

public GroovyContainerBuilder(Reader script, ClassLoader classLoader)

To this....

public GroovyContainerBuilder(Reader script, ClassLoader classLoader)

And then when we reference the classloader to use Groovy-specific mehods, we cast it to a GroovyClassLoader like this...

GroovyClassLoader loader = (GroovyClassLoader)classLoader;

This way, the GroovyClassLoader's "cache" field will continue to contain a reference to the pre-built script. I no longer get a "nanocontainer" class coming back after the first time the GroovyContainerBuilder.createContainer() is called. I get the DemoBuilder class defined in my script. Great!....of course now I've run into another issue. I get the following stack trace...

org.picocontainer.defaults.UnsatisfiableDependenciesException: java.lang.Class doesn't have any satisfiable constructors. Unsatisfiable dependencies: []
at org.picocontainer.defaults.ConstructorComponentAdapter.getAllSatisfiableConstructors(ConstructorComponentAdapter.java:117)
at org.picocontainer.defaults.ConstructorComponentAdapter.getGreediestSatisifableConstructor(ConstructorComponentAdapter.java:63)
at org.picocontainer.defaults.ConstructorComponentAdapter.getMostSatisfiableDependencyTypes(ConstructorComponentAdapter.java:57)
at org.picocontainer.defaults.InstantiatingComponentAdapter.getMostSatisifableDependencyAdapters(InstantiatingComponentAdapter.java:76)
at org.picocontainer.defaults.InstantiatingComponentAdapter.getComponentInstance(InstantiatingComponentAdapter.java:44)
at org.picocontainer.defaults.DecoratingComponentAdapter.getComponentInstance(DecoratingComponentAdapter.java:41)
at org.picocontainer.defaults.CachingComponentAdapter.getComponentInstance(CachingComponentAdapter.java:37)
at org.picocontainer.defaults.DefaultPicoContainer.getComponentInstance(DefaultPicoContainer.java:248)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:58)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
at org.nanocontainer.servlet.ServletRequestContainerFilter.doFilter(ServletRequestContainerFilter.java:37)

Here's my groovy script. Anyone see a problem with it????

import org.picoextras.servlet.sample.SomeRequestUtil
import org.picoextras.servlet.sample.SomeCounter

class DemoBuilder {
buildContainer(parent, compositionScope) {
pico = new org.picocontainer.defaults.DefaultPicoContainer(parent)
if (compositionScope instanceof javax.servlet.ServletRequest)

else if (compositionScope instanceof javax.servlet.http.HttpSession)

else if (compositionScope instanceof javax.servlet.ServletContext) {
}
else {
}
return pico
}
}

Looks like I spoke to soon. My last problem was a Groovy syntax problem. In my Groovy script I provided something like the following...

pico.registerComponentImplementation("util", SomeRequestUtil.class)

Apparently, anything provided with ".class" in Groovy is seen as a plain java.lang.Class object. All I had to do was remove the ".class" like this...

pico.registerComponentImplementation("util", SomeRequestUtil)

Everything works now, so, my fix was a good one!!!! Patch coming up.

Jake

Patch that fixes the reported issue!

Jake

I haven't applied the patch, but I have done some simplifying changes to the groovy and webwork stuff.

Could you please try again and see whether it works now?

P.S. Please read the updated doco:

http://docs.codehaus.org/display/NANO/NanoContainer
http://docs.codehaus.org/display/NANO/NanoContainer+WebWork
http://docs.codehaus.org/display/NANO/NanoContainer+Servlet

D.S.

Yep, I actually figured this out on my own after all the changes and hadn't gotten around to mentioning that here. However, I am also seeing another issue where when using System.out.println() anywhere in the script and running under Tomcat (not sure if the issue happens in other containers?), I get the following stack trace. This wasn't happening when the script had to be a class that implemented the method buildContainer(parent, assemblyScope). I was able to System.out to my heart's desire at that time.

I'm not sure whether this should be considered a Nanocontainer issue or a Groovy project issue. If it is a Groovy project issue, please close this and I'll report it in Groovy's Jira. Anyway, here's the stack trace....

2004-02-19 22:05:48 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.NoClassDefFoundError: org/apache/tomcat/util/log/SystemLogHandler
at org.apache.tomcat.util.log.SystemLogHandler$GroovyReflector.invoke(SystemLogHandler$GroovyReflector.java)
at groovy.lang.MetaMethod.invoke(MetaMethod.java:84)
at groovy.lang.MetaClass.doMethodInvoke(MetaClass.java:830)
at groovy.lang.MetaClass.invokeMethod(MetaClass.java:242)
at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:130)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:101)
at nanocontainer.run(nanocontainer.groovy:15)
at org.nanocontainer.script.groovy.GroovyContainerBuilder.createContainerFromScript(GroovyContainerBuilder.java:57)
at org.nanocontainer.script.ScriptedContainerBuilder.createContainer(ScriptedContainerBuilder.java:37)
at org.nanocontainer.integrationkit.LifecycleContainerBuilder.buildContainer(LifecycleContainerBuilder.java:24)
at org.nanocontainer.servlet.ServletRequestContainerLauncher.startContainer(ServletRequestContainerLauncher.java:48)
at org.nanocontainer.servlet.ServletRequestContainerFilter.doFilter(ServletRequestContainerFilter.java:36)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:233)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)

Jake

Upon further investigation I've found that moving back to groovy-beta3 fixes the issue. I have been using the very latest Groovy CVS and it looks like there is a regression of some sort. I'll close this and report it as a Groovy issue.

Jake

Resolved now as reported by Jake