Jakarta bytecode instrumentation

[Thorsten Goetzke]

Hello,

As mentioned by brian here https://groups.google.com/g/wildfly/c/zh2ZllHQtKo/m/kIYLXMK4BAAJ wildfly seems to ship with a bytecode instrumentation to migrate ee  to the jakarta namespace.

I run into the problem that this instrumentation does a bit too much for our legacy application. Are there some options to disable the instrumentation for deployments or alltogether? 

[James Perkins]

What version of WildFly Preview are you using?

[Thorsten Goetzke]

To give a litte more context: I have a module a which contains "activemq classic" as a ressource.

Then there is a deployment b that uses activemq (it depends on module a)

What happens is that the activemq library is available using the "old" ee namespace/ not the jakarta namespace.

However our own code in Deployment B gets somehow transformed by wildfly to require the jakarta namespace, even though the provided java class file uses the javax.jms namespace.

Results in a NoSuchMethod error, since now our transformed code requests the jakarta namespace from an untransformed activemq classic (which it doesn't have)

I am a bit lost on why that happens..

[Thorsten Goetzke]

wildfly-preview-26.0.0.Beta

[rop...@redhat.com]

You shouldn't mix javax & jakarta namespaces in your environment.

I'd recommend to create jakarta compatible module of "activemq classis".

You can use Batavia command line tool to create such jar from original jar.

[Brian Stansberry]

WildFly Preview's transformation of deployments can be disabled by adding the following system property to the server launch:

-Dorg.wildfly.unsupported.skip.jakarta.transformer=true

[Thorsten Goetzke]

Many thanks, after adding -Dorg.wildfly.unsupported.skip.jakarta.transformer=true I no longer get NoSuchMethodError