Using ADF Logging in a non-ADF project

In a previous post (Starting with ADF 11G Logging), I explained how ADF logging is simple to set up, and how it will enable you to set the logging levels at runtime, without having to restart any server. When I showed this to a colleague of mine, he immedialtely popped the question : “Can’t we use this for all of our java applications, even the ones that don’t use ADF?”. Well, the answer is yes, and it turns out to be very easy. Just add the correct jar to your project and your done.

This blog will demonstrate how to get this working. I use Eclipse Juno to create a small webproject, only containing a servlet that does the logging. In fact I will use the same servlet I used in the previous post.

So I open my Eclipse , and started with a File -> New -> Dynamic Web project. Give it a name, set ‘Dynamic web module version’ to 2.5, click the  ‘Add project to an ear’ checkbox and click finish.

dyn_wb_prj

Now Eclipse has created a web and ear module for me.

Image

Now right click the web project (ADFLogging), and select New -> Servlet, give it a name, eg. TestServlet, and click finish.

Remove the generated code in the servlet, and copy the code from the servlet ‘ExecuteLogger’ from my previous post (here) and paste it in our new serlvet.

PS. : When you copied the code from my previous blog, don’t forget to set ADFLogger.createADFLogger to our current servlet class name : TestServlet.class.

We will get compile errors on HttpServletRequest,etc… and on the ADFLogger class because they are not defined in the classpath of the project. So we’ll add them in order to get our servlet compiled.  I get the 2 jar’s from a JDeveloper installation I did on my machine. We’ll only add these jar’s in order to get the servlet compiled in Eclipse. We will NOT deploy them, as they are already available on our Weblogic server.

To add the jar’s, right click on the web project, and go to Properties. In the Properties, click on ‘Java Build Path’.

buildpath

Click on ‘Add External JARs…’ , and go to the directory where you installed your JDeveloper, which in my case is : C:\Oracle\Middleware.

In that directory , get following jar’s from the sub-directory :

\oracle_common\modules\javax.servlet_1.0.0.0_2-5.jar : contains the servlet classes like HttpServletRequest/Response,etc…

\oracle_common\modules\oracle.adf.share.ca_11.1.1\adf-share-base.jar : contains the ADFLogger classes.

Now we see the the following jar’s added :

jars_added

Click OK and return to the servlet. In the servlet use CTRL-SHIFT-O to import the neccessary classes from the jar’s we just added.

Now all compile errors should be gone.

Generate the ear file as follow : File -> Export -> Ear file

Select the ear project and enter destination of the ear file

When you examine the ear, you will notice that the folder \WEB-INF\lib is empty.

As the servlet and ADFLogger jar is already available on Weblogic, there is no need to deploy it with our application.

Now deploy the ear to the Weblogic and test the servlet with following url. :

http://localhost:7101/ADFLogging/TestServlet

It will generate following output :

output

To check the logging done by this servlet :

As I used the integrated Weblogic of JDeveloper, I will look for my logs using JDeveloper, but in a production environment,

these logs can be viewed using the enterprise manager of Weblogic. For details, see my previous blog.

In the Oracle Diagnostics Logging configuration, I see my servlet after the deployment. No message level is defined, so it will take “Warning”, as this one is defined as default by the Root Logger

logger

After te execution, I see following log lines in the log analyzer.

result

So that’s it. So the bottom line is to add the ADFLogger jar to your non-ADF project, and you are ready to go !

How to handle logging in BPEL Processes

1.1. Logging In Bpel

Logging can be performed on domain-level and system-level and you can use different mechanisms to log events, task details, …

In this post I’ve summarized the basic logging functionality you can use on bpel processes.


1.1.1. Process Logging Information

Oracle BPEL Process Manager uses the log4j tool to generate log files containing messages that describe startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.

The log4j tool enables logging at runtime without modifying the application binary.
Instead, logging behavior is controlled by editing properties in Oracle BPEL Control
and Oracle BPEL Admin Console.

Two logging levels are supported in Oracle BPEL Process Manager:
· Domain
o Manages logging information within specific domains
· System
o Manages logging information on a system-wide level

1.1.1.1. Domain-wide Logging

