dm Server
  1. dm Server
  2. DMS-41

Unexpected wiring to lower package version

    Details

    • Type: Defect Defect
    • Status: Done Done
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.0.0.M1, 2.0.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Environment:

      Linux Ubuntu 8.04; Java 1.5.0_15; x64 CPU; Eclipse 3.4.1; Spring IDE 2.2.1.v200811281800; SpringSource Tool Suite dm Server Tools 1.1.0.v200811281800

      Description

      When a new version of a bundle that is used by two other bundles is added to the repository, it can consistently wire a different version of the shared bundle to each depending bundle. This pervents the two depending bundles from being able to reference any services, with an interface from the shared bundle, exported by the another. For example,

      bundle.dao.impl imports bundle.dao.interfaces;version [1.0.0,2.0.0)
      bundle.service.impl imports bundle.dao.interfaces;version [1.0.0,2.0.0)

      and in the user repository, there are bundle.dao.interfaces versions 1.0.0.CI1 and 1.0.0.CI2.

      What keeps happening, is that bundle.dao.impl uses version 1.0.0.CI2 and bundle.service.impl uses 1.0.0.CI1. So bundle.service.impl doesn't recognize the dao interfaces exported as services by bundle.dao.impl.

      In the attached zip are simple projects I used to reproduce this problem, as well as related files. I have been able to reproduce this error by doing the following.

      1. Copy bundle.dao.interfaces-1.0.0.BUILD20090203194937.jar (and source) to SERVER_HOME/repository/bundles/usr
      2. Add bundle.dao.impl to springsource-dm-server via the Eclipse tooling (dragging the project to the Server view)
      3. Start dm server via tooling
      4. Stop dm server
      5. Copy bundle.dao.interfaces-1.0.0.BUILD20090203194959.jar (and source) to SERVER_HOME/repository/bundles/usr
      6. Add bundle.service.impl to springsource-dm-server via the Eclipse tooling (dragging the project to the Server view)
      7. Start dm server via tooling

      This is when the error occurs.

      1. trace.log
        5.25 MB
        Kieran Nichol

        Activity

        Hide
        Sam Brannen added a comment -

        Have you been able to reproduce this from the command line (i.e., outside Eclipse)?

        If so, did you still experience the same issue when using the "-clean" flag with the startup script?

        Show
        Sam Brannen added a comment - Have you been able to reproduce this from the command line (i.e., outside Eclipse)? If so, did you still experience the same issue when using the "-clean" flag with the startup script?
        Hide
        Kieran Nichol added a comment -

        Yes, I was able to reproduce this from the command line using the same steps as with eclipse, but instead of deploying via eclipse, I JARed the two impl bundles and copied them into the pickup directory. No luck either with the "-clean" flag. Here is the output from the command line:

        kierann@spintop2:~/apps/springsource-dm-server-1.0.1.RELEASE-2$ bin/startup.sh -clean
        [2009-02-04 12:29:44.615] main <SPKB0001I> Server starting.
        [2009-02-04 12:29:45.400] main <SPOF0001I> OSGi telnet console available on port 2401.
        [2009-02-04 12:29:50.544] main <SPKE0000I> Boot subsystems installed.
        [2009-02-04 12:29:52.116] main <SPKE0001I> Base subsystems installed.
        [2009-02-04 12:29:53.890] server-dm-3 <SPPM0000I> Installing profile 'web'.
        [2009-02-04 12:29:55.076] server-dm-5 <SPSC0001I> Creating HTTP/1.1 connector with scheme http on port 8080.
        [2009-02-04 12:29:55.108] server-dm-3 <SPPM0001I> Installed profile 'web'.
        [2009-02-04 12:29:55.169] server-dm-5 <SPSC0001I> Creating HTTP/1.1 connector with scheme https on port 8443.
        [2009-02-04 12:29:55.207] server-dm-5 <SPSC0001I> Creating AJP/1.3 connector with scheme http on port 8009.
        [2009-02-04 12:29:55.335] server-dm-5 <SPSC0000I> Starting ServletContainer.
        [2009-02-04 12:29:56.144] server-dm-11 <SPPM0002I> Server open for business with profile 'web'.
        [2009-02-04 12:29:56.237] fs-watcher <SPDE0048I> Processing 'INITIAL' event for file 'bundle.dao.impl.jar'.
        [2009-02-04 12:29:58.623] fs-watcher <SPDE0010I> Deployment of 'bundle.dao.impl' version '1.0.0.BUILD20090204202207' completed.
        [2009-02-04 12:29:58.630] fs-watcher <SPDE0048I> Processing 'INITIAL' event for file 'bundle.service.impl.jar'.
        [2009-02-04 12:30:02.430] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'.
        [2009-02-04 12:30:08.427] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'.
        [2009-02-04 12:30:26.425] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'.
        [2009-02-04 12:31:20.428] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'.
        [2009-02-04 12:31:22.583] Thread-2 <SPOF0004I> Shutdown initiated.
        [2009-02-04 12:31:22.697] fs-watcher <SPDE0035E> Deployment of module 'file [/home/kierann/apps/springsource-dm-server-1.0.1.RELEASE-2/work/com.springsource.server.deployer/Module/bundle.service.impl.jar-0/bundle.service.impl.jar]' was interrupted.
        [2009-02-04 12:31:22.799] server-dm-9 <SPSC0002I> Shutting down ServletContainer.

        Show
        Kieran Nichol added a comment - Yes, I was able to reproduce this from the command line using the same steps as with eclipse, but instead of deploying via eclipse, I JARed the two impl bundles and copied them into the pickup directory. No luck either with the "-clean" flag. Here is the output from the command line: kierann@spintop2:~/apps/springsource-dm-server-1.0.1.RELEASE-2$ bin/startup.sh -clean [2009-02-04 12:29:44.615] main <SPKB0001I> Server starting. [2009-02-04 12:29:45.400] main <SPOF0001I> OSGi telnet console available on port 2401. [2009-02-04 12:29:50.544] main <SPKE0000I> Boot subsystems installed. [2009-02-04 12:29:52.116] main <SPKE0001I> Base subsystems installed. [2009-02-04 12:29:53.890] server-dm-3 <SPPM0000I> Installing profile 'web'. [2009-02-04 12:29:55.076] server-dm-5 <SPSC0001I> Creating HTTP/1.1 connector with scheme http on port 8080. [2009-02-04 12:29:55.108] server-dm-3 <SPPM0001I> Installed profile 'web'. [2009-02-04 12:29:55.169] server-dm-5 <SPSC0001I> Creating HTTP/1.1 connector with scheme https on port 8443. [2009-02-04 12:29:55.207] server-dm-5 <SPSC0001I> Creating AJP/1.3 connector with scheme http on port 8009. [2009-02-04 12:29:55.335] server-dm-5 <SPSC0000I> Starting ServletContainer. [2009-02-04 12:29:56.144] server-dm-11 <SPPM0002I> Server open for business with profile 'web'. [2009-02-04 12:29:56.237] fs-watcher <SPDE0048I> Processing 'INITIAL' event for file 'bundle.dao.impl.jar'. [2009-02-04 12:29:58.623] fs-watcher <SPDE0010I> Deployment of 'bundle.dao.impl' version '1.0.0.BUILD20090204202207' completed. [2009-02-04 12:29:58.630] fs-watcher <SPDE0048I> Processing 'INITIAL' event for file 'bundle.service.impl.jar'. [2009-02-04 12:30:02.430] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'. [2009-02-04 12:30:08.427] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'. [2009-02-04 12:30:26.425] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'. [2009-02-04 12:31:20.428] service-monitor-thread-1 <SPCC0001W> Mandatory reference '&someDao' in bundle 'bundle.service.impl' version '1.0.0.BUILD20090204202303' is waiting for service with filter '(objectClass=bundle.dao.SomeDao)'. [2009-02-04 12:31:22.583] Thread-2 <SPOF0004I> Shutdown initiated. [2009-02-04 12:31:22.697] fs-watcher <SPDE0035E> Deployment of module 'file [/home/kierann/apps/springsource-dm-server-1.0.1.RELEASE-2/work/com.springsource.server.deployer/Module/bundle.service.impl.jar-0/bundle.service.impl.jar] ' was interrupted. [2009-02-04 12:31:22.799] server-dm-9 <SPSC0002I> Shutting down ServletContainer.
        Hide
        Kieran Nichol added a comment -

        Oh! I should also mention, the command line trial was performed on a clean install of springsource-dm-server-1.0.1.RELEASE (that's why I have the -2 in the directory name).

        Show
        Kieran Nichol added a comment - Oh! I should also mention, the command line trial was performed on a clean install of springsource-dm-server-1.0.1.RELEASE (that's why I have the -2 in the directory name).
        Hide
        Andy Wilkinson added a comment -

        Thanks for the zip of your workspace, it's allowed me to reproduce and problem and figure out the cause.

        The problem is with the way that Import-Bundle is current expanded into Import-Package entries. As things stand, the algorithm will stop as soon as it finds an installed bundle with a matching symbolic name and version. This means that it won't find any installed bundles with higher ids, or bundles in the provisioning repository that meets the requirements, if there's already a bundle installed with a matching Bundle-SymbolicName and version.

        In the case of the scenario described above, the deployment of bundle.dao.impl was causing bundle.dao.interfaces-1.0.0.BUILD20090203194937 to be installed first, along with bundle.dao.interfaces-1.0.0.BUILD20090203194959. In the first case both these bundles are found in the repository, so Import-Bundle correctly expands to wire to the higher version. Now, when bundle.service.impl is installed, there are two installed bundles that match the required Bundle-SymbolicName. As 1.0.0.BUILD20090203194937 was installed first it is found first. This causes the search to stop and the second Import-Bundle is incorrectly expanded to an import of the package from this lower version.

        The solution is to update the search algorithm such that it searches all of the installed bundles, and all of the bundles available in the provisioning repository for a matching Bundle-SymbolicName and version within the required ranage, and then, from these candidates, selects the bundle with the highest version.

        Show
        Andy Wilkinson added a comment - Thanks for the zip of your workspace, it's allowed me to reproduce and problem and figure out the cause. The problem is with the way that Import-Bundle is current expanded into Import-Package entries. As things stand, the algorithm will stop as soon as it finds an installed bundle with a matching symbolic name and version. This means that it won't find any installed bundles with higher ids, or bundles in the provisioning repository that meets the requirements, if there's already a bundle installed with a matching Bundle-SymbolicName and version. In the case of the scenario described above, the deployment of bundle.dao.impl was causing bundle.dao.interfaces-1.0.0.BUILD20090203194937 to be installed first, along with bundle.dao.interfaces-1.0.0.BUILD20090203194959. In the first case both these bundles are found in the repository, so Import-Bundle correctly expands to wire to the higher version. Now, when bundle.service.impl is installed, there are two installed bundles that match the required Bundle-SymbolicName. As 1.0.0.BUILD20090203194937 was installed first it is found first. This causes the search to stop and the second Import-Bundle is incorrectly expanded to an import of the package from this lower version. The solution is to update the search algorithm such that it searches all of the installed bundles, and all of the bundles available in the provisioning repository for a matching Bundle-SymbolicName and version within the required ranage, and then, from these candidates, selects the bundle with the highest version.
        Hide
        Andy Wilkinson added a comment -

        I should have mentioned above that a workaround for this issue would be to use Import-Package, rather than Import-Bundle, for the packages in the interface bundle.

        Show
        Andy Wilkinson added a comment - I should have mentioned above that a workaround for this issue would be to use Import-Package, rather than Import-Bundle, for the packages in the interface bundle.
        Hide
        Kieran Nichol added a comment -

        I just ran into a problem that might be relevant to this bug. I had the same problem with javax.mail: I have a bundle.mailer which uses import-package: javax.mail;version=[1.4.0,2.0.0). When I have just the dm-server-provided javax.mail v1.4.0 in my repository everything works good, but if I add javax.mail v1.4.1 everything wires to it except bundle.mailer which still wires to the lower version.

        Here are bundle.mailer's imports:

        Import-Package: javax.activation;version="[1.1.0,2.0.0)",
        javax.mail;version="[1.4.0,2.0.0)",
        javax.mail.internet;version="[1.4.0,2.0.0)",
        org.apache.log4j
        Import-Bundle: org.springframework.context.support;version="[2.5.5.A,3.0.0)"
        Import-Library: org.springframework.spring;version="[2.5.5.A,3.0.0)"

        Show
        Kieran Nichol added a comment - I just ran into a problem that might be relevant to this bug. I had the same problem with javax.mail: I have a bundle.mailer which uses import-package: javax.mail;version=[1.4.0,2.0.0). When I have just the dm-server-provided javax.mail v1.4.0 in my repository everything works good, but if I add javax.mail v1.4.1 everything wires to it except bundle.mailer which still wires to the lower version. Here are bundle.mailer's imports: Import-Package: javax.activation;version="[1.1.0,2.0.0)", javax.mail;version="[1.4.0,2.0.0)", javax.mail.internet;version="[1.4.0,2.0.0)", org.apache.log4j Import-Bundle: org.springframework.context.support;version="[2.5.5.A,3.0.0)" Import-Library: org.springframework.spring;version="[2.5.5.A,3.0.0)"
        Hide
        Sam Brannen added a comment -

        Since this issue is now marked as complete, can you please update the fix version?

        Thanks,

        Sam

        Show
        Sam Brannen added a comment - Since this issue is now marked as complete, can you please update the fix version? Thanks, Sam
        Hide
        Andy Wilkinson added a comment -

        This issue has also been fixed in the 1.0.x branch, and will be included in 1.0.3.RELEASE.

        Show
        Andy Wilkinson added a comment - This issue has also been fixed in the 1.0.x branch, and will be included in 1.0.3.RELEASE.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kieran Nichol
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: