Within CQ, Components (including Page Templates) can utilize JSPs for rendering not only HTML, but also other output formats such as JSON.

Unfortunately, many JSPs are written poorly and mix presentation logic with business logic (in the form of scriptlets) making them difficult to test, debug and maintain. One of the best ways to write better JSPs is to never use scriptlets and instead use a combination of EL expressions and Custom Tag Libraries (including the JSTL). This Blueprint details how Custom Tag Libraries should be developed and deployed to a CQ environment.

I just published a new Blueprint over on cqblueprints.com that details how to easily deploy 3rd party libraries into your CQ environment, even when those libraries do not contain the necessary OSGi entries in the Manifest file.

CQ is built on top of Apache Sling, and Apache Sling is built on top of an OSGi container (Apache Felix specifically).

OSGi containers behave slightly differently (in terms of how classes are loaded and made available on the classpath) than most Java developers are used to.

To be able to make classes available within the OSGi container, Jar files need to be packaged in a specific way, including adding extra meta-data to the standard MANIFEST.MF file. The problem this can create is that libraries created by other developers that have not been built with OSGi in mind are missing this extra information and so their Jar files cannot be deployed in CQ.

This Blueprint details how to easily and reliably expose non-OSGi enabled libraries in CQ.

I just published a new Blueprint over on cqblueprints.com that details how to easily build and deploy OSGi bundles into your Adobe Communique server.

CQ is built on top of an OSGi container and as a result custom code and functionality can be added to CQ through the features provided by OSGi. To be able to deploy custom code into an OSGi container, developers must package their code as a bundle. An OSGi bundle is simply a Jar file that has had extra meta data added to it. This Blueprint details how to create an OSGi bundle using Apache Maven and how to deploy that bundle into a running CQ instance.

JavaOne 2012

CON8122 - Amazon Web Services for Java Developers

Abstract: Amazon Web Services (AWS) is an ideal platform to develop on and to use for hosting enterprise Java applications. The zero up-front costs and virtually infinite scalability of resources enable Java EE developers to start small and be confident that their infrastructure will grow with their application. In addition, the nature of AWS and the services available help solve some of the problems Java developers often face in more-traditional environments. In this session, you will be introduced to AWS concepts, gain an understanding of how existing Java EE applications can be migrated to the AWS environment, what advantages there are in doing that, and how to architect a new Java EE application from the ground up to leverage the AWS environment for maximum benefit.