Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers

[Peter Kriens <Peter.Kriens@xxxxxxxxx>]

First I am not sure why Xerces or Crimson needs to be started? My
assumption always was that they implement JAXP and that I get access
to either implementation via the OSGi XML Service or JAXP. In either
case, as a client I should be oblivious of any initialization issues.
A client should only bind to the package it uses, in this case
javax.xml.parsers. Initialization ordering can be handled by using the
XML service.

Please note that a package is NOT available unless it is resolved.
This is completely independent of its start/stop status. If you can
use an imported package, then its dependencies are fully met.

I am not sure I understand your comments about Linux? This sounds
awfully close to how it works with services. I express my dependency
on javax.xml.parsers and look for the DocumentBuilderFactory and
SAXParserFactory services. Depending on the installed bundle set and
imported package version I get the parser my deployer wanted me to use.

Your virtual bundle creates a meeting point to break the coupling between
the client and the implementation. This is EXACTLY the purpose of the
service model.

So you can have your cake and eat it too with services. You can use
import-package which is much more robust over time than require bundle,
and you can easily switch implementation packages by managing the set
of installed bundles.

Or am I missing something?

Kind regards,

     Peter Kriens



AB> I was speaking with John Fallows after the conference regarding the
AB> differences between Requires-Bundle and Import-Package, and what they
AB> can/can't be used for. From what I currently understand,
AB> Requires-Bundle allows an ordering between two implementations such
AB> that one implementation must be brought up/started before another; and
AB> that regardless of the contents of the bundle, I get access to only
AB> what that bundle provides to me.

AB> On the other hand, if I use Import-Package, I can gain access to
AB> classs defined in that package, regardless of which bundle they happen
AB> to be in. This is handy if refactorings have occured where classes
AB> have moved between bundles but have the old name. However,
AB> Import-Package is looser since it's not necessarily the case that the
AB> other bundle has been started by the time the requester needs access
AB> to it.

AB> It sems to me like Import-Package is being promoted since it allows a
AB> looser coupling between the client bundle and the server bundle (for
AB> want of better terminology). In other words, with something like an
AB> XML parser, I could have an import for javax.xml, and then I could
AB> substitute either Xerces or Crimson since both would export those
AB> packages.

AB> However, I don't think that last approach works tremendously well.
AB> Firstly, the import package is specific to a particular package, and
AB> it's quite likely that the implementation of the service is going to
AB> be in a different package from the interfaces in any case. (For a
AB> single-interface type service, it might be OK. This may be more common
AB> in embedded OSGi environments but may not scale well to larger
AB> systems.) Secondly, you do want to semantically ensure that an XML
AB> service is available (though perhaps not caring which one) if you are
AB> intending to use it, so you would need to have some kind of
AB> relationship between bundles.

AB> Linux packages handle this quite neatly with alternatives (on some
AB> systems). For commonly (re)implemented packages (Java and TeX being
AB> examples), the executables in /usr/bin are symlinks to entries in
AB> /etc/alternatives. These are then symlinks to a particular
AB> implementation, and you can switch between alternatives (which updates
AB> the links in /etc/alternatives). Debian's package management system
AB> handles this by providing different debian packages (ala bundles) that
AB> define a dependency on a virtual package, and implementations provide
AB> that virtual package. Clients are then expressed on the virtual
AB> dependency, but don't specifically recommend any particular
AB> implementation.

AB> It seems that this would be suitable for bundles, as well. I could define:

AB> Bundle-SymbolicName: org.example.client
AB> Requires-Bundle: org.xml.parser

AB> and

AB> Bundle-SymbolicName: org.example.service.xml.parser
AB> Provides-VirtualBundle: org.xml.parser

AB> The bundle starting code could read in the serivce bundle, and set up
AB> a virtual bundle for org.xml.parser that essentially was a
AB> duplicate/symlink of org.example.service.xml.parser, which could
AB> probably be done at bundle discovery time. This would mean that the
AB> org.example.service.xml.parser would have to be started before
AB> org.example.client, since it's a bundle dependency, but you've still
AB> got the same portability between implementations that Import-Package
AB> aims to solve.

AB> The reason I believe this solution is more elegant than using Import-Package is:
AB> 1) It defines a lifecycle dependency, which ensures that it gets
AB> started/stopped when the client needs it
AB> 2) It doesn't permit accidental importing of classes that happen to be
AB> in the same package in other bundles
AB> 3) There's no ambiguity if two bundles export the same package, since
AB> there can only be one bundle with a given symbolic name (virtual or
AB> otherwise). Of course, some mechanism would need to be implemented to
AB> deterministically pick between two bundles that provided the same
AB> virtual bundle; either through versioning or singleton of the virtual
AB> bundle
AB> 4) The implementation of the service doesn't have to be in any
AB> particular package, just the shared interface/classes (e.g. xmlApis).
AB> It may even be the case that these APIs are factored into their own
AB> bundle to allow multiple implementations to use the same set of
AB> interfaces

AB> I think Import-Package has its uses for dealing with 'split bundles'
AB> after a refactoring, but I think a virtual-bundle approach would be
AB> better for decoupling client/service implementations.

AB> Alex.


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599