After having performed a quick dive into JDeveloper 12.2.1, I came across a quite interesting feature. OSB projects started to get converted to SOA projects! Being clueless about the reason for this strange phenomenon, I conducted a quick investigation and concluded it was due to adding XQuery transformations to the project. Below are my findings and how to go around this problem if you had the misfortune of coming across it as well.
While working on an OSB project in Jdeveloper 12.2.1, after adding an XQuery transformation, JDeveloper changes it to a SOA project. The project structure will change and an error will be produced by Jdeveloper when completing the XQuery creation. This will occur also when importing an OSB project that contains XQuery tranformations in Jdeveloper 12.2.1. Basically, as long as there is an XQuery file in the project, it will be converted to a SOA project. When trying to deploy the project, Jdeveloper will open the Wizard for SOA project deployment, which will fail, because we have in fact an OSB project.
Adding an XQuery file to the project
Below is an example of what happens when adding an XQuery file to an existing OSB Project.
Meanwhile, in the JDeveloper log, the below error can be seen as well:
Uncaught exception java.lang.NullPointerException at oracle.tip.tools.ide.fabric.addin.SCAProjectConfigurator.configSCAProject(SCAProjectConfigurator.java:216) at oracle.tip.tools.ide.fabric.addin.SCAProjectConfigurator.configSCAProject(SCAProjectConfigurator.java:131) at oracle.tip.tools.ide.fabric.addin.SCAProjectConfigurator.configSCAProject(SCAProjectConfigurator.java:126) at oracle.tip.tools.ide.fabric.addin.wizard.CompositeCreator.createComposite(CompositeCreator.java:284) at oracle.tip.tools.ide.fabric.addin.wizard.CompositeCreator.createEmptyComposite(CompositeCreator.java:202) at oracle.tip.tools.ide.fabric.addin.SCATechnologyListener$2.run(SCATechnologyListener.java:123) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) at oracle.javatools.internal.ui.EventQueueWrapper._dispatchEvent(EventQueueWrapper.java:169) at oracle.javatools.internal.ui.EventQueueWrapper.dispatchEvent(EventQueueWrapper.java:151) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Trying to deploy the project
Let’s say we are brave enough to ignore what happened and go ahead and try to deploy the project. We will be presented with the Deployment Wizard for SOA projects, which will fail if we go through all the way, since we have an OSB project in hands. Below you can see highlighted an indication that JDeveloper is looking at the project mistakenly as a SOA project.
There is a patch to fix this problem. To retrieve it, go to Oracle Support and refer to
Doc ID 2090174.1. Be sure to shut down JDeveloper before applying the patch and also to recreate the Default Domain in your installation (if you happen to be using the Integrated Server). As for the projects already affected, the cleanest approach is to recreate them and import the old files into them. As an alternative, it’s also possible to delete all soa-related artefacts from the projects and manually editing the .jpr files to remove the line highlighted below.
<hash n="oracle.ide.model.TechnologyScopeConfiguration"> <list n="technologyScope"> <string v="SOA"/> <string v="ServiceBusTechnology"/> <string v="XML"/> <string v="XML_SCHEMA"/> </list> </hash>
JDeveloper 184.108.40.206.0, when creating XQuery files in OSB projects
JDeveloper 220.127.116.11.0 when importing OSB projects containing XQuery files
And there you go. I hope this helps you to tackle this odd problem.
Carlos Pona (@carlospona84)
Carlos Pona is a SOA Technical Leader at Link Consulting.
Post header image by lees bus pics