inconsistent behaviour

[laksu]

I have an app with following:
Seam 1.2.1GA
Facelets 1.1.12
SJSAS Platform Edition 9.0_01 (build b02-p01)
Hibernate

I am able to run the app perfectly but at some runs, randomly, I get something like the following. I rerun, redeploy, restart server randomly (I cannot find a consistent pattern to resolve) and it eventually starts to run correctly again. Then after a few cycles of develop-compile-run I hit it again.
My best guess is some things in the application server are initialized asynchronously so that sometimes my app cannot find the bean thru jndi. I can not think of a way to resolve this. Any ideas.


org.jboss.seam.InstantiationException: Could not instantiate Seam component: isteklerAction
at org.jboss.seam.Component.newInstance(Component.java:1740)
at org.jboss.seam.Component.getInstance(Component.java:1643)
at org.jboss.seam.Component.getInstance(Component.java:1610)
at org.jboss.seam.Component.getInstance(Component.java:1604)
at org.jboss.seam.jsf.SeamELResolver.getValue(SeamELResolver.java:49)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:62)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:68)
at com.sun.el.parser.AstValue.getValue(AstValue.java:107)
at com.sun.el.parser.AstEqual.getValue(AstEqual.java:41)
at com.sun.el.parser.AstOr.getValue(AstOr.java:41)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192)
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:402)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer$RenderedChildIterator.update(HtmlBasicRenderer.java:673)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer$RenderedChildIterator.next(HtmlBasicRenderer.java:658)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:153)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:828)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:232)
at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:277)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:828)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:883)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:137)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:828)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:883)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:889)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: datassist/gop/action/IsteklerActionLocal
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:342)
at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:312)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:271)
at org.jboss.seam.Component.createProxyFactory(Component.java:1979)
at org.jboss.seam.Component.getProxyFactory(Component.java:1154)
at org.jboss.seam.Component.wrap(Component.java:1145)
at org.jboss.seam.Component.instantiateSessionBean(Component.java:1108)
at org.jboss.seam.Component.instantiate(Component.java:1093)
at org.jboss.seam.Component.newInstance(Component.java:1736)
... 54 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: datassist/gop/action/IsteklerActionLocal
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:165)
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:337)
... 62 more
Caused by: java.lang.NoClassDefFoundError: datassist/gop/action/IsteklerActionLocal
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:177)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 63 more

[cptnkirk]

Doing a lot of hot deploy? I usually find when things are screwy like this there's a permgen memory error at the very bottom of that stack trace. A restart of the app server causes the problem to go away.

I've recently migrated to JRocket R27.2 and haven't had any trouble so far. JRocket does a much better job than Sun's JVM with permgen clean up. Bascially I think they put it on the heap and clean up normally. If you do try JRocket, go with only R27.2, R27.1 had a ton of problems.

[shane.bryzak]

You can adjust the MaxPermSize by adding the following Java options:

-XX:PermSize=256m -XX:MaxPermSize=512

See the Getting Started chapter in the Seam documentation for more details.

[laksu]

I have had that already and it even may (and usually does) give the error at the very first run. And there never is a permGen error in the log.
I am not sure but I am relating it with me moving the library jars out of the project (to have a smaller .ear file) and adding these jars to the application server's classpath.
I also have not managed log4j to find log4j.properties and initialize properly and after a lot of googling I have a feeling that it may be something to do with the class loader. There I have really near-to-zero knowledge about class loaders and about how an application server employs one (or many)
Anything?

[pmuir]

It's a really bad idea to start randomly putting libs into the AS. Seam is tested with everything packaged into the ear/war (you can just grab a clean copy of your AS and put the ear in) - by following some other packaging structure you loose the benefit of all that testing :( Follow the packaging structure of the examples/seam-gen

[laksu]

Oops! All I meant was to speed up while developing. That turns into a different subject now but please bear with me: I wish to know how you guys out there handling this.
In the case I put things into the war/ear's lib I have a large file and that slows down build-deploy-run cycle. Just because it zips and unzips. And that specifically seems to take more time with NetBeans-JBoss combination: It removes the .ear to undeploy, then copies the new .ear and then JBoss unzips it and reinitialize everything and run. All of these take a really long time.
With Netbeans-SJSAS however it does something more like an incremental deployment. It takes significantly less time. The difference was so significant that I switched to SJSAS and abandoned JBoss. Then I managed to even improve the deploy time further by taking the seam jars and hibernate jars (with SJSAS I have to ship hibernate jars as I want hibernate for the persistence) out of the project's war/ear and added those jars' paths to the server classpath (not copied them into the lib dir)
Now you say that this is useless/unconventional/not recommended so I wonder how people go along with the development cycle. Doesn't it take a huge time, say correcting a typo and re-run?

[pmuir]

I use exploded deployment as set up by seam-gen - this avoids the zip/unzip time you mention and gives you the ability to change view files without a restart. AFAIK seam-gen works with netbeans ootb