• improve startlevel configuration using osginsf sites

    By Harald Albers 1 decade ago

    When configuring startlevels in profile documents, the syntax for osginsf bundles is quite clumsy.

    As far as I found out, I have to use a full path like

    osginsf:javaddin/updatesite.nsf/76B4F9E169F759F9C125790C0048064F/org.eclipse.equinox.ds_1.2.1.r36x_v20100803.jar

    The path contains the UNID of the Notes document hosting the bundle as well as any timestamps in the version, so every time I import an update site into the update site database, I have to figure out the paths of all bundles that require startup configuration again. 

    My requests in this context are:

    - Is there a shorter syntax for addressing osginsf bundles that I missed? If not, is there any chance to create such a feature?

    - It would also be helpful to have a wider input field for the startlevel configuration in the profile document.

    Regards,

    Harald

    • Answers

      By David Taieb 1 decade ago

       

      <p>
    The problem with specifying starting bundles for NSF based plugins is a bug. The correct behaviour shouldn&#39;t be different than for file based plugins i.e. to simply specify bundle id and not complete path. I will provide a fix for that soon.</p>
<p>
    I will change the configuration template to use a wider input field.</p>
<p>
    -david</p>

  • starting bundles by id

    By Harald Albers 1 decade ago

    To my observation, starting a bundle by its bundle id  from a profile document only works if the jar is located in ${dominobin}/javaddin/rcp/eclipse/plugins.

    If you place the jar in ${dominobin}/javaddin/shared/eclipse/plugins, a relative path like ../../../shared/eclipse/plugins/ is required. The same applies to file based sites.

    This is no problem because you do not have to specify the bundle's  file name and therfore the path will not change when updating the bundle.

    The problem with the osginsf paths ist that I do not know how to relatively address a bundle in a Notes update site database (is there a way?) and thus have to use the absolute path as reported by the diag command. 

    I would be perfectly happy with a relative path syntax like with the file sites (not including UNIDs, of course).

    Thank you for the exellent support.

    Harald

    • starting nsf bundles by id in DOTS 2.0

      By Harald Albers 1 decade ago

      Dear David,

      I'm still confused about how to start nsf bundles by their bundle id from a nsf based profile.

      Please be so kind and provide the exact syntax to use.

      Regards,

      Harald Albers

      • Only use the bundle id

        By David Taieb 1 decade ago

        Hello Harald,

        The original design was to simply use the bundle id without any path, no matter where the plugin came from (NSF based or file system). 

        So if you want to start plugin com.acme.myplugin the system is:

        in xml profile:

        or  to start the plugin with a particular level.

        in configuration database, simply type plugin name in the "List of plugins to automatically start".

        I tested it again this way and it seems to be working. Please let me know if you are experiencing problems.

        Thanks

        -david

         

        • problem starting org.eclipse.equinox.ds

          By Harald Albers 1 decade ago

          Thanks for your hints. On closer examination, I found that my auto start problem is bundle specific.

          For my OSGi environment to work, I have to start 4 bundles:

           

          org.eclipse.equinox.cm,&nbsp;javax.persistence,&nbsp;org.eclipse.persistence.jpa.osgi and&nbsp;org.eclipse.equinox.ds.

          I can start the first three bundles via the site's startPlugin element using their bundle ids, regardless of their location.

          org.eclipse.equinox.ds however generally requires a more specific location argument like osginsf:dots/updatesite-lib.nsf/8C0A3CDBDDEE2866C125790D002D15E3/org.eclipse.equinox.ds_1.2.1.r36x_v20100803.jar or ../../../updatesites/lib/eclipse/plugins/org.eclipse.equinox.ds.

          The only way to get this bundle started by its bundle id ist to place it in the primary osgi directory (${dominobin}\osgi-dots\rcp\eclipse\plugins).

          I have no idea why this bundle behaves different than the other ones. I get no error messages, and after a failing startup the bundle is reported as resolved and can get started manually.

          This happens on Windows XP and linux. I tried both Eclipse 3.6.2 and the recommended 3.5.1 version as the DOTS environment. I used the org.eclipse.equinox.ds version 1.2.1.R36x_v20100803 and 1.0.0.v20080427-0830.

          I am attaching a typical startup log that states that the bundle cannot be found (no big surprise).

          Do you have any idea what might go wrong here?

          • Did you add :start at the end?

            By David Taieb 1 decade ago

            From the log, I think you tried to add :start at the end and that may be the problem.

            I tried it in my local environment and it worked well. Here is a snippet of my dots.xml:

             

            &lt;osgiProfile&gt;

