Deployment to WebCenter Pre-configured OC4J

Ever wondered how to deploy your first portletized adf application to the ‘Webcenter preconfigured OC4J’ … it’s not documented in the Developer guide and you can’t find it on technet … so what should we do do …

Read further …

When you’ve created your ADF-application and you’ve portletized it to be deployed to your ‘Webcenter preconfigured OC4J’, you need to define the connection to your container (webcenter pre-configured)

This isn’t that easy as I expected because you can’t find the ports listed in the Enterprise Manager Console of the Webcenter pre-configured container. These settings aren’t documented either in the Developer Guide or on technet, so after a lot of searching and trying out we’ve finally figured it out.

There are 2 ways to get the connection-settings used by the ‘Webcenter pre-configured OC4J’:

  • Check out the log-window when shutting down the container in Jdeveloper, the following information is shown:

C:\jdev10132\jdev\extensions\oracle.adfp.seededoc4j. -shutdown -port 22667 -password welcomeShutdown OC4J instance…Executing:
C:\jdev10132\jdk\jre/..\bin\java -jar “C:\jdev10132\j2ee\home\admin.jar”
ormi:// oc4jadmin welcome -shutdown

  • Check out the rmi.xml file which can be found in the following directory



XML Publisher won’t start up anymore … !!!???

A month or two ago, I installed Oracle XML Publisher on my notebook. In order to run XMLP you need to run the “Oracle XML Publisher Enterprise start” (OC4J) via the Start Menu first. Next, you can run XMLP in your internet browser.

First it worked fine, but one day, XML Publisher wouldn’t start up anymore… and apparently the cause was the OC4J that failed to get up and running, as starting the OC4J start-up script resulted in the following error:

2006-12-04 09:47:57.453 ERROR Failed to set the internal configuration of the OC 4J JMS Server with: XMLJMSServerConfig[file:/C:/oracle/product/10.1.0/db_1/oc4j/ j2ee/home/config/jms.xml]

As my knowledge of Java is very limited, and there was nothing else I could think of that would solve my problem, I decided to simply re-install XMLP and … it worked again. But after a while, the old problem came back … Only did re-installing the software not work this time …

I went to look in the OC4J log files, and found that apparently my IP-address had shifted. Via the command ipconfig, I figured out that the IP-address causing the OC4J not to start, corresponded to my Wireless Network Connection… I disabled the WNC, and … EUREKA! It worked fine again. At least: I was able to start XMLP again, and fortunately I had my LAN-cable plugged in, so that I could access the database and continue with what I was doing.

But still, I kept wondering what went wrong, and why it went wrong and what if I really need that wireless connection to be enabled, while using XMLP?

Recently, I found an answer:

“You have encountered a “safety feature”
within the lightweight (pure java) OC4J Java Messaging System (JMS)
implementation. The OC4J Java Messaging System creates a lock file to constrain
access to a specific persistent message store to the single OC4J instance that
created it.”

“The persistence lock file captures
information about the OC4J instance that owns or previously owned the
persistence store and this information includes the IP address of the owning
oc4j instance. During startup if the OC4J Java Messaging System (JMS) discovers
that a persistence store it has been configured to use has a lock file that it
doesn’t own it will abort the startup procedure to avoid data corruption.“

Opening, for instance the jms.state.lock file shows the following:


… where the IP-address at the beginning of the line is – coincidence or not … – my Wireless Network Connection!!! So, a change had taken place at the network level since I last started an OC4J instance, causing the OC4J not to start anymore.

The start-up problem can be resolved via the following steps:

  • Ensure that there is no running OC4J instance that is accessing the persistence store
  • Navigate to the “persistence” directory for the OC4J instance that fails to start
  • Remove the “.lock” files

When starting the XMLP OC4J instance, the *.lock files will be created again, but your OC4J will start without any problem, as they will contain the correct IP-address.

Finally Oracle has announced their new hit on Oracle OpenWorld: Oracle WebCenter

For me this means I can finally talk about my sneak preview-experiences at Oracle HQ.

In August I went to San Francisco for 1 week expert testing of Oracle Workplace Suite, now formally announced by Oracle … ‘WEBCENTER’

The goal of this week’s expert testing was to get acquainted with Workplace Suite/WebCenter and most of all, test the product and give feedback to the product managers of Oracle.
We had to give feedback about the overall usability and user friendliness of the tool, which features were missing, enhancements could be made and most of all which bugs we ran into.

The product :

Workplace Suite/WebCenter is an extension to JDeveloper as well as the Application Server. The developer has the possibility to integrate portal- and content db-functionality in their existing JavaServer Faces application, and combine the strength of portal, contendb and adf in one web application.

An example of an application using the Workplace Services/Suite:

Day 1, Introduction/Overview :
Everybody gives a short introduction of themselves and then it’s time to find out what Workplace Suite has got to offer.

