Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Embedding
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In an embedded scenario the JRuby runtime bundle needs to import the packages used by the executed (j)ruby code. As these packages could certainly not be specified at build time, adding the DynamicImport-Package: * directive to the OSGi manifest seems to be a proper solution. The following line can be added to jruby.bnd.template:

      DynamicImport-Package: *
      

        Issue Links

          Activity

          Hide
          Charles Oliver Nutter added a comment -

          Is there any down side to adding this? I don't know OSGi well.

          Show
          Charles Oliver Nutter added a comment - Is there any down side to adding this? I don't know OSGi well.
          Hide
          Christian Brensing added a comment -

          The DynamicImport-Package-Header is the last line of defense and should only be used when there are no other options. The Header defines that if at runtime a class must be loaded whose package is not specified via Import-Package then it will be searched in all available bundles. You can not specify the version of the dynamically imported package. But for JRuby which executes scripts with unknown imported java packages, using this Manifest-Header is the only OSGi-implementation-independent way of preventing a ClassNotFoundException. With Equinox another solution is using Buddy-Classloading.

          The Groovy project solved this issue with DynamicImport-Package too, see GROOVY-3192.

          Show
          Christian Brensing added a comment - The DynamicImport-Package -Header is the last line of defense and should only be used when there are no other options. The Header defines that if at runtime a class must be loaded whose package is not specified via Import-Package then it will be searched in all available bundles. You can not specify the version of the dynamically imported package. But for JRuby which executes scripts with unknown imported java packages, using this Manifest-Header is the only OSGi-implementation-independent way of preventing a ClassNotFoundException . With Equinox another solution is using Buddy-Classloading. The Groovy project solved this issue with DynamicImport-Package too, see GROOVY-3192 .
          Hide
          Tommy M. McGuire added a comment -

          Adding that DynamicImport-Package to the JRuby jar's MANIFEST.MF would allow the JRuby jar's class loader to access any (Java) package exported by any other jar file in the OSGi container. However, once a linkage is established between the JRuby jar and some other jar, it is permanent. No other script, running in the context of the JRuby jar's class loader, will be able to access any other version of that package from any other jar file.

          That limitation is problematic in the enterprise OSGi environment, where you could have several JRuby applications deployed to an OSGi container and multiple versions of library jars floating around. The only workaround that I can see would be to have multiple copies of the JRuby jar, under different names and versions, and associate one copy with each application.

          DynamicImport-Package is bad OSGi practice because OSGi is a module system, and rather than declaring a dependency on a specific version of some specific (Java) package (or jar file; that can be done either way), it indicates a dependency on anything, and those dependencies are only determined at runtime.

          I think that any usage of DynamicImport-Package in the JRuby jar file could better be done by having the proper Import-Package or Import-Bundle in the application, and making sure that any JRuby scripts run in the context of the application's class loader. It works fine for JRuby on Rails applications built using Warbler. Also, there has been some recent discussion on the jruby-user mailing list recently, in the context of the JSR 223 scripting engine; I cannot link to the archive at the moment, but the subject is "running jruby in an osgi container".

          Show
          Tommy M. McGuire added a comment - Adding that DynamicImport-Package to the JRuby jar's MANIFEST.MF would allow the JRuby jar's class loader to access any (Java) package exported by any other jar file in the OSGi container. However, once a linkage is established between the JRuby jar and some other jar, it is permanent. No other script, running in the context of the JRuby jar's class loader, will be able to access any other version of that package from any other jar file. That limitation is problematic in the enterprise OSGi environment, where you could have several JRuby applications deployed to an OSGi container and multiple versions of library jars floating around. The only workaround that I can see would be to have multiple copies of the JRuby jar, under different names and versions, and associate one copy with each application. DynamicImport-Package is bad OSGi practice because OSGi is a module system, and rather than declaring a dependency on a specific version of some specific (Java) package (or jar file; that can be done either way), it indicates a dependency on anything , and those dependencies are only determined at runtime. I think that any usage of DynamicImport-Package in the JRuby jar file could better be done by having the proper Import-Package or Import-Bundle in the application, and making sure that any JRuby scripts run in the context of the application's class loader. It works fine for JRuby on Rails applications built using Warbler. Also, there has been some recent discussion on the jruby-user mailing list recently, in the context of the JSR 223 scripting engine; I cannot link to the archive at the moment, but the subject is "running jruby in an osgi container".
          Hide
          Tommy M. McGuire added a comment -
          Show
          Tommy M. McGuire added a comment - Ah, there it is. The thread on jruby-user starts with: http://archive.codehaus.org/lists/org.codehaus.jruby.user/msg/4A539DEE.8010102@trialox.org
          Nick Sieger made changes -
          Field Original Value New Value
          Link This issue is duplicated by JRUBY-5414 [ JRUBY-5414 ]
          Hide
          Hugues Malphettes added a comment -

          +1 to everything Tommy explained.

          org.jruby.embed.osgi.OSGiScriptingContainer contributed in JRUBY-5384 is probably a good solution to the use case described: instead of having to resolve all the objects of the bundle from the thread's context-classloader, the classloader of the bundle can be added to the instance of the OSGiScriptingContainer itself.

          JRUBY-5414 has a more detailed explanation about this.

          Show
          Hugues Malphettes added a comment - +1 to everything Tommy explained. org.jruby.embed.osgi.OSGiScriptingContainer contributed in JRUBY-5384 is probably a good solution to the use case described: instead of having to resolve all the objects of the bundle from the thread's context-classloader, the classloader of the bundle can be added to the instance of the OSGiScriptingContainer itself. JRUBY-5414 has a more detailed explanation about this.

            People

            • Assignee:
              Unassigned
              Reporter:
              Christian Brensing
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: