Problem Summary:
The document previewer when attaching files to consults is unable to preview PDF files - it's generating an error in the catalina.out file. This means that physicians cannot preview PDFs to determine if they are the correct ones to be attaching to a consult. Screenshot attached.
Expected Result:
A preview of the PDF should appear in the preview section of the Attach Consultation Document screen.
Actual Result:
An error is generated in catalina.out and the PDF does not appear in the preview area.
Steps to Reproduce:
(1) Go into a consult.
(2) Click "Attach File to Consultation" to open the "Attach Consultation Documents" screen.
(3) Click the name of a PDF document that has been added to the patient chart.
(4) Nothing appears in the preview area on the right of the screen.
(5) The catalina.out contains the error shown below.
Reproduced In:
12_1 Deb 157 (fresh install) + Ubuntu 12 LTS (fresh install)
Additional Information:
2013-06-07 10:56:33,918 ERROR [ManageDocumentAction:448] Error decoding pdf file 20130607105502test_pdf_2pgs.pdf
2013-06-07 10:56:34,002 ERROR [ManageDocumentAction:601] Error
java.lang.NullPointerException
at java.io.FileInputStream.<init>(FileInputStream.java:116)
at org.oscarehr.document.web.ManageDocumentAction.getPage(ManageDocumentAction.java:587)
at org.oscarehr.document.web.ManageDocumentAction.view(ManageDocumentAction.java:558)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:274)
at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:194)
at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:110)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at oscar.oscarSecurity.LoginFilter.doFilter(LoginFilter.java:127)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at net.sf.cookierevolver.servlet.CRFilterImpl.doFilter(CRFilterImpl.java:60)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.oscarehr.util.LoggedInUserFilter.doFilter(LoggedInUserFilter.java:60)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.oscarehr.util.DbConnectionFilter.doFilter(DbConnectionFilter.java:65)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.oscarehr.util.ResponseDefaultsFilter.doFilter(ResponseDefaultsFilter.java:69)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.oscarehr.util.ProblemCheckFilter.doFilter(ProblemCheckFilter.java:188)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Looks like a configuration issue. I can't reproduce this.
The code that's in question has to do with the DOCUMENT_DIR property. Can you make sure that your document directory stuff is setup properly.
update priority, since i verified this works on a clean install of 12.1 so I don't think it's affecting most people.
Hi Marc. I checked the DOCUMENT_DIR property - the directory existed, the file in question was there, permissions were good, etc. I am also able to open the document from other places in OSCAR (e.g. the Documents section). I also tested again in a fresh install of Deb 167 (instead of 157) with the same result.
Re-upping priority as I've been able to reproduce in multiple fresh Deb installs (157, 167) and on a live client site.
Also, if it helps, the value for the DOCUMENT_DIR parameter in both Deb installs is:
DOCUMENT_DIR=/var/lib/tomcat6/webapps/OscarDocument/oscar_mcmaster/document/
I think it's a setup issue.
it does some weird stuff. Just make sure that DOCUMENT_DIR is readable and writable by the tomcat user. and make sure it's parent directory is too.
The DOCUMENT_DIR is owned by Tomcat and the permissions are rwxr-xr-x. Went all the way back up to /var/lib/tomcat6/webapps and the permissions / ownership are the same all the way up.
If it wasn't readable/writeable by Tomcat, I shouldn't be able to view or write documents from the Documents section in the Encounter Screen should I?
Think I'll need some pointers here ...
Hi Marc. I tried this again in Deb 194 and with the same result. It's a fresh install and documents are opening fine everywhere else in OSCAR - they just won't preview in the consult section. Also, labs are previewing just fine in the consult section - the only thing impacted are documents.
it looks like the problem comes from the method createCacheVersion2() failing in ManageDocumentAction.
it would be helpful if you can run this and change the try-catch statement to print out the actual exception. I think this would give the best clue.
}catch(Exception e) {
log.error("Error decoding pdf file " + d.getDocfilename());
decode_pdf.closePdfFile();
}
to
}catch(Exception e) {
log.error("Error decoding pdf file " + d.getDocfilename(),e);
decode_pdf.closePdfFile();
}
Hi Marc. Where exactly would you like me to make the change? Remember that the Deb version doesn't provide access to the code to recompile so I won't be able to recompile if that's what you're looking for.
I retested this in the latest Deb (225) and the problem still exists. In case it helps, I've also attached the two files that I'm using for testing.
Reproduced again in the latest Deb (242). Attached catalina.out showing error, screenshot showing problem and oscar.properties file.
Hi Marc,
I am having the same issue. with the modification to include the error message you get:
2014-02-03 10:52:37,438 ERROR [ManageDocumentAction:448] Error decoding pdf file 20140130124013Test Fax.pdf
java.lang.NullPointerException
at org.jpedal.io.ObjectStore.saveStoredImage(Unknown Source)
This is pointing specifically to line 438:
decode_pdf.getObjectStore().saveStoredImage( documentCacheDir.getCanonicalPath() + "/" + d.getDocfilename() + "_" + pageNum + ".png", image_to_save, true, false, "png");
The full log is attached. Can you please indicate what is your JDK that you are using. I am having this problem with Java sun 6. I think it might be jdk dependent.
I use the same
marc@pearl:~/workspaces/ero/oscar$ java -version
java version "1.6.0_35"
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) Server VM (build 20.10-b01, mixed mode)
On Mon, Feb 3, 2014 at 11:15 AM, Hagir hagir@users.sf.net wrote:
--
Marc Dumontier
519-584-5601
http://oscardevel.com/wordpress/
http://www.oscarmcmaster.org
Related
Bugs:
#2597Check my commit Marc. I was able to spot the problem. The Jpadel class that creates cached images of the document (the PdfDecoder.java) uses page indexes from 1-n with one being the 1st page. The problem is the preview page is called with pageNum=0 (assuming the index starts with 0), which cant be created as page 0. It always returns as NPE. I tested it with pageNum=1 and it works a charm. Please let me know if this commit can be improved or if you think would affect any other area of the application.
Hagir
https://source.oscartools.org:8080/#/c/8932/
once reviewed, will add it to master branch
Fantastic that this one is fixed! Hagir, looks like the commit was accepted in 12_1. Can you add it to master as well?
I am having problem viewing documents in master, or in alpha branch. Makes it hard to verify.