Problem when using weblogic.jspc from an IDE

Question

I am trying to call JSPC from an IDE (as part of an Eclipse Builder). To optimize performance I want to avoid to spwan a new process. So I am trying to call weblogic.jspc's main method directly from the IDE. Everything works fine for simple simple pages.
          But when the page refers to a tag library with a tag providing a TagExtraInfo class, weblogic.jspc complains about the class not extending the TagExtraInfo base class although it does:
          Errors encountered while compiling 'D:\vrp-localdeploy\applications\wot\WOT' :
          Translation of /rentalcar/tiles/i18n/CarCapacityView.jsp failed: (line 17): Error in using tag library uri='/tags/i18n' prefix='i18n': For tag 'bundle', extra info class 'org.apache.taglibs.i18n.BundleTEI' does not extend javax.servlet.jsp.tagext.TagExtraInfo
          I could not figure out what exactly causes the problem. Using exactly the same settings workes just fine.
          Any suggestions?

Answer 1

The full stack trace reads as follows:
          <p>
          Errors encountered while compiling 'D:\vrp-localdeploy\applications\wot\WOT' :
          <p>
          Translation of /common/include/i18n/definitions.inc failed: (line 17): Error in using tag library uri='/tags/i18n' prefix='i18n': For tag 'bundle', extra info class 'org.apache.taglibs.i18n.BundleTEI' does not extend javax.servlet.jsp.tagext.TagExtraInfo
          <br>
               at weblogic.jspc.runJspc(jspc.java:559)
               at weblogic.jspc.runBodyInternal(jspc.java:410)
               at weblogic.jspc.runBody(jspc.java:319)
               at weblogic.utils.compiler.Tool.run(Tool.java:146)
               at weblogic.utils.compiler.Tool.run(Tool.java:103)
               at weblogic.jspc.main(jspc.java:708)
               at tui.vrp.tools.presentation.builder.PresentationBuilder.compileJSP(PresentationBuilder.java:1173)
               at tui.vrp.tools.presentation.builder.PresentationBuilder.checkResource(PresentationBuilder.java:718)
               at tui.vrp.tools.presentation.builder.PresentationBuilder$PresentationDeltaVisitor.visit(PresentationBuilder.java:102)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:77)
               at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49)
               at tui.vrp.tools.presentation.builder.PresentationBuilder.incrementalBuild(PresentationBuilder.java:1268)
               at tui.vrp.tools.presentation.builder.PresentationBuilder.build(PresentationBuilder.java:677)
               at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:593)
               at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
               at org.eclipse.core.runtime.Platform.run(Platform.java:783)
               at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:168)
               at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:202)
               at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:231)
               at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
               at org.eclipse.core.runtime.Platform.run(Platform.java:783)
               at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:234)
               at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:253)
               at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:282)
               at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139)
               at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200)
               at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
          <p>
          Unfortunately it doesn't really give any real reason - it is a general piece of code in jspc to report problems.
          <p>
          But I dug a lot bit deeper into the code and realized that the original problem is a ClassCastException in line 1290 of class StandardTagLib, which reads as follows:
          <p>
               tagextrainfo = (TagExtraInfo)Beans.instantiate(classloader, s3);
          <p>
          This looks quite obvious that the class named by s3 simply is no extension of TagExtraInfo, but unfortunately the only class with that name being referenced by the class path does extend this class. I wondered what the problem might be and came up with the following answer:
          <p>
          The class of the bean instantiated by Beans.instantiate extends a class with the name "javax.servlet.jsp.tagext.TagExtraInfo" which is cast to another class with exactly <b>the same name, but a different class loader</b>. Since neither of the class loaders is parent of the other one, both classes are not considered being the same class although they have the same name. Sounds weird, but exactly this is the problem!
          <p>
          Where does it come from and why it works fine when the tool is executed in a separate thread or on the console?
          <p>
          From my understanding the problem is caused in line 395 of the class weblogic.jspc:
          <p>
               GenericClassLoader genericclassloader = new GenericClassLoader(classpathclassfinder);
          <p>
          This line of code creates a class loader not knowing a parent class loader by which the class weblogic.jspc was loaded. All classes weblogic.jspc is using or calling will be loader by either the same or a parent class loader - this is important to understand. Since TagExtraInfo is directly referenced by StandardTagLib one instance of the class object (the object of type class) will be generated and linked when the class StandardTagLib is instantiated for the first time by the class loader which loaded weblogic.jspc (or by its parent). This is consequence which can not be avoided.
          <p>
          But now look at line 1290 of class StandardTagLib: It explicitly requests the class to be loaded by the GenericClassLoader instantiated in line 395 of the class weblogic.jspc. This class loader, off course, is not aware of the same class just being loaded by another class loader since it has no knowledge of it. It simply creates a fresh copy of the class object, which only differs in the reference to the class loader which created this class object.
          <p>
          Actually, I figured that the following line of code replacing the upper one, would resolve the problem:
          <p>
          GenericClassLoader genericclassloader = new GenericClassLoader(classpathclassfinder, this.getClass().getClassLoader());
          <p>
          Doing this, the GenericClassLoader would know its logical parent by reference and would implicitly - thanks to the implementation of java.lang.ClassLoader - try to find the class using its parent first, would find a valid class, and hence use the same instance of the class object instantiated by the parent class loader. The problem would be solved.
          <p>
          It works fine in the console or under a running application server, because they will always have the weblogic jar in their system class path. ClassLoaders not having a parent are implied to have the system class loader as their parent - the piece of code does work in this case.
          <p>
          Under Eclipse this is no option, off course. We would restrain us to exactly this version of the APIs used by the weblogic version in the system class path.
          <p>
          I was trying to patch this myself by extending weblogic.jspc by my own class to pass on a proper class loader knowing its parent, and I was sort of successful: The problem disappeared. But I can't gain exactly what I am looking for, because the method runJspc with four parameters (around line 447) of weblogic.jspc is private to the class and its public brother always passes true to this method as the fourth parameter - causing jspc to recompile all JSPs instead of just the requested ones.
          <p>
          Everything refers to WL81SP3.
          <p>
          That's were I got stuck currently. I have read some postings about this problem in the internet - some dating far back into the history. So, I have the impression that there have been some folks around with the same problem. I think the patch I suggested does not any harm and I could simply use jspc in my builder without any problems.
          <p>
          Regards,
          <p>
          Elmar Schwarz