OpenCMS and OC4J 10.1.2 (part 2)

Trying to get OpenCMS working with OC4J 10.1.2 (or 10.1.3 dp4) seems to be quite challenging task. What makes this very interesting is that I don't seem to get any errors or exception messages in any of the logs despite of enabling full debugging in log4j.properties file.

There were definitely something wrong with the installation of OpenCMS on OC4J. The installation failed on NPE but system somehow managed to start up. Perhaps some of the modules got installed correctly. I can see that some of the config files point to Tomcat setup (like pointing to ROOT -default web application), so there might be something Tomcat specific behind the scenes that affect the application execution on other containers.

Anyways, to fork the problem area I installed OpenCMS using Tomcat (which works fine) so that I got the repository installed correctly on my Oracle 10.1.3 database. What I did then was I copied all the OpenCMS config etc. files under Tomcat webapps to the OC4J directory to make sure everything is as it should be after the installation. What happens is that systems starts up nicely, the log file compared to Tomcat looks exactly the same (used UltraEdit file diff'er to find out the differences). But what happens next after entering login (Admin/admin), is not something I am looking for. The login screen keeps popping up all the times and the workspace isn't shown. No error messages, no exceptions, no beeps, no nothing.

One step closer to despairness was when I downloaded the whole OpenCMS sources tree on my JDeveloper and re-built the whole application from sources. Now the only thing to find out was to remotely debug the OpenCMS server using JDeveloper's remote debugger and starting OC4J in debugging mode. Ok. This should work... or should it? I set the debug break point and debug the application line-by-line. For some reason the debugger freaks out in the critical moments that should point out the problem area. What is going on?

I also see that other people face the same problem when looking at OpenCMS mailing list.

Battle continues. Having the sources and detail debugging should eventually reveal the source of the problem. Let's see how long this takes.


OpenCMS and OC4J 10.1.2

For those that want to get OpenCMS working with OC4J here is an important note. The OpenCMS installer uses Java threads when setting up the modules. If you don't have user threads enabled in OC4J, you will face errors like "Unable to read opencms xml configuration". To work around this, you have to enable background threads for the container and this you do by adding following parameter to the OC4J container startup:

So if you start the OC4J from command line: java -jar oc4j.jar, you need to start with java -Doc4j.userThreads=true -jar oc4j.jar.
After this you will be able to run the setup successfully and continue using OpenCMS.

Re-packagaging EAR

For those that need helping hand on the re-wrapping the OpenCMS war file to be deployed as EAR in OC4J here are the steps:
1. Create a new subdirectory
2. Copy the opencms.war file to that directory
3. Create META-INF -directory and new file application.xml

<?xml version = '1.0' encoding = 'windows-1252'?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">

4. Package EAR file: jar cvf opencms.ear *


For deployment I usually use a script that uses admin.jar. Here is a sample I use on Windows:

set OC4JDIR=D:\apps\oc4j_extended_101202\j2ee\home
set FILEE=%1%
java -jar %OC4JDIR%\admin.jar ormi://localhost admin welcome -undeploy %FILEE%
java -jar %OC4JDIR%\admin.jar ormi://localhost admin welcome -deploy -deploymentName %FILEE% -file %FILEE%.ear
java -jar %OC4JDIR%\admin.jar ormi://localhost admin welcome -bindWebApp %FILEE% %FILEE% http-web-site %FILEE%

For Linux you need to figure out yourself how to replace the variable names in Unix style ;)

Login Problems

In the end of the installation I still faced some NPE exceptions, looks like they were related somehow to user management.
Once I re-started the instance I got following errors in the opencms.log:
19 Oct 2005 06:59:21,578 ERROR [ org.opencms.main.OpenCmsCore: 296] Critical error during OpenCms initialization: The OpenCms setup wizard is still enabled.

This can be fixed by setting the setup wizard setting to false in opencms.properties -file.

