org.jruby.embed.osgi suport in OSGi for ruby code and java code loaded from OSGi bundles

The patch contains an extra build dependency: http://repo2.maven.org/maven2/org/apache/felix/org.osgi.core/1.4.0/org.osgi.core-1.4.0.jar
which is why it is so big.

It'd be better to use the "official" org.osgi.core 4.2.0 (or 4.0.0) JAR instead of the Felix one.

Thanks for the review, it is the part of the code that I am the least happy with.
Unfortunately there is no standad OSGi API to access the file system.
My understanding is that OSGi strives to hide the file system; probably to support distributed services and cases where for some reason there is no file system.

I developed this reflective code when I added to jetty the osgi support: Servlet#getRealPath returns a File.
Since then I have reviewed what others are doing: spring-dm uses an OSGi fragment that is loaded only when equinox is detected. That fragment compiles only with equinox.
Pax-web used to return null on Servlet#getRealPath.

If someone has a different approach or would rather use a fragment I don't have a strong opinion myself.
We could make the bridging to the file system more pluggable: leave the default one here in place and let developers pass an optional FileLocator and BundleClassLoaderResolvor when they setup the system. That interface would be specific to jruby.

What do you think?

> It'd be better to use the "official" org.osgi.core 4.2.0 (or 4.0.0) JAR instead of the Felix one.
I made it a point to not use the org.eclipse.osgi
Is it this one http://repo1.maven.org/maven2/org/osgi/org.osgi.core/4.2.0/org.osgi.core-4.2.0.jar ?

I'll assume the maven central org/osgi version is the official one. Pulling it into build_lib now.

We'll need to update our maven artifacts/builds as well, but otherwise everything's been pulled in. I made a few minor cleanups.

Commits for including org.jruby.embed.osgi stuff:

commit 4d23231a9480164b9d670b3103f74a512720bb46
Author: hmalphettes <hmalphettes@gmail.com>
Date: Wed Jan 19 12:27:52 2011 +0800

add org.jruby.embed.osgi to jruby

Signed-off-by: Charles Oliver Nutter <headius@headius.com>

commit 127a74449d36d61920d3bc3d3a2a8f947ac174eb
Author: Charles Oliver Nutter <headius@headius.com>
Date: Sun Jan 23 21:52:59 2011 -0600

Fix nbproject and warnings about ambiguous varargs calls in OSGi stuff.

Commit to update to official and current org.osgi jar:

commit 2661473bb3d452d7725373c32f8c9dced4b2bd0b
Author: Charles Oliver Nutter <headius@headius.com>
Date: Wed Jan 26 22:44:35 2011 -0600

Switch to official and current OSGi jar.

I found a critical bug in the OSGiFileLocator#getBundle(String name) that I submitted in this patch:
I assumed that the Bundle was started: "//this should not happen as this bundle is marked as Activation-Policy: lazy"
That was wrong... the bundle is not lazily loaded at the moment.

This fixes the issue:
/**

• @param symbolicName
• @return The bundle with this symbolic name
  */
  public static Bundle getBundle(String symbolicName) {
  BundleContext bc = FrameworkUtil.getBundle(OSGiFileLocator.class).getBundleContext();
  if (bc == null)
  Unknown macro: { //if the bundle was not activatged then let's activate it. try { FrameworkUtil.getBundle(OSGiFileLocator.class).start(); } catch (BundleException e) { throw new IllegalStateException("Could not start the bundle " + FrameworkUtil.getBundle(OSGiFileLocator.class).getSymbolicName()); } bc = FrameworkUtil.getBundle(OSGiFileLocator.class).getBundleContext(); if (bc == null) { //this should never happen throw new IllegalStateException("The bundle " + FrameworkUtil.getBundle(OSGiFileLocator.class).getSymbolicName() + " is not activated."); } }

  for (Bundle b : FrameworkUtil.getBundle(OSGiFileLocator.class).getBundleContext().getBundles())

  Unknown macro: { if (b.getSymbolicName().equals(symbolicName)) { return b; } }

  return null;
  }

Here is the diff.
My apologies on being behind to test the actual jruby jar as built from ant.
Still looking for a light way to test OSGi during the build. I use eclipse and maven-tycho but that is really heavy weight and different from the rest of the jruby build.

We'll call this resolved with your latest patch applied (see below). Do keep trying to find a way for us to test this...I'm nervous going forward without something to test that it's all working correctly.

commit 7bec9de0021e03dca2c70c30a98d3f546820b7c3
Author: Charles Oliver Nutter <headius@headius.com>
Date: Wed Feb 16 13:26:02 2011 -0600

Additional fix for JRUBY-5384: org.jruby.embed.osgi suport in OSGi for ruby code and java code loaded from OSGi bundles

OK, investigating pax-exam and junit4osgi. Selection criteria: the simplest framework that will fit into jruby's ant build.
I am a tycho convert where tests are easy to run. But tycho is using maven 3 and would be a lot of extra files and constraints on the jruby build.
If someone in the community has experience with this type of situation I would be happy to hear suggestions and opinions and work on them.

The size isn't terribly important if we accept that it would fetch the test harness (not keep in repository) and probably only run in CI.