1

Using Java instrumentation, we can access a class that is loaded by the Java classloader from the JVM and modify its bytecode by inserting our custom code, all these done at runtime. We need not worry about security, these are governed by the same security context applicable for Java classes and respective classloaders.

We are able to access some java application using this as they run in same classloader.

Now what we are trying to do is to access eclipse RCP application using java instrumentation but in RCP each bundle has its own classloader and our instrumentation code runs with java application classloader. when we are accessing it, it is throwing "Workbench has not been created yet" exception whereas the workbench is up and running.(I hope this is because of diffrent classloaders for both of them).

I have tried doing thing from here but to no success. Is there any way we can work RCP application out with java instrumentation.

Community
  • 1
  • 1
Amarendra
  • 11
  • 1

1 Answers1

0

When you instrument a class, the references of the inserted code are resolved by the ClassLoader of the modified class. If that class loader does not delegate to the application loader, e.g. because it is rule based and doesn’t know your instrumentation specific classes you can’t enforce delegation.

What you can do:

  • Use access override to define classes in the scope of the loader of the instrumented class. Since defineClass is final the bundle class loader can’t intercept it. However, the references of these injected classes are again resolved by the bundle loader so you have to add all required instrumentation classes this way.
  • Since the bundle class loader will do the parent loader delegation for the official Java API classes, you can instrument one of the core Java classes to add a helper method which will be called by the instrumented classes and delegates to your instrumentation classes which must have been added to the boostrap loader
  • You can use the trick described in the answer you have already linked to put a MethodHandle into the system properties. The instrumented classes can retrieve and invoke it as MethodHandle is a core class which will be correctly resolved by the bundle loader and the underlying method can be invoked without having access to its defining class (assuming that parameter and return types are all either primitive types or core classes).
Community
  • 1
  • 1
Holger
  • 285,553
  • 42
  • 434
  • 765
  • The last method has a problem you have to be aware of if you have multiple applications in the same JVM. Like for example when you deploy multiple wars in a servlet container. The problem is that the MethodHandle points to only one instance of your class when you probably need a different instance for each application. – Felix Jul 02 '15 at 17:50
  • 1
    @Felix: that can be handled via the keys, e.g. if you use the instrumented classes (`Class` objects) as keys, there can’t be a conflict. Nevertheless, the modularization of Java 9 might introduce new obstacles but maybe also new solutions… – Holger Jul 02 '15 at 18:08