These can be configured through the BPEL Console (http://hostname:port/BPELConsole) > manage BPEL domain > logging or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\domains\\config

The different domains to log about:
· .collaxa.cube.engine.deployment – deployment related logging
· .collaxa.cube.compiler – compilation related logging
· .collaxa.cube.messaging – messaging layer (as bpel used messaging services to scale)
· .collaxa.cube.security – server side security (fwrk)
· .oracle.bpel.security – inside validator logging
· .collaxa.cube.ws – everything that is related to communication (WSIF layer, SOAP, Adapters) – shows you at least a longer stack if something breaks there
· .collaxa.cube.xml – xml transformation, storage, hydration
· .collaxa.cube.services – logging for services like Notification or Human Workflow
· .collaxa.cube.engine.delivery – Delivery Service and Manager, responsible for callbacks, and first (initiating) delivery
· .collaxa.cube – cube related logging (system)

1.1.1.2. System-wide Logging

System-wide loggers are used for logging information about infrastructure, AXIS and WSIF bindings. They can be configured through the BPEL Admin Console (http://hostname:port/BPELAdmin) > logging or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\system\config

The different systems to log about:
· org.collaxa.thirdparty.apache.wsif – logger for system-wide WSIF
· org.collaxa.thirdparty.apache.axis.transport – logger to see what axis is sending on the wire
· org.collaxa.thirdparty.apache.axis – general axis related logging
· collaxa.cube.services – all BPEL PM wide services
· collaxa.cube.infrastructure – infrastructure such as DB connectors

1.1.1.3. Log Level

The following logging levels are available and listed here from highest priority to lowest priority. When a logging level is specified, all messages with a lower priority level than the one selected are ignored.

· Off
o Disables logging. This selection is the highest priority.
· Fatal
o Logs critical messages. After logging occurs, the application quits abnormally.
· Error
o Logs application error messages to a log; the application continues to run (for example, an administrator-supplied configuration parameter is incorrect and you default to using a hard-coded value).
· Warn
o Logs warning messages to a log; the application continues to run without problems.
· Info
o Logs messages in a format similar to the verbose mode of many applications.
· Debug
o Logs debugging messages that should not be printed when the application is in a production environment.
· All
o Enables all logging. This selection is the lowest priority.

1.1.2. Logging with Sensors

You can use sensors to generate application logging activity.

Note that logging with sensors impacts performance because sensor data objects are built even when logging is disabled.

You add sensors to specific activities and then extract data from variables. To do this, you must implement a custom sensor publishing action to do the log4j logging. For example, you can create a sensor on an invoke activity and create a message that is
sent to a JMS queue.

1.1.3. Logging with bpelx:exec in a Java Embedding Activity

You can also log messages by adding custom Java code to a BPEL process using the Java BPEL exec extension bpelx:exec inside a Java Embedding activity in Oracle JDeveloper.

The method addAuditTrailEntry(String):void enables you to add an entry to the audit trail.

Deploying ADF Application to Standalone OC4J

For the deployment of an ADF Application to my standalone OC4J I’ve faced some problems which aren’t clearly explained/solved on OTN.
You will find many people facing the same problems when deploying applications to OC4J from jboException until Log4j-exceptions, etc.

I will try to address some of these problems in this blog using my own project deployed to a standalone OC4J.

Following errors/problems cam uping during deployment:

  • java.lang.NoClassDefFoundError: oracle/jbo/JboException
  • java.lang.NoClassDefFoundError: org/apache/log4j/Category
  • Problems with shared libraries and user-libraries when deploying from JDeveloper-IDE
  • Memory problems during deployment

How were this problems addressed and how did I package the application?

In my J2EE application the following technologies are being used: Toplink, EJB 3.0, OCS and finally ADF Faces as the frontend. Additional libraries we’re using: log4j-libraries.

This J2EE application uses the MVC-paradigm which means i’m working with 3 important layers: Model, View and Controller. In my case the Model is written in Toplink, the DataControl which is the glue between the Model and View is based on the EJB 3.0 (sessionbeans) and in the end we which faces for our Controller.

How did I package this application, by the creation of deployment profiles for each application that’s used in the application:

  • A jar-file for the Toplink-model and bizzlogic-model
  • An ejb-jar file for the EJB-project(s)
  • A war-file containing all logic of the view-layer (jspx, images, pageDefinitions, backing beans, web.xml file, jazn-data file, orion-application.xml file, etc.
  • An ear-file packaging all the different deployment profiles together using the Application Assembly tool

As I mentioned before i’m using log4j in the application and I experienced a lot of problems during deployment because a newer version of log4j is used in our application, than the one which is used by default by OC4J. How can you solve this problem:

  • Add the version you’re using in your project (log4j-1.2.13.jar) and the commons-logging jars from JDeveloper to the EAR file and point towards these 2 jar-files in the MANIFEST.MF file from the project that uses log4j

Secondly I mentioned Toplink is used for the Model-layer for which we needed to perform a manual configuration as well:

  • Copy xdb.jar from the toplink workbench folder to the directory of the standalone OC4J installation \toplink\jlib\xdb.jar

To address the jboException you need to install the ADF Runtime Installer to your standalone container. You can do this using the JDeveloper IDE, first create an Application Server Connection to your standalone OC4J. Go to the menu ‘Tools’, choose the ‘ADF Runtime Installer’ and choose to deploy to ‘standalone OC4J’.

Make sure your OC4J isn’t running when you perform this task because otherwise all libraries can’t be upgraded because they’re being used by the container.

Last but not least the ‘OutOfMemoryException’/PermGen Space can be adressed by adding memory to your standalone OC4J or IAS. For OC4J you could add the following attribute to the oc4J.cmd-file which can be found in the bin-folder of your oc4J_home => add the following:

OC4J_JVM_ARGS=-XX:PermSize=128m -XX:MaxPermSize=256m

If you need an indepth explanation about memory-management you can view the Memory Management topic on this blog.

Have fun!