In a previous post, I showed you how to render a PDF documentation (.pdf) with an extra image prepended to the whole PDF document using PDF Rewriter. In this post, I'll show how to render a PDF documentation with an additional PDF page appended as a back-cover. This PDF backcover can not be done by PDF Rewritter, as an Adobe staff confirmed PDF Rewriter (used Apache FOP 0.95) has yet to support merging PDF files.
**UPDATE: External links to pdf-files on http-servers and https-servers supported since Apache FOP 1.1.
For merging PDF files, I'll be using a Java PDF library - pdfbox. For this, we need pdfbox app OSGi bundle/jar (1.8.2 as of this writing or the latest version) deployed in the Felix OSGi container so we can develop a .jsp to call into the API for merging PDFs. So get the library ready in your CQ environment with these steps:
In this post, I'll show you how to render PDF documentation (.pdf) with an extra image page prepended to the front of the whole PDF document, and how to embed an extra image to the top of an existing page.
According to a previous post - Adobe CQ Renders Pages with Custom Extension - making .pdf an accetable extention can be done in CQ. In fact, by default, the .pdf extension is already accetable by CQ, according to an existing Page.pdf.jsp file at
I'm using CQ5.6.1 which is not too reliable when I played with extension so after try and error, I modified the above file to reference proxy.jsp using full path and without carriage return at the end of line to avoid any possible 500 Internal Server Error. The Page.pdf.jsp file now saved have only one line:
You may already know CQ can render HTML pages with .html extension, I'd like to show you how to tell CQ to render pages with other custom extension. For example, instead of responding to http requests end with .html, we want CQ responds to requests end with .foo.
In order to tell CQ to be able to deal with a custom request with a special page extension (e.g., .foo), you need to
Here's the details of what you need to do:
With regards to java concurrency, when reading some API documentation (e.g. java.util.concurrent), there's the term "non-blocking" and "blocking." In computer science, non-blocking means:
In Java concurrency, ForkJoinPool uses a work-stealing multi-threading framework which works well for executing tasks of uneven distribution of chunk sizes. Before you read on, you need to know Java Multithreading Approaches first.
A ForkJoinPool implements ExecutorService but it differs from other (I'll refer them as 'traditional') ExecutorService mainly by virtue of employing work-stealing - all threads in the pool attempt to find and execute subtasks created by other active tasks. It automatically balance the task load between threads, while traditional ThreadPoolExecutor has no mechanism for such kind of load balancing. If no available worker thread is available, tasks will be blocked until a thread becomes available to steal work from those workers who are busy.
In Java concurrency, there are two low level concurrency implementations in Java to create a thread - extend the Thread class or implement Runnable interface. These basic approaches neither return value from the thread nor throw exception should anything goes wrong. There's a third approach since Java 1.5 - use Java Concurrency package which supports to receive return values from thread execution.
Before I go into WeakHashmap, first let's look at different types of reference-object. A reference object encapsulates a reference to some other object. There are different level of reachability of references, from the strongest to the weakest. The weaker the reference, the more likely it is to be thrown away.
Java Serialization is a mechanism to transform a graph of Java objects into byte stream (an array of bytes) for storage or transmission, such that said array of bytes can be later transformed back into a graph of Java objects.
To opt a class in for Seriliazation, you