[adinn]

Hi James,

I think I have spotted an issues in the way imports are being processed in ScriptRepository.processScripts() and I'm not sure I agree with the current semantics.

The current code uses two arrays, defaultImports and targetImports to track IMPORT statements seen, respectively, at the top level and in the body of the current rule. It  treats these two lists as exclusive specifications i.e. if a rule specifies any IMPORTs then these are used instead of the script level IMPORTs. I think it makes more sense for these two lists to be cumulative (modulo a wrinkle which we will come to). In other words, if modules M1 and M2 have already been imported at script level and then a rule specifies IMPORT M3 and import M4 the module set for the rule should be [M1, M2, M3, M4].

The current code does not need much of a change to do this. The handling in the ENDRULE case is fine (targeImports just clones defaultImports). However, this needs changing whne we hit an import inside a rule. If targetImports is NULL at this point then we needs to make a copy of defaultImports with one extra spare slot. If it is non-NULL then we simply  need to make a copy of targetImports with one spare slot.

So, what is the wrinkle? Well, I think we should also provide a way of erasing any existing imports. The HELPER syntax sets a precedent for this since a line containing just the keyword HELPER clears any rule or script level HELPER setting. So, we should treat a line containing just the keyword IMPORT as clearing any rule or script level imports. i.e. if modules M1 and M2 have already been imported at script level and then a rule has an empty IMPORT line then the module set for the rule should be []. Of course, if the rule has an empty IMPORT line followed by, say, IMPORT M3 then the module set for the rule should be [M3]. Similarly, if modules M1 and M2 have been imported at script level and we see an empty IMPORT line at script level then we should reset to have no script level imports.

I think this best implemented at the rule level by setting targetImports to a zero length array when we see an empty input line -- setting it to null runs the risk of inheriting the defaults if it is then followed by a 2nd IMPORT also embedded in the rule). A top level just requires resetting defaultImports to null (since at that point targetImports always ought to be null). In order to avoid any hostages to fortune I think we should also check at the point where the RuleScript is created whether targetImports is a zero-length array and if so make sure we pass null to the RuleScript constructor.

[jameslivingston]

That sounds reasonable. I'll look at implementing it

[radek.koubsky]

Hello guys,

I have been watching your conversation and I am really excited about your solution. When you release it, I can do some tests with my project at least. Do you have any idea when the implementation is going to be released? Thank you.

Radek

[adinn]

Hi Radek,

Support for imports under JBoss Modules is already available in the latest Byteman release (3.0.3). It is currently only available if you configure it on the Java command line using -javaagent (scripts bmava and bminstall and class Install hav enot yet been modified to recognise the necessary options). However, the functionality has been tested and should work fine.

You need to add 2 extra options to the -javagent command line argument

  export AGENTJAR=${BYTEMAN_HOME}/lib/byteman.jar

  export MODPUGINJAR=${BYTEMAN_HOME}/lib/contrib/byteman-jboss-modules.jar

  export MODPLUGIN=org.jboss.byteman.modules.jbossmodules.JBossModulesSystem

  java -javaagent:${AGENTJAR},...,modules:${MODPLUGIN},sys:${MODPLUGINJAR}

where ... should be replaced with your normal options e.g. listener:true

This should mean that you are able to install rules which use import statements to make a JBoss module visible at injection time.

If you want your rule to have access to module X then insert

  IMPORT X

in your rule between the METHOD clause and the AT clause. X must be the name of a module known to JBoss Modules. If you want the rule to be visible to all rules then insert the import statement at the top level before the rules you want to have access to the modules. You can use more than one IMPORT statement in a rule/script to add more than one module to the imports list for a rule/script.

n.b. two details are not yet working correctly:

imports at rule level should add to the current script imports -- at present they replace the script imports

you should be able to use an empty import statement) to cancel all outstanding imports -- either reset the script imports list to empty or set the rule imports list (inherited from script level) to empty.

Please try using this feature and let me know if you neede any help or encounter any problems or things you think might improve it.

regards,

Andrew Dinn

[radek.koubsky]

Hi Andrew,

thanks for your info. I tried the JBoss Modules plugin according to your guide and I still get java.lang.NoClassDefFoundError, this is my configuration:

Wildfly version 8

Byteman 3.0.3

My helper jar and rules are here RadekKoubsky/byteman-wildfly-log · GitHub

I had to change paths for ENV VAR:

export BYTEMAN_HOME=$HOME/Byteman/byteman-download-3.0.3

export MODPLUGINJAR=${BYTEMAN_HOME}/contrib/jboss-modules-system/byteman-jboss-modules-plugin.jar

export MODPLUGIN=org.jboss.byteman.modules.jbossmodules.JBossModulesSystem

export PATH=${PATH}:${BYTEMAN_HOME}/bin

I think you meant it to be something like this as there is no "contrib" directory within the "lib" directory and the jar name is a little bit different.

This is my configuration of standalone.conf:

JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.byteman.transform.all -javaagent:${BYTEMAN_HOME}/lib/byteman.jar=script:${HOME}/byteman-wildfly-log/rules/servlets.btm,sys:${HOME}/byteman-wildfly-log/target/byteman-wildfly-log-0.0.1-SNAPSHOT.jar,listener:true,modules:${MODPLUGIN},sys:${MODPLUGINJAR}"

I had to add dependency to my helper project as well, same version of undertow core is used in Wildfly 8:

<dependency>
  <groupId>io.undertow</groupId>
  <artifactId>undertow-core</artifactId>
  <version>1.1.0.Final</version>
  <scope>provided</scope>
</dependency>

I created a new helper class byteman-wildfly-log/ServletHandlerLog.java at master · RadekKoubsky/byteman-wildfly-log · GitHub

and used it with a new rule within the servlet.btm script (you have to uncomment it as I did not want to push not working code to my repository):

#Log cookies - does not work with JBoss Modules plugin
#RULE logServletHandler.handleRequest.cookies
#CLASS io.undertow.servlet.handlers.ServletHandler
#METHOD handleRequest(HttpServerExchange)
#HELPER org.jboss.byteman.koubsky.servlets.ServletHandlerLog
#IMPORT io.undertow.core
#AT ENTRY
#IF true
#DO logCookie($CLASS, $1)
#ENDRULE

I suppose the io.undertow.server.HttpServerExchange class is located in the io.undertow.core module.

You can try the rule above with this quickstart: quickstart/helloworld-rs at 8.x · wildfly/quickstart · GitHub

However, Byteman throws an exception when using the IMPORT statement, stacktrace:

23:41:38,321 DEBUG [io.undertow.servlet.handlers.ServletHandler] (default task-1) [ThreadId-140] (Method handleRequest) Request info:  URL = http://localhost:8080/wildfly-helloworld-rs/rest/, protocol = HTTP/1.1, method = GET, query string: 
23:41:38,322 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /wildfly-helloworld-rs/rest/: java.lang.NoClassDefFoundError: io/undertow/server/HttpServerExchange
  at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.7.0_80]
  at java.lang.Class.privateGetDeclaredMethods(Class.java:2625) [rt.jar:1.7.0_80]
  at java.lang.Class.privateGetPublicMethods(Class.java:2743) [rt.jar:1.7.0_80]
  at java.lang.Class.getMethods(Class.java:1480) [rt.jar:1.7.0_80]
  at org.jboss.byteman.rule.expression.MethodExpression.findMethod(MethodExpression.java:262) [byteman.jar:]
  at org.jboss.byteman.rule.expression.MethodExpression.typeCheck(MethodExpression.java:188) [byteman.jar:]
  at org.jboss.byteman.rule.Action.typeCheck(Action.java:106) [byteman.jar:]
  at org.jboss.byteman.rule.Rule.typeCheck(Rule.java:550) [byteman.jar:]
  at org.jboss.byteman.rule.Rule.ensureTypeCheckedCompiled(Rule.java:487) [byteman.jar:]
  at org.jboss.byteman.rule.Rule.execute(Rule.java:705) [byteman.jar:]
  at org.jboss.byteman.rule.Rule.execute(Rule.java:686) [byteman.jar:]
  at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: java.lang.ClassNotFoundException: io.undertow.server.HttpServerExchange
  at java.net.URLClassLoader$1.run(URLClassLoader.java:366) [rt.jar:1.7.0_80]
  at java.net.URLClassLoader$1.run(URLClassLoader.java:355) [rt.jar:1.7.0_80]
  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_80]
  at java.net.URLClassLoader.findClass(URLClassLoader.java:354) [rt.jar:1.7.0_80]
  at java.lang.ClassLoader.loadClass(ClassLoader.java:425) [rt.jar:1.7.0_80]
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) [rt.jar:1.7.0_80]
  at java.lang.ClassLoader.loadClass(ClassLoader.java:358) [rt.jar:1.7.0_80]
  ... 37 more

