Hi,

I've previously posted on the Byteman forum in connection with not being able to use Byteman to transform an EJB. That post can be read here: https://community.jboss.org/thread/215034?tstart=0

The pull for using Byteman in our setup is to have the ability to inject code appropriately during integration tests, to simulate different error scenarios when interacting with external systems.

We run our integration tests using Arquillian and have then tried to introduce Byteman as well. Using Byteman works well in our setup on regular POJO's, however, when trying to use Byteman to transform an EJB, we see the following exception being thrown from the application server when running the integration test (error thrown right after Byteman transforms the EJB):

SEVERE: java.lang.VerifyError

          at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

          at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

          at org.jboss.byteman.agent.Retransformer.installScript(Retransformer.java:136)

          at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:337)

          at org.jboss.byteman.agent.TransformListener.loadScripts(TransformListener.java:260)

          at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:213)

          at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

Now, the theory of what goes wrong is (see Andrew Dinns answer in the post mentioned above), that the changes Byteman makes during its transformation of the EJB invaldiate some assumptions about the layout of the bytecode that the EJB code depends upon.

To take this matter further it's necessary to get some more insight in the nature of an EJB and what could be the reason why it's not possible to use a tool such as Byteman to do a bytecode transformation of the EJB without leaving it in an incosistent state.

Any insights/comments/solutions highly appreciated.

Thanks.

Regards,

Simon