felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-730) Can't import highest package version
Date Mon, 29 Sep 2008 14:45:44 GMT

    [ https://issues.apache.org/jira/browse/FELIX-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635393#action_12635393

Richard S. Hall commented on FELIX-730:

Yes, Pierre, you should see the same behavior. The reason is that the resolver favors "resolved"
exports when chosing a candidate. The exports from the system bundle are always resolved,
so they will always have priority over unresolved ones. To do a test, you could try to resolve
your other exporter. If both the system bundle and your other exporter are resolved, then
when you resolve the client, it should wire to the higher version of the package.

I did make a change as a result of this bug, but it won't change your scenario. The issue
I changed was that the resolver was using "in use" (i.e., if there was a wire to the package)
instead of "resolved" as the state to determine whether the export was given higher priority
or not. This was a spec compliance bug, since it doesn't matter whether the package is used
or not, it only matters if the exporter is resolved.

> Can't import highest package version
> ------------------------------------
>                 Key: FELIX-730
>                 URL: https://issues.apache.org/jira/browse/FELIX-730
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>         Environment: linux
>            Reporter: Pierre De Rop
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: felix-1.2.2
>         Attachments: framework.log
> This issue follows up the thread: http://www.mail-archive.com/users@felix.apache.org/msg02152.html
> - I use jdk 1.6, and all the jdk packages are re-exported from the felix.properties file,
with version = 1.6.0
> - I have a bundle "jaxb.jar" which exports package "javax.xml.bind" with version 2.1.4

> (and the jdk also exports that package, but with version = 1.6.0).
> - a bundle "SipServletDeployer" simply imports "javax.xml.bind" (but without any versions)
> -> the issue is: the bundle "SipServletDeployer" gets wired to the 1.6.0 (jdk) version
of javax.xml.bind, instead of version 2.1.4.
> (but if I force "version=2.1.4" in  "SipServletDeployer", then it is properly wired to
the jaxb.jar bundle).
> Richard; could you please take a look at the log attached to this issue, because I don't
think package "javax.xml.bind" is 
> already loaded from system bundle (version 1.6.0) at the time "SipServletDeployer" is
loaded ...
> you can grep "javax.xml.bind" from the log file:
> DEBUG: WIRE: 64.0 -> javax.xml.bind.annotation -> 15.0     (bundle 64 is wired
to 15 (jaxb.jar) because it imports javax.xml.bind;version=2.1.4
> DEBUG: WIRE: 62.0 -> javax.xml.bind -> 15.0                     (bundle 62 is wired
to  15 (jaxb.jar) because it imports javax.xml.bind;version=2.1.4
> DEBUG: WIRE: 30.0 -> javax.xml.bind -> 0                         (but bundle 30
(SipServletDeployer) is wired to jdk (system bundle) because it does not import with v=2.1.4
> etc ...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message