Hi,

I would assume that your JTidy library exports the SAX packages from
where your bundle must import them. Ideally, the JTidy library exports
SAX with a version and your bundle can specify that version to import.
If not you might want to remove the org.sax package(s) from the jre-1.5
(or jre-1.6) property in the sling.properties file to make sure, the
only visible org.sax packages come from the JTidy library.

If your JTidy library does not export the SAX packages (and neither
imports them), the bundle is corrupt and will never work because in the
OSGi environment no other bundle will be able to use the SAX classes.

Regards
Felix

Am Montag, den 24.01.2011, 16:50 +0100 schrieb Federico Paparoni: 
> Hi all,
> 
> My application uses a library (JTidy) that has an embedded version of
> org.xml.sax different from Felix one
> 
> 
> 24.01.2011 16:44:49.820 *ERROR* [127.0.0.1 [1295883888648] GET
> /content/david/2010/08/31/firststeps.pdf HTTP/1.1]
> org.apache.sling.servlets.
> resolver.internal.SlingServletResolver Original error class
> java.lang.LinkageError java.lang.LinkageError: loader constraint violation:
> when
>  resolving overridden method
> "org.apache.fop.fo.FOTreeBuilder.fatalError(Lorg/xml/sax/SAXParseException;)V"
> the class loader (instance of or
> g/apache/felix/framework/ModuleImpl$ModuleClassLoader) of the current class,
> org/apache/fop/fo/FOTreeBuilder, and its superclass loader (ins
> tance of <bootloader>), have different Class objects for the type
> org/xml/sax/SAXParseException used in the signature
>         at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:101)
> 
> Is there a way to tell my bundle that it must use org.xml.sax.* from the
> provided library?
> Cheers
> 


Reply via email to