Groovy embedded in a Jakarta EE 9 module on Payara fails to deploy

I have been porting an application over to Jakarta EE on Payara 2022.1 and I ran into a problem that took me a deal of time to diagnose. The problem was that I kept getting messages indicating that jakarta. packages were not found. It turned out that the deployer kept trying to deploy my war as a JavaEE application because the application contained, in a sub-dependency, a library that depended on a javax.servlet.http.HttpServlet. I was using the org.mnode.ical4j:ical4j-extensions module which itself depends on org.codehaus.groovy:groovy-all. It is groovy-all that contains the groovy.servlet.GroovyServlet that extends javax.servlet.http.HttpServlet. I happen not to be using the ical4j-extensions in such a way that actually requires the groovy-all module. So I have managed to get the application to deploy by simply excluding groovy-all. Which is all very fine but… My question is whether it is correct that Payara should not even try to deploy the application as a Jakarta EE9 application? The logic seems to be… If the application contains a dependency on any JavaEE class anywhere within the deployed classes regardless of whether such a class is actually used or not then the Eclipse Transformer is not used to transform any jakarta packages to javax packages. Clearly it would be good if Groovy produced a version of groovy-all that is Jakarta EE9-friendly but I am wondering whether Payara should always use the Transformer if the package contains any JakartaEE9 references.

Hi, Chris, the auto-detection mechanism isn’t perfect and yes, it prefers Java EE over Jakarta EE 9. If you want to force deploying the application as a Jakarta EE 9 app, you can define the fish.payara.deployment.transform.namespace system property on the Payara Server and set it to true. See the documentation here:


Thanks for the response. I hadn’t spotted that property. That helps.
I think that it would be helpful if Payara could give a more helpful message in such a case. It took me a long for me to find out what the problem was.