We develop some java agent, which uses Java Instrumentation API to instrument loaded classes, which then, in some point in the future, should call back some classes from our agent. Agent adds itself to bootclassloader using instrumentation.appendToBootstrapClassLoaderSearch .

When putting this agent to fresh new Eclipse Virgo installation and trying to start it, we get
org.osgi.framework.BundleException: Bundle org.eclipse.equinox.region 1.0.0.v20110503 failed to start.
….

Caused by: java.lang.ClassNotFoundException: XXX_OurClassHere_XXX
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

I have tried to provide
-Dorg.osgi.framework.bootdelegation=sun.*,com.sun.*,our.package.*
to JAVA_OPTS before starting Virgo, but to no avail. -Dorg.osgi.framework.system.packages.extra did not help either.

Can you point me to some way to make our agent's classes visible to OSGI container and applications inside it?

Hope to hear from you soon,
Nikita

> it's not that easy since it would have to be aware not just of the OSGi environment
> but also about the 'outside OSGi' world. Here there are no bundles to interogate
> so it's hard to know whether the package is/will be available or not.

Right, but in case of Eclipse PDE, it seems to capture everything via Target Platform and Execution Environment(JRE and all that), so it should have a fairly precise idea of what comes from where; both at run- and compile-time. At least I thought so.

Anyhow, I tried to implement A' using PDE, but it's complaining about that JRE pkgs are not available for Export-Package in the (empty) framework extension fragment. Could you show me the manifest for that?

Another minor thing: would you be able to clean up the examples from those noisy  -s? (or am I the only one seeing those?)

> it's best to raise the issue with them
Sure I will. Just your examples seem to use Equinox, so I thought you might have run into this. ( you seem to be more responsive than Eclipse newsgroups

Thank you very much, again.

The only way I achieved it, was to declare it as VM argument -Xbootclass/a:/javax.transaction-1.1.0.jar in the OSGi Framework Run Configuration, since it was not sufficient to declare it as required PDE project build path library.

That's up to the tool really but it's not that easy since it would have to be aware not just of the OSGi environment but also about the 'outside OSGi' world. Here there are no bundles to interogate so it's hard to know whether the package is/will be available or not.

Note that I haven't used Eclipse PDE much but I believe it does not support yet boot classpath delegation but I might be wrong – it's best to raise the issue with them.

What about compile time enforcement of these constraints? Given the above configuration is based on aruntime property, how can, say Eclipse PDE, pick up the visibility rules and complain when something isn't explicitly imported (rather than deferring to a runtime crash)?

A good use-case for this technique is when an OSGi Framework is embedded in a larger Java application, e.g. a JEE application server. We can expose classes and interfaces such as the EJB APIs to the OSGi bundles. Again, the bundles simply import package javax.ejb and the deployer sorts out the details.

Thanks,
Senthil

@Simon: Thanks Simon – I've updated the blog entry with an explanation on how extension bundles can be used (solution A' above).

Cheers and thanks again for the comments!