dm Server
  1. dm Server
  2. DMS-1937

import of com.springsource.org.aspectj.weaver gives Uses violation:

    Details

    • Type: Defect Defect
    • Status: To Do To Do
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0.M6
    • Fix Version/s: None
    • Component/s: None
    • Environment:

      RHEL ,jdk6

      Description

      I had a spring AOP based application ,to support the same i had imported com.springsource.org.aspectj.weaver .Under dm1.0.2 it was working fine
      Now under dm 2 i get Uses violation

      Have attached the binary alongwith

        Activity

        Hide
        Benjamin Conlan added a comment -

        Also note that this leads to (or comes from) as systemic error with regards to the spring osgi repository with respect to the use of the Import-Library and aspectj:

        Library-SymbolicName: org.aspectj
        Library-Version: 1.6.5.RELEASE
        Library-Name: AspectJ
        Import-Bundle: 
         com.springsource.org.aspectj.runtime;version="[1.6.5.RELEASE ,1.6.5.RELEASE]",
         com.springsource.org.aspectj.weaver;version="[1.6.5.RELEASE, 1.6.5.RELEASE]"
        
        Show
        Benjamin Conlan added a comment - Also note that this leads to (or comes from) as systemic error with regards to the spring osgi repository with respect to the use of the Import-Library and aspectj: Library-SymbolicName: org.aspectj Library-Version: 1.6.5.RELEASE Library-Name: AspectJ Import-Bundle: com.springsource.org.aspectj.runtime;version= "[1.6.5.RELEASE ,1.6.5.RELEASE]" , com.springsource.org.aspectj.weaver;version= "[1.6.5.RELEASE, 1.6.5.RELEASE]"
        Hide
        Andy Wilkinson added a comment -

        I've run the attached binary with the improved uses analysis in place:

         Uses violation: <Import-Package: org.springframework.beans.factory.aspectj; version="0.0.0"> in bundle <ServiceCounterIntf_1.0.0>
                    Found conflicts:
                        package        'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.region.user_0.0.0' used by 'org.springframework.beans.factory.aspectj_3.0.0.RC1' in bundle 'org.springframework.aspects_3.0.0.RC1'
                        conflicts with 'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.org.aspectj.weaver_1.6.6.BUILD-20090909' imported by bundle 'ServiceCounterIntf_1.0.0'
        

        The problem here is that Spring's beans bundle (which uses Import-Package for AspectJ) is wired to the region.user bundle, i.e. the bundle that shares packages into the user region from the kernel. The ServiceCounterIntf bundle (which uses Import-Bundle for AspectJ) has been wired to the AspectJ weaver bundle as is expected when using Import-Bundle.

        All AspectJ packages are shared between the kernel and the user region to ensure that the serviceability support woven in by Medic will work in both environments. This means that, unfortunately, we can't fix the problem by no longer sharing the types between the kernel and the user region.

        We should give this some thought to see if there's anything clever we can do here to allow Import-Bundle to still work (it'd need to figure out the right packages to wire to from the region.user bundle somehow). In the meantime, this problem can be avoided by using Import-Package for AspectJ packages, rather than Import-Bundle.

        Show
        Andy Wilkinson added a comment - I've run the attached binary with the improved uses analysis in place: Uses violation: <Import-Package: org.springframework.beans.factory.aspectj; version="0.0.0"> in bundle <ServiceCounterIntf_1.0.0> Found conflicts: package 'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.region.user_0.0.0' used by 'org.springframework.beans.factory.aspectj_3.0.0.RC1' in bundle 'org.springframework.aspects_3.0.0.RC1' conflicts with 'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.org.aspectj.weaver_1.6.6.BUILD-20090909' imported by bundle 'ServiceCounterIntf_1.0.0' The problem here is that Spring's beans bundle (which uses Import-Package for AspectJ) is wired to the region.user bundle, i.e. the bundle that shares packages into the user region from the kernel. The ServiceCounterIntf bundle (which uses Import-Bundle for AspectJ) has been wired to the AspectJ weaver bundle as is expected when using Import-Bundle. All AspectJ packages are shared between the kernel and the user region to ensure that the serviceability support woven in by Medic will work in both environments. This means that, unfortunately, we can't fix the problem by no longer sharing the types between the kernel and the user region. We should give this some thought to see if there's anything clever we can do here to allow Import-Bundle to still work (it'd need to figure out the right packages to wire to from the region.user bundle somehow). In the meantime, this problem can be avoided by using Import-Package for AspectJ packages, rather than Import-Bundle.
        Hide
        Andy Wilkinson added a comment -

        The current implementation of nested frameworks means that using Import-Package is the best solution for this problem at the moment. I would advise using a tool like Bundlor to help with the generation of the Import-Package statement.

        The next revision of the nested frameworks implementation will make this considerably more straightforward as wirings between the two frameworks will be direct, rather than going through the surrogate user.region bundle as they do today. This means that, post 2.0, it may well become possible to use Import-Bundle for packages that are being shared into the user region from the kernel.

        Show
        Andy Wilkinson added a comment - The current implementation of nested frameworks means that using Import-Package is the best solution for this problem at the moment. I would advise using a tool like Bundlor to help with the generation of the Import-Package statement. The next revision of the nested frameworks implementation will make this considerably more straightforward as wirings between the two frameworks will be direct, rather than going through the surrogate user.region bundle as they do today. This means that, post 2.0, it may well become possible to use Import-Bundle for packages that are being shared into the user region from the kernel.
        Hide
        vishal added a comment -

        So basically to use any package from kernel region i cannot import the bundle as whole .My understanding was ,the import-bundle header is internally converted to import package by dm .

        Show
        vishal added a comment - So basically to use any package from kernel region i cannot import the bundle as whole .My understanding was ,the import-bundle header is internally converted to import package by dm .
        Hide
        Andy Wilkinson added a comment -

        Yes, that's correct. To use a package from the kernel region you should use Import-Package. The problem with using Import-Bundle is that the bundle that you're trying to import doesn't exist in the user region and the partitioning between the kernel and the user region intentionally prevents it from seeing the bundle in the kernel. This means that a second copy of the bundle is pulled into the user region to satisfy the Import-Bundle and leads to the uses conflicts described above.

        As I mentioned above this will improve when the next revision of the nested frameworks implementation is available but this will only be included in the 3.6 line of Equinox and won't be available before dm Server 2.0 is released.

        Show
        Andy Wilkinson added a comment - Yes, that's correct. To use a package from the kernel region you should use Import-Package. The problem with using Import-Bundle is that the bundle that you're trying to import doesn't exist in the user region and the partitioning between the kernel and the user region intentionally prevents it from seeing the bundle in the kernel. This means that a second copy of the bundle is pulled into the user region to satisfy the Import-Bundle and leads to the uses conflicts described above. As I mentioned above this will improve when the next revision of the nested frameworks implementation is available but this will only be included in the 3.6 line of Equinox and won't be available before dm Server 2.0 is released.
        Hide
        Glyn Normington (c) added a comment -

        dm Server is being proposed for donation to Eclipse as the Virgo project. We have reviewed all the outstanding issues against dm Server and we have decided that this issue will be migrated to a Virgo bugzilla bug automatically. For the moment, we are tagging this issue. When we have transferred the issue, we will close it noting the corresponding bugzilla bug which you should then track.

        Show
        Glyn Normington (c) added a comment - dm Server is being proposed for donation to Eclipse as the Virgo project. We have reviewed all the outstanding issues against dm Server and we have decided that this issue will be migrated to a Virgo bugzilla bug automatically. For the moment, we are tagging this issue. When we have transferred the issue, we will close it noting the corresponding bugzilla bug which you should then track.
        Hide
        Glyn Normington (c) added a comment -

        It is worth noting in the context of Virgo that when Virgo upgrades to the next rev (an OSGi standard, still being formulated) of the Equinox nested framework support, then it should be possible to expose kernel region bundles in the user region. Then we can extend import-bundle if necessary and this problem should then be solved.

        Show
        Glyn Normington (c) added a comment - It is worth noting in the context of Virgo that when Virgo upgrades to the next rev (an OSGi standard, still being formulated) of the Equinox nested framework support, then it should be possible to expose kernel region bundles in the user region. Then we can extend import-bundle if necessary and this problem should then be solved.

          People

          • Assignee:
            Unassigned
            Reporter:
            vishal
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              First Response Date: