glassfish
  1. glassfish
  2. GLASSFISH-20937

loadClass from org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor needs to be improved

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2, 3.1.2.2, 4.0
    • Fix Version/s: None
    • Component/s: hk2, OSGi
    • Labels:
      None

      Description

      Currently, loading class way from org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor is directly starting OSGi bundle, then loading class.

      OsgiPopulatorPostProcessor(OSGiModuleImpl paramOsgiModule) {
      this.osgiModule = paramOsgiModule;

      loader = new HK2Loader() {

      @SuppressWarnings(

      { "unchecked", "rawtypes" }

      )
      @Override
      public Class<?> loadClass(final String className)
      throws MultiException {
      osgiModule.start();
      return (Class<?>) AccessController.doPrivileged(new PrivilegedAction() {
      public java.lang.Object run() {
      try

      { return osgiModule.getBundle().loadClass(className); }

      catch (Throwable e) {
      ...

      A question is as following,

      Why not directly calling Bundle.loadClass?

      According to API Doc,

      If this bundle's state is INSTALLED, this method must attempt to resolve this bundle before attempting to load the class.

      So, we only wish the bundle state is changed into Resolved rather than Active, right?

        Activity

        Hide
        TangYong added a comment -

        The same improvement also happened in the following method,

        [Class] org.jvnet.hk2.osgiadapter.OSGiModuleImpl

        public synchronized void resolve() throws ResolveError

        { // Since OSGi bundle does not have a separate resolve method, // we use the same implementation as start(); start(); }
        Show
        TangYong added a comment - The same improvement also happened in the following method, [Class] org.jvnet.hk2.osgiadapter.OSGiModuleImpl public synchronized void resolve() throws ResolveError { // Since OSGi bundle does not have a separate resolve method, // we use the same implementation as start(); start(); }
        Hide
        TangYong added a comment -

        I am sorry that things is not really simple,

        I have known why you firstly start the bundle. For some cases, eg. While kernel is starting, it will proceed to some higher hk2 start level, and attempt to start these bundles, if removing osgiModule.start(), these bundles will stay in Resolved state rather than active state.

        However, for general case(using @Service or getService), this will be Brute Force because we only want to load classes rather than starting the bundle.

        Right?

        Show
        TangYong added a comment - I am sorry that things is not really simple, I have known why you firstly start the bundle. For some cases, eg. While kernel is starting, it will proceed to some higher hk2 start level, and attempt to start these bundles, if removing osgiModule.start(), these bundles will stay in Resolved state rather than active state. However, for general case(using @Service or getService), this will be Brute Force because we only want to load classes rather than starting the bundle. Right?

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            TangYong
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: