Web server configuration

Session persistence

Web servers often implement a session persistence mechanism used typically for traditional server clustering and fail-over techniques.

Often, the JViews JSF components are not serializable as they pertain to view related abstractions, which are typically not persistable and are stored in the HTTP session.

In order to prevent the typical serialization warnings derived from this mismatch, you can disable the session serialization mechanism for the JViews JSF based application.

How to disable session persistence in TOMCAT at Web application level

Create a file context.xml and place it on the META-INF directory of your .war file.
Use the Apache™ TOMCAT configuration setting shown in the following code to disable the session serialization mechanism:
```
<Context path="/your-application-path">
   <Manager className="org.apache.catalina.session.StandardManager"
    pathname=""/>
</Context>
```

Note

All the JViews JSF samples already have this session serialization setting disabled for TOMCAT at this level.
These settings apply to TOMCAT 7 and later.

How to disable session persistence in TOMCAT at Web server level

Modify the TOMCAT/conf/context.xml to use this as the Session Manager definition:
```
<Manager pathname=""/>
```

Note

These settings apply to TOMCAT 7 and later.

For more details on these settings see the TOMCAT configuration documentation.

For details on how to disable session serialization with your Web server, refer to its configuration documentation.

Running JViews JSF components in JSR 168 portlets

Note

See the Release Notes for supported JSF implementations and JSF Portlet bridge combinations.

If you want to use JViews Framework JSF components in a JSR 168 portlet environment, you first need to check with your portal vendor whether JavaServer™ Faces components are supported.

Your Web application must be correctly configured. This section describes each of the steps required to make JViews Framework JSF components compatible with portlets.

Note

JViews Framework JSF components are automatically switched to portlet mode if the classes of the portlet API are detected in the class path.

To avoid naming clashes between portlets, the JSR 168 specification requires content to be generated that is unique to each portlet. Therefore, the generated variables used by JViews Framework JSF components must be prefixed by the portlet namespace.

Scripts prefixed by a namespace

From JViews 8.5, the servlet filter ilog.views.faces.servlet.IlvJSNamespaceFilter is no longer needed and must not be set on the controller servlet.

JavaScript variables prefixed by a namespace

In portlet mode, the generated JavaScript™ variables are prefixed by the portlet namespace. Thus, their usage in the JSP™ page is quite different.

A JavaScript action is built on a managed bean by using the IlvFacesUtil.encodeJavaScriptVariables(String) static method.

The parameter is the desired JavaScript action where the variables are declared with the ${id} notation. For example:

IlvFacesUtil.encodeJavaScriptVariables("${view}.setInteractor(${interactor})");

where view and interactor represent JavaScript variables.

The JViews JSF components that have JavaScript handlers need only to reference these bean properties.

The following code shows a more complete use of JavaScript actions in the JSP page and the managed bean.

Example 1:

[...]
<jvf:zoomInteractor id="zoom" />
<jv:imageButton onclick="#{frameworkBean.setZoomAction}"/>
<jvf:view id="view" />
[...]

Example 2:

public class FrameworkBean {
[...]
private String setZoomAction;
public FrameworkBean(){
setZoomAction =
IlvFacesUtil.encodeJavaScriptVariables("${view}.setInteractor(${zoom})");
}
public String getSetZoomAction(){
return setZoomAction;
}
[...]
}

Declaring the image servlet

In portlet mode, the servlet used to render the image must be declared:

<jvf view [...] servlet=
"ilog.views.faces.dhtml.servlet.IlvFacesManagerServlet" />

Integrating JSF components into the portal

Depending on your portal implementation, integrating JSF components may require special configuration that is conditioned by the application server, the JSF implementation, the portlet-JSF bridge, and so on. Check with your portal vendor for what you need to do in this configuration step.