Tuesday, January 26, 2010

Escenic 4.3-x Quick Start Developers Guide

What is Escenic?

Escenic is a leading template based Strategic Content Management System. It is a family of several products out of which the following are predominantly used in various media applications:

• Escenic Content Engine
• Escenic Web Studio
• Escenic Content Studio
• Escenic Modules
o Article Comments
o Article Categories and Taxonomy
o Forum
o Menu Editor
o Geotagging
o Poll
• Escenic Ad Manager
• Escenic Analysis Engine

For a complete list of Escenic products refer to: http://www.escenic.com/products/

Escenic Content Engine

The Escenic Content Engine is the heart for the Escenic Content System, storing all text, images, audio, video and other digital assets and provides the back-end functionality for applications such as Escenic Content Studio. Content is also made accessible through Java Server Pages tag libraries, RESTful web services and an open Java API.

Escenic templates need this content engine to run on.

Installation Requirements


Operating System
Application Server or Servlet Container
Database Server
JDBC Driver
LDAP Server
JDK
Web Server (optional)

Example Stack


OS: Solaris 10
Servlet Container: Tomcat 5.5.27
Database Server: Oracle 10g
JDBC Driver: Ojdbc 10.x
LDAP Server: Sun One (iPlanet)

Detailed Installation Instructions: http://technet.escenic.com/multimedia/archive/00001/ece-install-guide_pdf_1231a.pdf

Escenic Template System


An Escenic template system is analogous to a file system with the following mapping:
Folder -> Sections
Files -> Articles

Any Escenic site is a collection of templates where Sections and Articles present as data structures in the database are presented to the templates (web pages) in the form of regular Java Beans.

Thus for starters you can assume every page of an Escenic web site as a Section or an Article page. Each of these section or article pages has a template associated with it.
Section pages have ‘section’, ‘grid’ and ‘element’ templates associated with them whereas Article pages are associated to the ‘article’ template.

Typical Request Flow Mechanism of an Escenic Application

HTTP URL Request (by an end users browser)
Escenic Servlet Filter Chain
Escenic Template System
HTTP Response


When the end user requests a URL, the request is handled by the application server, which forwards the request to the appropriate web application (Escenic web app in our case).

The request on reaching the web app is handled by the Escenic filter chain. The various filters configured as a part of the standard Escenic filter chain have the following two tasks:

1. Retrieve content beans from the database and make them available as java beans in the request scope to be used by a template.
2. Forward the request to an appropriate Escenic template page. Unless overridden by WEB-INF/localconfig/defaults.properties the request is always forwarded to a file called WEB_APP_ROOT/template/common.jsp

Article Page Request

Article pages are requested by URL patterns like below containing the Escenic ID of the article being requested.

http://www.timesonline.co.uk/tol/sport/football/article7002354.ece

When a request like above is handled by the Servlet chain, it knows it has to extract the content bean of article with ID: 7002354 from the database, within section the ‘football’ sub-section of the ‘sport’ section.

Based on the information in the request URL, the filters will set the following beans in the request scope before forwarding the request to the appropriate template page (WEB_APP_ROOT/template/common.jsp in most cases):


S No

Bean Name

Type

Description

1

publication

neo.xredsys.api.Publication

Publication object. Which publication object to set in
request scope is determined from the context root of the URL.
In this example, the Servlet filter would set the publication object
corresponding to publication named ‘tol’.

2

section

neo.xredsys.api.Section

Again, which section object to set in scope is determined
from the URL. In this example, football section,
which is a sub-section of sport section will be set in scope

3

article


neo.xredsys.presentation.PresentationArticle

The article object with ID:7002354 will be set in request
scope in this example

After setting the above beans, the filter chain will forward control the template page: common.jsp.

Typical Template System Flow for an Article Request

Default Template (template/common.jsp)
Wireframe (template/wireframe/classic.jsp)
Article Layout (template/art_default.jsp or template/art_standard.jsp For an article request, the template system would look for a file with ‘art_’ prefixed to the default article template configured. Thus art_default.jsp or art_standard.jsp)
template/[version number]/article/articleTypeSwitch.jsp (There is a concept of article types in Escenic. This JSP forwards control to a specific JSP after checking the ‘type’ of article bean set in request scope by the filter chain)
Article Template (template/[version number]/article/standardArticle.jsp)

Section Page Request

Section pages are requested by URL patterns like below:
http://www.timesonline.co.uk/tol/news/

Just like the case of an article request the following beans are set in request scope on a section page request:
1. publication – neo.xredsys.api.Publication
2. section – neo.xredsys.api.Section
3. pool – neo.xredsys.presentation.PresentationPool

Unlike an article page, which is composed of only one template – the article template, a section page is composed of the following three templates:

a. Section template
b. Grid template
c. Element template

After setting the above beans in scope, the control would be forwarded to common.jsp (unless overridden).

Typical Template System Flow for a Section Request

Default Template (template/common.jsp)
Wireframe (template/wireframe/classic.jsp)
Section Layout (template/sec_default.jsp or template/sec_standard.jsp For a Section request, the template system would look for a file with ‘sec_’ prefixed to the default section template configured. Thus sec_default.jsp or sec_standard.jsp)
template/[version number]/section/standard.jsp
Grid Template (a file with prefix ‘grid_’. The exact file invoked will depend on the grid template associated with the Section requested. For example, if the name of the grid template associated with the section requested is ‘indexPage’, then the file templat/grid_indexPage.jsp will be invoked)
↓ ↓ … ↓
Element template 1 Element template 2 … Element template n
(What element templates are invoked is controlled by the element templates associated with the particular Grid template. This is usually controlled by publishers using Escenic Content Studio)
Each module on the Section page has its own element template. Thus, element templates are the basic building blocks of a section page.

Example, in the following page from newsoftheworld.co.uk, each of the modules with a red outline is rendered by an element template JSP file.



Publication Resources

A resource is nothing but a binary stream of data and Each Escenic publication (web-site) has the following essential resources:

1. Article-type (/escenic/article-type)
For starters, assume that every page in Escenic that is not a section page, is an article page. Now, there are various article types available in each Escenic publication. The article-type resource defines:
• Number of article-types available in the publication
• Name of each article type available in the publication
• Fields associated with each article type in the publication

For example: A publication may have an article type called: ‘standardArticle’ with the fields like: headline, teaser, body, main-image etc.

2. Layout (/escenic/layout)
This resource defines what grid elements are available in the publication and what element templates can constitute a particular grid template.
For example: A publication may have two grid templates defined, namely, ‘indexpage’ and ‘homepage’.

This resource first defines the article and section layouts available in the publication. The names of article and section layouts defined here are used to determine the names of JSP files with prefixes ‘sec_’ and ‘art_’ the template system forwards control to.

Next, the resource defines what grid templates are available in the publication. The name of the grip template is used to determine what JSP file is invoked in a Section request. For example, if section named ‘sport’ is invoked by a URL request and a grid template named ‘indexpage’ is assigned to the sport section then a file named grid_indexpage.jsp would be called. (For the sequence of invocation refer to the request flow diagram described previously)

This resource then defines what element templates are available in the publication. All element templates assigned to the grid template associated with the invoked Section request are called by the template system. The name of the element template JSP files is prefixed by ‘fp_’.

3. Image Versions (/escenic/image-version)

4. Features (/escenic/feature)

For detailed documentation refer to Escenic Page developers guide: http://technet.escenic.com/multimedia/archive/00001/page-dev_pdf_1228a.pdf

Disclaimer: This should not be treated as official Escenic documentation and should be only used as a beginners reference guide. The author does not take any responsibility for errors in the content. Please refer to technet.escenic.com for official documentation.


Bookmark and Share

Wednesday, October 7, 2009

Hibernate - Escenic Transaction Filter Integration | Error In Initialization


Issue

When trying to integrate Hibernate with Escenic Transaction Filter I observed the following exceptions, which prevented the Hibernate Session Factory to initialize correctly. Our application has both custom Event handlers and Transaction filters written for implementing certain functionalities. These event handlers and transaction filters in turn use the Hibernate ORM framework for database transactions.

java.lang.ExceptionInInitializerError
        at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:117)
        at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:43)
        at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:162)
        at org.hibernate.tuple.entity.AbstractEntityTuplizer.(AbstractEntityTuplizer.java:135)
        at org.hibernate.tuple.entity.PojoEntityTuplizer.(PojoEntityTuplizer.java:55)
        at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:56)
        at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:295)
        at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:434)
        at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:109)
        at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
        at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:226)
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
        at com.db.HibernateUtil.(Unknown Source)
        at com.db.MyTimesDAO.getSession(Unknown Source)
        at com.db.PlusDAO.insertRecord(Unknown Source)
        at com.article.ArticleTransactionFilterImpl.insertRecord(Unknown Source)
        at com.article.ArticleTransactionFilterImpl.handleTransaction(Unknown Source)
        at com.service.EscenicTransactionFilter.doUpdate(Unknown Source)
        at neo.xredsys.api.IOObjectUpdater.applyFiltersTo(IOObjectUpdater.java:3390)
        at neo.xredsys.api.IOObjectUpdater.applyUpdateFiltersTo(IOObjectUpdater.java:3369)
        at neo.xredsys.api.IOObjectUpdater.updateArticle(IOObjectUpdater.java:680)
        at neo.xredsys.api.ArticleTransactionImpl.update(ArticleTransactionImpl.java:62)
        at neo.xredsys.rio.RIOAdapterImpl.update(RIOAdapterImpl.java:625)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at neo.xredsys.rio.RIOSessionImpl$1.invoke(RIOSessionImpl.java:80)
        at $Proxy1.update(Unknown Source)
        at neo.xredsys.rio.RIOSessionImpl$12.run(RIOSessionImpl.java:1518)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
        at neo.xredsys.rio.RIOSessionImpl.update(RIOSessionImpl.java:1514)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
        at java.security.AccessController.checkPermission(AccessController.java:427)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
        at net.sf.cglib.core.ReflectUtils.getConstructor(ReflectUtils.java:245)
        at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220)
        at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216)
        at net.sf.cglib.core.KeyFactory$Generator.firstInstance(KeyFactory.java:157)
        at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225)
        at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145)
        at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:117)
        at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
        at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
        at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
        ... 44 more