&nbsp; &nbsp; &nbsp;&lt;osgiOptions clean=&quot;false&quot;&gt;&nbsp;

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;startPlugin id=&quot;org.eclipse.equinox.ds&quot;/&gt;

&nbsp; &nbsp; &nbsp;&lt;/osgiOptions&gt;

&lt;/osgiProfile&gt;

            Note that you can do it via the config database too, but do not add :start at the end. In doubt, from the config document, go to the last tab which shows the xml format corresponding to your selections. Verify that :start is not at the end.

            • start was added by framework

              By Harald Albers 1 decade ago

              I just used the bare bundle id. The runlevel and :start werde added automatically.

              Looking at your configuration, I noticed that you set clean="false". Does your setup also work with the default value of true?

              Maybe the bundle runs due to remembered bundle state from a previous session.

               

              I created a simple setup to investigate the issue and still got the same results as with my previous setup:

              This environment has a file site containing only org.eclipse.equinox.ds and javax.persistence. In dots.xml I declare a default configuration with a new workspace (at that point non existent, to avoid caching effects) that includes the site and startPlugin elements for both additional bundles.

              The file system is like that:

               

              C:\Programme\IBM\Lotus\Domino\osgi-dots&gt;dir/S/B

C:\Programme\IBM\Lotus\Domino\osgi-dots\dotssec.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\launcher.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp

C:\Programme\IBM\Lotus\Domino\osgi-dots\shared

C:\Programme\IBM\Lotus\Domino\osgi-dots\site

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.core.contenttype_3.4.100.v20100505-1235.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.core.jobs_3.5.1.R36x_v20100824.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.core.runtime.compatibility.auth_3.2.200.v20100517.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.core.runtime_3.6.0.v20100505.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.equinox.app_1.3.1.R36x_v20100803.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.equinox.common_3.6.0.v20100503.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.equinox.preferences_3.3.0.v20100503.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.equinox.registry_3.5.0.v20100503.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.osgi_3.6.2.R36x_v20110210.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\rcp\eclipse\plugins\org.eclipse.update.configurator_3.3.100.v20100512.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\shared\eclipse

C:\Programme\IBM\Lotus\Domino\osgi-dots\shared\eclipse\plugins

C:\Programme\IBM\Lotus\Domino\osgi-dots\shared\eclipse\plugins\com.ibm.dots_2.0.0.201110061021.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse\plugins

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse\plugins\javax.persistence_2.0.3.v201010191057.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse\plugins\org.eclipse.equinox.ds_1.2.1.R36x_v20100803.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse\plugins\org.eclipse.equinox.util_1.0.200.v20100503.jar

C:\Programme\IBM\Lotus\Domino\osgi-dots\site\eclipse\plugins\org.eclipse.osgi.services_3.2.100.v20100503.jar

              Using this setup, the following profile only starts javax.persistence:

               

                  &lt;osgiProfile mqName=&quot;DOTS&quot; workspaceName=&quot;workspace-test2&quot;&gt;</div>

    &nbsp; &nbsp; &lt;osgiOptions clean=&quot;true&quot;&gt;</div>

    &nbsp; &nbsp; &nbsp; &nbsp; &lt;startPlugin id=&quot;<strong>org.eclipse.equinox.ds</strong>&quot;/&gt;</div>

    &nbsp; &nbsp; &nbsp; &nbsp; &lt;startPlugin id=&quot;javax.persistence&quot;/&gt;</div>

    &nbsp; &nbsp; &lt;/osgiOptions&gt;</div>

    &nbsp; &nbsp; &lt;site url=&quot;file:C:\Programme\IBM\Lotus\Domino\osgi-dots\site&quot;/&gt;</div>

    &lt;/osgiProfile&gt;</div>

              The following profile starts both bundles:

               

              <osgiProfile mqName="DOTS" workspaceName="workspace-test3">     <osgiOptions clean="true">         <startPlugin id="../../../site/eclipse/plugins/org.eclipse.equinox.ds"/>
              &nbsp; &nbsp; &nbsp; &nbsp; &lt;startPlugin id=&quot;javax.persistence&quot;/&gt;

