Monday, January 04, 2010

JDev ps1 : adf-config.xml invalid & SDO / TaskForm deployment

Note: Issues are solved with SOA 11g PS2!

There are two behaviours in JDev 11g ps1 that you do not want in conjuction with a Subversion checkout source directory:

1) Open SCA composite in JDeveloper
When you create SCA compsities with the latest release of JDeveloper 11g patch set 1, you could run into an frustrating error:

One or more metadata store location(s) configured in file:
/.adf/META-INF/adf-config.xml are invalid.

SOA project(s) will not compile! Please edit this file and fix metadata-store location(s).
Use following block to fix metadata store for namespace /soa/shared :

<namespace path="/soa/shared" usage="soa-shared-usage">
<metadata-store-usage id="soa-shared-usage">
<metadata-store name="oracle.mds.persistence.stores.file.FileMetadataStore">
<property name="metadata-path" value="${oracle.home}/integration">
<property name="partition-name" value="seed">
2) Deploy SDO / ADFBC exposed webservice It is not possible to deploy an ADFBC exposed as a web service to the application server. I have created a (new) simple ADC BC component and exposed this as a webservice with JDev 11g ( When I deploy this you get the errror:
09:13:33 PM Target platform is (Weblogic 10.3).
09:13:56 PM Retrieving existing application information
09:13:58 PM Running dependency analysis...
09:13:58 PM Deploying profile...
09:13:59 PM #### Deployment incomplete. ####
09:13:59 PM == ERROR: No j2ee modules detected in EAR archive. Deployment aborted.
== (oracle.jdeveloper.deploy.VetoableDeployException)
Both issues are related in JDeveloper and working from a subversion checked-out directory. This is a known bug, 9189120, there is no fix or workarround yet. A workaround could be, not the best one, but ut is working: Create a copy of your Subversion directory without any subversion (hidden) directory. Work in JDeveloper from this directory. After you have completed your work, copy the changes back to your subversion check-out directory and apply the subversion commit or update. A discussion is going on the the Forum:  Another workaround is using JDeveloper and the SVN plugin and NOT TortoiseSVN concurrently.