I prefer the originally-proposed addExports() but allowing the layer to authorize it -- with a security check or other custom constraint the implementer chooses to code.
Cheers, Paul On Fri, May 6, 2016 at 9:34 AM, Peter Levart <peter.lev...@gmail.com> wrote: > Hi, > > > On 05/06/2016 10:07 AM, Andrew Dinn wrote: > >> >Have you looked at injecting code in the victim module that invokes >>> >Module addExports to export the packages to the Byteman modules (modules >>> >plural because it sounds like the code is split between the unnamed >>> >module of the app class loader and the unnamed modulie of the boot >>> loader). >>> >> Not yet but I will do. n.b. for all practical purposes there is only one >> Byteman module although which one it is depends upon whether the agent >> jar is hoisted into the bootstrap or remains in the system loader. In >> the former case the code is split but only in that the Main class gets >> left in the system loader while all others sit in bootstrap. Since Main >> merely acts as a trampoline it does not require any special module >> linkage. >> regards, >> >> >> Andrew Dinn >> > > So if Main agent class is always loaded by bootstrap loader / unnamed > module, what about an API point in Instrumentation like: > > void addModuleExportsToBootstrapUnnamed(Module module, String pn); > > This would only allow adding exports from arbitrary module / package to > bootstrap unnamed module, which would contain (part of) agent. This part of > agent could also contain trampolines with regulated access from > instrumented / tested classes. Every call to such exposed code would have > to be done by invocation through Byteman layer then which could regulate > access by any means including but not limited to exporting the Byteman code > package to selected set of modules. > > Such limited addExports API would not allow to break encapsulation in > arbitrary ways. > > Regards, Peter > >