Hi Dan, The sort of optionality that you’re looking for is usually best handled using a service. That way you can have multiple implementations using different, non-optional, implementation packages, and the rest is hidden from you behind your service API.
Actually ensuring that packages are truly optional can be quite involved, and usually leads to quite complicated code. You typically need to have a factory class in your bundle that attempts to load a class from the relevant package in a try/catch. When one succeeds then you choose that implementation. In this case you either need a default fallback, or DynamicImport-Package, or both, and it gets pretty nasty. I actually did a lightning talk about this at the 2013 OSGi community event. The slides are here: http://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward The specific scenario you describe below (XML parsing) seems exactly right for using an OSGi service, not an optional package dependency. Have you looked at the OSGi compendium’s XML Parser Service? Regards, Tim On 20 Mar 2014, at 15:33, Daniel McGreal <[email protected]> wrote: > Thank you BJ, > > Supposing I hadn't any classes from optional packages in my signatures then, > is the rest of the approach acceptable? Or is it more desirous to do a check > if the class exists before continuing, rather than trying to catch an > exception? > > Thanks, Dan. > > > On 20 Mar 2014, at 15:25, BJ Hargrave wrote: > >> If the types in the optional package are used directly in your api >> signatures, the optional package is not optional. Your package has a uses >> constraint on that package which the JVM will need access to to load and >> verify your type. >> >> Optional packages are more for: I'd like to log if the log package is >> present. But the log package does not appear in your API. That is, you have >> an implementation dependency on log not an API signature dependency on log. >> -- >> BJ Hargrave >> Senior Technical Staff Member, IBM >> OSGi Fellow and CTO of the OSGi Alliance >> [email protected] >> >> office: +1 386 848 1781 >> mobile: +1 386 848 3788 >> >> >> >> >> From: Daniel McGreal <[email protected]> >> To: OSGi Developer Mail List <[email protected]> >> Date: 2014/03/20 11:16 >> Subject: [osgi-dev] Handling Optional Dependencies >> Sent by: [email protected] >> >> >> >> Hi Osgi Developers, >> >> For the first time I have come up against a wish to implement an optional >> dependency. Specifically, I have an 'api' bundle with an interface which has >> a method that takes a String, which is actually some XML. I don't want to >> force a dependency on a specific XML parser but I would like to provide some >> helper methods for callers using JDOM (basically, that's ourselves!) along >> with this bundle. A whim leads me to investigate having an optional >> dependency on JDOM in the API bundle instead of creating a new bundle just >> for this utility. >> >> My question is, essentially, are there any examples of what this community >> considers best practice when dealing with the optional dependency at >> runtime? >> >> For example, one of the methods looks like this: >> >> private static Document buildXmlFromString(String strMsg) throws >> JDOMException, IOException { >> InputStream is = new ByteArrayInputStream(strMsg.getBytes()); >> SAXBuilder builder = new SAXBuilder(); >> return builder.build(is); >> } >> >> My naïvety leads me to implement a best guess at making JDOM optional for >> this method by >> >> private static Document buildXmlFromString(String strMsg) throws >> JDOMException, IOException { >> InputStream is = new ByteArrayInputStream(strMsg.getBytes()); >> try{ >> SAXBuilder builder = new SAXBuilder(); >> return builder.build(is); >> }catch(NoClassDefFoundError ncdfe){ >> throw new JdomUnavailableException(); >> } >> } >> >> private static class JdomUnavailableException extends >> UnsupportedOperationException {} >> >> Is this an OK approach? Are there intricacies around method signatures (e.g. >> the JDOMException above) or anything I should be aware of? >> >> Many thanks, Dan. >> >> >> >> >> _______________________________________________ >> 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
