ACE: LiveCycle Designer ES4

Last November I sat the Adobe Certified Expert LiveCycle ES4 Designer beta exam. After a couple of months waiting for the results to be compiled and the final exams to be created from the beta questions, I finally received the results this week…

Happily, I passed! :-)

Next step – the Adobe Certified Expert LiveCycle ES4 Server exam…

Posted in Certifications, LiveCycle | Tagged , , , | Leave a comment

LiveCycle Gotchya: Turnkey Install Verification Error

I recently installed LiveCycle ES4 on a new computer, and came across an issue I’ve had in the past but have not blogged about. The turnkey installation option installs all required LiveCycle components, including JBoss. A default JBoss installation uses port 8080 which I know was free on the machine, but when installing I received the error:

Turnkey Install Verification Error:
The following port(s) are required for the Turnkey JBoss instance, but are still in use: 8080

The following port(s) are required for the Turnkey JBoss instance, but are still in use: 8080

After confirming with netstat that the port was indeed not in use, I remembered that antivirus software can sometimes interfere with the installation process. By temporarily disabling the antivirus software and reattempting the installation, port 8080 was available, and I could continue the installation.

Hopefully this will save someone else some time in the future!

Posted in LiveCycle | Tagged , , | 2 Comments

Removing Package Contents From an AEM Publish Instance

I’m currently looking to upgrade from CQ 5.5 to AEM 5.6.1 for one of my clients, and one of the preparation steps in the Upgrading to AEM 5.6.1 guide states:

Remove custom application code. In some cases custom application code may interfere with the upgrade process. It is therefore recommended to remove custom code before upgrade and re-install the code after upgrade is complete.

Removing custom code from author instances is simple – just go into the Package Manager and uninstall the packages you want to remove. Easy. But what about the publish instances? Replicating an uninstalled package does not remove the nodes from the publish instances. Nor does manually installing then uninstalling the packages directly on the publish instances.

So what is the solution? From what I’ve read and heard, the unofficially ‘official’ way to remove custom code from the publish instances as well as the author is to create an empty package that contains filters to the paths/nodes you would like to remove. When you install this on the author it will delete the nodes indicated in the filter since the package itself is empty, and when you replicate this package, it will also delete the nodes from the publish instances.

Posted in AEM, CQ5 | Tagged , | 2 Comments

CRXDE Lite Surprise – Code Formatting

A colleague of mine showed me a nice little surprise today – In most IDE’s, when you highlight code and and hold shift while tabbing, the selected code group shifts to the left. In CRXDE Lite, it formats your code for you!

Check it out: CRXDE Lite code formatting.

Posted in AEM, CQ5 | Tagged | Leave a comment

AEM Best Practice: OSGi Configurations

One of the best practices I’ve come across recently in AEM is to never use the OSGi console directly to edit configurations. People may argue “But that’s what it’s there for!”, and indeed it is an easy interface to use for configuration changes. However there are drawbacks to managing your configuration changes this way in a AEM project.

Let’s demonstrate this by changing the configuration of the Apache Sling GET Servlet.

Apache Sling GET Servlet

When you edit a configuration in the OSGi console and save it, the updated configuration is saved to the JCR, generally under /apps/sling/config or /apps/system/config depending on the component you configure. First thing to note here is that you have no control over where this node is saved to, or if this configuration should be for a specific runmode – the parent folder is called config, not config.author or config.publish (for more information on runmodes, see How to set up run mode and my previous post Confirming the Runmode).

Content Explorer File Binary

Secondly, and more importantly, the configuration node that has been created is of type nt:file. Therefore it contains a child called jcr:content, which has a property called jcr:data which contains the binary contents of the file. So as you can see (or more accurately NOT see), the details of the configuration itself are not readily apparent. When viewing this binary, we see the following:

aliases=”xml:pdf”
index=B”false”
enable.txt=B”false”
index.files=[“index”,”index.html”]
enable.html=B”false”
enable.json=B”true”
enable.xml=B”true”
json.maximumresults=I”600″

Why is this bad? What happens when you want to change a single configuration value here programatically, or even through CRXDE lite, CRX Explorer, or curl for that matter? You would need to write code that extracts the binary contents of the file, manipulate this content to adjust the values to the desired configuration, then write this back to the jcr:data property of the file contents. This is quite messy, if all you want to do is change a single value of a complex configuration and leave the rest the same.

So what’s the alternative? Create the configuration node manually, and use properties for each of the configuration settings. The configuration screen in the OSGi console gives you virtually all the information you need to create this node yourself. In addition, you also have the ability to choose the location of these settings, and therefore you can store them under you project branch, and also control the runmode in which they are used. This can be done in 3 simple steps:

1 – Create the folder structure

Create folders /apps/myproject/config.author and /apps/myproject/config.publish. Make sure the config.author and config.publish folders are of type sling:Folder

Content Explorer Config With Runmodes

2 – Create the configuration node

Create a node of type sling:OsgiConfig under the runtime folder you wish to configure. The name of the node should be the same name as the Persistent Identity (PID) of the configuration in the OSGi Console. HINT: If this is a factory class and can have multiple instances, use the Factory Persistent Identifier (Factory PID) and append the name with ‘-xxxxx’, where xxxxx is a unique identifier.

Sling GET Servlet PID

Content Explorer Author Config

3 – Add the names and values from the OSGi configuration as properties

Using the label in brackets at the end of the configuration description as the property name, and the value of the configuration as the values of the properties.

Sling GET Servlet Properties

Content Explorer Author Config With Properties

That is it! Now, if you change the values of the configuration nodes’ properties, you can refresh the OSGi console and see these changes reflected to prove the configuration is taking effect. So from now on, whenever you need to change a configuration, you can make the change directly in the JCR, as well as easily make any configuration changes via curl or java, without needing to deal with file binaries.

Posted in AEM, CQ5 | Tagged , , , | 8 Comments

CQ5 on SlideShare

I’ve just came across some interesting presentations on CQ5 on SlideShare, including presentations that recently featured during CQCON 2013 in Basel, Switzerland.

While it’s not the same without the presenter, the slides still give nice insights into what’s happening out there in the CQ world. I personally found presentations such as CQCON CQ Maven Methods and Automated self-testing and health check of CQ and Sling instances to be useful.

I’m definitely looking forward to Evolve ’13 and seeing what’s on offer there!

Posted in AEM, CQ5 | Tagged , , , , , | Leave a comment

CQ5 Gotchya: Client Libraries Not Automatically Refreshing – Part 2

In addition to the blog post I wrote about CQ5 Client Libraries Not Automatically Refreshing, there is another issue with client libraries that has been introduced in AEM (CQ5.6).

When you create a new client library (cq:ClientLibraryFolder) in AEM, it is not automatically registered in the system as it was in CQ5.5. This means that although your code is there, it cannot be used until Sling recognises it. Adobe are planning a fix for this in a future Service Pack, but until that is released there is a manual workaround.

Navigate to the Html Library Manager in the OSGi console at http://localhost:4502/system/console/components/com.day.cq.widget.impl.HtmlLibraryManagerImpl and stop the component. After the component has been stopped, the page refreshes and the component is not visible anymore – refresh the browser and start the component again. Now your client library will be registered and should be working.

Note that this only applies to newly added client libraries. If you edit an existing client library then you should not need to use this fix.

Posted in AEM, CQ5 | Tagged , , , , | 1 Comment