<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>Yes, that's it. Looking at </tt><tt>EmbeddedOSGiFrameworkLauncher</tt><tt>
      you generate that list from
      Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA and then add a few hard
      coded bits too it. IIRC, that property lists the packages that the
      system bundle exports and not what is delegated at CL level. <br>
      <br>
      What you probably want to use instead is <a
href="http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Constants.html#FRAMEWORK_BOOTDELEGATION">Constants.</a></tt><tt><tt><a
href="http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Constants.html#FRAMEWORK_BOOTDELEGATION">FRAMEWORK_BOOTDELEGATION</a>.
        The values in the configuration map given to launch(Map) should
        probably just be copied/merged with the subsystem configuration.
        Otherwise the framework will not have the correct view of the
        framework launch properties.<br>
      </tt><br>
    </tt>
    <div class="moz-cite-prefix">On 10/10/2012 10:45 AM, David
      Bosschaert wrote:<br>
    </div>
    <blockquote cite="mid:50753591.80905@redhat.com" type="cite">These
      packages are passed to the "jboss.modules.system.pkgs" system
      property which is set before the boot module loader is created:
      <br>
<a class="moz-txt-link-freetext" href="https://github.com/jbossas/jboss-as/blob/master/embedded/src/main/java/org/jboss/as/embedded/InitialModuleLoaderFactory.java#L66">https://github.com/jbossas/jboss-as/blob/master/embedded/src/main/java/org/jboss/as/embedded/InitialModuleLoaderFactory.java#L66</a>
      <br>
      <br>
      Cheers,
      <br>
      <br>
      David
      <br>
      <br>
      On 09/10/2012 17:16, Thomas Diesler wrote:
      <br>
      <blockquote type="cite">&gt; I think it would be fair to assume
        that the org.osgi.core packages are shared from the initiating
        classloader
        <br>
        <br>
        sure, but how does this work? The osgi subsystem loads the
        framework from a module which loads the org.osgi.framework
        packages from another module. The osgi system packages that can
        be configured through framework properties still come from the
        modules hierarchy and not from the syscp. So I wonder how
        anything except java.* and some system packages defined though
        Modules can be used from outside the AS.
        <br>
        <br>
        On 10/09/2012 05:12 PM, David Bosschaert wrote:
        <br>
        <blockquote type="cite">I think it would be fair to assume that
          the org.osgi.core packages are shared from the initiating
          classloader - the one that kicks off the framework launcher.
          This is what the TCK does too, it puts these packages
          explicitly on the org.osgi.framework.system.packages.extra
          property and this is how I have it currently implemented.
          <br>
          <br>
          I originally implemented a bridging approach where these
          classes were separate (so one instance of class X owned by the
          caller and one instance of class X owned by JBoss Modules) but
          this doesn't work when you are passing objects created by
          JBOSGi back into framework APIs. For example, if you call
          BundleContext.getService(ServiceReference sr) our
          implementation actually expect our own ServiceReferenceImpl to
          be passed in, which clearly doesn't work with the bridging
          approach (or it will get very complicated).
          <br>
          <br>
          Cheers,
          <br>
          <br>
          David
          <br>
          <br>
          On 09/10/2012 15:40, Thomas Diesler wrote:
          <br>
          <blockquote type="cite">
            <br>
            Hi David,
            <br>
            <br>
            I'm wondering how the org.osgi.core class sharing is
            supposed to work with this. If the AS7 internal framework is
            getting those types from the org.osgi.core module and the
            launcher/client gets them from the syscp they cannot be
            assigned - so the client could not consume/provide those
            types through the framework API.
            <br>
            <br>
            cheers
            <br>
            --thomas
            <br>
            <br>
            <blockquote type="cite">On 10/09/2012 09:57 AM, David
              Bosschaert wrote:
              <br>
              <blockquote type="cite">
                <br>
                    This can only be done with value types from the
                syscp, right?
                <br>
                <br>
                Yes, correct.
                <br>
                <br>
                    This code should not not be needed
                <br>
                    if (ctrl.getMode() == Mode.ACTIVE)
                <br>
                    return ctrl.getValue();
                <br>
                    ctrl.setMode(Mode.ACTIVE);
                <br>
                <br>
                I don't follow what you mean here? Where are you seeing
                that code? Or what is it a replacement for?
                <br>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
            -- <br>
            xxxxxxxxxxxxxxxxxxxxxxxxxxxx
            <br>
            Thomas Diesler
            <br>
            JBoss OSGi Lead
            <br>
            JBoss, a division of Red Hat
            <br>
            xxxxxxxxxxxxxxxxxxxxxxxxxxxx
            <br>
            <br>
            <br>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 
</pre>
  </body>
</html>