Presentation loading fails in OSGi environment

I'm opening a new thread for this problem as suggested by Muhammad Adnan.

In my application, I work with dom4j library so I have to switch thread's context class loader to org.dom4j.Document's class loader to be able to use dom4j. Until Aspose.Slides for Java 16.11.0, I had no problem with loading presentations. With Aspose.Slides for Java 16.11.0, I'm not able to load presentation if I do the above context class loader switching.

I understand Aspose.Slides for Java does not depend upon dom4j, and I mentioned dom4j just for you to understand why I use context class loader switching.

What I'm asking is why was the test below executed without any exception using any of the previous versions of Aspose.Slides, but it fails with the latest one - 16.11.0?

This test gets executed in my OSGi (PaxExam) environment:

public void asposeSlidesTest() {

ClassLoader old = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(Document.class.getClassLoader());

try {

InputStream inputStream = new FileInputStream("Bonn_DMV_Classification.ppt");
Presentation presentation = new Presentation(inputStream);
inputStream.close();
} catch (Exception e) {
e.printStackTrace();
} finally {
Thread.currentThread().setContextClassLoader(old);
}
}

This is the part of the stack trace with the exception:

java.lang.NullPointerException
at com.aspose.slides.ms.pbdb106a0.p7cce53cf.af.do(Unknown Source)
at com.aspose.slides.ms.pbdb106a0.p883e881b.b.do(Unknown Source)
at com.aspose.slides.PatternFormat.do(Unknown Source)
at com.aspose.slides.PatternFormat.(Unknown Source)
at com.aspose.slides.zc.(Unknown Source)
at com.aspose.slides.zc.(Unknown Source)
at com.aspose.slides.FillFormat.setFillType(Unknown Source)
at com.aspose.slides.Presentation.final(Unknown Source)
at com.aspose.slides.Presentation.(Unknown Source)

Thanks,
Zeljko

Hi Zeljko,

I have observed the sample code shared by you and comments shared by you regarding using the thread context to org.dom4j.Document class. We have encountered the similar issue in past as well and we suggested customer to try using the this.getClass().getClassLoader() in thread context. Can you please try using the suggested guidelines shared over this link. I am hopeful things will work.

Many Thanks,