[jameslivingston]

Looking at this with a debugger, I can see the problem. The rule can correctly see the undertow classes due to the IMPORT, however your helper class takes one as a parameter and it cannot see them.

In findMethod, rootType's target class is set to org.jboss.byteman.koubsky.servlets.ServletHandlerLog from the system loader rather than org.jboss.byteman.koubsky.LogHelper_HelperAdapter_Interpreted_N from the module-aware loader. That is because MethodExpression:176 is:

  typeGroup.create(rule.getHelperClass().getCanonicalName())

If your helper needs to see classes from a module, a solution is to put the helper into a module (with the necessary dependencies) and IMPORT it, rather than adding it via the 'sys' agent parameter.

helperImplementationClass (which can see IMPORTED modules) is not set up until compile time, and in this case it would be required during typechecking. The only options I can see are to hoist the helper/loader setup out to be before the typechecking phase, or document it as a limitation.

[adinn]

I think James as this right. The to fix this is to deploy the helper in a JBoss module and then import that module into the rule (better import it at script level).

Since the helper class needs to reference undertow code it's module should  import the module containing the undertow classes. That means the helper and the code being injected into will be using the same version of the classes -- actually,  the same classes.

[radek.koubsky]

Hi James,

thanks for clarification. I removed my Helper jar from "sys" agent option and put the Helper jar to separate module with the following module.xml file:

<module xmlns="urn:jboss:module:1.1" name="org.wildfly.byteman.log">
    <resources>
        <resource-root path="byteman-wildfly-log-0.0.1-SNAPSHOT.jar"/>
    </resources>
    <dependencies>
    <module name="io.undertow.core"/>
    </dependencies>
</module>

I had to changed the servlet.btm, which starts with this code:

IMPORT org.wildfly.byteman.log
IMPORT io.undertow.core
HELPER org.jboss.byteman.koubsky.LogHelper



#Log cookies - does not work with JBoss Modules plugin
RULE logServletHandler.handleRequest.cookies
CLASS io.undertow.servlet.handlers.ServletHandler
METHOD handleRequest(HttpServerExchange)
HELPER org.jboss.byteman.koubsky.servlets.ServletHandlerLog
AT ENTRY
IF true
DO logCookie($CLASS, $1)
ENDRULE

.... rest of rules ...

I am not sure how does the plugin work with transitive dependencies e.g.:

org.wildfly.byteman.log module depends on io.undertow.core module => there is no need to add IMPORT io.undertow.core

However, when I run the quickstart, none of the rules from the servlet.btm file are executed. According to the output of bmsubmit.sh, the rules cannot find helper classes imported from the org.wildfly.byteman.log module

part of the bmsubmit output:

