In an effort to improve performance as much as possible, I rewrote a custom render process to be one step calling a custom component.The speed improvement is great, but I am getting intermitant errors where files are missing from the global document storage. Now it would be great if the error included other information from the Document object to help debug exactly which object was missing it's file. It doesn't so I logged all the Document objects to track it down myself. I am creating com.adobe.idp.Document objects and put them into a Map later passed to the form render call's attachment parameter. This all occurs in about 1/2 second yet many times the GDS file behind the attachment is gone when the form render runs. I have tried with and without calling passivate, and passivateGlobally. It still fails. I just have to open then close the same task in Workspace a few times before it will occur. The bigger the attachments, the more likely it is to occur. The default disposal timeout is set to 10 minutes, so something must be explicitally disposing these documents. Any ideas?
I figured it out. Well, I stopped the error and have a theory as to why. My custom component uses Reader Extensions. I would get an error about not finding the classes unless I included the jar in the component.xml classpath. That would seem how most of the custom component samples I find do it. I found some blog entires referring to using <import-packages> instead of <classpath> for other errors. So I removed all the jars and the classpath. I added this:
Problem solved and my render got even faster. By including the Reader Extension jars, that created those classes in the component's classloader. That in turn required me to add the standard client jar containing Document. My theory is the the Document object in the component was garbage collected while a copy in the main classloader was still using a copy of it. Both pointed to the same GDS file. I also theorize that the GDS file gets deleted in the finalize of Document.