Posts tagged "CQ"

Place simple HTML and image files online with CRX and CQ

The Sling underpinnings of CRX and CQ allow for complex, conditional, rendering of content. That is fine and good, but what if you are just wanting to render a simple HTML page? CRX/CQ can serve static content as well. This includes any HTML files, images, SWFs and PDFs. This is a quick description of three ways to add this sort of content to your repository.

Using cURL

The most basic way to get static content into the CRX/CQ repository is to place it there using HTTP. Here is a simple example showing how to upload a page, sample.html, to a CRX server using curl:

curl -u admin:admin -T sample.html http://localhost:8080/content/sample.html

The resulting page is accessed at the same URL it was placed to.

Using WebDAV

By default, CRX/CQ allow WebDAV connections. With any WebDAV client, point to the CRX/CQ WebDAV endpoint at http://<host>:<port>/crx/repository/crx.default. I have a laptop with Windows 7 64 bit. WebDAV does not work with that operating system so I had to download a WebDAV client. My personal preference for a WebDAV client is CyberDuck (http://cyberduck.ch).

Once you connect to your CRX/CQ instance you can place your static content within the repository.

Using Package Manager

The third way to add content to your repository is to create a package and import the package. The advantage of this method is that your content becomes a single file that is portable and able to archived. Packages can be created using tools such as Maven. The method I describe here uses no build tools.

First, create a folder node to contain your content within your repository using CRXDE Lite. Right click on the node you want to contain your new node and select the Create->Create folder… from the context menu.

This will bring up a dialog to name your new folder.

Once you have created and named your new folder, be sure to press the Save All… button within CRXDE Lite. Any changes are lost if you leave the page before saving.

At this stage go back to the main screen by pressing the CRXDE Lite logo at the top and the screen. On the main screen, select the Packages link to go to the Package Manager.

In the Package Manager you can create a new, empty, package for the folder you just created in your repository. Select the Create Package button.

This will open a dialog. Enter the name and version of your package. The group of the package should be the default, my_packages. Press OK.

The package is listed within the Package Manager. Right now this package is completely empty. Within the listing for the new package select the Edit… button.

Within the dialog that is opened, select the Filters tab and press the Add Filter button. Specify the root path of the package. Press the search button next to the root path field and select the folder within the repository for the Web pages. Press OK to select the folder and press the Save button in the Edit Package dialog.

In the listing for the new package press the Build button to the right of the Edit button. The Activity Log at the bottom of the page will show you the progress of the build. Once built, press the Download button in the package’s listing to save a copy to your computer.

This package file will be a zip file with content directories and manifest files. At this stage we finally get to your content. Place the content you want to include in your repository inside the package file. Place the content inside the directory of the zip file that matches the folder in the repository you wish to place it. Once the package file contains all of your content you can upload it to any CRX/CQ repository.

To upload the package, go once again to the Package Manager. Within the Package Manager is the Upload Package button.

A dialog to select a package file appears after the Upload Package button is pressed. Select your package file. Pressing OK adds the Package you selected to CRX/CQ. The package will be listed in the Package Manager. It very important to know that the package itself has not been applied to the repository. To apply the content changes found in the package file, press the Install button within that package’s listing.

Once the package is installed the content can be access through your CRX/CQ instance.

See Also

Apache Sling –  Discover Sling in 15 minutes has instructions on how to use the curl command to add and edit content within the Sling instance. This works the same way in CRX/CQ.

The documentation site for CRX/CQ, dev.day.com, contains documentation on WebDAV access to CRX/CQ and how to work with packages.

 

 

Installing CRX 2.1 or CQ 5.4 for Desktop Development

[Revised 11 April 2012: added section, Before You Begin]

CRX provides the base functionality for both CQ and Experience Services. CQ adds its own flavor of extended functionality to CRX and Experience Services does so as well. So they are all very similar and installing a development server on your local machine is the same for CQ, Experiences Services or generic CRX.

Before You Begin

To install CQ, Experience Services or CRX, you need the quickstart jar for the server and licensing as either a license key or the license.properties file. Quickstart files are cross platform. So the same quickstart will work on any compatible platform. You need to have both of these lined up ahead of time.

System Requirements

Adobe documentation describes the technical requirements for the servers at http://dev.day.com/docs/en/cq/current/deploying/technical_requirements.html. Your workstation should have 2 GB of free disk space and 1.5 GB of available memory. A Java run time, either version 1.5 or 1.6, is required. JRE 1.6 is preferred. JRE 1.7 will not work.

For development and testing on your local machine, the deployment requirements in the documentation can be more broad. The servers should work on computers with recent versions of the Windows and Macintosh systems.

Create a Deployment Directory, Rename Quick Start and Provide License

CQ, CRX and Experience Services all can be deployed using a single jar file, called a quickstart file, that is run by a Java JVM. This single jar contains everything needed to run, including the server, configuration files, and binaries. There are naming conventions for the quickstart files. Some of the conventions are mandatory, others override default behavior. If the quickstart is for CQ, the name of the quickstart file must start with cq-. If CRX, the name must begin with crx-. If Experience Services, the name must begin with adep-ria-. The port used by the server can be set using file naming, too. Place -[port] at the end of the file name (just before the .jar suffix) and the quickstart server will run on that port. The file name and the path to the quickstart file must not contain any spaces.

I have a directory, servers, at the root of my c drive to contain my server instances for testing and development. I place each quickstart file into its own directory. You do this because, when run, the quickstart will unpack itself within this directory. In my naming convention, I place the version of the server in the directory name.

These are examples of the quickstart files I use, where I place them and how I name them on the Windows 7 workstation.

Experience Services 10.0.0 using port 450

C:\servers\adep-ria-quickstart-10-0-0\adep-ria-quickstart-4502.jar

 

Experience Services 10.0.1 (service pack 1) using port 4503

C:\servers\adep-ria-quickstart-10-0-1\adep-ria-quickstart-4503.jar

 

CQ 5.5.0 using port 8081

C:\servers\cq-5.5.0-20120220\cq-quickstart-5.5.0-20120220-8081.jar

 

Before the first time a quickstart is used, each of these directories should have two files inside of them. First, of course, is the quickstart jar itself. The second file that should be in each of these directories is a license.properties file. If the license.properties file is not present, the user will be prompted for a license key the first time the quickstart is run. If you do not have a license.properties file or license key, get in touch with either Adobe sales or Adobe customer support.

Start the Server the First Time

Using the command line, confirm the version of Java is correct. I have more than one version of Java installed for testing, so it is possible that the default Java is not correct even if you do have JRE 1.5 or JRE 1.6 installed.

java -version
 

If this does not return the correct version of Java, you will need to use the complete file path to Java when starting the server.

To start the server, change the directory of the command line to be the same directory that contains the quick start jar. Use Java to run the jar.

java -Xms1536m -jar cq-quickstart-5.5.0-20120220-8081.jar
 

The first time the server runs it creates a crx-quickstart folder in the same directory and unpacks its resources into this directory. It does some basic configuration based on the naming conventions used with the quick start file. Once the resources are unpacked, the quick start server runs.

Log Into the Administrative Console

Once the server has started, a browser window will open to allow you to log into administrative console of the server. The default user name is admin, the default password is admin.

You can start the server the same way from the command later. After the first time, starting it up will not take as much time. The jar is not unpacked.

For More Information

The developer site at day.com, http://dev.day.com, contains more information about how to configure and use CQ, Experience Services and CRX.

 

Using the Data Store Garbage Collection in CRX and CQ

Andrew Khoury sent this information to me, basing the instructions on his solution to a customer’s problem.

I posted a solution to the problem in which the journal files for CRX grew and became a problem. The journal files are tar files in which the repository stores its information. However, items greater than 4KB are not stored in the repository tar files. Instead, CRX stores that data in a set of indexed files found within the crx-quickstart/repository/repository/datastore directory.

Like the tar journal files, these files have data appended, not rewritten. So the size of the datastore directory grows with each deployment that contains files larger than 4KB.

Just as there is a garbage collection functionality for repository tar files, there is a way to do garbage collection on the datastore. Running garbage collection removes unused items from the datastore directory and decreases the amount of its data.

Experience Services and CQ are both built using CRX as their base. So the instructions for CRX applies to the Experience Services and CQ servers, as well.

