Thanks Timothy, > 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.
> 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? Normally, I would but my natural laziness combined with the very limited functionality I was intending to provide prompted me to investigate working with optional dependencies, something I hadn't done before. Just to add a new tool to the box, as it were. > 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 I have read this information and I will surely appreciate it greatly when a legitimate use case comes along. Many thanks, Dan. On 20 Mar 2014, at 15:44, Timothy Ward wrote: > 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
