Migrating a portlet that uses JCR

JCR is a standard specification for content management implemented by ECM (Enterprise Content Management) systems . GateIn is an ECM. By default, many parts of the portal are managed in a JCR repository, for example, the web resources (JavaScript and CSS), the portlet, the pages' metadata, and the resource bundles. Each portlet can call an internal or external JCR repository and handle the contents. In this recipe, you will see a simple example of the migration of a portlet with JCR and how use JCR in this context.

Getting ready

The following is an example of a portlet that inserts a new node and prints out all the nodes. Here is the code:

import javax.jcr.AccessDeniedException;
import javax.jcr.Node;
import javax.jcr.Repository;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.NodeIterator;

...

@Override
public void processAction(ActionRequest request, ActionResponse response)
      throws PortletException, IOException {
   ...
   Session session = (Session)repository.login();
  Node root = (Node)session.getRootNode();
  Node newNode = (Node)root.addNode("my new node");
  newNode.setProperty("my property", "my value");
  session.save();
  printAllNodes(root, "");
  session.logout();
}

public void printAllNodes(Node root, String space) throws RepositoryException {
    NodeIterator nodeIterator = (NodeIterator)root.getNodes();
    while (nodeIterator.hasNext()) {
      Node node = (Node)nodeIterator.nextNode();
      System.out.println(space+node.getName());
      printAllNodes(node, space+"   ");
    }
  }

How to do it...

All the objects that you see in this code—the Repository, Node, NodeIterator—are standard JCR APIs. The standard confers big advantages to migrations. All you need to do is call the javax.jcr.Repository class. Each portal has its own mode to call the Repository. GateIn, as for all components and services, calls the JCR Repository through the eXo Container:

PortalRequestContext context = 
   (PortalRequestContext) WebuiRequestContext
    .getCurrentInstance();
ExoContainer pcontainer = context.getApplication()
  .getApplicationServiceContainer();
RepositoryService repositoryService = 
   (RepositoryService) pcontainer
       .getComponentInstanceOfType(RepositoryService.class);
Repository repository = (Repository)repositoryService
   .getRepository("repository");

The same thing can be done in a groovy script as follows:

<% 
   def repositoryService =  uicomponent.getApplicationComponent(RepositoryService.class);
%>

How it works...

GateIn integrates a JCR Repository donated by eXo to the JBoss community, eXo JCR.

eXo JCR implements the JCR specifications 1.0. Its architecture is similar to GateIn. PicoContainer hosts the services and the components are configured by XML.

The configuration of the repository can be found in the portal/WEB-INF/conf/jcr folder. Here are the main XML configuration files:

  • component-plugins-configuration.xml: Used to create the default users in the JCR path /User for the workspace portal-system. Note how the users are also considered JCR nodes.
  • jcr-configuration.xml: Contains the services for to the JCR Repository. Here the list:
    • org.exoplatform.services.jcr.config.RepositoryServiceConfiguration: The configuration of the JCR repository. It delegates to the next repository-configuration.xml file.
    • org.exoplatform.services.jcr.RepositoryService: The service seen in the previous example, callable by the client to execute the JCR operations
    • org.exoplatform.services.jcr.ext.distribution.DataDistributionManager: A utility to perform massive read and write operations in an efficient manner; see the next paragraph for details.
    • org.exoplatform.services.jcr.ext.hierarchy.NodeHierarchyCreator: This service is used to initialize the JCR workspaces. It is used in component-plugins-configuration.xml to create the default users and in jcr-configuration.xml to set the default permissions for the gadgets.
    • org.exoplatform.services.jcr.webdav.WebDavServiceImpl: The webdav service. Through it, you can connect to GateIn with a client and manage the JCR repository. You will see an example below.
  • repository-configuration.xml: The eXo JCR configuration. It creates three workspaces connectable remotely through webdav:
    • portal-system: The main workspace containing all the information of the portal. It can be called by connecting to http://localhost:8080/rest/private/jcr/repository/portal-system
    • portal-work: Contains information about password reminders and authentication gadget tokens. It can be called connecting by to http://localhost:8080/rest/private/jcr/repository/portal-work
    • system: Contains the system nodes created by eXo JCR where all nodes are based. No need to interact with them unless debugging or developing. It can be called by connecting to http://localhost:8080/rest/private/jcr/repository/system

Each of these workspaces can be configured as follows:

  • Storage: Can be set through the filesystem or database. The default is hsqldb. Initializer. Here, you can add plugins to initialize the nodes.
  • Cache: The configuration of the caching of the nodes. GateIn uses JBoss cache 3.2.6 for the caching and clustering.
  • Lock Manager: Decides when to lock a node and when to release it. It is tied to JBoss cache and is used by the transaction manager.
  • Indexing: In this part, you configure the property of the query handler based on Lucene as the directory of the indexes and the caching mode for the JCR query.

    Note

    Lucene is the main open source indexing product. Many open source products use it. It provides good performance for query execution. For details on Lucene, see the official site: http://lucene.apache.org

There's more...

Here are two important digressions on eXo JCR:

Data distribution manager

The data distribution manager is used to distribute the data over the JCR in a smart fashion.

It can ensure that read and write performance is optimal, especially if you have many nodes to store, instead of storing them yourself under the same parent node (which can affect the performance if you have many nodes to store). We simply delegate data access and storage to the DataDistributionType corresponding to the expected mode that will store the data for you in an optimized and reliable way.

The following code is an example of how it can be used:

// Get the data distribution corresponding to the readable   
   mode
DataDistributionType type = manager
   .getDataDistributionType(DataDistributionMode.READABLE);

// Get or create the node corresponding to "john.smith"
Node node = type.getOrCreateDataNode(parentNode, "john.smith");

Clustered nodes

JBoss Cache is an open source framework used for distributed and transactional caching. GateIn uses it for clustering. Basically, there are two configurations:

  • JCR caching: The major part of the resources is managed by JCR. JBoss Cache is integrated in to eXo JCR, so the configuration of the cluster is done in a declarative manner. There are two different configurations, one for clustering mode and one for local mode. The difference is that the local mode only manages the local caching of the data, so they are not replicated. Here are the main configuration files that can be found in the portal/WEB-INF/conf/jcr/jbosscache folder:
    • config.xml: Creates the partition Defaultpartition-jcr where the data will be replicated
    • lock-config.xml: Creates the partition Defaultpartition-jcrlock used to maintain the information on the locking of the nodes. When a node is called, a value is replicated in this partition, so that all the nodes know it is in use and the transaction will be managed with the current locking mechanism.

    By default, the cache used in cache mode is local. To set cluster mode go to conf/gatein/configuration.properties and set the property gatein.jcr.config.type=cluster instead of local.

  • Caching for resources outside of JCR: A very similar configuration is used for data not contained in the JCR Repository. Each portlet can manage its own data and replicate them in a very simple mode. Here is an example of a portlet that replicates a string value:
    import org.exoplatform.services.cache.CacheService;
    import org.exoplatform.services.cache.ExoCache;
    
    ...
    
    CacheService cacheService = (CacheService) pcontainer
        .getComponentInstanceOfType(CacheService.class);
    ExoCache<String, String> cache =  
          cacheService.getCacheInstance("/production");
    cache.put("mynewkey", "mynewvalue");  
  • And here is an example of a value exported from the cache:
    ...
    String value = cache.get("mynewkey");
    ...
  • The default partition used is DefaultPartition-gatein and the configuration files are in the portal/WEB-INF/conf/jbosscache folder divided into local and cluster mode as for the JCR configuration.

Webdav service

Webdav (Web-based Distributed Authoring and Versioning) is a protocol composed by a set of HTTP instructions that allows working on documents remotely.

You can connect to webdav URLs through a web browser. Here is an example of a webdav connection in Mac OS X.

Go to Go | Connect to Servers as shown in the following screenshot:

Webdav service

Log in as any GateIn user:

Webdav service

Enter the webdav path:

Webdav service

You are now connected. From here, you can add a new node:

Webdav service
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.34.161