Once trying to open up the admin workspace using URL: http://localhost:8888/opencms/opencms/system/login, I will get the login dialog where I enter the default Admin username and password. From the log files seems like I get successful authentication but the workspace never shows up. The login dialog will always be shown to user. Seems like browser type (IE, TB) doesn't have anything to do with this.

The login problem is still to be resolved until OpenCMS can be successfully used with OC4J.

I'll be back.


BPEL Orchestration versus Choreography

I found a great arcticle (by Matjaz Juric) describing the concepts of BPEL Orchestration versus Choreography in simple way:


Jakarta Slide on OC4J

Never give up (referring to this post). Finally got Jakarta Slide server running on OC4J. The issue was with XML stack, there seems to be some sort of differences between the default Oracle XDK and the XML stack used with Slide. Anyways, to get Slide running you should define the Xerces and Xalan parsers as the JAXP factories in the OC4J startup.
Here is a sample startup script for my OC4J:
cd $HOME/oc4j/j2ee/home
-jar oc4j.jar

Xalan and Xerces libraries should be placed under JAVA_HOME/jre/lib/ext and remember to give at least read access to the account running the OC4j container.

JDeveloper 10.1.2 and Linux-x86_64 with JDK 1.5 (64-bit)

For those running on 64-bit Linux (e.g. using AMD64 CPUs) it is possible that you have 64-bit JDK 1.5 pre-installed. This is the case at least with Fedora Core 4.0 (64-bit).

If you want to get 10.1.2 JDeveloper running with JDK 1.5 you might get an error message such as:
Error: Hotspot VM not supported
Error: JDeveloper can't recognize the JDK version

Tha last error message is because of the first. To work around this you should edit the $JDEV_HOME/jdev/bin/jdev.conf -file and comment out the line that shows:
SetJavaVM hotspot

After this you should be able to start JDeveloper 10.1.2.

You might get some weird sticky startup screen showing in front of the initial questionnaire windows. After passing these (either try moving the windows or just pressing Enter) you should be fine with JDeveloper.


Powerpoint notes removal add-in

I described earlier a way to add a VBA macro in Powerpoint to allow removing the comments out of PPTs. This required adding the macro each time manually or having the macro in the powerpoint template by default. I decided that I make this small utility more handy by adding this as PPT add-in. This way the macro will be available all the times when dealing with PPTs.

Here is the PPT add-in (HJK_Remove_Notes.ppa), which you need to copy to the Microsoft add-ins directory. In my workstation the target directory is: C:\Documents and Settings\hkaukovu\Application Data\Microsoft\AddIns

After this you should restart the Powerpoint and navigate to Tools -> Add-Ins and press "Add New...". Choose the HJK_Remove_Notes.ppa -file and press Enable Macros button to start the add-in. You should have Plugins -menu item after the "Help" and from there if you choose "Delete Notes" you should be able to delete all the notes from the currently open PPT. The VBA macro will confirm you before you delete the notes.

If you find any issues pls let me know.

Comment on Blojsom installation on OC4J

I wrote in my earlier article about installing Blojsom on OC4J.

There is an easier way for installing applications on OC4J as pointed by Olaf Heimburger in his blog:



OC4J: Adding your own logging handler for J2EE application logging

For those that have the need to use their own custom or ready-made logging handlers with Oracle OC4J container, here is a sample how to do it.

Oracle OC4J J2EE logging is based on the J2SE 1.4 java.util.logging. This is the new standard logging utility that has most of the same features log4j has, althought log4j still has more custom logging handlers compared to JUL logging.

You can add your own JUL (java.util.logging) handler as logging handler in the container component (defined in j2ee-logging.xml), but this doesn't affect any of the sub-component loggings, like JMS, server, RMI etc. j2ee-logging.xml affects on custom logging events used in the applications.

One thing to note here is that in order to use e.g. java.util.logging.FileHandler, you must set the "-Djava.util.logging.config.file" -option in the "java -jar oc4j.jar" call to configure the logging options. Setting the properties in the j2ee-logging.xml doesn't have any effect on the java.util.logging handlers.

