Which PDFBOX jar are you adding? The FULL 9 meg app or just PDFBOX.jar ?

 

How are you calling the classes?  From SSJS in an XPage or from a Java Code Element called from SSJS ? 

 

If you are calling the classes from an XPage then the jar's have to go in the ibm\lotus\domino\xsp folder on the designer client and server. 

 

If calling from an agent or jave code element then the jar's go in the ext\lib folder 

 

 

 First run (which initiated the org.apache.commons.logging problem): pdfbox-app-1.7.0.jar

 Second run: pdfbox-1.7.1.jar and fontbox-1.7.1.jar

 

I have written a couple of higher level wrappers in java, so I call the java wrappers from SSJS.

 

pdfbox-app-1.7.0.jar included a version of org.apache.commons.logging, while the new ones do not include this library. IBM distributes one version that resides in osgi/..../plugins directory. If 2 are installed, they seem to conflict when invoked (even when they are identical). The osgi/.../plugins will not find the org.apache.commons.logging if it is installed in lib/ext and vice versa.

 Ok, I'll do some testing later today.  

 

So you are calling your Java wrappers that are implemented as POJO's or Java Code elements? 

 

 I have added some rather large .jar files to the nsf directly and did not suffer from the designer performance you were referencing.  

 

Have you bumped the amount of memory DDE uses beyond the 256 default ? 

 

 

 That's great.

 

The Java wrappers are POJO's. In some cases the documents are populated from SSJS, but mostly I pass document unids to an even higher level POJO and do the work in Java. That way I can test the entire code in Eclipse with a more convenient debugger.

 

The performance was reduced with ODFDOM installed, but unusable with both ODFDOM and PDFBOX.

 

The DDE memory have been adjusted to 768M or 1024M. I run it in a Virtualbox VM on Ubuntu. My guess is that the performance reduction is due to network traffic when refreshing / rebuilding the application after a save. Also upgrading the application on remote servers is an incredibly slow process.

 

The server is not state of the art. There's only one user. The plan is to upgrade in january, which might help.

 

 

 Johnny

 Ok.  I dropped the pdfbox-app-171 jar into the Notes/jvm/lib/ext folder.

 

All the code ran fine and I'm not seeing any conflict with the osgi loader. 

 

It may be because I'm not calling any other code that uses commons logger, but at the moment everything seems to be jelled just fine. 

 

 

 Yes, my experience too. Sorry for lack of precision in my description earlier.

 

The reason it took some time for me to identify the problem was that everything seemed to work fine. The problem was detected when I tried to use a XPage that needed this OSGI module (Domino webDav). The server error-log pointed to org.apache.commons.logging error, then the second org.apache.commons.logging could be located inside pdfbox-app.

 So what if you use the PDFBOX jar without the commons logging and add the common loggings jars to the nsf itself.

 

As that uses a separate class loader that should allow the pdfbox to resolve the class but not conflict with the osgi one when it wants to load. 

 

I will try this over the weekend to see if it at least the class is resolvable.  Kind of kludgy, but might work.