JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-5384

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

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6RC1
    • Fix Version/s: JRuby 1.6RC3
    • Component/s: Embedding
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      2

      Description

      This extension to org.jruby.embed provides the support to load ruby code and java code from OSGi bundles.

      It was developed and built here: https://github.com/intalio/org.jruby.osgi/
      All developed by myself and using the same license and copyright than the rest of the jruby code.
      The attached patch adds the couple of new classes necessary to the sources of jruby.
      I tested a local build of jruby-complete and the MANIFEST generated looks fine.

      I have not figured out a way to run the testunits directly from ant.

      1. 0001-add-org.jruby.embed.osgi-to-jruby.patch
        153 kB
        Hugues Malphettes
      2. JRUBY-5384-critical-error.diff
        2 kB
        Hugues Malphettes

        Activity

        Hide
        Hugues Malphettes added a comment -

        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;
          }

        Show
        Hugues Malphettes added a comment - 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; }
        Hide
        Hugues Malphettes added a comment -

        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.

        Show
        Hugues Malphettes added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

        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

        Show
        Charles Oliver Nutter added a comment - 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
        Hide
        Hugues Malphettes added a comment - - edited

        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.

        Show
        Hugues Malphettes added a comment - - edited 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.
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Hugues Malphettes
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: