Change lookup mechanism to Service Provider

[GoogleCodeExporter]

Instead of relying on properties file for implementation classes, it would be 
great to use the standard lookup mechanism as defined by the JAR File 
specification:

http://download.oracle.com/javase/1.3/docs/guide/jar/jar.html#Service%20Provider

You may use the following class to lookup implementations of an interface if 
you need to maintain backward compatibility with JDK 5:

http://download.oracle.com/javase/6/docs/api/javax/imageio/spi/ServiceRegistry.h
tml

Original issue reported on code.google.com by gegasta...@gmail.com on 28 Jul 2011 at 8:56

[GoogleCodeExporter]

As you have seen XDocReport use custom solution with properties files whicg 
declare classes to instanciate and register (for template engine, document 
kind, converter ....). We want to support OSGi and this solution works on OSGi 
context (fr.opensagres.xdocreport.document is an OSGi bundle and 
fr.opensagres.xdocreport.document.docx, fr.opensagres.xdocreport.document.odt 
are OSGi fragments linked to fr.opensagres.xdocreport.document).

So I have 2 questions : 

1) Is Service provider supports OSGi?
2) for the moment XDocReport is JDK 5 compatible. You suggest us to use 
http://download.oracle.com/javase/1.5.0/docs/api/javax/imageio/spi/ServiceRegist
ry.html to maintain backward compatibility with JDK 5. You mean that you don't 
use 
http://download.oracle.com/javase/1.3/docs/guide/jar/jar.html#Service%20Provider
 but 
http://download.oracle.com/javase/1.5.0/docs/api/javax/imageio/spi/ServiceRegist
ry.html. Is that?

Thanks for your suggestion.

Regards Angelo

Original comment by angelo.z...@gmail.com on 28 Jul 2011 at 11:44

• Changed state: Accepted

[GoogleCodeExporter]

Answer from George : 

----------------------------------------
1) I cant tell for sure if its 100% OSGI compliant, but its worth testing it.

2) the first link is a guide explaining the Service Provider format.
The second one is the class that makes this happen

The SPI strategy looks very much alike what you are already using,
only that is a Java default standard.
----------------------------------------

Original comment by angelo.z...@gmail.com on 29 Jul 2011 at 7:53

[GoogleCodeExporter]

Hi,

Before using the SPI strategy, we would like test it in OSGi context if it 
works.

Anyway thank a lot for this information.

Regards Angelo

Original comment by angelo.z...@gmail.com on 29 Jul 2011 at 8:11

[GoogleCodeExporter]

Unless I miss smthg javax.imageio.spi.ServiceRegistry is not compatible with 
OSGi since It doesn't lookup for class at the bundle ClassLoader level :

http://www.mail-archive.com/osgi-dev@www2.osgi.org/msg00436.html

Original comment by pascal.leclercq on 30 Jul 2011 at 7:08

[GoogleCodeExporter]

Hi Pascal,

Thank a lot for your information. Perhaps we could develop oru own service 
provider (to manage OSGi) which is based on 
META-INF/services/fr.opensagres.xdocreport... insread of 
xdocreport*.properties. Client which wish implements their converter, template 
engine type, document type will use Java standard mechanism to define classes.

What do you think?

Regards Angelo

Original comment by angelo.z...@gmail.com on 30 Jul 2011 at 12:04

[GoogleCodeExporter]

Pascal are you sure that we cannot use javax.imageio.spi.ServiceRegistry? For 
OSGi context we have a bundle an fragment (implementation). Perhaps it works?

regards Angelo

Original comment by angelo.z...@gmail.com on 30 Jul 2011 at 4:39

[GoogleCodeExporter]

Original comment by angelo.z...@gmail.com on 1 Aug 2011 at 7:27

[GoogleCodeExporter]

Angelo can you have a look at TemplateEngineInitializerRegistry ?

Original comment by pascal.leclercq on 2 Aug 2011 at 5:18

• Changed state: Fixed