Running Datastore Garbage Collection

  1. Go to http://[server domain]:[server port]/crx and log in as administrative user
  2. Click Repository Configuration
  3. Click Datastore Garbage Collection
  4. Check all boxes and click Run (if it runs successfully then you are done)

If this process completes successfully, you are done.

If Datastore Garbage Collection fails with an error

Look at the error in the application server log and crx-quickstart/logs/crx/error.log. You may see “File not found: 123,” where 123 corresponds to the id number of a tar file. If so, first try to restore the tar file that corresponds to that id from a backup. For example, the tar file for id 123 would be crx-quickstart/workspaces/crx.default/data_00123.tar. The number in the data tar file name is always padded to five digits so add zeros before the number to make it five digits.

Next steps

If an error occurred, do the following. Do the rest of these steps even if you were not able to restore the missing tar file(s).

  1. Stop the application server or the quickstart server.
  2. If using *nix, log into the server via ssh and cd to the crx-quickstart directory. If using Windows, go to the crx-quickstart drectory.
  3. Make backups of the tar index files. Within the *nix environment use these commands:
    cd repository/version
    mkdir index_tar_backup
    mv index*.tar index_tar_backup/
    chmod 640 data*.tar
    cd ../workspaces/crx.default
    mkdir index_tar_backup
    mv index*.tar index_tar_backup/
    chmod 640 data*.tar
  4. Backup crx-quickstart/workspaces/crx.default/workspace.xml as crx-quickstart/workspaces/crx.default/workspace.xml.backup
  5.  Open crx-quickstart/workspaces/crx.default/workspace.xml in a text editor
  6. Comment out the PersistenceManagerelement:Before:
    <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"/>

    After:

    <!--PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"/-->
  7. Add a new persistence manager element with the consistency check parameters set:
    <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyFix" value="true" />
    </PersistenceManager>
  8. Restart the application server or the quick start server
  9. Monitor start up by tailing crx-quickstart/logs/crx/error.log and watch fo any errors. In the error.log you will see something very similar to the following when the start up is complete:
     02.03.2012 15:39:52 *INFO * CRXHttpServlet: PackageShareServlet initialized. (CRXHttpServlet.java, line 52)
     02.03.2012 15:39:52 *INFO * CRXHttpServlet: PackageManagerServlet initialized. (CRXHttpServlet.java, line 52)
     02.03.2012 15:40:04 *INFO * TarUtils: File system status: created 200 files in 14 ms (14285 ops/sec) (TarUtils.java, line 782)
    02.03.2012 15:40:04 *INFO * TarUtils: File system status calculated in 35 ms (TarUtils.java, line 795)
  10. Go to http://[server domain]:[server port]/crx and log in as an administrative user
  11. Click Repository Configuration
  12. Click Datastore Garbage Collection
  13. Check all boxes and click Run
  14. Edit the file, crx-quickstart/workspaces/crx.default/workspace.xml, replacing it with the original version that was backed up.

Deconstructing Experience Services: Apache Sling

Apache Sling implements a content management system that uses a Java content repository (JCR), an object database, to store its content and OSGi to add functionality and deploy content. It has server-side scripting and can use multiple languages such as Ruby, JSP and javascript.

Sling forms the basis of the Web Experience Management (WEM/CQ) within Adobe’s ADEP Experience Services. It is robust and makes Web sites easy to develop and then deploy into production. In addition, it has a system for managing digital assets stored within the JCR. ADEP Experience Services implements Sling using its CRX JCR.

In an earlier post I talked about my experience years ago with a content management built on top of a object database called Userland Frontier. Frontier allowed content to be totally separated from the code and HTML used to implement it. That experience has given me a deep appreciation for Web Experience Management.

Within WEM content is not HTML, but the text, photos and other media used as raw material for Web pages. Content is rendered to HTML when needed based on metadata of the content and the context the content is being viewed. If a person views the content from their desktop computer, the content will be rendered for the desktop computer. If another person views that same content from their smart phone, the content will be rendered for the smart phone. The context drives the way content is rendered, but context is not limited to device type. Content can be rendered for women differently than for men. Or it can be rendered differently for a person in one city than for someone in another. Sling makes this smart rendering of content possible and WEM gives the owner of the Web site the tools to use it.