2 Replies Latest reply on Apr 7, 2005 10:19 AM by starksm64

    Is org.jboss.util.loading.Translator still used?

    starksm64

      Is the org.jboss.util.loading.Translator still used for bytecode manipulation under jdk 1.4.x? The reason for defaulting the web container class loader to a UCL was to allow for the use of aop in web apps, but this is causing problems when you have multiple web apps with jsp pages with the same names due to the fact that they map to the same class name.

        • 1. Re: Is org.jboss.util.loading.Translator still used?
          bill.burke

          Yes, it is still being used under jdk 1.4.x. The only way I can get around it is to hack java.lang.CLassLoader and insert it into the bootclasspath. I don't think we want to recommend such an option as Sun will be all over us with.

          FYI, we don't use Translator with JDK 5.0 as we recommend the javaagent stuff.

          I don't see what the problem is though. Why can't you create a HierarchicalClassLoader for webapps and have that implement HierarchicalClassLoader? This might require some refactoring of AOP as I think I call a method on the LoaderRepository to set the Translator. In other words, I'll need a generic way to set the Translator for the entire VM.

          • 2. Re: Is org.jboss.util.loading.Translator still used?
            starksm64

            The ULR is a deployment level configuration. The only way two wars in an ear can be isolated today is if they use independent class loaders and these are not jboss class loaders. They can be which is why I was asking if Translator was required to interact with aop.