Uploaded image for project: 'Tapestry'
  1. Tapestry
  2. TAPESTRY-1631

tapestry-spring initializes lazy-init beans too soon



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.5
    • Fix Version/s: 5.0.6
    • Component/s: tapestry-spring
    • Labels:
    • Environment:
      Spring 2.0.4


      We have some spring beans which are intended for various environments, so we can have a weblogic transaction manager configured in a weblogic container, but not when we run inside the Jetty container. To achieve this, we mark these beans with the lazy-init=true attribute.
      Starting in tapestry-spring 5.0.5, all of our spring beans get initialized at startup, including the weblogic transaction manager., which results in a ClassNotFoundException.
      In SpringModuleDef.java, there is a method in the ModuleDef which looks like:
      public Class getServiceInterface()

      { return getBean().getClass(); }

      The call to getBean() causes the bean to be instantiated, and hence triggers the CNFE. I have taken the liberty of patching this code, so that this method makes a call to _context.getType(beanName) through an additional method getBeanType() that I added.
      This change passes the testing in maven, and after it is installed in my local Maven repository, my application runs!
      My only concern is that my code change is sending to Tapestry the type that Spring thinks the bean is, rather than the actual Class of the bean. I expect that means that proxies will look to Tapestry like the proxied type, instead of the actual class of the proxy.
      I have a very simple subversion patch that I will try to attach to this report.


        1. tapestry-spring-1631.patch
          1.0 kB
          Nick James



            • Assignee:
              hlship Howard Lewis Ship
              nickj Nick James
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: