JProfiler Installation & Configuration for Weblogic

In below details you will be able to configure the Jprofiler in Weblogic server environment. Profiling the Weblogic application server is tricky. By following the below steps you can easily set up the environment.

Refer below link for complete JProfiler documentation. (JProfiler Documentation)

1.     Introduction

JProfiler eases developers in creating more efficient applications by improving their performance. It is oriented towards testing and exploring different aspects of the performance of a Java program, concerning the operation of the JVM making use of available platform resources.

JProfiler provides the following functionality:

·         Memory consumption measurement

·         Memory stack frames tracing

·         CPU loads profiling

·         Momentary heap allocation information

·         Thread state progress statistics

·         Visual representation of VM work loads by different parameters

·         Source code reference

·         Garbage collection during profiling

·         Remote profiling

·         Profiling only of a particular stage or a combination of several stages of the program life cycle

·         Using different target environments

·         Saving profiler information for further examination

·         Exporting profiler information in text format

JProfiler Installation

2.1     JProfiler Installation Overview

On the all the servers that has JProfiler component listed, following steps have to be carried out:-

1)Login to the linux box as a non-root user

2)Download the TAR.GZ Archive ( jprofiler_linux_7_1_2.tar.gz) for JProfiler  and keep the license key with you.

3)Upload jprofiler_linux_7_1_2.tar.gz to the box (for eg in /home/oracle  directory)

4) Execute the below commands:

                   gunzip jprofiler_linux_7_1_2.tar.gz

tar xf jprofiler_linux_7_1_2.tar

5) Ensure the software to export display is available in the local box (E.g Xserver) and it is running

6) Ensure JRE is set with version >1.5

2.1.1     Additional Steps to be carried out on the JProfiler Server

After completing the Steps listed above in Section 2.1,

1) Navigate to the JProfiler Install Directory

  Ensure that JAVA_HOME & DISPLAY variables are set.

2) Execute the shell script under extracted JProfiler folder

                   <JProfiler Directory>/bin/jprofiler

3) Enter the license key and click on evaluate (this is for trial version), below screen will be shown. Note: License key is only required where JProfiler GUI will be running.

4) To update the license information click on ‘Help’ and then ‘Enter License Key’

Update the information as required ,Click OK to complete License Update.

2.2       Steps to configure the application server for profiling

2.2.1     Profiling Weblogic Admin Server

Modify the server startup script you want to profile as below.  For example if you want to profile the admin server modify the startWebLogic.sh  to append the JProfiler argument

JAVA_VM= export JAVA_VM JPROFILER_OPTIONS="-agentpath:<JProfiler Directory>/jprofiler7/bin/linux-x86/libjprofilerti.so=port=<xxxx>,nowait $JPROFILER_OPTIONS" export JPROFILER_OPTIONS

Note:- If the java version used by Weblogic/jrockit is 64 bit, change the jprofiler lib path in the above section to <JProfiler Directory>/jprofiler7/bin/linux-x64

Add ${JPROFILER_OPTIONS} to the below portion of the startWeblogic script.

if [ "${WLS_REDIRECT_LOG}" = "" ] ; then         echo "Starting WLS with line:"         echo "${JAVA_HOME}/bin/java ${JPROFILER_OPTIONS} ${JAVA_VM} ${MEM_ARGS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}"         ${JAVA_HOME}/bin/java ${JPROFILER_OPTIONS} ${JAVA_VM} ${MEM_ARGS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS} else         echo "Redirecting output from WLS window to ${WLS_REDIRECT_LOG}"         ${JAVA_HOME}/bin/java ${JPROFILER_OPTIONS} ${JAVA_VM} ${MEM_ARGS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}  >"${WLS_REDIRECT_LOG}" 2>&1 fi

Make changes in above script:

1. Give the JProfiler installation directory
2. Give the port number to open the connection for JProfiler Agent.
3. Restart the server.

2.3     Open JProfiler session for profiled Application server

• Step 1: Navigate to the JProfiler Install Directory, Ensure that JAVA_HOME & DISPLAY variables are set.
• Step 2: Execute the shell script under extracted JProfiler folder , <JProfiler Directory>/bin/jprofiler
• Step 3: JProfiler window will open , click on ‘Session’ and select ‘New Session’. In case you have saved the session earlier  please skip to Step 9.

• Step 4: Select ‘Attach to profiled JVM (local or remote)’

• Step 5: Enter the Host name for the application server need to profiled and the port number (configured in step 2.2)
• Step 6: Enter the session name as required and click ‘OK’. This session will be saved and next time you can directly open the session.
• Step 7: JProfiler will try to connect to profiled application server , once connected below screen appears.

Select Instrumentation.

• Step 8: JProfiler will start collecting data & below screen will be displayed. Start / Stop the several Jprofiler recording as per requirement. 

• Step 9: In case if you have already saved the session earlier. Open the JProfiler window , Click ‘Session’ and select ‘Open Session’

• Step 10: Select the previous saved session and Click ‘Open’.

• Step 11: Click ‘OK’ , Reports will be generated like screenshot attached in Step 8.

This project needs to migrate WTP metadata in eclipse

Sometime if you are importing the portal web project or java project , even after doing clean build it throws error.... 'This project needs to migrate WTP metadata'

There are possible solution to this issue :

1) Delete the .settings folder from the project , refresh the workspace and clean build.
2) Right click on the project and click 'validate'.
3) Delete the .metadata file and create the new workspace. This should be the last option as it may require a lot of rework to set up the workspace.

For me first two option worked , however we used the third option also in one of the case.

IPC (Inter Portlet Communication) in weblogic portal using WLP-Handled Events

In this post you will be able to understand and implement IPC using WLP-Handled Events. I will be using here 'Custom Event Handler' and backing file for the listener portlet to execute the further logic. In this way events are being handled by Weblogic Portal Framework and so not compatible with other JSR 286 portlet containers. Please refer Oracle Weblogic Documentation for details.

Assumption: Reader is aware of basic Weblogic portal framework

  Below are the steps to configure the IPC with 'Custom Event Handler' :


 1) Open the portlet in Portlet Editor.

 2) Click on 'Event Handlers' and click on tab 'WLP-Handled Events'.

 3) Add Handler as 'Handle Custom Event'

 4) Type 'Event Label' and 'Event Name'

 5) Select 'Listen To (wildcard)' to 'Selected Portlets'

 6) Select the portlet under 'Listen To (portlets)' , from where event need to be triggered

 7)  Now click on 'Add Action' and select 'Invoke BackingFile Method' ( in this particular example I am using backing file to listen the event).

 8) Type the method name ( see below for detail in next point).

 9) Create the method in the portlets backing file with signature HttpServletRequest request, HttpServletResponse response, Event event and do the following to get the data sent through payload from 1st portlet.
   9.1) Get PortletBacking context                                                                                                                                                                                                PortletBackingContext pbc = PortletBackingContext.getPortletBackingContext(request);
 9.2) Get Event String eventQName = event.getQName().toString();
 9.3) Get the payload event.getPayload();

10) Fire custom event from 1st portlet:
    QName qName = new QName("urn:com:oracle:wlp:netuix:event:custom", "<EventName from step 4>");
    PortletBackingContext pbc = PortletBackingContext.getPortletBackingContext(request);
        pbc.fireCustomEvent(qName, <payload>);

Note: Please refer Oracle Weblogic documentation for details.

  

Configure log4j in Weblogic10.3

For Configuring log4j in Weblogic 10.3 follow below steps:

1) Place log4j-1.2.16.jar in your project build path.

2) put log4j.xml in your domain directory ( you can make any folder for ex. 'configuration')

3) There are many ways to initilize log4j, here I am including two ways

  a) Edit the server start up script
     Open $DOMAIN_HOME\bin\setDomainEnv.cmd and set LOG4J_CONFIG_FILE with complete path of log4j.xml. For example if you have placed log4j.xml under configuration folder.
set LOG4J_CONFIG_FILE=%DOMAIN_HOME%\configuration\log4j.xml

b) With Spring framework 
If you are using Spring framework in your application then add below entry in web.xml.
    <context-param>
   <param-name>log4jConfigLocation</param-name>
   <param-value>file:${DOMAIN_HOME}/configuration/log4j.xml</param-value>
 </context-param>
 <context-param>
   <param-name>log4jExposeWebAppRoot</param-name>
   <param-value>false</param-value>
 </context-param>
 <listener>
   <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
  </listener>

4) Restart the server.

You are done with log4j configuration !!

Overview of ICEfaces Portlet Integration with WeblogicPortal , D2D Mechanism

1. SCOPE

                    This page is intends to briefly explain overview of ICEfaces with Its AJAX capability components.  It summarizes problems occurs while using ICEfaces with JSF portlets. What are benefits of using D2D. Suspicion areas while using D2D.

2. ICEfaces overview

1.       ICEfaces is extension to JSF for providing rich UI experience by enhancing JSF framework and lifecycle with AJAX based feature.

2.        ICEfaces provides an extensive Ajax-enabled component suite that facilitates rapid development of rich interactive web based applications.

3. Portlet development using ICEfaces 2

Portlet support in ICEfaces is now provided by the PortletFaces Bridge, an implementation of the JSR 329: Portlet 2.0 Bridge for JavaServer Faces. The portlet bridge specification technically applies to JSF 1.2 but the PortletFaces version been adapted to support JSF 2. The PortletFaces Bridge is tested and shipped with the ICEfaces 2 distribution and can be used to develop portlet applications with ICEfaces.

portlet.xml

ICEfaces 2 makes use of the PortletFaces Bridge to handle the mapping of the portlet lifecycle onto the JSF lifecycle. This has many advantages like enabling proper resource handling and cleaner integration with the portal container.

    <portlet>

        <portlet-name>chat-ice2-portlet</portlet-name>

        <display-name>Chat</display-name>

        <portlet-class>org.portletfaces.bridge.GenericFacesPortlet</portlet-class>

        <init-param>

            <name>javax.portlet.faces.defaultViewId.view</name>

            <value>/view.xhtml</value>

        </init-param>       

    </portlet>

The important parts are:

·         The portlet-class, which needs to be defined as org.portletfaces.bridge.GenericFacesPortlet.

·         The javax.portlet.faces.defaultViewId.view which should identify the page that is the initial view of the portlet.

3.     Portlet development using ICEfaces 1.8

           portlet.xml

... <portlet>

             <portlet-name>toggleMessage</portlet-name>

             <portlet-class> com.icesoft.faces.webapp.http.portlet.MainPortlet </portlet-class>

             <init-param>

                  <name>com.icesoft.faces.portlet.viewPageURL</name>

                   <value>/toggle.iface</value>

             </init-param>

</portlet> ...

The <portlet class> is the fully qualified class name of the class that implements the Portlet interface. ICEfaces has its own portlet, which could be considered a bridge of sorts, that handles incoming calls from the portal container and passes them on to the ICEfaces framework. You must use this portlet or a subclass of this portlet as the <portlet-class> value. The <init-param> setting uses a key of com.icesoft.faces.portlet.viewPageURL. The value of this parameter is the initial view that the portlet displays on the initial render pass. It is important to use the .iface extension to ensure that the request is properly handled by the ICEfaces framework.

DD Configuration 

As an extension to JSF, ICEfaces provides its own version of the FacesServlet (PersistentFacesServlet)

as well as an additional Servlet (BlockingServlet) for handling asynchronous updates. We register these

Servlets in the deployment descriptor file (web.xml) by adding the following entries:

<servlet>

<servlet-name>Persistent Faces Servlet</servlet-name>

<servlet-class>

com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet

</servlet-class>

<load-on-startup> 1 </load-on-startup>

</servlet>

<servlet>

<servlet-name>Blocking Servlet</servlet-name>

<servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>

<load-on-startup> 1 </load-on-startup>

</servlet>

We also need to add a new Servlet mapping of PersistentFacesServlet to .iface.

<servlet-mapping>

<servlet-name>Persistent Faces Servlet</servlet-name>

<url-pattern>*.iface</url-pattern>

</servlet-mapping>

We also need to add a couple of mappings for ICEfaces’ internal use.

<servlet-mapping>

<servlet-name>Persistent Faces Servlet</servlet-name>

<url-pattern>/xmlhttp/*</url-pattern>

</servlet-mapping>

<servlet-mapping>

<servlet-name>Blocking Servlet</servlet-name>

<url-pattern>/block/*</url-pattern>

</servlet-mapping>

 5. D2D

Direct-to-DOM (D2D) rendering is just what it sounds like—the ability to render a JSF component tree directly into a W3C standard DOM data structure. ICEfaces provides a Direct-to-DOM RenderKit for the standard HTML basic components available in JSF.

The way this basic Direct-to-DOM mechanism is deployed in an ICEfaces application involves server-side caching of the DOM and an Ajax bridge that transmits DOM changes across the network to the client browser where the changes are reassembled in the browser DOM.

When the ICEfaces JAR is included in your JSF application, the Direct-to-DOM RenderKit is automatically configured into the application. There are no other considerations from the developer perspective. Direct-to-DOM rendering is completely transparent in the development process.

One of the key features of Direct-to-DOM rendering is the ability to perform incremental changes to the DOM that translate into in-place editing of the page and result in smooth, flicker-free page updates without the need for a full page refresh.

Direct-to-DOM (D2D) rendering is a mechanism that renders a JSF component tree into a W3C standard DOM. When the rendered DOM is cached between JSF lifecyles, it can be used to compute the difference between 2 successive page views, to determine a precise set of DOM changes required to update the page from one view to the next. D2D rendering is core to the Automatic Ajax feature of the ICEfaces 2.0 framework.

Rendering

When the ICEfaces 2.0 Jar is added to a JSF application, the standard RenderKit is overridden with the ICEfaces RenderKit, and specifically, the ICEfaces RenderKit provides a DomResponseWriter instead of the standard JSF ResponseWriter. The DomResponseWriter diverts the output of any component renderer into a server-side DOM data structure.

DOM Differencing

A newly produced DOM from the D2D rendering process represents the page that will be replicated in the client browser DOM. The cached previous DOM is a replica of the DOM currently in the client browser, so the difference between the two DOMs defines the page updates that need to occur at the client browser. The differencing mechanism performs the basic task of calculating the set of updates to transform one DOM into the next, but the implementation in ICEfaces 2.0 has been highly optimized.

Page Updating

Given the set of page updates from the differencing algorithm, the standard JSF Ajax mechanism is used to deliver and insert those updates into the client DOM, thus completing the JSF lifecyle with D2D rendering.

6. ICEfaces components of our interest

                                                        

 Popup

                       The panelPopup component can be used to display various types of content inside a drag able or modal dialog. These dialogs can be used on pages to display important information and options to the user in a manner similar to a standalone offline application.

Data Table                    

                                  The dataTable component can display Objects in a Collection or an Array where each Object represents one row in the table and columns match instance variables in the Object. This mapping is achieved through the JSF attribute iterator pattern of value and var and introspection. The dataTable can limit the number of rows it displays and CSS styles can be applied to both rows and columns.

Auto-Complete

                                          The auto-complete component is named ice:selectInputText. It provides an inputText component enhanced with the ability to select an option before input has been completed. As the user enters text into the component a pop-up list of possible matching values is provided to the user.

7. ICEfaces advantages and AJAX based features

                                                      

Automatic Ajax

                              Automatic Ajax is a mechanism in the ICEfaces framework that calculates precise/minimal page updates from one JSF lifecycle to the next, eliminating the need for standard JSF <f:ajax> tags in the page.

Single Submit                       

                          Single Submit provides the ability to submit one component to execute in the JSF lifecycle, and is integral to the Automatic Ajax mechanism in ICEfaces 2. This means that only the specified component will decode, validate, update it's bean model state, and trigger events, but a full render phase will occur. Direct-to-DOM Rendering is then used to determine the set of incremental page updates that must occur in the client browser DOM.

Ajax Push

                 Ajax Push allows the application to incrementally update any part of the page at any time, for any group of clients. This is a small change in terms of the technical capabilities of Ajax applications, but it is a revolutionary change in terms of what applications can actually provide to users. Ajax Push is the key to building collaborative multi-user applications for the web.

8. Problem areas

i) ICEfaces 2 support for Weblogic Portal - NO

ii) Can we use ICEfaces 1.8 with GenericFacesPorltet class in portlet.xml – “NO”

iii) Using D2D in Weblogic portal as per ICEfaces documentation When the ICEfaces JAR is included in your JSF application, the Direct-to-DOM Render Kit is automatically configured into the application. There are no other considerations from the developer perspective. Direct-to-DOM rendering is completely transparent in the development process.

References:

i)  IceFaces Wiki

             ii) IceFaces DevGuide