A createinstance issue to be aware of in OAS 10.1.3.x

When 10.1.3.0 came out and the only way to create a new oc4j instance was to use the createinstance BAT file on windows or script on unix. Once 10.1.3.1 came out you could create a new instance in ASC but I still use the createinstance script and doing so today ran into an issue as described below on OAS 10.1.3.1:

1. ran a command to create a new instance as follows

createinstance -instanceName ok

2. when promoted for the password I normally use "welcome1" but this time I thought I would use a different password and when I did that the instance still got created but an execption was thrown and it failed to start it.

[SEVERE: CoreRemoteMBeanServer.fetchMBeanServerEjbRemote Error reading application-client descriptor: Error communicating with server: Lookup error: javax.naming.AuthenticationException: Not authorized; nested exception is:
javax.naming.AuthenticationException: Not authorized; nested exception is:


3. So I started it manually as follows which worked fine in the end.

opmnctl startproc process-type=ok

4. Then when I logged into ASC and tried to administer this instance the following error occurred

Unable to make a connection to OC4J instance ok on Application Server 1013linux_purple.papicell-au2.au.oracle.com. A common cause for this failure is an authentication error. The administrator password for each OC4J instance in the Cluster must be the same as the administrator password for the OC4J instance on which Application Server Control is running.

It turns out that in order for ASC to administer the OC4J instance the password must be the same password used by ASC application which in my case was the home container. This being the first time I decided to use a different password I had never seen this issue before. In the end I changed the password for my instance "ok" to be welcome1 like the "home" container so I could administer it from ASC.

The following link shows how to change the password:

http://download.oracle.com/docs/cd/B31017_01/core.1013/b28940/em_app.htm#BABFAHBH

I decided to change it manually using the instructions under this heading:

A.2.5 Using the Command Line to Change the oc4jadmin Password for a Remote OC4J Instance

My First BPEL demo

I followed this how to on OTN using JDeveloper 10.1.3.1. All though the how to is for JDeveloper 10.1.2 it was easy enough to do it in JDeveloper 10.1.3 as the steps are similar.

http://www.oracle.com/technology/obe/obe_as_1012/integration/bpel/jdev_sect/first_bpel_proj/1st_bpel_prj.htm

All though just a simple hello world BPEL demo what I found interesting is that once you deploy your BPEL project the actual BPEL deployed process (HelloWorld in my case) is automatically published as a web service making it easily accessible from any client. In my case I accessed my BPEL process using a J2SE java client and then an ADF JSF Web Client.

Impressed from what I have seen on my first run with BPEL and the SOA suite, hope to play around with this a little bit more when time permits.

OC4J 10.1.3 j2ee-logging.xml console handler example

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

j2ee-loging.xml

<log_handler
name='console-handler'
class='java.util.logging.ConsoleHandler'
formatter='oracle.core.ojdl.logging.SimpleFormatter'
level='FINEST' />

....

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


Java Code

....
public class LoggingTest extends HttpServlet
{
private static Logger logger =
Logger.getLogger("simplelogging");
....

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.

Eg:

$ORACLE_HOME/opmn/logs/<container-log-file>

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.

http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/getsta.htm#i1008205

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 (rset.next())
{
 i++;
 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");
     System.out.println(datedatum.stringValue());
 }
 else if (typeCode == TypeDescriptor.TYPECODE_NUMBER)
 {
     // the embedded object is a NUMBER        
     NUMBER numberdatum = (NUMBER)embeddedDatum;
     System.out.println("Number Type");
     System.out.println(numberdatum.stringValue());
 } 
 else if (typeCode == TypeDescriptor.TYPECODE_VARCHAR2)
 {
     // the embedded object is a VARCHAR2
     String varchardatum = embeddedDatum.stringValue();
     System.out.println("VARCHAR2 Type");
     System.out.println(varchardatum);
 }
}

More information on this can be found in the documentation

http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraint.htm#CHDEBICE

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 10.2.0.3 database and it worked well, and I can see this being a very popular new feature.

An example and documentation can be found here:

http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/dbmgmnt.htm#CHDEJECF

The 11g JDBC driver can be downloaded from here:

http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html

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 : local=papicell-au.au.oracle.com/10.187.80.135:47632, remote=papicell-au2.au.oracle.com/10.187.80.136:15087
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):
ROW: operation=INSERT, ROWID=AAAYq7AAEAAAGv+AAA

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 c.name = 'user_dump_dest'";