I observed that when the Escenic event handler was invoked before the transaction filter in the JVMs lifecycle, the singleton instance of HibernateSessionFactory initialized successfully and subsequent use of this session factory by both the event handler and transaction filter (or any other component in the JVM using the same session factory) worked as expected. However, when the transaction filter was invoked before the even handler the above-mentioned initialization exception was thrown. Once the above exception was thrown, even an invocation of the Event handler failed to initialize the Hibernate session factory successfully making Hibernate framework unusable by any component in the JVM.

Resolution

1. Added the following in the JVM security policy file:
java.policy
grant codeBase "file: /u01/tomcat/shared/lib/cglib-2.1.3.jar" {

        permission java.security.AllPermission;

};

2. Initialized the HibernateSessionFactory using Escenic Initial Context creator.

The following class actually initializes the HibernateSessionFactory:

import org.apache.log4j.Logger;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;

import com.myproject.framework.exception.SystemException;

public class HibernateUtil {

      private static final Logger logger = Logger.getLogger(HibernateUtil.class);
      private static final SessionFactory sessionFactory;

      static {
            try {
                  logger.debug("Building hibernate session factory");
                  // Create the SessionFactory from hibernate.cfg.xml
                  sessionFactory = new Configuration().configure().buildSessionFactory();
                  logger.debug("Hibernate session factory built successfully");
            } catch (Throwable e) {
                  throw new SystemException("Initial Hibernate SessionFactory creation failed", e);
            }
      }

      /**
       * Returns the singleton instance of the SessionFactory
       *
       * @return SessionFactory
       */
      public static SessionFactory getSessionFactory() {
            return sessionFactory;
      }
}

This class was invoked during the Escenic initial context creation to initialize the session factory by adding the following entry in Escenic Initial.properties file as below

service.2.0.0-HibernateInit=/com/myproject/HibernateInitializer

and defining a file called HibernateInitializer.properties in [ECE_localconfig]/com/myproject with the following entry:

$class=com.db.HibernateUtil

Note: In non-escenic applications, if a similar problem is encountered, one can try using a start-up filter defined in the web-application deployment descriptor file (web.xml) instead. The idea is to basically initialize the singleton of the HibernateSessionFactory before invocation by the transaction filter

Wednesday, August 19, 2009

Tomcat 5 | Useful Configurations | Performance Tuning

JVM Arguments

argv[4]: -Xmx2560m
Heap Size setting. Min and Max should be set to the same value if you know that your application will mostly operate on the max heap value.
argv[5]: -Xms2560m
argv[13]: -Dsun.rmi.dgc.server.gcInterval=3600000
As there exists a bug in JDK 1.5, this is the recommended setting, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6200091
argv[14]: -Dsun.rmi.dgc.client.gcInterval=3600000
This is used in combination to the above.
argv[17]: -Dsun.rmi.transport.connectionTimeout=20000
For network failure tuning.
argv[18]: -Dsun.rmi.transport.tcp.handshakeTimeout=20000
For network failure tuning.
argv[19]: -Dsun.rmi.transport.tcp.readTimeout=20000
For network failure tuning.
-XX:+DisableExplicitGC
Do not use. Refer: http://forums.sun.com/thread.jspa?threadID=5369546&tstart=0
argv[20]: -verbose:gc
For debugging
argv[21]: -XX:+UseParNewGC
For debugging
argv[22]: -XX:+PrintGCTimeStamps
For debugging
argv[23]: -XX:+PrintGCDetails
For debugging

Tomcat Settings

Connector Settings

maxThreads="300" minSpareThreads="25" maxSpareThreads="77"
enableLookups="false" redirectPort="8443" acceptCount="256"
connectionTimeout="60000" disableUploadTimeout="true" />
The maxThreads and related settings are based on the corresponding settings on Apache.
Ensure that development mode is set to false in TOMCAT/conf/web.xml [We have not tried this so far. Detailed investigation is in the pipeline]

JDBC Connection Pool Settings (context.xml)

connectionProperties="{ValidateConnection=true,ConnectionWaitTimeout=10}" username="*****" password="*****" validationQuery="select 1 from dual" testOnBorrow="true" poolPreparedStatements="true" maxOpenPreparedStatements="10" initialSize="10" minIdle="10" maxActive="25" maxIdle="20" maxWait="30000" removeAbandonedTimeout="60" removeAbandoned="true" logAbandoned="true"/>

Apache Settings

mod_proxy_http is used instead of mod_proxy_ajp as the connector between Tomcat and Apache as it is more stable. This change sometimes requires ProxyPreserveHost setting to be turned ON to ensure correct configurations.
ProxyPass http://localhost:8080/ retry=0
ProxyPassReverse http://www.mysite.co.uk/
The retry=0 settings is used to resolve an issue on production environment that caused intermittent 503 errors served by Apache. (Refer: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html )
If IPV4 is used in the environment, modify default httpd.conf settings to change the Listener port configurations as indicated below:


0.0.0.0:80 rather than Listen 80