Friday, 24 August 2007

OC4J 10.1.3 j2ee-logging.xml console handler example

A note for myself , as I was trying to find an example on this:


level='FINEST' />


<logger name="simplelogging" level="FINEST" useparenthandlers="false">
<handler name="console-handler">

Java Code

public class LoggingTest extends HttpServlet
private static Logger logger =

Date d = new Date();
String s = d.toString();
logger.fine("pas simple logging test the current time is " + s);
// log levels
logger.log(Level.SEVERE,"pas simple logging test SEVERE!");
logger.log(Level.WARNING,"pas simple logging test WARNING!");
logger.log(Level.INFO,"pas simple logging test INFO!");
logger.log(Level.CONFIG,"pas simple logging test CONFIG!");
logger.log(Level.FINE,"pas simple logging test FINE!");
logger.log(Level.FINER,"pas simple logging test FINER!");
logger.log(Level.FINEST,"pas simple logging test FINEST!");


Output Location

The output using a console handler will go to the opmn log file for the container being used.



Tuesday, 21 August 2007

11G JDBC driver ojdbc5.jar and ojdbc6.jar

After installing 11g on linux you will find that the JDBC 11g driver is shipped as two files and ojdbc14.jar is no longer in there.

  • $ORACLE_HOME/jdbc/lib/ojdbc5.jar - JDK 1.5
  • $ORACLE_HOME/jdbc/lib/ojdbc6.jar - JDK 1.6
So if your using JDK 1.5 use ojdbc5.jar and if using JDK 1.6 use ojdbc6.jar. JDK 1.4 is no longer supported for the 11g drivers so thats the reason no ojdbc14.jar exists now for 11g. The documentation below clearly specifies support for JDK 1.4 is no longer available in the 11g JDBC drivers.

SYS.ANYDATA Oracle Type support in 11g JDBC Driver

This release of Oracle JDBC driver provides a Java interface to access SYS.ANYTYPE and SYS.ANYDATA Oracle types. His a small piece of code showing how to access a SYS.ANYDATA column from JDBC 11g.

Table definition:

create table anydata_table
(col1 number,
col2 sys.anydata)

Java Code snippet:

stmt = conn.createStatement();
rset = stmt.executeQuery("select * from anydata_table");
int i = 0;
while (
System.out.println("** Row " + i);
ANYDATA anydata = (ANYDATA)rset.getObject(2);
Datum embeddedDatum = anydata.accessDatum();
TypeDescriptor typeDescriptor = anydata.getTypeDescriptor();
int typeCode = typeDescriptor.getTypeCode();
if (typeCode == TypeDescriptor.TYPECODE_TIMESTAMP)
// the embedded object is a DATE
TIMESTAMP datedatum = (TIMESTAMP)embeddedDatum;
System.out.println("Timestamp Type");
else if (typeCode == TypeDescriptor.TYPECODE_NUMBER)
// the embedded object is a NUMBER
NUMBER numberdatum = (NUMBER)embeddedDatum;
System.out.println("Number Type");
else if (typeCode == TypeDescriptor.TYPECODE_VARCHAR2)
// the embedded object is a VARCHAR2
String varchardatum = embeddedDatum.stringValue();
System.out.println("VARCHAR2 Type");

More information on this can be found in the documentation

Monday, 20 August 2007

Database Change Notification in 11g JDBC driver

With the release of the 11g JDBC driver I decided to give Database Change Notification a test drive which is now part of the 11G JDBC driver. I tested this against a database and it worked well, and I can see this being a very popular new feature.

An example and documentation can be found here:

The 11g JDBC driver can be downloaded from here:

His some output of the database change event as a result of an INSERT into a table I had previously registered a change event for.

DCNListener: got an event (pas.jdbc.DCNListener@1a001ff)
Connection information :,
Registration ID : 6
Notification version : 0
Event type : OBJCHANGE
Database name : lnx102
Table Change Description (length=1)
operation=[INSERT], tableName=SCOTT.DEPT, objectNumber=101051
Row Change Description (length=1):

Tuesday, 14 August 2007

Obtaining the trace file name from JDBC when sql tracing is enabled

When turning on SQL trace in a JDBC thin program as follows I needed to get the actual trace file name at the time.

// turn on sql_trace
stmt = conn.createStatement();
stmt.execute("alter session set sql_trace=true");
System.out.println("\nSQL_TRACE=TRUE has been started \n");

All though not difficult I found this piece of SQL that I could run to determine the trace file being used by my program, which I executed from my JDBC program prior to turning on SQL tracing, so that at the end of the program I knew exactly what trace file I needed to analyze.

final String traceSQL =
"select c.value || '/' || d.instance_name || '_ora_' || " +
"to_char(a.spid, 'fm99999') || '.trc' "
"from v$process a, v$session b, v$parameter c, v$instance d " +
"where a.addr = b.paddr " +
"and b.audsid = userenv('sessionid') " +
"and = 'user_dump_dest'";

public void displayTraceFileName (Connection conn)
throws SQLException
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery(traceSQL);;

String fileName = rset.getString(1);
System.out.println("TRACE FILE NAME : " + fileName);

Example output:

TRACE FILE NAME : /home/oracle/oracle/product/10.2.0/db_1/admin/lnx102/udump/

Note: If your on a windows the SQL differs slightly, as shown below.

rem User must have access to v$session, v$process,
rem v$paramater and v$instance views


select c.value || '\ORA' || to_char(a.spid, 'fm00000') || '.trc'
from v$process a, v$session b, v$parameter c
where a.addr = b.paddr
and b.audsid = userenv('sessionid')
and = 'user_dump_dest';

Friday, 10 August 2007

Removing the data-sources.xml from deployment archives in JDeveloper

I am constantly asked how to remove the data-sources.xml file from a deployment EAR file. The issue here is JDeveloper is automatically configured to bundle a data-sources.xml file during deployment which is basically all your JDeveloper connections created as a entry for each connection. The easy way to avoid the data-sources.xml being bundled during deployment is as follows BUT there is a catch to doing this.


  1. Choose Tools > Preferences to display the Preferences dialog.

  2. Select Deployment on the left side.

  3. Deselect Bundle Default data-sources.xml During Deployment.

  4. Click OK.

So that will ensure you don't end up bundling the data-sources.xml during deployment , as most people have their data sources created at the container level so there is no need to deploy data sources in each application.

The problem is once you deselect the option as shown above if your running an application in the embedded OC4J server and it requires the data-sources.xml then you will get runtime issues. The trick is to switch it on while testing in the embedded OC4J server and then switch it off at deployment time.

This issue is documented here: