rblog

PhantomJS and 0kb PDF-files

Have spent the past few days troubleshooting an issue with PhantomJS. While veryfing in development and test all was fine, the application running on WebSphere did produce PDF’s like a charm. But when we moved to stage that did not work. The strange thing was that all tests we did from command line was fine, but the application kept on producing 0kb files – the logs told us. Not empty files, empty PDF’s produced by PhantomJS will be 5kb, so this was another issue. So, a new version of the application was deployed which did not delete from the temp folder, .js and .html file was found, but no still no PDF.

I did from previous problems know that a 0kb file on Windows is not always a real file, more a pointer to a file that was there before. And after hours of work with no progress, other than improved logging and good test suites (but not that good since they did not test what caused the error), it turned out to be a .css import in the HTML causing the error. The import statement should be environment aware, but it turned out that it was referring to the development environment. This worked out fine in test since there was no firewall blocking the endpoint, but in stage it was. HTML-files with the import statement pointing to a blocked endpoint caused PhantomJS to produce nothing. Even if the code
console.log(prettyTime() + " [INFO] Now create pdf")
page.render(output, {format: 'pdf'});
console.log(prettyTime() + " [INFO] PDF has now been created")

did not throw any error. While writing this post I did search for page.render and error handling and found this post https://github.com/amir20/phantomjs-node/issues/290 Must admit that I do not understand what

I have changed this behavior to make it more clear. You can do catch() from promise.

really means. I will forward it to the developers. Anyhow, html-file with this error causes PhantomJS to produce nothing without any error. If we removed the import, all fine.

Svn:externals to the rescue

For years I have had this folder structure in SVN related to Splunk

|
|_apps
| |_my-config
|
|_deployment-apps
| |_my-config

Whenever doing changes in my-config under apps I have had to manually copy the changes to deployment\my-config. But today I realized that I have had it, so Google to the rescue. The solution was to use

svn:externals

. So what I did was

  1. SVN deleted the folder deployment-apps\my-config
  2. Updated the folder deployment-apps, added the property svn:externals my-config https://mysvnserver/svn/myrepo/trunk/apps/my-config

Simple as that, and then when you do svn status you will see that deployment-apps\my-config has an X which indicates that is is external

svn status
X deployment-apps\my-config

Performing status on external item at 'deployment-apps\my-config':

My code is on git-hub

Years ago I created a Java program that exports the post from my blog and creates a PDF of the content. I used to have it on Google Code, but is has been taken down a long time ago. Finally I found time to store it elsewhere, now on Github https://github.com/rhellem/b2evolution-to-pdf

Not surprisingly since I am just about to finish the two day intensive GIT traning https://www.praqma.com/training/git-mastering/

Error when updating Windows service using wassservice.exe

Trying to update the nodeagent service following the guideline found at IBM Knowledge Center failed, complaining about the value of the -username was not known.

Unrecognized parameters encountered on the command line: 'wasadmin '

It turned out that I had a slash at the end of the folder name for the washome, which then acted as an escape char for the double qoute

-washome "D:\WebSphere\AppServer\"

Changed to

-washome "D:\WebSphere\AppServer"

and all was fine.

Fresh start

Not first day working after summer holiday, but first day at the office, giving it a fresh start, did wash my water bottle and even the whiteboard – very old doodles meaning nothing – better having a white whiteboard.

SVN scary

Sending common_select_deployitenvironment.bat
Transmitting file data .
Committed revision 666.

Better hurry up and commit yet another change.

Hjem