SOA Suite 10g–> 11g migration and Issue with composite.xml Attributes

Here is a heads up for those that might still be working on 10g –> 11g migrations. There is one unfortunate bug (8980875) in the migration process that seems innocent in the beginning but has critical effects in the end.

I logged a service request for continuous XML parse errors in the managed server log files:

org.xml.sax.SAXParseException: <Line 5, Column 92>: XML-20129: (Error) Namespace prefix 'ui' used but not declared.

This occurs at deployment time. In most cases the deployed composite worked just fine.

Error comes from the composite.xml content where the migrated 10g SOA projects have all the XML root element “composite” attributes in a single line. The deployment parser seems to be some sort of home grown XML parser that assumes that all the attributes are physically separated in their own lines, like this:

<composite name="Archive"

and when the migrated projects have something like this:

<composite name="HelloWorld" revision="1.0" mode="active" state="on" xmlns:ui="http://xmlns.oracle.com/soa/designer/

in a single line, the deployment will give errors in this part. You might have some references in composite.xml pointing to external servers using “ui.wsdlLocation” like this:

<reference ui:wsdlLocation=http://mydevhost1.mydomain.com:8001/soa-infra/services/CommonExceptionHandling/CommonExceptionHandling.wsdl name="CommonException...

By default these should not affect the runtime environment since this is used at development time. Unfortunately combined with this bug 8980875, the pointer seems to stay in the runtime environment causing gray hairs when e.g. all of the sudden production environment has pointers to development environment. Changing this ui.wsdlLocation seems very hard if not possible using the built-in deployment scripts and default search/replace element descriptors.

In the end, the advice from me is to change all the migrated 10g –> 11g SOA projects manually to correct the composite.xml “composite” element attributes to their own lines. This will help greatly in the dev->tst->prd deployments avoiding those unwanted cross environment pointers.


One possible reason for not being able to login to OracleVM Manager

Today I faced the a weird situation when trying to login to OracleVM Manager 3.0.1 console. OVMM console did show up and provided me login screen. After entering username and password I got a weird internal error claiming login failed. Username and password were the right ones.

After a while of of debugging I noticed that all the passwords had expired from the OracleDB that holds the OracleVM repository.

I logged in as sys user and changed the default profile:

alter profile default limit password_life_time unlimited;

Then altered the passwords for the most important accounts: SYSTEM, OVS.

SYS user seemed to be in ok condition.

Then I restarted the OVMM process (root):

service ovmm stop
service ovmm start

After this login worked fine.