Sue Vickers and Peter Moskovits, 2 product managers, give us an overview of the portlet technology in Workplace Suite. In short the developer can add portlet-like capabilities to his JavaServer Faces application.

A new Application Template was defined that bundles all the necessary libraries you will need to add portal, contentdb and ADF functionality to your application.

Using wizards you can define your own custom portlets or register existing portlet providers, described in a wsdl file, which have their own defined portlets.

The portlets available through the provider are shown in the component palette, where the developer can drag-and-drop the different portlets on the JSF-page.

2 new components where added to give the end-user the possibility to redesign and redefine the look-and-feel of the portal-like jsf application at runtime.

The end-user can hide, show, maximize, minimize and re-locate the portlets, using the panelCustomizable- or showDetailFrame-component.

Portal developers will appreciate the out-of-the-box portlets provided such as the webclipping portlet, omniportlet and rich text portlet.
Another feature that will come in handy is ‘parameter wiring’ of portlets, the ability to have a Driving (master) portlet and a Driven portlet (detail).

For example: a search portlet where the user searches for a specific file on his content repository – the Driving/master portlet – and a detail-portlet showing the result of the search-operation, which can be an omni-portlet, web-service, …

As you’ve already noticed in the previous example, the developer can create a content-rich applica tions using the content db-features provided in Workplace Suite.
Through the usage of datacontrols, if you’ve developed in ADF you’re already familiar with this concept, you can integrate content db functionality.
You have the possibility to perform searches or browse the content of different repositories like file systems, the oracle portal repository or 3d party repositories using a JCR adapter (the Java API for accessing Content Repositories).

Day 2, Security & Deployment :

Today we will get an introduction on how deployment and security has to be defined for our workplace suite application works.

For the security-aspect Oracle has chosen for JAAS based security, which gives us the possibility to change policies at runtime and to define security on each level (attribute-, method- and object-level).
Using an out-of-the-box wizard you can choose to use JAAS for your application, from this moment on you will need to set privileges on each object in your application.
After enabling JAAS-security, you can add the different users and user-groups that will be using the application in your project preferences in Jdeveloper, under the tag authentication (see JAZN). For each user- or usergroup you will define the role, their privileges for your project/application.

Now our application is secured, but what about deployment?
To deploy our Workplace Suite Application we will use the lifecycle tool that consists of a multi-phase process to transfer the application and application metadata.
First a deployment profile is created that defines the kind of application we want to deploy, in our case a Workplace Suite application.
This deployment-profile will hold the generic-ear file that defines standard J2EE deployment. The pre-deployment tool will use this ear file to add portal- and content-db functionality using the MetaData Store. The MDS (MetaData Store) holds the application metadata concerning portal,ADF and contentdb.
When the pre-deployment tool has finished the targeted-ear file is created and this ear-file is deployed to Oracle Container For Java (OC4J).
When changes are made to portlet providers after deployment, these changes can be deployed to the production environment (e.g. new portlets are added to the portlet providers).
Without having to re-deploy the whole application you can import your customizations in the existing production environment.
Security settings are deployed by the JAZN Migration tool, which will describe the settings in an ldif-file and write them to your LDAP-server.
Using the mode of migration you can define which settings need to be deployed, the ‘Realm Mode’ only migrates users & roles, ‘Policy Mode’ migrates grantees and associated permissions, ‘All Mode’ migrates all security settings.

Day 3, 4 and 5:
During these 3 days we had the opportunity to test these features and to work out our own application which could be 1 of 3 cases provided by Oracle or your own test cases.
An outline was given of all the functionalities that need thorough testing … the time was come to get dirty.
I chose to create an application that used all of the functionalities we had seen and I wanted to deploy this application using the lifecycle tool.
After adding different portlets, parameter wiring, content db and ADF components to my application, it was time to deploy this to my standalone OC4J container.
Day 5 was d-day for everyone, for us and for the product managers, because today everyone needed to give feedback and if possible a project show-off.
My goal for today was to deploy my application to the stand-alone container. Apparantly, I was the only developer that wanted to test this functionality and got full assistance and back-up of the Oracle Workplace Suite/WebCenter development-team.

Between the lines … the manager of the guys of the development team that were supporting me wasn’t to happy about his two most important developers assisting me in the deployment process, but I was ;o)

In the afternoon all the product managers came to listen to our concerns, feedback and they took a look at the applications everyone built.
During this feedback-time I was still working on the deployment of my application with the development-team by my side … the deadline was approaching.
After a lot of searching, cursing, searching and cursing we finally managed to deploy the application ‘just in time’, and not only I, but the development- and the oracle-team were waiting on this moment!
We could conclude with a very reassuring and fulfilled feeling… deployment works!
I almost forgot to mention … my laptop holds the only working version of the container to deploy workplace suite applications to … you can build a workplace application, but you can’t deploy it ;o) Hopefully, the deployment features in the production release will be improved!