5 Replies Latest reply on Sep 21, 2004 9:07 AM by kirillp

    development on JBoss

    kirillp

      Hello,

      We're developing an application on JBoss using Eclipse. The application includes JSP pages, Hibernate, Stateless Session Beans, and Entity Beans.

      We are using an ant build script for deployment. The problem is that any minor change in any part of the project requires that we restart the JBoss server (sometimes the Hotdeploy does not work properly... even if it does, the hot deployment takes a while).

      Are there any ways to speed up the process, specifically:

      1. When a JSP file is edited, no need to redeploy the entire application...
      2. If a Java file is changed, it needs only to be recomplied
      3. If a Hibernate mapping/class is changed, no need to redeploy the application, only recompilation.

      Any ideas, best practices?

      Thanks!

        • 1. Re: development on JBoss
          min-changcha

          Hi Estoty

          I don`t have enough knowledge to help you.
          Even so, I recommend to separate tomcat and jboss to you.
          It means you don`t restart jboss when jsp or servlet on tomcat have changed.
          Because tomcat supports auto reloading of classes.

          After it is separated, you may call ejb components on tomcat and use it.(In this case, ejb components run on jboss.)

          • 2. Re: development on JBoss
            min-changcha

            After it is separated, you may call ejb components on tomcat and use it.(In this case, ejb components run on jboss.)

            ->

            After it is separated, On tomcat, you may call ejb components and use it.

            • 3. Re: development on JBoss
              frito

              Which JBoss version are you using?
              Working around this problem may help you right now.
              But if hot redeployment doesn't work try this:

              "doensn't work" means an error occurs in the log while deploying or on runtime afterwards? Investigate for the reason (take a look at the classloaders used for the deployment units).
              If you find out something that should work, ask again in this forum describing exactly what you are trying to do and the configuration (e.g. war and ear with ejbs in the same loader repository...)
              provide a (small) testcase which reproduces the problem and report a bug on sourceforge

              All this will help yourself to solve the problem and all other users and developers of JBoss.

              • 4. Re: development on JBoss
                lretief

                Separating Tomcat and JBoss onto separate VM's could cause significant performance degradation, so I would not recommend that as a workaround.

                Rather solve the problem by providing us with the information Frito requested.

                • 5. Re: development on JBoss
                  kirillp

                  Hello,

                  Thanks for your replies.

                  "Does not work" means that Hibernate mappings are scrambled for some reason. This is the error trace:

                  09-21-2004 14:49:56 ERROR STDERR - net.sf.hibernate.MappingException: No persister for: data.settings.pojo.LayoutTheme
                  at net.sf.hibernate.impl.SessionFactoryImpl.getPersister(SessionFactoryImpl.java:347)
                  at net.sf.hibernate.impl.SessionImpl.getClassPersister(SessionImpl.java:2690)
                  at net.sf.hibernate.impl.SessionImpl.assembleCacheEntry(SessionImpl.java:2129)
                  at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2112)
                  at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1991)
                  at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1953)
                  at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:69)
                  at net.sf.hibernate.type.EntityType.resolveIdentifier(EntityType.java:204)
                  at net.sf.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:2205)
                  at net.sf.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:315)
                  at net.sf.hibernate.loader.Loader.doQuery(Loader.java:305)
                  at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:133)
                  at net.sf.hibernate.loader.Loader.doList(Loader.java:1033)
                  at net.sf.hibernate.loader.Loader.list(Loader.java:1024)
                  at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:854)
                  at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1544)
                  at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1521)
                  at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1517)
                  at net.bookingasp.action.LogonAction.execute(LogonAction.java:81)
                  at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
                  at com.livinglogic.struts.workflow.WorkflowRequestProcessor.processActionPerform(WorkflowRequestProcessor.java:158)
                  at com.livinglogic.struts.workflow.WorkflowRequestProcessorLogic.process(WorkflowRequestProcessorLogic.java:568)
                  at com.livinglogic.struts.workflow.WorkflowRequestProcessor.process(WorkflowRequestProcessor.java:179)
                  at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
                  at net.bookingasp.ActionServlet.process(ActionServlet.java:24)
                  at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
                  at net.bookingasp.framework.filters.JaasLoginFilter.doFilter(JaasLoginFilter.java:55)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
                  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
                  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
                  at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
                  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
                  at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:277)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:80)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
                  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
                  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:122)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
                  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
                  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                  at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
                  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
                  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
                  at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
                  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
                  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:702)
                  at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
                  at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644)
                  at java.lang.Thread.run(Thread.java:534)

                  I'm using the following JBoss version

                  JBoss (MX MicroKernel) [4.0.0DR4 (build: CVSTag=HEAD date=200405190212)]

                  I know that JBoss 4 Final has been released since a day or two, so if you really think the problem lies therein, I shall install the latest version.

                  But actually the question is wider, it concerns not only JBoss deployment, but in general efficient development on JBoss. You already suggested the separation of Tomcat & Jboss, I've given some thought to that too, however the source tree is complicated, and the separation of JBoss and Tomcat will be painful. A few things are not going to be working under that structure, so a lot of re-coding will have to be done.

                  Some sort of exploded directory would be real nice... The information that I found on the JBoss site is scarce, and I was wondering if someone could give me pointers to the best-practice implementation of this, in Eclipse.

                  Thanks!