For OSGI, this does not work correctly.
Each OSGI Bundle has its own ClassLoader that protects the private part from outsiders.
The logical solution is to transfer the ClassLoader to the local JasperReportsContext.
It is necessary to find all the methods where the above construction is used.
All resources and classes must be raised using JRClassLoader.
JRClassLoader should get the current ClassLoader from JasperReportsContext.
If you haven't installed ClassLoader in JasperReportsContext, you should use the above construction.
In JRGroovyCompiler, when creating a GroovyClassLoader, it is necessary to give the ClassLoader from JasperReportsContext.
Old code
CompilationUnit unit = new CompilationUnit(config);
New code
ClassLoader classLoader = jasperReportsContext.getDefaultClassLoader();
GroovyClassLoader groovyClassLoader = new GroovyClassLoader(classLoader, config);
CompilationUnit unit = new CompilationUnit(config, null, groovyClassLoader);
By default, groovy does not see JasperReport classes.
For OSGI, it is necessary to redo the system for determining the current ClassLoader.
The construction is almost universally used
For OSGI, this does not work correctly. Each OSGI Bundle has its own ClassLoader that protects the private part from outsiders. The logical solution is to transfer the ClassLoader to the local JasperReportsContext.
It is necessary to find all the methods where the above construction is used. All resources and classes must be raised using JRClassLoader. JRClassLoader should get the current ClassLoader from JasperReportsContext.
If you haven't installed ClassLoader in JasperReportsContext, you should use the above construction.
In JRGroovyCompiler, when creating a GroovyClassLoader, it is necessary to give the ClassLoader from JasperReportsContext. Old code
New code
By default, groovy does not see JasperReport classes.