Quite often we need to customize our Content Servers using some specific Java code. Usually we accomplish this by creating a custom component and utilizing Service Handlers or Java Filters (or both). Unfortunately, sometimes it might be hard to decide when you should use one over the other. So, let’s dig deeper into both and understand how they work.

Service Handlers

Service Handlers are a mechanism that allows us to add new services or modify existing services by using  Java.

Multiple Service Handlers could contain the same Java method, but the Content Server would only execute the one that is contained within the Service Handler that has the lowest Search Order. The Search Order is defined during the creation of the configuration table. The configuration table is a table that exposes your custom code to the Content Server.

Service Handlers could be chained/put-in-place to be executed:

• Instead of new service actions:
  • Create a Service Handler with a lower Search Order.
• Before existing service actions:
  • Create a Service Handler with a lower Search Order,
  • Make a call to the same method after your custom java code:

Java Filters

Java Filters is an event subscription mechanism through which developers can subscribe to the various events that occur within the Content Server and execute custom Java code.

During the operation of Content Server, there are various events that constantly being fired up. The developer can subscribe to these events and alter the behavior of Content Server. When the desired event would occur the control would be passed to the subscribers of the event and the custom java code could be executed. The Content Server then expects a result of the custom code execution.  The results are pretty straight forward:

• CONTINUE – informs Content Server that everything went accordingly;
• FINISHED – informs Content Server to stop running any other filters with the similar name;
• ABORT – informs Content Server to halt execution of the current process.

When to Use Service Handlers versus Java Filters

Java Filters is the least-intrusive and easiest way to customize the behavior of Content Server with Java, whereas Service Handlers require more thorough understanding of the actions that need to be customized.

Java Filters is the preferred and most commonly used way of customization, but it is limited to the existing set of filters within the Content Server. So, if there is no defined filter to which you can subscribe, then you can create your own custom component that uses Service Handlers to customize the behavior.

These steps show how to install Google Chrome on Oracle Enterprise Linux 6.x.  I suspect these steps would also work with Fedora, CentOS and Red Hat (RHEL).  This approach uses Google’s YUM repository.

1. Login or switch to the root user
2. Create a file named google.repo in the /etc/yum.repos.d dirctory
3. Add the appropriate segment to your new google.repo file

• 32 bit
  

4.     Yum install google-chrome-stable

How often does the Site Studio project file change? The first determination that needs to be made is what all affects the project file. Some examples are as follows:

• Adding a new website section (service SS_ADD_NODE)
• Switching content on a region marker in Site Studio contribution mode (service SS_SWITCH_REGION_ASSOCIATION)
• Changing the property of a website section (service SS_SET_NODE_PROPERTY)

Out of the box, these changes are committed to the WebCenter Content repository (as a new revision of the project file content item) every 10 minutes. This 10 minute interval is set by the WebCenter Content configuration flag SSProjectAutoCheckinInterval (integer value in seconds which defaults to 600).

While waiting for the the time interval set with SSProjectAutoCheckinInterval, the project file changes are stored in a temp file located here: vault/~ssprojects/
The service SS_COMMIT_SITE_CHANGES can, “Be run at any time to commit changes on demand”. The only required parameter is siteId. “The user executing this service must have write access to the project file to execute the service.”

There is another configuration flag SSAutoCheckinBusyTimeout (integer value in seconds which defaults to 30) that is, “Used to set the minimum time duration (in seconds) before the auto check-in mechanism attempts a check-in of a project file. This configuration flag prevents two nodes from trying to check the project file in at the same time”. The auto check-in behavior appears to use service CHECKIN_ARCHIVE and with the default time of 10 minutes, this should handle any issues that might come up with the release date debacle.

The undocumented configuration flag SSOverwriteProjectsUponCheckin (boolean value which defaults to false) controls whether the latest project file revision is overwritten. So, out of the box, project file auto check-ins stack revisions one on top of the other, instead of simply overwriting the latest revision. This is, is in my opinion, a good thing.