Posts tagged "CQ"

Installing CRX 2.1 or CQ 5.4 for Desktop Development

Posted on April 2, 2012 by Deke Smith | Comments (0)

[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

Posted on March 13, 2012 by Deke Smith | Comments (2)

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

Posted on October 13, 2011 by Deke Smith | Comments (0)

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.