Hi Neil,
first of all, thanks a lot for your time looking into this issue!
The funny thing is, that I wrote an answer yesterday and literally at
the last line of the email I found the solution. But it was to late to
rewrite the whole mail.
So there are two problems. One is, that I wasn't aware of the fact that
deploying with gogo is different than deploying with the Sling
management console because gogo always also deploys the optional
dependencies. With these optional dependencies it works with the right
version range as Neil describes it in a) of his mail. I tried that
before but it never worked because I got missing classes as I deployed
with the Management Console and didn't check the "deploy optional
dependencies" checkbox. This lead me to the assumption that I really
need the version 1.1.2 of jstl specifically because it worked with that one.
The problem that it doesn't work with the jstl 1.1.2 dependency still
persist but as Neil wrote it is not a preferable configuration so I
don't need a solution for that. But as I prepared all the information
yesterday anyway I will put them into the mail in case it's useful for
others.
I'm very happy to know that there are very skilled OSGi people like Neil
here in the mailing list who are willing to help with difficult problems
like the one below. I've put not just hours but person days into this
issue and without such help I would have had to skip using OSGi sooner
or later even though I like the concept a lot. Support like the one from
Neil let me look forward to my work with OSGi as I know there is a
strong last resort for problems I got stuck with. Thanks alot!
++ the transitive dependency proplem ++
The last time I tried to add not a huge bulk of information that would
take too much time for somebody to read. But it obviously was not enough
information.
I created an obr at http://www.wingsuit.de/obr/repository.xml. This
contains my jcrbrowser bundle with the dependency to version 1.1.2 of
jstl. But with its dependencies it can only be resolved inside Sling. So
I added all information I could get about the bundles in text files:
o http://www.wingsuit.de/dependency_problem/info_jcrbrowser.txt
o http://www.wingsuit.de/dependency_problem/info_taglibs.standard_1.1.2.txt
o http://www.wingsuit.de/dependency_problem/info_jstl_1.2.0.v20110728.txt
o http://www.wingsuit.de/dependency_problem/info_jstl_1.1.2.txt
The way I started the jcrbrowser is documented here
http://www.wingsuit.de/dependency_problem/starting_jcrbrowser.txt
Please see further comments inline:
Am 27.02.12 12:20, schrieb Neil Bartlett:
Hi Sandro,
It's difficult to reconstruct because you haven't listed all relevant
imports/exports, but I *think* this is the situation:
1) Your bundle 98 imports 2 packages:
o.apache.taglibs.standard.tag.rt.fmt AND javax.servlet.jsp.jstl.fmt.
Let's abbreviate these rt.fmt and jstl.fmt.
yes
2) There is a uses constraint: rt.fmt uses jstl.fmt.
I didn't see that in the error message at first. Thanks for pointing out.
3) Bundle 94 exports rt.fmt and imports jstl.fmt version
[1.1.2,2.0.0). Because of the version range, bundle 94 has wired to
the available export jstl.fmt version 1.2.
ok, I understand that.
4) Your bundle 98 wants to import rt.fmt from bundle 94 but it cannot
due to the uses constraint from point (2) above: it must import
jstl.fmt from the same exporter that bundle 94 imports it from.
Ok, there are two solutions to that as I understand it:
One is to make 94 resolving to version 1.1.2 of my jstl.fmt import
somehow. But I don't know how thats possible with OSGi right now. Thats
the question that is still open (which is ok for me).
I didn't set a version for my jstl import now so I will use whatever the
taglibs standard import will choose for itself. This works now when I
deploy my bundle with it's optional dependencies.
There appear to be several solutions to this problem:
a) Why is your import range of package jstl.fmt so tight?? Do you
*really* require only and exactly version 1.1.2 of the package??
Please read up on the concept of Semantic Versioning in OSGi. As a
consumer of the jstl.fmt API you should probably use a range like
[1.1.2,2.0), i.e. like bundle 94 (taglibs.standard).
I understand that changes between 1.1.2 and 1.2.0 should only be
relevant for API providers and not for consumers like me. As I wrote I
didn't deploy the optional dependencies which led me to the wrong
assumption that I specifically need the version 1.1.2 of jstl. I'm happy
that it works now as it should in the terms of Semantic Versioning.
b) Why have you installed two versions of the jstl bundle? You don't
seem to need the 1.2.0 version so why not just uninstall it? While
OSGi *can* handle multiple versions of the same export, it does make
life more complicated and easily leads to situations such as this.
Keep things simple unless you really have a need for both versions to
be present.
I didn't intentially did that. When deploying the jcrbrowser ("deploy -s
jcrbrowser") the 1.1.2 version got installed because of the jcrbrowser
dependency and the 1.2.0 version got installed because of the dependency
from taglibs.standard (94). I don't wanted both versions to be installed.
Please see
http://www.wingsuit.de/dependency_problem/starting_jcrbrowser.txt for
the output.
c) If you install both your bundle (jcrbrowser) and the
taglibs.standard bundle at the same time before resolving either of
them, then the Framework should try to pick the wiring that allows
them both to resolve. It looks like you installed and resolved
taglibs.standard first -- which resulted in it wiring up to the
highest available package export of jstl.fmt -- and then later
installed jcrbrowser, resulting in the uses constraint violation.
Wherever possible, install/uninstall bundles in batches *before*
attempting to resolve or start any of them.
I really just did a deploy of the jcrbrowser and no other actions
before. I could manually select the bundles needed and then resolve or
start them in a batch. That will always work. But I don't want my users
to do that. What I like about OSGi is, that my users can just "deploy -s
jcrbrowser" and all the dependencies are resolved for them. Is it not
the prefered way?
Thanks again,
Sandro
Hope this helps.
Regards, Neil
On Monday, 27 February 2012 at 07:52, Sandro Boehme wrote:
Hello,
the problem seems to be simple: My bundle declared two package
dependencies (package A and B) with always one specific version
version="[1.1.2,1.1.2]". The problem seems to be, that B has a
dependency to A with version="[1.1.2, 2.0.0)" of A. When deploying
my bundle, B gets wired to version 1.2.0.v20110728 of A and my
bundle doesn't resolve because it expects version 1.1.2 of A. See
http://www.wingsuit.de/transitive_dependency.jpg At runtime B has
the choice to use the latest version of A that nobody needs (what
it does) or to use the one that is actually imported by my
dependent bundle. I wonder why it uses the first option.
I set the import statements for A before B to try if the order is
relevant but that didn't change anything. I guess I got something
wrong or don't know something about how OSGi works. I checked the
OSGi spec but couldn't find a solution. Is there any declaration
that I overlooked? I know the question is not specific to Felix but
I would appreciate it a lot if anybody has a hint on how I could
proceed to resolve the dependency! In case the problem is described
in "OSGi in Action" I would bye the book.
In case it's needed there is some detailed background: I'm
developing a node browser application ("jcrbrowser") for Sling
that is written in JSP's with JSTL-EL. When I upload the two
dependencies from http://ebr.springsource.com/repository
com.springsource.javax.servlet.jsp.jstl-1.1.2.jar (A in my example)
and com.springsource.org.apache.taglibs.standard-1.1.2.jar (B in my
example) manually via the Management Console everything works
fine. It doesn't work with other versions of those two jars. I
would like to provide the jcrbrowser as a bundle in an OBR to make
it easy for users to install it in Sling with its dependencies. So
I declared all the jstl dependency as package imports like this:
Import-Package: javax.servlet.jsp.jstl.fmt;version="[1.1.2,1.1.2]"
and all the taglibs.standard dependency similar:
org.apache.taglibs.standard;version="[1.1.2,1.1.2]"... Then I added
my obr for my bundle and the obr from Spring that provides the two
bundles (http://sigil.codecauldron.org/spring-external.obr) to
Sling (Felix) and deployed my bundle.
The result of "start 98" is: org.osgi.framework.BundleException:
Constraint violation for package 'javax.servlet.jsp.jstl.fmt' when
resolving module 98.0 between existing import
95.0.javax.servlet.jsp.jstl.fmt BLAMED ON [[98.0] package;
(&(package=javax.servlet.jsp.jstl.fmt)(version>=1.1.2)(version<=1.1.2))]
and uses constraint 99.0.javax.servlet.jsp.jstl.fmt BLAMED ON [[98.0]
package;
(&(package=org.apache.taglibs.standard.tag.rt.fmt)(version>=1.1.2)(version<=1.1.2)),
[94.0] package;
(&(package=javax.servlet.jsp.jstl.fmt)(version>=1.1.2)(!(version>=2.0.0)))]
I understand it as:
"Constraint violation for package '...jstl.fmt' when resolving
jcrbrowser, expecting jstl.fmt version 1.1.2 but bundle jstl(99)
wired a higher version to bundle taglibs standard (94)."
Where 98=jcrbrowser 94=taglibs.standard (B) 99=jstl bundle
1.2.0.v20110728 (A) 95=jstl bundle 1.1.2 (A)
94 taglibs.standard: Import-Package:
org.apache.taglibs.standard.tag.common.fmt;version="[1.1.2,
2.0.0)"
99 jstl bundle-version 1.2.0.v20110728: Export-Package:
javax.servlet.jsp.jstl.fmt;version="1.2.0.v20110728";uses:="javax.servlet.http,javax.servlet.jsp"
95 jstl bundle-version 1.1.2:
Export-Package:
javax.servlet.jsp.jstl.fmt;version="1.1.2";uses:="javax.servlet.jsp"
Best,
Sandro
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
(mailto:[email protected])
For additional commands, e-mail: [email protected]
(mailto:[email protected])
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
