That doesn't apply to my question. I'm running WildFly on the JDK. Main is available in other Java apps run on the same JDK. There's something about WildFly that seems to be preventing my code from using Main.
1 of 1 people found this helpful
See the section entitled "Accessing JDK classes".
Although the article is for wildfly 10, it is also applicable to wildfly 11.
Thank you! That made it work.
The only down side is, up until today I've been able to avoid any WildFly/JBoss specific things in my EAR.
If anyone else needs to make Jasper compile JRXML files on Java 9 under Wildfly, this will help:
I understand. For what it's worth, even with this file embedded in your ear, other app servers would simply ignore it. Your ear isn't "locked" to wildfly with just this change, so to speak.
It can be extremely difficult to keep a deployment completely agnostic of the app server it's deployed in. Things have improved tremendously over the years, but it's still not perfect.
Well, that fixed the first problem. Jasper can now find "com.sun.tools.javac.Main", but when Jasper tries to compile a report the compiler can't find the Jasper classes. Classes like 'net.sf.jasperreports.engine.fill.JREvaluator".
Those classes are on the classpath. When I test this outside of WildFly the com.sun.tools.javac.Main compiler can find the Jasper classes.
I tried adding paths to the Jasper packages in the deployment structure XML file, but something in WildFly is still blocking them.
I'm not sure I understand completely how your deployment is configured. Are the Jasper jars in the ear's lib directory, or the embedded war's WEB-INF/lib directory? Or are they in some arbitrary location on the filesystem? If they are in the filesystem, you'll need to create a module. The module itself can point to dependencies anywhere, a dependency to the the module can be added to the jboss-deployment-structure.xml.
For modules, anything that is provided with wildfly will be in the $WILDFLY_HOME/modules/system/layers/base directory. For people that create their own modules, they are typically placed directly $WILDFLY_HOME/modules.
The same article that I linked to above shows examples of how to modify the jboss-deployment-structure.xml file to add dependencies to "normal" modules in the section above the Accessing JDK Classes.
Understanding the wildfly classloading mechanism is something that a lot of newcomers have problems with. It may seem burdensome at first, but it really is pretty great. All of the restrictions are meant to prevent issues such as having multiple instances of a class loaded, and not knowing which definition is being used. Of course, those things can still happen, but it's usually because the deployments themselves are embedding things that they shouldn't be.
The Jasper jars are in our EAR.
In addition to the Jasper jars, our reports have dependencies on our own classes. Some of those are deployed in the EAR and others are deployed in apps. We provide our own classloader that makes classes in those apps available. The apps can be deployed without restarting the enterprise application.
I solved our problem by adding the Eclipse ECJ compiler to our EAR. Jasper looks for that compiler first. That compiler uses our enterprise app's classloader, so it can see all of the classes in our EAR and our apps. The com.sun.tools.javac.Main compiler used WildFly's ModuleClassLoader, not ours.
Thanks for your help.