......

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

 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/
lnx102_ora_8462.trc

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

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

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 c.name = 'user_dump_dest';

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.

Steps

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:

http://download-west.oracle.com/docs/html/B25947_01/deployment_topics013.htm

Access a Data Source from OC4J remotely from a java client

I needed to access an data source in an OPMN managed OC4J instance remotely from a java client. My data source was in the 10.1.3.2 release of Oracle Application Server and my client was JDeveloper 10.1.3.2. Here is how I got this to work.

1. New Empty project in JDeveloper
2. Add the following libraries, which will ensure all the required jars needed are added to the classpath:

• Oracle JDBC
• JSP Runtime
• Apache Ant

3. Create a client as follows, the connection is made with a provider URL using opmn:ormi format as shown below:

package pas.test;

import java.sql.Connection;

import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;

import javax.sql.DataSource;

public class AccessDataSource10132
{

 public static void main(String[] args)
   throws Exception
 {
   Connection conn = null;
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY,
       "oracle.j2ee.rmi.RMIInitialContextFactory");
   env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
   env.put(Context.SECURITY_CREDENTIALS, "welcome1");
   env.put(Context.PROVIDER_URL,
     "opmn:ormi://sracanov-au2.au.oracle.com:6005:OC4J_FCF/default");

   InitialContext ic = new InitialContext(env);

   DataSource ds = (DataSource) ic.lookup("jdbc/scottDS");
   conn = ds.getConnection();
   System.out.println("Auto commit is -> " + conn.getAutoCommit());

   System.out.println("all done..");
 }
}

The output is as follows:

Auto commit is -> true
all done..

ORA-01461 from JDBC program trying to insert large String

Having a database column defined as VARCHAR2(4000) in a table and trying to insert a character string which was 3983 characters failed with a runtime error as follows in a 10.2.0.2 Oracle Database with the character set AL32UTF8.

java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into
a LONG column

What is odd is that when run against the same database version 10.2.0.2 with a character set as WE8ISO5589P1, it worked fine no errors at all. The issue is that the when using character set as WE8ISO8859P1 it will be inserted without loss. But if the database is in the character set AL32UTF8 the Latin 1 characters will be expanded and the total size will increase.

Eg: http://www.unicode.org/charts/PDF/U0080.pdf

A simple Java class illustrates this as follows:

package project1;

public class Test
{
public static String test =
  "No lions. No tigers, but bears …";

static void showEncodedLength(String s, String encoding)
  throws Exception
{
  byte[] b = s.getBytes(encoding);
  System.out.println(encoding + " byte length: " + b.length);
}

public static void main(String[] args)
  throws Exception
{
  System.out.println("String length: " + Test.test.length());
  showEncodedLength(Test.test, "ASCII");
  showEncodedLength(Test.test, "ISO8859_1" );
  showEncodedLength(Test.test, "UTF8");
}
}

When run the output is as follows showing that the length increases when using UTF8 encoding even though only just this will result in a runtime error when trying to insert into large columns such as VARCHAR2(4000). The error ORA-01461 itself is not very useful, and fails to indicate the real issue here. From the output below you can see that it requires more length to insert into a UTF8 database

Output

String length: 32
ASCII byte length: 32
ISO8859_1 byte length: 32
UTF8 byte length: 34

If you have such an issue you should consider using a CLOB column if the data may exceed the maximum size of a varchar2 column as was the case here.

Connecting to the OC4J MBeanServer Doc Issue

I was attempting to connect to the OC4J MBeanServer in my opmn managed OC4J instance and was using the online documentation below.

http://download.oracle.com/docs/cd/B31017_01/web.1013/b28952/mbeans.htm#CIHFDJBJ

I found that in the example the service URL was specified incorrectly.

// Create a variable for a URL containing data needed to access 
// the connection target; in this case, an OPMN-managed OC4J instance
String url="service:jmx:rmi///opmn://opmnhost1.company.com:6003/home"

It is missing the : in the service URL. The correct way is shown below you will see the : added after rmi. A documentation bug has been filed.

Eg:

private String url="service:jmx:rmi:///opmn://papicell-au2.au.oracle.com:6003/home";

