Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [concierge-dev] Fragment Bundle Classpath
I have confirmed this is now working in Kura. Thanks for the quick fix!

—Dave

On Nov 3, 2014, at 9:03 AM, Jan S Rellermeyer <rellermeyer@xxxxxxxxxx> wrote:

Great! Thanks, Jochen.

I will look into the conflict detection problem. Looks like this is not covered by the TCK because otherwise I would have run into it before.

--Jan.

<graycol.gif>Jochen Hiller ---11/03/2014 06:21:43 AM---I provided a fix to git master where at least this log4j use case should work now.

From: Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx>
To: Concierge developer discussions <concierge-dev@xxxxxxxxxxx>
Date: 11/03/2014 06:21 AM
Subject: Re: [concierge-dev] Fragment Bundle Classpath
Sent by: concierge-dev-bounces@xxxxxxxxxxx




I provided a fix to git master where at least this log4j use case should work now. 
See http://git.eclipse.org/c/concierge/org.eclipse.concierge.git/commit/?id=2d4fc90c76a50671370fdb1ea0ff5e3afdc9a863

Other use cases which version range checks for fragment bundles with import packages which may conflict with host bundle import packages needs further implementation.

Bye, Jochen

On Sun, Nov 2, 2014 at 11:45 AM, Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx> wrote:
    OK. I will provide a patch in master for that, based on test cases.
    Bye, Jochen

    On Sun, Nov 2, 2014 at 11:25 AM, Tim Verbelen <tim.verbelen@xxxxxxxxxxxxxx> wrote:
      Hi Jochen,

      I was just looking into the same thing :-). I came to the same conclusion. In checkConflicts we should also check the version ranges and check if these are compliant and can resolve to a consistent class space.

      Cheers,

      Tim


      On 11/02/2014 11:04 AM, Jochen Hiller wrote:
        Hi all,

        The OSGi R5 Core spec says in chapter 3.14.
          A host and a fragment conflict when they cannot resolve to provide a consistent class space. If a conflict is found, the Fragment bundle is not attached to the host bundle.
         
        I've added a test case for that scenario: see http://git.eclipse.org/c/concierge/org.eclipse.concierge.git/tree/org.eclipse.concierge/test/org/eclipse/concierge/FragmentBundleWithImportsTest.java?id=1f892b107b94a7a34e48cf3ef963a2d469917098

        Jan/Tim: is the test case correct? My assumption is that if a bundle requirement has no attributes or no directives it should be "compliant", if not matching it can NOT be resolved. In the case of log4j it is OK to have import package statement for javax.xml.parsers both in host and fragment.

        I've created a patch for that where this test above does work, and also Eclipse Kura log4j is working. Shall I create a branch for this patch? I think the TCK tests should run before adding this to master.

        Bye, Jochen

        On Sat, Nov 1, 2014 at 12:38 PM, Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx> wrote:
          Hi all,

          I run the test again, and Concierge will complain with:

          [Sat Nov 01 12:15:49 CET 2014] [ERROR] Unsuccessfully attempted to attach JarBundleResource {storage/default/3/bundle0 of bundle [log4j.apache-log4j-extras-1.1.0]} to JarBundleResource {storage/default/2/bundle0 of bundle [log4j-1.2.17]}

          Exception: Conflicting import statement null from BundleRequirement{Import-Package javax.xml.parsers}

          [Sat Nov 01 12:15:49 CET 2014] [DEBUG] Solution: MultiMap {JarBundleResource {storage/default/2/bundle0 of bundle [log4j-1.2.17]}=[{BundleRequirement{Import-Package javax.jmdns;resolution:=optional}->Export-Package javax.jmdns}, {BundleRequirement{Import-Package javax.management}->Export-Package javax.management}, {BundleRequirement{Import-Package javax.naming}->Export-Package javax.naming}, {BundleRequirement{Import-Package javax.xml.parsers}->Export-Package javax.xml.parsers}, {BundleRequirement{Import-Package org.w3c.dom}->Export-Package org.w3c.dom}, {BundleRequirement{Import-Package org.xml.sax}->Export-Package org.xml.sax}, {BundleRequirement{Import-Package org.xml.sax.helpers}->Export-Package org.xml.sax.helpers}], Concierge System Bundle=[{BundleRequirement{Import-Package javax.jmdns;resolution:=optional}->Export-Package javax.jmdns}, {BundleRequirement{Import-Package javax.management}->Export-Package javax.management}, {BundleRequirement{Import-Package javax.naming}->Export-Package javax.naming}, {BundleRequirement{Import-Package javax.xml.parsers}->Export-Package javax.xml.parsers}, {BundleRequirement{Import-Package org.w3c.dom}->Export-Package org.w3c.dom}, {BundleRequirement{Import-Package org.xml.sax}->Export-Package org.xml.sax}, {BundleRequirement{Import-Package org.xml.sax.helpers}->Export-Package org.xml.sax.helpers}]}

          [Sat Nov 01 12:15:49 CET 2014] [INFO] framework: Bundle [log4j-1.2.17] started.

          AFAI understand the problem is in BundleImpl.attachFragment(), which calls checkConflicts(): this will report an import statement conflict. See BundleImpl lines 2292ff

          The host and fragment bundles manifest' are as:

          host (log4j_1.2.17.jar)

          Import-Package: javax.jmdns;resolution:=optional,
           javax.jms;resolution:=optional,
           javax.mail;resolution:=optional,
           javax.mail.internet;resolution:=optional,
           javax.management,javax.naming,
           javax.xml.parsers,org.w3c.dom,org.xml.sax,org.xml.sax.helpers

          fragment (log4j.apache-log4j-extras_1.1.0.jar)

          Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transform.dom,
           javax.xml.transform.sax,javax.xml.transform.stream,org.apache.log4j.config,
           org.apache.log4j.extras;version="1.1",org.apache.log4j.filter;version="1.1",
           org.apache.log4j.or,org.apache.log4j.rolling;version="1.1",
           org.apache.log4j.rule;version="1.1",org.w3c.dom,          org.xml.sax,org.xml.sax.helpers

          From what I see this should be OK as both imports will not use different version (unspecified). Maybe the conflict check has not only to consider the packages, but also its versions?

          Just as side note: the package javax.xml.parsers will be taken from org.osgi.framework.system.packages.extra framework property. I think that should be not related to this issue, but just to state on that.

          @Jan/Tim: is my assumption correct?

          Bye, Jochen


          On Sat, Nov 1, 2014 at 11:52 AM, Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx> wrote:

            Hi Tim, Dave,

            I yet have a test case for that which worked well some weeks ago.
            See https://github.com/JochenHiller/concierge-tests/blob/master/test/org/eclipse/concierge/test/integration/EclipseKuraTest.java, test01InstallAndStartLog4j

            I just ran the test and indeed, it does fail now again, the fragment will not be resolved.
            I will investigate into that.

            Thanks for pointing us to the issue.

            Jochen

            On Sat, Nov 1, 2014 at 11:19 AM, Tim Verbelen <tim.verbelen@xxxxxxxxxxxxxx> wrote:
              Hi Dave,
                Eclipse Kura is now running well in Concierge.
              That's great news!
                One item I can’t seem to resolve is logging. We use log4j and apache-log4j-extras to provide rolling log support. The apache-log4j-extras bundle attaches as a fragment to the log4j bundle. I can use packages exported by the host bundles with no problem, but when I attempt to use packages exported by the fragment bundle I get ClassNotFoundException. I included the error log below. My understanding is that when a fragment bundle attaches to the host, it extends the host’s classpath. I am happy to send a simple test case, bundles, manifest files, or whatever would be helpful.
              I'll look into it. A simple test case would help a lot.

              Cheers,

              Tim

              --
              Tim Verbelen
              Department of Information Technology
              Broadband Communication Networks (IBCN)
              Ghent University - iMinds
              Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
              T:               +32 9 33 14940 ; T Secr: +32 9 33 14900
              F:               +32 9 33 14899
              E:               tim.verbelen@xxxxxxxxxxxxxx
              W :               www.ibcn.intec.UGent.be 


              _______________________________________________
              concierge-dev mailing list
              concierge-dev@xxxxxxxxxxx
              To change your delivery options, retrieve your password, or unsubscribe from this list, visit
              https://dev.eclipse.org/mailman/listinfo/concierge-dev



        _______________________________________________
        concierge-dev mailing list
        concierge-dev@xxxxxxxxxxx
        To change your delivery options, retrieve your password, or unsubscribe from this list, visit
        https://dev.eclipse.org/mailman/listinfo/concierge-dev


      --
      Tim Verbelen
      Department of Information Technology
      Broadband Communication Networks (IBCN)
      Ghent University - iMinds
      Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
      T: +32 9 33 14940 ; T Secr: +32 9 33 14900
      F: +32 9 33 14899
      E:       tim.verbelen@xxxxxxxxxxxxxx
      W :       www.ibcn.intec.UGent.be


      _______________________________________________
      concierge-dev mailing list
      concierge-dev@xxxxxxxxxxx
      To change your delivery options, retrieve your password, or unsubscribe from this list, visit
      https://dev.eclipse.org/mailman/listinfo/concierge-dev
_______________________________________________
concierge-dev mailing list
concierge-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/concierge-dev
_______________________________________________
concierge-dev mailing list
concierge-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/concierge-dev

Back to the top