Byteman rules on application classes in Wildfly not executed

[jgreif]

In my first experiment with Byteman 3.0.1, I used bminstall to add the agent to Wildfly 8.1.0 Final (on Windows 10), with the ...byteman.verbose property set.  Then I used bmsubmit to (apparently successfully) add the simple rules shown below, triggering on classes in my application's EAR.  When exercising the program in ways guaranteed to invoke these methods (I verified in he debugger that they were called), the rules are apparently not triggered -- that is, nothing shows up in the log files, either the byteman verbose output indicating rule execuion, or the desired output of the rules, although the various messages from processing the rules when they are defined, redefined or removed, are shown in the logs.

Is this likely to be some kind of classloader issue?

I've also tried using traceOpen/Close and putting the traceln output into a separate file, and various simplifications (such as omitting the ...log.debug() action) and complications of these rules, also unsuccessfully.

c:/apps/byteman-download-3.0.1/bin/bmsubmit -l

# File c:/cygwin/home/jgreif/tmp/count-callbacks.btm line 5

RULE count task invocation callbacks

CLASS com.webalo.up.uam.container.impl.ActionInvocationManager.TaskInvocationCallbackHandler

METHOD handleCallback

AT ENTRY

IF TRUE

DO

traceln("out", "****CB " + java.lang.System.currentTimeMillis());

com.webalo.up.uam.container.impl.ActionInvocationManager.log.debug("****CB " + java.lang.System.currentTimeMillis())

ENDRULE

# File c:/cygwin/home/jgreif/tmp/count-create-inv.btm line 5

RULE count create invocation

CLASS com.webalo.up.invocation.TaskInvocationManager

METHOD UamContainer.ActionResult createAndInitInvocation

AT ENTRY

IF TRUE

DO

traceln("****INV " + java.lang.System.currentTimeMillis());

com.webalo.up.invocation.TaskInvocationManager.log.debug("****INV " + java.lang.System.currentTimeMillis())

ENDRULE

[jgreif]

Oops.  Fixed the misnamed inner class in the first rule, but the rule was still not triggered.

[adinn]

Hi Jeff,

Thanks for reporting your problem. I'll do what I can to help but I am off on holiday for 2 weeks starting Friday. So, if we cannto resolve this straight away there may be a delay (unless someone else on the forum can pick up the problem and identify what is wrong).

Oops.  Fixed the misnamed inner class in the first rule, but the rule was still not triggered.

I assume this means you used '$' instead of '.' to separate the iner class name from its outer class package+name.e.g.

RULE count task invocation callbacks
CLASS com.webalo.up.uam.container.impl.ActionInvocationManager$TaskInvocationCallbackHandler
. . .

This may be some WIndows 10 weirdness I have not encountered. Or it may just be a problem with your current setup. Could you please post provide a few more details to aid diagnosis?

1) It would be helpful to see the command lines you are using to run your application, and to run the bminstall and bmsubmit commands.

2) Also, could I see the Byteman verbose output that you saw in the logs. That ought to show i) what Byteman has attempted to inject and ii) what (if anything) might have gone wrong during injection, parsing, type checking or execution.

3) Just in case the verbose output is incompete: after you have started your program (with the agent installed and the rules submitted) and are sure you have exercised the target methods could you then (before shutting down the app) run bmsubmit with no command line arguments. This should report which rules the agent knows about and, this is the useful bit, the status of any injection attempts, inlcuding  details of any successes or failures at injection or type checking.

4) One other thing: is the Byteman agent jar (byteman-3.0.1.jar) in the classpath when you start your application? If so, do any of your classes reference any Byteman classes? I'm asking not because this is needed -- on the contrary -- but I just want to check.

If you can provide any of this information it may well make it a lot easier to identify the problem. Thanks.

regards,

Andrew Dinn

[jgreif]

Thanks for the quick response.  Here's the additional info.

These are the java options for running JBoss:

-server -Xmx768m -Xms64m -XX:MaxMetaspaceSize=256m -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n -Djboss.server.log.dir=C:/cygwin/home/jgreif/git/products/build/md-state/logs -Dlog4j.debug=true -Djboss.bind.address=0.0.0.0 -Dcom.webalo.installationDirectory=C:/cygwin/home/jgreif/git/products/build/md-state

and the command is

$JBOSS_HOME/bin/standalone.sh $@ >$MDSTATE/logs/jboss-std-streams.log 2>&1

Note that the byteman agent is not installed on this command line, but later using bminstall.

This is how I ran bminstall

c:/apps/byteman-download-3.0.1/bin/bminstall -Dorg.jboss.byteman.verbose=true 14392

This is how I ran bmsubmit

c:/apps/byteman-download-3.0.1/bin/bmsubmit c:/cygwin/home/jgreif/tmp/count-callbacks.btm c:/cygwin/home/jgreif/tmp/count-create-inv.btm

So if I uninstall the rules using bmsubmit -u, and run bmsubmit again as above, the output in the command prompt is

install rule count task invocation callbacks

install rule count create invocation

and the logs show

2015-08-26 09:20:45.642 INFO  [Thread-217] stdout  -- TransformListener() : handling connection on port 9091

2015-08-26 09:21:03.835 INFO  [Thread-217] stdout  -- TransformListener() : handling connection on port 9091

2015-08-26 09:21:03.853 INFO  [Thread-217] stdout  -- retransforming com.webalo.up.uam.container.impl.ActionInvocationManager$TaskInvocationCallbackHandler

2015-08-26 09:21:03.853 INFO  [Thread-217] stdout  -- retransforming com.webalo.up.invocation.TaskInvocationManager

This is the output of bmsubmit -l

# File c:/cygwin/home/jgreif/tmp/count-callbacks.btm line 5

RULE count task invocation callbacks

CLASS com.webalo.up.uam.container.impl.ActionInvocationManager$TaskInvocationCallbackHandler

METHOD com.webalo.uam.container.UamContainer.ActionResult handleCallback

AT ENTRY

IF TRUE

DO

traceOpen("cbfile", "c:/Temp/ticb.out");

traceln("cbfile", "****CB " + Long.toString(java.lang.System.currentTimeMillis()));

traceClose("cbfile");

com.webalo.up.uam.container.impl.ActionInvocationManager.log.debug("****CB " + Long.toString(java.lang.System.currentTimeMillis()))

ENDRULE

# File c:/cygwin/home/jgreif/tmp/count-create-inv.btm line 5

RULE count create invocation

CLASS com.webalo.up.invocation.TaskInvocationManager

METHOD UamContainer.ActionResult createAndInitInvocation

AT ENTRY

IF TRUE

DO

traceln("****INV " + java.lang.System.currentTimeMillis());

com.webalo.up.invocation.TaskInvocationManager.log.debug("****INV " + java.lang.System.currentTimeMillis())

ENDRULE

and when I carry out operations that enter the methods specified by the rules, the logs show nothing.

Perhaps the verbose output property was not set correctly, but over the course of many variant submissions of these rules, I saw errors indicated in some cases.

[jgreif]

Perhaps there is a clue here:

I restarted Wildfly and changed the bminstall command to the following:

c:/apps/byteman-download-3.0.1/bin/bminstall -Dorg.jboss.byteman.verbose=true -Dorg.jboss.byteman.compileToByteCode=true -Dorg.jboss.byteman.dump.generated.classes=true -Dorg.jboss.byteman.dump.generated.classes.directory=c:/Temp/byteman-classes 11596

and ran otherwise as before.  The rules loaded as before, but no transformed classes were generated into the specified directory, and the rules still failed to fire.

[adinn]

Hi Jeff,

Hmm, this is very strange.

Could you try injecting the rules without the calls to the dbeug methods on your log classes.

  com.webalo.up.uam.container.impl.ActionInvocationManager.log.debug("****CB " + Long.toString(java.lang.System.currentTimeMillis()))

and

  com.webalo.up.invocation.TaskInvocationManager.log.debug("****INV " + java.lang.System.currentTimeMillis())

i.e. just call traceln.

What is interesting is that when you run "bminstall -l" the output does not indicate that the rules have beein injected into any classes. Normally, if a class has been transformed then you see a record in the output showing the classloader of the trigger class into which the rule was injected. Also, after the messages saying "retransforming com.xxx" I would expect to see messages detailing the success or failure of the injection attempt. So, it looks like the Transformer is being passed the classes for retransformation but is not seeing the uploaded rules.

The only circumstance where I have seen anything like this happen is when the byteman agent jar has been deployed with the application. Have you placed byteman.jar in one of your deployment units or in a module directory somewhere? iif so then that is a mistake as it will mean that there can be two versions of the Byteman classes. In which case the transformer which is doing the bytecode rewriting may be looking at a version of the rule manager class to find the loaded rules while the agent listener which reads in the scripts is handing them on for storage using another version of the class.

Could you try to download the Byteman sources, point you rdebugger at them and then break static method Rule.execute(String, Object, Object[]) --  just to see whether it is getting called? If it is tghen perhaps also you could see whether the hash lookup it does oon the input String is finding a Rule object. If it is called but returns null then I suspect this is the duplicate class issue.

[jgreif]

The debug methods were added just to make sure I would see the rules executing in the logs.  I removed them, and saw no difference in the output of bmsubmit or subsequent bmsubmit -l.

There is no file in the wildfly tree that contains "byteman" in its name..

There are however, two (identical) copies of the jar containing the classes that should be transformed, as is usual for stuff deployed in Wildfly:

./standalone/deployments/webalo.ear/lib/webalo-all.jar

./standalone/tmp/vfs/deployment/deployment35539ecee1379f9c/webalo-all.jar-5cd914a255c6c3c1/webalo-all.jar

I set a breakpoint on Rule.execute, but it was not reached.

Just to be sure I hadn't called bminstall twice, I restarted JBoss and went through the same sequence, except that I exercised the classes to be instrumented before executing bminstall, so there would be something to transform immediately when the rules were submitted.  Saw no change in the output in the logs or command prompt, and nothing in the directory specified for dumping the gengerated classes.  Rule.execute was not reached in the debugger after the rules were installed.

[jgreif]

To rule out possible Windows 10 dependency, I tried the same thing on a Linux box (VM) running a slightly older version of my Wildfly application, seeing the same behavior, and no rule execution.

[jgreif]

Did some more detailed debugging, made some progress, and found some issues.

Issue #1:  At TransformContext line 135, the condition evaluating to true indicates that either there is no matching method for the rule in the class, or no matching location within a matching method.  Wouldn't it be good to report this via System.out in the body of the if statement, at least if he verbose property is set?

Once I discovered that transforming my rules entered the 'if' body, i determined that one of the rules was erroneous and corrected it (the return type was a nested class notated with a '.' rather than '$', and also tried to concatenate a String with a long, instead of explicitly converting the latter to String.).  The rule

RULE count create invocation

CLASS com.webalo.up.invocation.TaskInvocationManager

METHOD UamContainer$ActionResult createAndInitInvocation(com.webalo.up.uam.UiActionInvocation, com.webalo.up.interaction.InteractionId, com.webalo.up.interaction.ao.InteractionAppObj)

AT ENTRY

IF TRUE

DO

   traceln("****INV " + Long.toString(java.lang.System.currentTimeMillis()));

ENDRULE

then got a VerifyError when injection was attempted into the loaded class:

2015-08-30 21:47:30.698 INFO  [Thread-195] stdout  -- retransforming com.webalo.up.invocation.TaskInvocationManager

2015-08-30 21:47:30.836 INFO  [Thread-195] stdout  -- org.jboss.byteman.agent.Transformer : possible trigger for rule count create invocation in class com.webalo.up.invocation.TaskInvocationManager

2015-08-30 21:47:30.882 INFO  [Thread-195] stdout  -- RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into com.webalo.up.invocation.TaskInvocationManager.createAndInitInvocation(com.webalo.up.uam.UiActionInvocation,com.webalo.up.interaction.InteractionId,com.webalo.up.interaction.ao.InteractionAppObj) com.webalo.up.uam.container.UamContainer$ActionResult for rule count create invocation

2015-08-30 21:47:30.977 INFO  [Thread-195] stdout  -- org.jboss.byteman.agent.Transformer : inserted trigger for count create invocation in class com.webalo.up.invocation.TaskInvocationManager

2015-08-30 21:47:30.981 INFO  [Thread-195] stdout  -- org.jboss.byteman.agent.Transformer : Saving transformed bytes to c:/Temp/byteman-classes\com\webalo\up\invocation\TaskInvocationManager.class

2015-08-30 21:47:30.993 INFO  [Thread-195] stdout  -- Retransformer : VerifyError during retransformation : some rules may not have been correctly injected or uninjected!

2015-08-30 21:47:30.994 ERROR [Thread-195] stderr  -- java.lang.VerifyError

2015-08-30 21:47:30.994 ERROR [Thread-195] stderr  -- at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

2015-08-30 21:47:30.994 ERROR [Thread-195] stderr  -- at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:144)

2015-08-30 21:47:30.995 ERROR [Thread-195] stderr  -- at org.jboss.byteman.agent.Retransformer.installScript(Retransformer.java:144)

2015-08-30 21:47:30.995 ERROR [Thread-195] stderr  -- at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:349)

2015-08-30 21:47:30.996 ERROR [Thread-195] stderr  -- at org.jboss.byteman.agent.TransformListener.loadScripts(TransformListener.java:272)

2015-08-30 21:47:30.996 ERROR [Thread-195] stderr  -- at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:225)

2015-08-30 21:47:30.996 ERROR [Thread-195] stderr  -- at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:158)

Issue #2:  Is it possible to get more information about a VerifyError?

and a different error involving failure to inject the rule (submitted before its target class is loaded). at classloading time as the class's first instance is being constructed:

2015-08-30 21:37:30.840 INFO  [mdc-threadpool 25: com.webalo.up.dml.tcp.NioTcpUpsUaServer$ConnectionCreationRunnable] stdout  -- RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into com.webalo.up.invocation.TaskInvocationManager.createAndInitInvocation(com.webalo.up.uam.UiActionInvocation,com.webalo.up.interaction.InteractionId,com.webalo.up.interaction.ao.InteractionAppObj) com.webalo.up.uam.container.UamContainer$ActionResult for rule count create invocation

2015-08-30 21:37:30.925 INFO  [mdc-threadpool 25: com.webalo.up.dml.tcp.NioTcpUpsUaServer$ConnectionCreationRunnable] stdout  -- org.jboss.byteman.agent.Transformer : inserted trigger for count create invocation in class com.webalo.up.invocation.TaskInvocationManager

2015-08-30 21:37:30.929 INFO  [mdc-threadpool 25: com.webalo.up.dml.tcp.NioTcpUpsUaServer$ConnectionCreationRunnable] stdout  -- org.jboss.byteman.agent.Transformer : Saving transformed bytes to c:/Temp/byteman-classes\com\webalo\up\invocation\TaskInvocationManager.class

2015-08-30 21:37:30.942 SEVERE [mdc-threadpool 25: com.webalo.up.dml.tcp.NioTcpUpsUaServer$ConnectionCreationRunnable] com.webalo.up.dml.tcp.NioTcpUpsUaServer  -- Could not construct TcpUserAgentConnection: Exception: org/jboss/byteman/rule/exception/EarlyReturnException

java.lang.NoClassDefFoundError: org/jboss/byteman/rule/exception/EarlyReturnException

  at com.webalo.up.uam.container.impl.ActionInvocationManager.<init>(ActionInvocationManager.java:103)

  at com.webalo.up.uam.container.impl.UamContainerImpl.<init>(UamContainerImpl.java:89)

  at com.webalo.up.uam.container.impl.UamContainerImpl.<init>(UamContainerImpl.java:71)

  at com.webalo.up.uam.UamManagerImpl.processUserAgentConnection(UamManagerImpl.java:74)

  at com.webalo.up.manager.UpsManager$UaServerListener.connectionEstablished(UpsManager.java:66)

  at com.webalo.up.dml.AggregateUpsUaServer$ChildUasListener.connectionEstablished(AggregateUpsUaServer.java:128)

  at com.webalo.up.dml.tcp.NioTcpUpsUaServer$ConnectionCreationRunnable.run(NioTcpUpsUaServer.java:419)

  at com.webalo.util.ThreadPool$RunnableRef.run(ThreadPool.java:1325)

  at com.webalo.util.ThreadPool$PoolThread.runRunnable(ThreadPool.java:788)

  at com.webalo.util.ThreadPool$PoolThread.run(ThreadPool.java:597)

Caused by: java.lang.ClassNotFoundException: org.jboss.byteman.rule.exception.EarlyReturnException from [Module "deployment.webalo.ear:main" from Service Module Loader]

  at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)

  at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)  at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)

  at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)

  at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)

  ... 10 more

