Announcement Announcement Module
Collapse
No announcement yet.
Tomcat Redeploy fails if AOP is used. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tomcat Redeploy fails if AOP is used.

    Hello all.
    I have a very strange problem, and although I am almost sure where it lies, I have had absolutely no success in solving this issue.

    I have a .war application.
    I am using a generic approach for persistance via an AOP Introduction DAO implementations.

    However using AOP (and generating classes with it) renders the application unremovable. It seems that the framework (or the JVM in any case) holds references to the classes used in the AOP proxy, and when I try to undeploy the application, I get an error, because the .jar files in the WEB-INF/lib are held referenced, and can not be deleted. So when I undeploy the application I get the two .jars (one with the Introduction Interceptor implementation .class, and the other with the introduced interface .class) left in the deployment directory breaking any further attempts to (re)deploy the application. No other .jars are left in the WEB-INF/lib directory. The spring, hibernate, cglib and all other framework .jars get correctly removed with obviously no stale handlers.
    Calling GC prior to undeploying the app makes no difference. Calling the GC after the undeploying makes no difference also. Calling both GC both before and after renders the same issue.

    The only available fix/workaround is to completely shutdown Tomcat, manually remove the deployment directory, and startup Tomcat afterwards, which is obviously extremely time-hungry and very, very frustrating.

    So the question itself: What Is Going On? Is it really an issue with the dynamic class generation? Or did I do something wrong? Can I fix it? Any pointers?

  • #2
    There are several reasons for this problems - I know a recent (1 or 2 weeks ago) thread on the Hibernate Forums related to OutOfMemory Exceptions and hot redeploy on Tomcat.
    One alternative is to remove as many libraries as you can from your webapp level and place them into the shared directory (thus they will be loaded only once and will be available to all the web-apps).
    This should alleviate your problems to some extent. What versions of Tomcat and Spring are you using?

    Comment


    • #3
      More data

      Originally posted by costin
      There are several reasons for this problems - I know a recent (1 or 2 weeks ago) thread on the Hibernate Forums related to OutOfMemory Exceptions and hot redeploy on Tomcat.
      I've had a TON of these... Not latel;y however, because I am forced to restart Tomcat after redeploy.

      Originally posted by costin
      One alternative is to remove as many libraries as you can from your webapp level and place them into the shared directory (thus they will be loaded only once and will be available to all the web-apps).
      That would be difficult
      The .jars that are left in the deployment directory are actualy modules of my application. They too contain spring.xml files, and my context is generated from all the descriptors I can find in the app. However I have had some issues with the class*:any-resource-name not locating resources from the shared or common lib directories in Tomcat (I am still struggling to find out the exact reason).
      I also have another problem: the classes in these jars depend heavily on the Spring AOP framework, and because of that if I put these .jars in common or shared, I am also forced to put there almost everything Spring requires, rendering my application almost empty.
      I should also specify, that I am trying to redeploy BECAUSE of changes in the named .jars. Not in the .jsps.

      Originally posted by costin
      This should alleviate your problems to some extent. What versions of Tomcat and Spring are you using?
      Spring: 1.1.1 with all the libs (including hibernate) from the lib directory of the distro.
      Apache Tomcat/5.0.27.

      EDITED SOME HOURS LATER: This MIGHT! have something in relation to the fact, that my proxy factory is abstract with 'children'...
      Code:
      	<!-- ABSTRACT AutoDAO used as a base for real DAO implementations -->
        <bean name="abstractAutoDAO" lazy-init="true" class="org.springframework.aop.framework.ProxyFactoryBean" abstract="true">
          <property name="interceptorNames">
            <list>
             <value>autoDAOInterceptor</value>
            </list>
          </property>
          <property name="optimize">
            <value>true</value>
          </property>
          <property name="target">
            <bean class="java.lang.Object"/>
          </property>
        </bean>
      
      ...
      
        <bean name="clientsDAO" id="clientsDAO" parent="abstractAutoDAO">
          <property name="proxyInterfaces">
            <list>
              <value>...DAOClients</value>
            </list>
          </property>
          <property name="target">
            <ref local="clientsDAOTarget"/>
          </property>
        </bean>

      Comment

      Working...
      X