&nbsp; &nbsp; &lt;/osgiOptions&gt;

&nbsp; &nbsp; &lt;site url=&quot;file:C:\Programme\IBM\Lotus\Domino\osgi-dots\site&quot;/&gt;

&lt;/osgiProfile&gt;

               

              The first case produces these log messages (shortened):

               

              <span style="color:#008000;"><strong>!ENTRY org.eclipse.osgi 4 0 2011-10-26 12:34:23.131</strong></span></div>

<span style="color:#008000;"><strong>!MESSAGE Bundle org.eclipse.equinox.ds@10:start not found.</strong></span></div>

&nbsp;

!ENTRY org.eclipse.core.runtime 4 0 2011-10-26 12:34:23.303

!MESSAGE&nbsp;

!STACK 0

org.osgi.framework.BundleException: The bundle &quot;org.eclipse.core.runtime_3.6.0.v20100505 [6]&quot; could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.equinox.app; bundle-version=&quot;[1.0.0,2.0.0)&quot;

&nbsp;

!ENTRY org.eclipse.update.configurator 4 0 2011-10-26 12:34:23.365

!MESSAGE Could not install bundle ../../site/eclipse/plugins/javax.persistence_2.0.3.v201010191057.jar &nbsp; Bundle &quot;javax.persistence&quot; version &quot;2.0.3.v201010191057&quot; has already been installed from: initial@reference:file:../../site/eclipse/plugins/javax.persistence_2.0.3.v201010191057.jar/

               

              The second setup produces these log messages (shortened):

               

              !ENTRY org.eclipse.core.runtime 4 0 2011-10-26 12:56:16.335

!MESSAGE&nbsp;

!STACK 0

org.osgi.framework.BundleException: The bundle &quot;org.eclipse.core.runtime_3.6.0.v20100505 [6]&quot; could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.equinox.app; bundle-version=&quot;[1.0.0,2.0.0)&quot;

&nbsp;

!ENTRY org.eclipse.update.configurator 4 0 2011-10-26 12:56:16.413

!MESSAGE Could not install bundle ../../site/eclipse/plugins/javax.persistence_2.0.3.v201010191057.jar &nbsp; Bundle &quot;javax.persistence&quot; version &quot;2.0.3.v201010191057&quot; has already been installed from: initial@reference:file:../../site/eclipse/plugins/javax.persistence_2.0.3.v201010191057.jar/

&nbsp;

!ENTRY org.eclipse.update.configurator 4 0 2011-10-26 12:56:16.413

!MESSAGE Could not install bundle ../../site/eclipse/plugins/org.eclipse.equinox.ds_1.2.1.R36x_v20100803.jar &nbsp; Bundle &quot;org.eclipse.equinox.ds&quot; version &quot;1.2.1.R36x_v20100803&quot; has already been installed from: initial@reference:file:../../site/eclipse/plugins/org.eclipse.equinox.ds_1.2.1.R36x_v20100803.jar/

&nbsp;

  • I think I found and fixed the bug

    By David Taieb 1 decade ago

    I was able to detect a problem in how the staring bundles id are resolved. Can you please try the attached launcher.jar sidepack to see if it helps. I also added some message when I detect that some plugins id cannot be resolved.

    Thanks

    -david

    • not solved

      By Harald Albers 1 decade ago

      Im very sorry, the problem still exists.

      I tested the new launcher on a) my development system and b) a dedicated test system.

      a) development machine no change in behavior, still absolute path required for starting DS bundle. Both the absolute and the bundle id-only startPlugin entries produce an "Unable to resolve starting plugin" console message.

       

      &gt; load dots -profile kis