RULE logServletHandler.handleRequest.cookies
CLASS io.undertow.servlet.handlers.ServletHandler
METHOD handleRequest(HttpServerExchange)
HELPER org.jboss.byteman.koubsky.servlets.ServletHandlerLog
AT ENTRY
IF true
DO logCookie($CLASS, $1)
ENDRULE
Transformed in:
loader: ModuleClassLoader for Module "io.undertow.servlet:main" from local module loader @7782d113 (finder: local module finder @2d6c73b1 (roots: /home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules,/home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules/system/layers/base))
trigger class: io.undertow.servlet.handlers.ServletHandler
threw org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
at org.jboss.byteman.rule.Rule.<init>(Rule.java:232)
at org.jboss.byteman.rule.Rule.create(Rule.java:355)
at org.jboss.byteman.agent.TransformContext.parseRule(TransformContext.java:178)
at org.jboss.byteman.agent.TransformContext.transform(TransformContext.java:82)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:748)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:816)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:787)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:259)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92)
at org.jboss.modules.Module.loadModuleClass(Module.java:568)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
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)
at io.undertow.servlet.core.ManagedServlets.addServlet(ManagedServlets.java:47)
at io.undertow.servlet.core.DeploymentManagerImpl.createServletsAndFilters(DeploymentManagerImpl.java:231)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:176)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Transformed in:
loader: ModuleClassLoader for Module "io.undertow.servlet:main" from local module loader @7782d113 (finder: local module finder @2d6c73b1 (roots: /home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules,/home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules/system/layers/base))
trigger class: io.undertow.servlet.handlers.ServletHandler
threw org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
at org.jboss.byteman.rule.Rule.<init>(Rule.java:232)
at org.jboss.byteman.rule.Rule.create(Rule.java:355)
at org.jboss.byteman.agent.TransformContext.parseRule(TransformContext.java:178)
at org.jboss.byteman.agent.TransformContext.transform(TransformContext.java:82)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:748)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:816)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:787)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:259)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92)
at org.jboss.modules.Module.loadModuleClass(Module.java:568)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
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)
at io.undertow.servlet.core.ManagedServlets.addServlet(ManagedServlets.java:47)
at io.undertow.servlet.core.DeploymentManagerImpl.createServletsAndFilters(DeploymentManagerImpl.java:231)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:176)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Transformed in:
loader: ModuleClassLoader for Module "io.undertow.servlet:main" from local module loader @7782d113 (finder: local module finder @2d6c73b1 (roots: /home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules,/home/koubsky/Wildfly8/wildfly-8.2.0.Final/modules/system/layers/base))
trigger class: io.undertow.servlet.handlers.ServletHandler
threw org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
org.jboss.byteman.rule.exception.TypeException: Rule.typecheck : unknown helper class org.jboss.byteman.koubsky.servlets.ServletHandlerLog for rule logServletHandler.handleRequest.cookies
at org.jboss.byteman.rule.Rule.<init>(Rule.java:232)
at org.jboss.byteman.rule.Rule.create(Rule.java:355)
at org.jboss.byteman.agent.TransformContext.parseRule(TransformContext.java:178)
at org.jboss.byteman.agent.TransformContext.transform(TransformContext.java:82)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:748)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:816)
at org.jboss.byteman.agent.Transformer.tryTransform(Transformer.java:787)
at org.jboss.byteman.agent.Transformer.transform(Transformer.java:259)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92)
at org.jboss.modules.Module.loadModuleClass(Module.java:568)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
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)
at io.undertow.servlet.core.ManagedServlets.addServlet(ManagedServlets.java:47)
at io.undertow.servlet.core.DeploymentManagerImpl.createServletsAndFilters(DeploymentManagerImpl.java:231)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:176)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Maybe I missed something in cofinguration, thanks for help.

[jameslivingston]

That problem is caused by your packages being under "org.jboss.byteman". Out of the box, JBoss/Wildfly is configured with JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman" so that all running code can see the necessary byteman classes like control flow exceptions.

By using that as a prefix, JBoss modules delegates to the system loader rather than looking at the module definition. It should work if you change the package prefix to something else. We should probably document that.

[radek.koubsky]

Yes, you are right. I changed the name of the package and everything works fine now. I had to use the "org.jboss.byteman" preffix in order to make my helper class visible via the "sys" option.

I put an example of use of the JBoss Modules plugin to my github repository (master branch) and documented it in readme file (RadekKoubsky/byteman-wildfly-log · GitHub)

[fmiguelez]

Hi,

We developed a small embedded profiler for our JEE application a few monthds ago, which is based on Java(TM) Execution Time Measurement Library. We measure execution time of EJB methods  using interceptors and POJO methods using byteman. Our profiler is installed as a JBoss module in our JBoss installation (JBoss EAP version 6.1.0 GA).