So in order to run the OC4J with the wanted logging handler you need to startup the container with following command line:
java -Djava.util.logging.config.file=d:\apps\jdev1012\j2ee\home\properties\logging.properties -jar oc4j.jar

Here is a sample j2ee-logging.xml:

<log_handler name="oc4j-handler" class="java.util.logging.FileHandler">
<logger name="oracle" level="ALL" useParentHandlers="false">
<handler name="oc4j-handler"/>

Here is a sample logging.properties file:

# "/" the local pathname separator
# "%t" the system temporary directory
# "%h" the value of the "user.home" system property
# "%g" the generation number to distinguish rotated logs
# "%u" a unique number to resolve conflicts
# "%%" translates to a single percent sign "%"



Loading Java properties file inside EJB component (OC4J)

Loading properties file inside Java is common way to parametrize the application. Under single JVM you would use following code to load the properties file:

Properties prop = new Properties();
prop.load(new FileInputStream("hello.properties"));
catch (FileNotFoundException e)
catch (IOException e)

Under OC4J you might want to keep all the properties files under the same directory e.g. $OC4J_HOME/properties. For this you should edit the container application.xml file under $OC4J_HOME/config -directory. Add following line to the application.xml:

<library path="../properties"/>

In the J2EE application you can trust the class loader to find the properties file under this directory. For this you should code your application as:

Properties prop = new Properties();
catch (FileNotFoundException e)
catch (IOException e)


Calling C/C++ gSOAP Web Services from JDeveloper

gSOAP is publicly developed C/C++ SOAP framework for Web Services client and server development.

Here is some loggin information trying to get Java -> C++ (via Web Services) to work together.

gSOAP distribution does not have ready made *.dlls or *.lib libraries for direct compilation. I had already Microsoft Visual C++ 6, which was just perfect environment for compiling the gSOAP basic *.dll's and sample C/C++ application. I tought I start the mini-project with the calculator samples mentioned in the manual. Generated the needed source code (*.cpp and *.h) + resource files using soapcpp2.exe.

Ok. after little bit of tweaking I got the first calc.exe to run as Web Service. Remember to add the "soap_set_namespaces(&soap, namespaces);" line after "soap_init(&soap)" in the C++ code. This will result the response message having all the needed namespaces and avoiding "SOAP version mismatch or invalid SOAP message" -error. Also noticeable was that the simple samples in manual did not work "as is" but the multi-threaded (with pooling) seems to work just fine, so that code base was used to serve the Web Service calls.

Imported the generated WSDL to the JDeveloper ( and generated the Java sample code. Trying to run the Web Service stub results in following error message: "Method 'ns1:add' not implemented: method name or namespace not recognized".

=> The problem was that the sample Calc.cpp had some odd namespace definitions. After I copied the namespace definitions form Calculator.nsmap the Web Service started working.

After this the TCP packet monitor showed that Web Service returns the right answer, but Java deserializer returns an exception at Java side:

[SOAPException: faultCode=SOAP-ENV:Client; msg=No Deserializer found to deserialize a ':result' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.; targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':result' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.]
at org.apache.soap.SOAPException.<init>(SOAPException.java:78)
at org.apache.soap.rpc.Call.invoke(Call.java:308)
at oracle.emp.kaukovuo.ws.mypackage.CalculatorStub.add(CalculatorStub.java:79)
at oracle.emp.kaukovuo.ws.mypackage.CalculatorStub.main(CalculatorStub.java:36)
Process exited with exit code 0.

Looks like the result -element should be data typed (the same kind of problems as with Microsoft SOAP Toolkit). This is easily worked around with J2EE Web Services by adding web.xml initialization parameter "accept-untyped-request" to "true". How is this done in Java client environment when receiving response?

The response to the question lies in gSOAP manual chapter: "8.1.5 XSD Type Encoding Considerations".

The most important thing is to compile the header file with "-t" option. This generates code to send typed messages (with the xsi:type attribute).
For fast development you should take a look at the *.xml files that soapcpp2 compiler generates. These will reflect the requests and responses that the SOAP client/server will receive. In the first phase you don't need to get everything running to test.