Issue #3:  Shouldn't bminstall ensure that all the necessary classes from byteman.jar can be found?

[jgreif]

A little more info:

1.  The VerifyError returned from the native code has no detail message.

2.  There were some indications online that some versions of java 7 and 8 had verifier bugs, so I upgraded from java 8u40 to java 8u60.  This made no difference.

3.  The other rule I was testing with, when modified to look like this:

'

RULE count task invocation callbacks

CLASS com.webalo.up.uam.container.impl.ActionInvocationManager$TaskInvocationCallbackHandler

METHOD handleCallback

AT ENTRY

IF TRUE

DO

   traceln("****CB " + Long.toString(java.lang.System.currentTimeMillis()))

ENDRULE

got the same kind of VerifyError.

[adinn]

Hi Jeff,

Just back from holiday and very pleased to see you pinned the problem down further :-)

Here are a few responses to your comments

Issue #1:  At TransformContext line 135, the condition evaluating to true indicates that either there is no matching method for the rule in the class, or no matching location within a matching method.  Wouldn't it be good to report this via System.out in the body of the if statement, at least if he verbose property is set?

Yes, it would be a very good idea to print some verbose trace here but as a earning rather thna an error. The reason Byteman has not already done this is that it cannot be sure this is an error. A rule may fail to match for a variety of reasons and many of them are quite legitimate.

Let's take your example. In the class loader where the target class is found the related class name mentioned in the rule did not match because you used '.' instead of '$'. But for all Byteman knows there may be another version of the target class in another loader where the name you supplied does resolve. So, is this an error?

A more interesting example can be seen if you have a rule which injects AT EXIT and mentions local variable $i. Let's assume the target method contains this code

class Foo {
. . .
Object referrer(Object value)
{
  for (i = 0; i < refs.length; i++) {
    if (refs[i] == value) { return this; }
  }
  return null;
}

The rule will successfully inject inside the loop but will not inject at the last line. You don't want to see an error in this case and may be misled if  you see 'Warning : failed to inejct Rule xxx into Foo.referrer()". This can also happen with an overriding rule (CLASS ^Foo) where FooClass.myMethod does not include local i but FooSubClass.myMethod does mention it.

What I am surprised by is that bmcheck did not identify the failure to match. It is supposed to check that every rule has been injected at least once and print a warning if that does not happen.

The whole verbose trace system is up for a revamp right now -- first to provide depth and content filters and then to generate more trace and more appropriate trace. It may take a while to implement this but I'll be glad to add this to the list of points where notification of failures could be improved.

the return type was a nested class notated with a '.' rather than '$', and also tried to concatenate a String with a long, instead of explicitly converting the latter to String

If you have along value lval then you shoudl be able to use an expression like  "Value = " + lval in your Byteman rule. Byteman is supposed to detect that you are adding something to a String and automatically convert the long value to a String by replacing lval with new Long(lval).toString(). Are you sure this was not working?

The rule

RULE count create invocation

CLASS com.webalo.up.invocation.TaskInvocationManager

METHOD UamContainer$ActionResult createAndInitInvocation(com.webalo.up.uam.UiActionInvocation, com.webalo.up.interaction.InteractionId, com.webalo.up.interaction.ao.InteractionAppObj)

AT ENTRY

IF TRUE

DO

   traceln("****INV " + Long.toString(java.lang.System.currentTimeMillis()));

ENDRULE

then got a VerifyError when injection was attempted into the loaded class:

. . .

2015-08-30 21:47:30.981 INFO  [Thread-195] stdout  -- org.jboss.byteman.agent.Transformer : Saving transformed bytes to c:/Temp/byteman-classes\com\webalo\up\invocation\TaskInvocationManager.class

That is very interesting. It may be to do with the use of innner classes. Are these inner classes static or non-static? In the latter case this may be a known problem which arises from the fact that it is not always possible to refer to a non-static inner class from bytecode. Could you either

  1) provide me with a copy of that class file

  2) run javap -c -verbose -classpath c:Temp\byteman-classes com.webalo.up.invocation.TaskInvocationManager and provide me with a copy of the output

