dm Server
  1. dm Server
  2. DMS-2045

Incorrect package wiring is shown in the shell when the same package is available from two bundles

    Details

    • Type: Defect Defect
    • Status: Done Done
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: Sprint 14
    • Fix Version/s: Sprint 14, 2.0.0.RC1, 2.0.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Story Points:
      1

      Description

      I noticed this when looking at DMS-2029. Without the fix described in that defect two bundles will be present that export the org.apache.commons.logging package. The shell reports the following incorrect wiring:

      :> bundle examine 64
      
      Id:              64
      Name:            com.springsource.slf4j.org.apache.commons.logging
      Version          1.5.6
      State:           ACTIVE
      Spring Powered:  false
      Bundle Location: file:/Users/wilkinsona/dev/dm-server/jersey/dm-server/build-dm-server/target/package-expanded/springsource-dm-server-2.0.0.BUILD-20091113093257/repository/ext/com.springsource.slf4j.org.apache.commons.logging-1.5.6.jar
      
      Imported Packages:
          org.slf4j.spi [1.5.6, 1.5.6]
              exported by com.springsource.region.user 0.0.0 [1]
          org.slf4j [1.5.6, 1.5.6]
              exported by com.springsource.region.user 0.0.0 [1]
      
      Exported Packages:
          org.apache.commons.logging 1.1.1
              imported by org.springframework.transaction 3.0.0.RC1 [32]
              imported by org.springframework.beans 3.0.0.RC1 [25]
              imported by org.springframework.osgi.io 1.2.1 [5]
              imported by org.springframework.web.servlet 3.0.0.RC1 [56]
              imported by org.springframework.context.support 3.0.0.RC1 [54]
              imported by org.springframework.oxm 3.0.0.RC1 [31]
              imported by org.springframework.context 3.0.0.RC1 [26]
              imported by org.springframework.core 3.0.0.RC1 [27]
              imported by org.springframework.web 3.0.0.RC1 [33]
              imported by org.springframework.js 2.0.8.RELEASE [55]
              imported by org.springframework.osgi.core 1.2.1 [3]
              imported by org.springframework.jdbc 3.0.0.RC1 [29]
              imported by com.springsource.org.apache.commons.digester 1.8.1 [63]
              imported by org.springframework.orm 3.0.0.RC1 [30]
              imported by org.springframework.osgi.extender 1.2.1 [4]
              imported by com.springsource.org.apache.commons.beanutils 1.8.0 [62]
              imported by com.springsource.org.apache.commons.httpclient 3.1.0 [20]
              imported by com.springsource.org.apache.struts 1.1.0 [61]
              imported by org.springframework.aop 3.0.0.RC1 [23]
          org.apache.commons.logging.impl 1.1.1
              imported by com.springsource.org.apache.commons.digester 1.8.1 [63]
      

      The Equinox telnet console reports the following correct wiring:

      osgi> packages 64
      org.apache.commons.logging; version="1.1.1"<com.springsource.slf4j.org.apache.commons.logging_1.5.6 [64]>
        com.springsource.org.apache.struts_1.1.0 [61] imports
        com.springsource.org.apache.commons.beanutils_1.8.0 [62] imports
        com.springsource.org.apache.commons.digester_1.8.1 [63] imports
      org.apache.commons.logging.impl; version="1.1.1"<com.springsource.slf4j.org.apache.commons.logging_1.5.6 [64]>
        com.springsource.org.apache.commons.digester_1.8.1 [63] imports
      

        Issue Links

          Activity

          Hide
          Andy Wilkinson added a comment -

          The problem here is that the State that the Shell works with is a copy of the system state with a different wiring, i.e. the Shell's showing the correct wiring for the State that it's working against, it's the State itself that's wrong.

          When we create a copy of the State in the quasi framework we need to ensure that we maintain the source State's wiring.

          Show
          Andy Wilkinson added a comment - The problem here is that the State that the Shell works with is a copy of the system state with a different wiring, i.e. the Shell's showing the correct wiring for the State that it's working against, it's the State itself that's wrong. When we create a copy of the State in the quasi framework we need to ensure that we maintain the source State's wiring.

            People

            • Assignee:
              Andy Wilkinson
              Reporter:
              Andy Wilkinson
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1h
                1h
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 46m Time Not Required
                46m