I've been looking into implementing this, and had some discussion with Andrew via email, but it probably should have been here on the forum (oops).
> The problem is basically that to typecheck rules, interpret rules,
> compile/run rules, and use a helper it may need to see additional
> classes. As far as I can tell from your explanation, they should all
> use the same set of visible classes, so having typechecking and
> interpreting use the helper-subclass loader ("Cl_Hs") would work, aside
> from it not existing yet at typechecking time.
Yes, that's right the job merely requires providing each module system a
means of handing over a suitable classloader when it is needed. The
actual creation of the helper subclass will not actually require any change.
The hard bit is to create the helper subclass in a module loader which
can see both the trigger class's module and the helper class's module.
But each module system provides a way of specifying module links so we
jsut need to gather the desired linkage and then get the module system
to support it.
n.b. the helper class's module may already have imported the trigger
class module. For example, that would be needed if one (or some)of the
helper builtins accepted $this as an argument. But then again the helper
class's module may only need to import other modules. For example, the
helper builtins might only be passed primitive, String or List values
but one (or some) of them might want to be able to test or print the
state of current Transaction.
> So we'd need a plugin system for creating that loader (and equivalent
> information for typecheck-time), with potential implementations for non
> -modular systems (equivalent to what we have now), JBoss Modules, OSGi,
> and Jigsaw. Optionally being able to auto-detect what impl to use.
Yes, we need a level of indirection so that Byteman juts creates a
normal class loader by default but can use a module-loader specific
mechanism when a module system is in place in the runtime. If an IMPORT
statement is found in the body of a rule or at top level in a script
then we need a module loader which imports the requested modules. So a
module-system plugin will give us that level of indirection. This means
the current mechanism also needs wrapping up inside a plugin mechanism.
In fact that change should probably be committed as a preparatory step
(although, as always with a design problem, you may actually need to
implement a working solution before you know what to prepare for :-).
Yes, the subclass loader needs to be created at type check time and then
used to create the subclass. I think that is already how it is done. If
not then only a minor tweak should be needed. The current code already
uses a special loader that delegates to the trigger class's loaded when
it creates the subclass. That is to avoid polluting the trigger class's
loader with a Byteman-generated class. This means that when a rule is
uninjected the subclass loader can be dropped and bothit and the
generated class can be garbage-collected.
n.b. if a rule requires no IMPORTs then we probably don't need to
delegate to the module plugin -- we could just create a delagting loader
to inherit from the trigger class's loader. However, I think it would be
best to delegate anyway so the plugin manages all cases, even the
trivial ones. One reason for dong everything via the plugin is to keep
it uniform. In particualr, we will eventually need to support some sort
of lifecycle end callback -- when a rule is uninjected we should tell
the module loader that the corresponding module loader is no longer
needed -- and that will be easier if we don't have any special casing to
consider.
I still am not sure what is possible as regards Jigsaw. I am sure we
need a mechanism to access classes across Jigsaw module boundaries but I
have not researched what runtime options we have for doing that. Anyway,
JBoss modules will be the first place to start.
Auto-detection would be a nice add-on but for the first cut I suggest
that we use an agent-load time parameter to reset the default.
> We'd also need some new rule syntax for adding imports to the data that
> gets handed to the plugin to create it. I don't think the details of a
> "IMPORT MODULE ..." would need to be the same since the module systems
> are different, but obviously we wouldn't add unnecessary differences.
Yes, I think as far as user visible changes go we just need to support
an IMPORT statement. Any text following the IMPORT keyword (up to end of
line) would be module-system specific text identifying a single module
to be imported into the helper subclass's loader.
An IMPORT could occur in the body of a rule, say in the same position as
the HELPER clause between METHOD and LOCATION clauses, in which case it
applies just for that rule. It could also occur at the top level in a
script, in which case applies to all subsequent rules in script.
Multiple IMPORT statements, both within a rule and at top level, would
accumulate. So, the plugin needs to be passed a list of String in the
request for a loader.
The current set of top-level imports could be emptied by a top-level
IMPORT statement with no trailing text (other than white space). That's
similar to how the HELPER setting currently works. it would probably
also be be legitimate to use an empty IMPORT statement as the first
IMPORT in a rule body to cancel the top-level imports just for that rule.
I agree with making the plugin handle all cases, whether IMPORT it used or not.
Obviously what is needed will change as problems are discovered during development, but as a first pass interface the plugin API could look something like:
The no-modules implementation being "return (new ClassbyteClassLoader(triggerClassLoader)).addClass(helperAdapterName, classBytes);" and no-ops for the other two method.
The method to destroy the adapter may be needed or useful for some module systems. We might need to pass the Rule or some other identifier to the create and destroy methods so that the implementation can identify which is which properly.
Obviously byteman will need to load the plugin implementation, so how is something we need to think about. In the case of JBoss Modules, a plugin will obviously need to use the modules API which should be in the system classloader. One obvious option is to require the plugin implementation to be visible to the system classloader and have the class name specified via the javaagent options (and bminstall script option). Another way would be to pass the jar name and read something out of META-INF but that would limit it to one plugin implementation per jar.
Related to that, would we want to ship our implementations in the main byteman jar (requiring all dependencies at compile time) or as separate jars (needing more configuration to use). We should support loading them from a jar for external plugin implementations, but our ones could go either way.
