I agree that versioning is a good solution to this problem. The JRE contains a variety of packages that are basically broken, e.g. javax.transaction which omits the UserTransaction interface (amongst others). So you need to ensure your bundles resolve against another bundle that provides the full javax.transaction API. Versioning that bundle higher than 0.0.0 and then importing at least that version is a good way.
Another possibility is to configure your framework so that the broken JRE packages are simply not exported. Check the documentation for your specific framework to find out how to do this. Also you could try using the "bundle-symbolic-name" attribute on Import-Package to ensure you import the package from a specific bundle, eg Import-Package: javax.transaction;bundle-symbolic-name:="myj2eelib.jar". However this is not much better than using Require-Bundle because introduces a dependency on a specific bundle. I would like to see this attribute extended to allow negative selections, e.g. Import-Package: javax.transaction;bundle-symbolic-name:="!system.bundle" which would resolve to any bundle that is NOT the system bundle. Neil On Tue, Dec 15, 2009 at 9:53 AM, Felix Meschberger <[email protected]> wrote: > Hi Andrea, > > Andrea Zoppello schrieb: >> Hi Felix, >> >> I know the rules on versioning, btw i've some doubts about. Here my doubt: >> >> 1) The concept of version range applies only to import-package or also >> to export-package. I i've understand well >> this apply only to import package.. is this right?? > > Yes, the range only applies to imports. > >> >> 2) What happen when an import-package in a client bundle could be >> satisfied in different wasy??? >> Which is the policy the framework choose?? Is this an implementation >> detail?? > > The framework is expected to try hard to create consistent dependency > trees and if possible to select a single export for all using > (importing) bundles. > > The full details are described in the core spec in section 3.7, > Resolving Process. > >> >> Just to explain this problems arise to me using some feature of >> javax.activation within javax.mail package. > > Oh, yeah. This is special ! ... and it is special drama by that matter. > > I suggest you create a bundle, which contains (and exports) both > javax.activation and javax.mail. This helps alot. The reason for this is > that a class from javax.activation tries to access resources from > javax.mail. > > > Regards > Felix > > >> >> Andrea >> Felix Meschberger ha scritto: >>> Hi, >>> >>> If your other bundle is exporting the javax.* packages with an explicit >>> version you might import-package the packages in your user bundle with >>> the "same" version. >>> >>> E.g. the provider exports javax.servlet;version=2.5, so you may declare >>> >>> Import-Package: javax.servlet;version=2.5 >>> >>> and get the proper export. >>> >>> HTH >>> >>> Regards >>> Felix >>> >>> Andrea Zoppello schrieb: >>> >>>> Hi all, >>>> >>>> I've the following problem: I'm starting my OSGi container ( Equinox ) >>>> with jdk1.6, so as the result >>>> i've the system bundle exporting the javax.* packages with version >>>> "0.0.0" >>>> >>>> From a my client bundle i want that during the resolution my bundle will >>>> not use the javax.* package exported >>>> by the system bundle, but the ones exported by another one. >>>> >>>> One of the possible solution, could be to use the require bundle instead >>>> of import package, but i'd still >>>> prefer the import-package. >>>> >>>> Maybe i'm missing something, but i don't know how to solve that >>>> problem... >>>> >>>> Is there any way to solve the general problem of having bundle "not >>>> wired" with packages exported by >>>> the system bundle??? >>>> >>>> Andrea >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