<span style="font-size:9px;">&gt; Unable to resolve starting plugin osginsf:dots/updatesite-lib.nsf/8C0A3CDBDDEE2866C125790D002D15E3/org.eclipse.equinox.ds_1.2.1.r36x_v20100803.jar</span></div>

27.10.2011 08:49:10 &nbsp; Domino OSGi Tasklet Container started ( profile KIS )

&gt; tell kis ss ds

<span style="font-size:9px;">27.10.2011 08:49:26 &nbsp; [KIS] 10 &nbsp;ACTIVE &nbsp; &nbsp; &nbsp;org.eclipse.equinox.ds_1.2.1.R36x_v20100803</span></div>

      ----------------

      > load dots -profile kis
      > Unable to resolve starting plugin org.eclipse.equinox.ds
      27.10.2011 08:50:03   Domino OSGi Tasklet Container started ( profile KIS )
      > tell kis ss ds
      27.10.2011 08:50:23   [KIS] 10  RESOLVED    org.eclipse.equinox.ds_1.2.1.R36x_v20100803

      &nbsp;

.log of second example:

!ENTRY org.eclipse.osgi 4 0 2011-10-27 09:04:28.129

!MESSAGE Bundle org.eclipse.equinox.ds@10:start not found.

&nbsp;

      b) testing machine

      DOTS fails to start, even without configuration database or dots.xml. No log file is produced.

       

      &gt; load dots

&gt; Ausnahmebedingung in Thread &quot;main&quot;java.lang.IllegalStateException: java.lang.NullPointerException

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.launcher.OSGILauncher.startOSGI(OSGILauncher.java:288)

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.launcher.OSGILauncher.launchOSGIFramework(OSGILauncher.java:145)

Caused by: java.lang.NullPointerException

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.launcher.OSGiProfile.getKnownEclipseLocations(OSGiProfile.java:855)

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.utils.NameList.toString(NameList.java:212)

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.launcher.OSGiProfile.getStartupInitialProperties(OSGiProfile.java:773)

&nbsp; &nbsp; &nbsp; &nbsp; at com.ibm.dots.launcher.OSGILauncher.startOSGI(OSGILauncher.java:250)

&nbsp; &nbsp; &nbsp; &nbsp; ... 1 more

27.10.2011 09:07:39 &nbsp; Domino OSGi Tasklet Container started ( profile DOTS )

&nbsp;

       

       

       

    • problem caused by version string

      By Harald Albers 1 decade ago

      I finally found out what is so special about org.eclipse.equinox.ds: The version string contains an underscore. If you remove the underscore from the filename and manifest header, the bundle will be found and started.

      • possible cause

        By Harald Albers 1 decade ago

        I think the problem is due to fileName.lastIndexOf( '_' ) in NameList.extractPluginID(String name)

        • I think you nailed it

          By David Taieb 1 decade ago

          My code didn't expect _ to be in the version. Very unusual indeed. 

          I have attached another launcher.jar sidepack for testing. I also fixed the NPE that you found on getKnownEclipseLocations.

          Please let me know if all problems are fixed for you and I'll post a new release.

          • partial success

            By Harald Albers 1 decade ago

            The NullPointerException is gone, but the bundle still doesn't start.

            I get the console message "Unable to resolve starting plugin org.eclipse.equinox.ds".

            A simple test bundle with the same version string produces the same results.

            • Maybe third time is the charm :-)

              By David Taieb 1 decade ago

              I have found another similar issue (lasIndexOf instead of indexOf). Attached the sidepack as usual.

              Let me know

              Thanks

              -david

              • perfect!

                By Harald Albers 1 decade ago

                no problems any more!

                Thank you for providing a fix so quickly. I'm looking forward to the next release.

                Harald