This worked worked as a charm until we had to go deeper inside methods of classes of JBoss modules such as Hibernate module.Then I came across this thread and felt that you had saved my day. ;-)

Happiness did not last long. I tried modyfing how our profiler generated byteman rules, by using "IMPORT" (and loading byteman-jboss-modules-plugin at JBoss startup). It did not work

I debugged the library and discovered that the problem was how ModulesLoader was instantiated inside JBossModulesSystem. Our older jboss-modules library (1.2.0.Final) inside JBoss EAP 6.1.0 uses a protected constructor. I created a small wrapper and it works perfectly now for both versions (current and older one).

As we use the on-demand byteman agent installation (via byteman-install) we considered that it would be great that this tool also supported specifying JBoss modules plugin, so I also modified bminstall scripts and Install class.A new argument "-m" can be used to indicate the tool to configure the byteman JBoss modules plugin.

It would be great that these changes would be applied in next byteman release. Changes are available in this pull request: Added support for older jboss-modules (1.2.0) and new "-m" option for byteman -install by fmiguelez · Pull Request #59 ·…

I also upgraded version of artifacts from 3.0.8 to 3.0.9-SNAPSHOT. I am not quite sure what policy you follow to version artifacts. If you want to omit this change or you want me to create individual pull requests quit separated changes just let me know.

Thank you for your great job.

Regards,

Fernando Miguélez

[adinn]

HI Fernando,

Thanks very much for providing this very nice patch. Both changes are very helpful and gratefully received.

I am afraid there is one legal formality I need from you in order to accept this patch. Could you please rerun the commit to your git repo using the git signoff option  (i.e. run the command as  'git commit --signoff ...') and then submit a new pull request including the new commit.

We used to ask contributors to sign a specific legal agreement called a Contributor License Agreement (CLA) before accepting contributions to ensure that we were legally safe to accept the code and continue to make it available under the relevant license. The signoff option is now all that we need to allow contributions to be accepted.

The sign-off is to be interpreted under the following terms: you certify that you have created the patch in question, or that you certify that to the best of your knowledge, it was created under an appropriate open-source license, or that it has been provided to you by someone else under those terms.

[fmiguelez]

I have not much experience with git. We still use mainly SVN at work.

I tried signing off (not quite sure about what it means) previous using git commit --amend --signoff  (as hinted here: Git sign off previous commits? - Stack Overflow )

I think I did it twice. Could you please review the pull-request to confirm that needed changes are performed?

Thank you Andrew and excuse my inexperience.

[adinn]

Thanks very much Fernando. Yes, the sign-off landed twice but that is not a problem.

I have merged the PR into the Byteman main branch and will release it in a 3.0.9 release as soon as I can. I am planning to release a new version of Byteman in the 4.0.0-BETA series once several key module changes percolate into JDK9 so it is likely that both releases will happen in the next week or two.

n.b. I will propagate your changes from the master branch to the 4.0.0-BETA branch. The latter is used to build a prototype version of Byteman for use on JDK9. You might well be able to use the next 4.0.0-BETA release (should be 4.0.0-BETA4) as an alternative to the 3.0.9 release for running your application on JDK8 (the 4.0.0-BETA releases are supposed to work on both JDK8 and JDK9). However, please note that support for JBoss modules imports is definitely broken for the moment when a 4.0.0 release is employed on JDK9. I don't suppose support for running on JDK9 matters much to you at the moment. I do expect to have a 4.0.0 release ready for EAP users before any of them need to move up to JDK9.

Thank you very much for this very useful addition to Byteman and congratulations on becoming a project contributor!

regards,

Andrew Dinn

[fmiguelez]

Great to hear that. We would like to use version 4.0.0 when it is ready it but we are currently stuck at JDK7 (recently upgraded from JRockit 1.6). Our JBoss version refuses to run on JDK8 so JDK9 upgrade will have to wait

We need to upgrade our software framework to run on newer versions of Wildfy first, but I do not think it is a priority since stability is prioritary in our production environments. If byteman 4 can run on JDK7 we could give it a try anyway.

Thank you for your time Andrew.

Regards,

Fernando