6 Replies Latest reply on Apr 18, 2007 9:40 AM by Pete Muir

    inconsistent behaviour

    Levent Aksu Newbie

      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

        • 1. Re: inconsistent behaviour
          Jim Hazen Expert

          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.

          • 2. Re: inconsistent behaviour
            Shane Bryzak Master

            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.

            • 3. Re: inconsistent behaviour
              Levent Aksu Newbie

              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?

              • 4. Re: inconsistent behaviour
                Pete Muir Master

                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

                • 5. Re: inconsistent behaviour
                  Levent Aksu Newbie

                  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?

                  • 6. Re: inconsistent behaviour
                    Pete Muir Master

                    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