Jump to content
  • JRClassLoader using JRProperties compiler classpath

    Assigned User lucianc
    CategoryBug report

    Since JRClassLoader does not use the classpath specified in JRProperties.COMPILER_CLASSPATH, reports cannot be compiled unless all the classes are in the runtime classpath of the compiler -- instead of the build time classpath. So, for example, if as a part of building a project data transfer beans are built and used in reports as variables, the variable verification step of the report compilation will fail -- unless the beans were in the classpath of the JRAntCompileTask itself at definition time.


    The attached patch remedies this issue by modifying JRClassLoader to use a class loader which considers the compiler classpath. It's not perfect, as it relies on a single static classloader and does not monitor the COMPILER_CLASSPATH property for changes. On the other hand, it is not safe to simply construct a new classloader each time the loadClassForName(...) method is called because then each time the method is called (even with the same name) a different class object is loaded (and calls like isAssignableFrom fail).


    I have not thoroughly tested the patch, but it does seem to compile and populate all of my reports (when applied to 1.2.28)


    More discussion of this issue here:






    Attachments: jrclassloader.patch

    User Feedback

    Recommended Comments

    We have implemented an alternative solution to this issue. The report compilation Ant task now creates a classloader based on the task classpath and sets it as thread context classloader.


    JRClassLoader.loadClassForName() consults the context classloader, so it doesn\'t need to handle JRProperties.COMPILER_CLASSPATH itself when the compilation is invoked via the Ant task. When the compilation is directly invoked from Java code, we can require by contract that the caller takes care of setting the required thread context classloader.


    JRProperties.COMPILER_CLASSPATH could be considered cvasi-deprecated since the recommended JRJdtCompiler uses the context class loader to resolve classes.


    The changes have been checked-in on SVN rev 1606.


    If this fix doesn\'t work for you or you think it is not sufficient, please reopen the issue.




    Link to comment
    Share on other sites

  • Create New...