n.b. I am not absolutely sure that c:Temp\byteman-classes is the right syntax for the classpath so you may need to fiddle with it to get that right.

Issue #3:  Shouldn't bminstall ensure that all the necessary classes from byteman.jar can be found?

The problem here looks xlike it is happening because of the use of JBoss modules. By default JBoss modules cannot see classes in the system or bootstrap class path. The standalone.bat script usually ensures that they are visible by passing argument -Djboss.modules.system.pkgs=org.jboss.byteman on the java command line. However, if you set JAVA_OPTS in your runtime environment then this option can get deleted. Can you make sure that this property is set when you run your JVM and see if this fixes the 3rd problem.

1.  The VerifyError returned from the native code has no detail message.

Yes, I know, annoying isn't it :-)

3.  The other rule I was testing with, when modified to look like this:

RULE count task invocation callbacks

CLASS com.webalo.up.uam.container.impl.ActionInvocationManager$TaskInvocationCallbackHandler

METHOD handleCallback

AT ENTRY

IF TRUE

DO

   traceln("****CB " + Long.toString(java.lang.System.currentTimeMillis()))

ENDRULE

got the same kind of VerifyError.

This may also be to do with non-static inner classes. Is TaskInvocationCallbackHandler static or non-static?

[jgreif]

I just got back from vacation myself.  Thanks for continuing to look into these issues with Byteman -- your suggestions seem to have resolved them.

It appears that the VerifyErrors arose from the unavailable Byteman classes. When I added -Djboss.modules.system.pkgs=org.jboss.byteman to the JVM_OPTS, the rules were successfully installed and executed.  But this means that it is not possible to use bm-install + bm-submit to add rules to a running Wildfly unless that property was included in the command line. 

re Inner classes: 

     UamContainer$ActionResult is a nested interface (UamContainer is also an interface)

     ActionInvocationManager$TaskInvocationCallbackHandler is not static

but this did not matter, apparently.

re: concatenating String with long

    I don't know if this was causing a problem.  I had changed it to use Long.toString() to reduce the cross-section for problems.

You probably don't need the class file anymore.

[adinn]

Hi Jeff,

I just got back from vacation myself.  Thanks for continuing to look into these issues with Byteman -- your suggestions seem to have resolved them.

Excellent and no need for thanks. It's one of the great bonus opportunities of the open source model that users come and talk to you. Following up on details, even if you think you understand what is happening, is all part of making the most of that opportunity.

It appears that the VerifyErrors arose from the unavailable Byteman classes. When I added -Djboss.modules.system.pkgs=org.jboss.byteman to the JVM_OPTS, the rules were successfully installed and executed.  But this means that it is not possible to use bm-install + bm-submit to add rules to a running Wildfly unless that property was included in the command line.

Yes, indeed. That's why standalone.bat adds this setting to the java command line in normal circumstances -- i.e. when you don't configure your own JAVA_OPTS setting. It was set that way in the first JBoss AS to use JBoss Modules precisely to ensure that Byteman would work -- lots of the EAP projects use Byteman for testing. Am I right to assume that your standalone.bat also does this or has it been changed?

re Inner classes:
    UamContainer$ActionResult is a nested interface (UamContainer is also an interface)
    ActionInvocationManager$TaskInvocationCallbackHandler is not static
but this did not matter, apparently.

re: concatenating String with long
    I don't know if this was causing a problem.  I had changed it to use Long.toString() to reduce the cross-section for problems.

You probably don't need the class file anymore.

Ok, that's good to know. Interfaces ought not to present nay problem. The problem with non-static inner classes normally only arises if you run with compilation to bytecode switched on. It is explained by this JIRA issue.[BYTEMAN-288]. It was closed as won't fix because of a probelm explained in the related issue [BYTEMAN-236].

[jgreif]

We use standalone.sh under cygwin on Windows, and on our Linux production servers, but we do set our own JAVA_OPTS, into which we'll have to add that property.

[adinn]

Hi Jeff,

Jeff Greif wrote:

We use standalone.sh under cygwin on Windows, and on our Linux production servers, but we do set our own JAVA_OPTS, into which we'll have to add that property.

Thanks for confirming this and good luck with any future Byteman testing. And, of course, if the Leprechauns decide not to co-operate you can always post any issues in this forum.

regards,

Andrew DInn