3 Replies Latest reply on Aug 8, 2006 4:39 PM by starksm64

    Real classloader required before WAR startup

    bill.burke

      I'm running into a Catch 22 in integrating the EE5 injection stuff I'm doing. I need a classloader set up and initialized before the start of the Web container so that I can scan classes for annotations and set up any XML injeciton targets . This classloader needs to be the same classloader that will be used by the servlet container to instantiate servlets. The problem is that the classloader, currently, is not created until the web container is initialized and I need to set up the ENC and injeciton targets before the container is initialized.

      This is a bit a function of how I implemented the injection code. It pre-initializes all the injection target information by setting up lists of reflection objects that will be used to do the injection.

        • 1. Re: Real classloader required before WAR startup
          starksm64

          In the old deployment impl that was the purpose of the DeploymentInfo.localCl. However it had no integration with other deployment contexts. In the new vdf you should be able to scan for classes/resources using the vfs. This should be a common aspect that all deployers used to build up the deployment metadata from classes and xml descriptors.

          • 2. Re: Real classloader required before WAR startup
            bill.burke

            Is there any reason we couldn't set up the appropriate classloaders before scanning for dependencies? I guess what i'm saying is that I don't want to use Javassist and a throwaway Resource classloader and that I'd rather use reflection and the real classloader that is going to be used by the application.

            Eh, maybe I'm just being lazy, but I just spent a bunch of time refactoring the injection code and I don't want to do it again.

            • 3. Re: Real classloader required before WAR startup
              starksm64

              The scan of the deployment in the vdf happens during the analyze phase so that the result and associated management objects are available to the profileservice. There may not be a meaningful deployment class loader as the deployment processing can be run offline. Anything you are doing now under the current trunk branch is going to have to be ported to the virtual deployment framework based deployers.