XA Transaction Errors On Websphere Talking To 10g Database Through JDBC Driver 10g

When attempting to run XA JDBC program on Websphere the following runtime error can occur:

13545 The XA Error is : -7
13546 The XA Error message is : Resource manager is unavailable.
13547 The Oracle Error code is : 17002
13548 The Oracle Error message is: Internal XA Error
13549 The cause is : null.
13550 [5/18/07 10:29:24:538 MST] 00000084 WSRdbXaResour E DSRA0302E: XAException occurred.
Error code is: XAER_RMFAIL (-7). Exception is:
13551 [5/18/07 10:29:24:538 MST] 00000084 WSRdbXaResour 3 XAER_RMFAIL connection error occurred
13552 [5/18/07 10:29:24:538 MST] 00000084 WSRdbXaResour 3 process connection error occurred
event for XAResource com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@43e4a31d
13553 [5/18/07 10:29:24:538 MST] 00000084 WSJdbcConnect > close Entry
13554 com.ibm.ws.rsadapter.jdbc.WSJdbcConnection@5f13637b
13555 [5/18/07 10:29:24:538 MST] 00000084 WSJdbcConnect 1 state --> CLOSED

It turns out that from the stack trace/error a 17002 error means that the connection pool is handing out stale connections which have been closed. This is documented on IBM web site with various different ways of trouble shooting stale connection errors from WebSphere. See the link below.

http://www-1.ibm.com/support/docview.wss?uid=swg21247168#SCETroubleshooting
Troubleshooting stale connection problems

Getting to the Java SSO configuration screen in ASC differs in stand alone OC4J versus OPMN managed OC4J instances

A while ago I setup my stand alone OC4J instance to use Java Sigle Sign On (Java SSO) as part of OC4J 10.1.3.1. Today I needed to do the same in an OPMN managed OC4J instance as part of OAS 10.1.3.1 and found that to configure it the steps are slightly different between the two in ASC (Application Server Console).

Here is how to get to the configure screen for Java SSO:

Stand Alone

1. Log into ASC
2. Click on the "Administration" link on the top of the page.
3. On this page you will find the following -> "Task Name -> Administration Taks -> Properties -> SSO Configuration" click on the icon for "Go to Task".

OPMN Managed OAS

1. Log in ASC
2. Scroll down to the bottom of the topology page and click the link "Java SSO Configuration"

Note: Of course in order to configure Java SSO you need to start "javasso" application as part of the MiddleWare Services application area, before you can configure it.

Dependency injection is not possible from a Struts Action class

Thanks to Debu for pointing out that when trying to use dependency injection JAVA EE 5 support limits this only to managed classes such as EJBs, Interceptors, Servlets, etc. I was attempting to do this from a Struts Action class and was not able do so, now I know why.

See Debu's blog entry for more details:
http://debupanda.blogspot.com/2007/06/injecting-pojos-and-using-resource.html

In the end I was forced into using regular JNDI lookup as follows from JDeveloper 10.1.3.1 / OC4J 10.1.3.1 from a Struts Action class:

 HttpSession session = request.getSession();
 ResultPager bean = (ResultPager) session.getAttribute("pagerbean");

 if (bean == null)
 {
   try
   {
     Context ctx = new InitialContext();
     bean = (ResultPager) ctx.lookup("ResultPager");
     bean.init(_pageSize, "AllObjectsRo.countAll", "AllObjectsRo.findAll");
     session.setAttribute("pagerbean", bean);    
   }
   catch (NamingException ex)
   {
     throw new ServletException(ex);
   }

 }

Getting a query count of records in EJB3

I was working on a small pagination demo with EJB3 and JDeveloper 10.1.3.1. I thought creating a query to count the number of records in my result set would be as simple as "select count(*)" but in EJB3 and JPQL world you can't use "select count(*)" unless you create a native query. Here is my named queries I used to get a count of my result set. In JPQL it's done with a query as follows, so no need to use a native query after all.

select COUNT(o) from AllObjectsRo o

@NamedQueries({@NamedQuery(name="AllObjectsRo.countAll",
query="select COUNT(o) from AllObjectsRo o"),
@NamedQuery(name="AllObjectsRo.findAll",
query="select o from AllObjectsRo o")
})