Package org.jboss.byteman.agent
Class HelperManager
- java.lang.Object
-
- org.jboss.byteman.agent.HelperManager
-
public class HelperManager extends Object
class used to manage lifecycle events for rule helpers
-
-
Constructor Summary
Constructors Constructor Description HelperManager(Instrumentation inst, ModuleSystem moduleSystem)
construct a manager
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description ModuleSystem
getModuleSystem()
long
getObjectSize(Object o)
This method exposes a capability of the Byteman agent's Instrumentation instance while avoiding exposing the instance itself.void
installed(Rule rule)
perform install processing for a rulevoid
uninstalled(Rule rule)
perform install processing for a rulevoid
uninstalled(Rule rule, Class<?> helperClass)
-
-
-
Constructor Detail
-
HelperManager
public HelperManager(Instrumentation inst, ModuleSystem moduleSystem)
construct a manager- Parameters:
inst
- will be non-null if we are running in an agentmoduleSystem
- must be non-null, use NonModuleSystem if nothing specal is needed
-
-
Method Detail
-
installed
public void installed(Rule rule)
perform install processing for a rule- Parameters:
rule
- an instantiation of a specific rule script as a Rule which has been successfully loaded into the agent, injected, type-checked and, optionally, compiled. Note that install processing happens when an injected rule is first triggered, not when it is injected. This ensures that a rule is not installed until it has been successfully type checked. It also ensures that helper life-cycle calls are not made underneath a ClassFileTransformer transform callback. This is so that execution of life-cycle code does not initiate class-loading without the desired associated transforms being applied -- transformation is not entered recursively. The same reasoning accounts for ehy type-checking is delayed until trigger-time. Note also that some given rule script may be injected into more than one method of more than one class. A METHOD spec may match more than one method when the descriptor is omitted. A CLASS or INTERFACE specification may match more than one class for a variety of reasons: multiple deployments of the same named class; omission of the package name in the specification; injection through interfaces; use of overriding injection. Every successful install into a specific method (of some given class) leads to one installed callback even when the rule is injected at multiple matching points in the bytecode of that method.
-
uninstalled
public void uninstalled(Rule rule)
perform install processing for a rule- Parameters:
rule
- an instantiation of a specific rule script as a Rule which has been successfully loaded into the agent, injected, type-checked and, optionally, compiled. Note that uninstall processing is performed by the Retransformer during unloading (or redefinition) of scripts after any retransform of the classesd affected by the scripts has been performed. When a script is uninstalled an uinstall event should occur for each case where there a prior install event i.e. for each method into which the rule was successfully injected, type checked and, possibly, compiled. In cases where a rule is redefined the process is slightly different. If the redefined rule fails to parse, inject or type check then any previously injected rule gets uninstalled. If a redefined rule is successfully, parsed, injected and type-checked then uninstall and reinstall of the rule is elided. The obvious benefit of elision is that the associated helper manager does not get spuriously deactivated and reactivated by a simple redefinition. However, two potentially (but only mildly) surprising consequences follow: 1) If a newly injected rule is triggered before a subsequent uninstall then it will be the target of the uninstalled call i.e. callbacks which take a Rule argument cannot rely on seeing the same rule instance at install and uninstall. Of course, both rules will still have the same name. 2) If a newly injected rule is not triggered before the uninstall happens, or is triggered and fails to type check or compile, then the previously installed rule will be used as the target of the uninstalled call i.e. callbacks which take a Rule argument cannot rely upon the uninstalled rule object being derived from the latest installed script text.
-
getObjectSize
public long getObjectSize(Object o)
This method exposes a capability of the Byteman agent's Instrumentation instance while avoiding exposing the instance itself. It returns an estimate of the object size or -1 in case an agent has not been installed.- Parameters:
o
- the object to be sized- Returns:
- an estimate of the size or -1
-
getModuleSystem
public ModuleSystem getModuleSystem()
-
-