Ah, OK. I have considered a similar extensibility mechanism in the past, using a static map of file extension to Serializer<Image> that the Image class would use to determine how to load a given image URL. But maybe a service provider would work better.
On Sep 8, 2011, at 10:59 AM, Chris Bartlett wrote: > On 8 September 2011 21:36, Greg Brown <[email protected]> wrote: >>> I have only scanned this thread quickly and haven't examined the code, >>> but couldn't the SVG stuff be moved into a separate JAR as Sandro >>> suggested, after modifying the relevant >>> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via >>> Pivot/Java service loaders? >> >> The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), >> which isn't included with the distribution. The only Pivot class that has a >> dependency on it is Drawing, but if an app doesn't use the Drawing class, >> then the SVG Salamander classes aren't loaded. So there's no need to use a >> service provider - the JVM already takes care of that. > > I just looked at the source of the Drawing class and see that it is > *ONLY* used for SVGs. The name suggested a much more generic class. > Drawing has a dependency on the SVG classes, and then Image references > it, and Image is referenced in a lot of places. > > I meant using a service loader to find a service (Image implementation > provider) that could handle SVGs and return an Image. > org.apache.pivot.wtk.media.Image.LoadTask.execute() currently > instantiates a new Drawing if the extension is 'svg'. > That extension could be the basis of a service lookup, which would > find the service that might use Drawing (or any other SVG 'provider'). > i.e. Don't hard code a reference to the Drawing class into Image. > > Support for additional Image formats could easily be added by dropping > more 'image provider services' jars into the classpath.
