At one of my customers I use JDeveloper 11g also as a subversion client. It is actually my first experience of the SVN implementation of JDeveloper, because I'm not able to install a tool like TortoiseSVN on this computer.

I'm pretty positive on the svn-client in Jdev. But unfortunately I haven't found any means to change the password in the UI. At this customer my windows-password has to be changed monthly, and the svn-password depends on it.

Jdeveloper stores the subversion connect info in the file

$APPLICATION_DATA\Roaming\JDeveloper\system11.1.1.6.38.61.92\o.jdeveloper.subversion\repositories.xml

(where "system11.1.1.6.38.61.92" depends on the Jdeveloper build).
The file looks like:

<?xml version = '1.0' encoding = 'UTF-8'?>
<svn-repositories xmlns="http://xmlns.oracle.com/jdeveloper/1013/svn/repositories">
   <svn-repository>
      <url>https://svn.customer.nl/svn/odc/odc-cmr/APPLICATION/source/trunk</url>
      <alias>Application Trunk</alias>
      <user-name>makker</user-name>
      <password>PlainOrEncryptedPasword</password>
   </svn-repository>
</svn-repositories>

Remarkable is the version number in the namespace (1013), since it really comes from my Jdev11g install.

When you first create the connection and give in your username/password via the UI, the password will be stored in here encrypted. But you can also give in an unencrypted password. So I entered my new password in plain format. And it works.

I haven't found how I can encrypt the password, what would, of course, be better. If anyone has a tip, then I'm interested.

You can also rename or delete the file,  then JDeveloper will ask for the new server connection.

Sometimes I want to duplicate or reuse a Virtual Machine for another purpose. This week I had to start with a setup for a B2B communication for a client. So I pick one, duplicate them and change the particular hostname and corresponding network settings (/etc/hosts) to reflect the particular situation. So that I can communicate to the instance with its own host-alias.

It is not exactly necessary, but it is neat to have the hostname of the server changed to the particular situation. But if you have installed an Oracle 11g database, you'll encounter that you can't login at it anymore.
Some how the database checks the hostname and with the ip-address of the server its installed on.
I found the solution here in the doc, see paragraph 3.3.2.2. Network.

You'll have to make sure that the name of your host (see cat /etc/sysconfig/network) is in the /etc/hosts file with the ip address of the machine.
So my first network adapter is a host-only with a fixed address of 10.0.0.1. As such I installed the database. If I change my hostname to 'darwin-vce-soa', for instance then in the /etc/hosts there should be a line like:

10.0.0.1          darwin-vce-soa.darwin-it.local    darwin-vce-soa

Also make sure that you change the listner.ora and tnsnames.ora in $ORACLE_HOME/network/admin.

Oh, and if you are on a demo/development server, you may want to have password expiry turned off. See my blog-entry here.

If you change the host name of the server that runs your weblogic server, then connecting to a page in the weblogic server (/console, /em, etc) may cause page load errors.
When installing the weblogic server, it registers the current hostname as the name of the server in the domain config. It will do a URL-rewrite to that hostname when connecting to a webapplications.

To change the weblogic-hostname, go to config folder of the domain home and edit the config.xml.
under //server/web-server/frontend-host you find the host that is used for the url rewrite. Edit it according to your hostname settings:

<?xml version='1.0' encoding='UTF-8'?>
<domain xmlns="http://xmlns.oracle.com/weblogic/domain" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/security/xacml http://xmlns.oracle.com/weblogic/security/xacml/1.0/xacml.xsd http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator/1.0/passwordvalidator.xsd http://xmlns.oracle.com/weblogic/domain http://xmlns.oracle.com/weblogic/1.0/domain.xsd http://xmlns.oracle.com/weblogic/security http://xmlns.oracle.com/weblogic/1.0/security.xsd http://xmlns.oracle.com/weblogic/security/wls http://xmlns.oracle.com/weblogic/security/wls/1.0/wls.xsd">
  <name>fmw_domain</name>
  <domain-version>10.3.5.0</domain-version>
...
  <server>
    <name>AdminServer</name>
 ...  
    <listen-port>7001</listen-port>
    <listen-port-enabled>true</listen-port-enabled>
    <web-server>
      <!--<frontend-host>old-host</frontend-host>-->
      <frontend-host>fmwhost-vm</frontend-host>

Today I was to setup a B2B configuration. So I wanted to have two SOASuite11g VM's working together on my laptop. My colleague created a VM for this particular client in VMWare Player, so I wanted to use that one, in stead of one of my VirtualBox VM's.

One of the features I rely on in this setup is the host-only network. Since it is a B2B setup, I need the two VM's to communicate together, so they have to be able to ping each other over the same network. Although internally in the VM the particular network adapter will get an ip-address. But it was not "pingable" from the host.

I was about to uninstall VMWare Player and re-install it to get it defaulted again. But probably it would not make a difference in this. Luckily I found this terrific post that helped me out. Thanks Tino. And it gives some tips about how to do some VMnet changes on the commandline that cannot be done UI-wise in VMware Player.

It turns out that in Windows 7 the VMNet1 adapter on the host was set on manual setings having a an auto-ip address (eg. 169.254.x.x).

This can be solved by going to the "Network and Sharing Center" (the English name for the German "Netzwerk- und Freigabecenter"). Click on the "VMware Network Adapter VMnet1". And then:

• Click on the button Properties
• Disable "Internet Protocol Version 6 (TCP/IPv6)". 
• Select "Internet Protocol Version 4 (TCP/IPv4)" and click on the button "Properties"
• Set the radio button on "Obtain an IP address automatically"

Then it solved my problem. 

Wouldn't it be nice to see what particular version you have deployed on your SOASuite test or production environment. How often does it occur that you thought you solved a problem but it still does not work on test or production. And after doing loads of tests and investigation you encounter that not the version you expected was deployed?

This week I tried to add the svn Id keyword in a piece of comments in the WSDL of the service. But it turns out that at deployment the SOASuite filters out the comments. So that won't work.
But since I'm writing this blog you might expect I found a trick...

First add the svn keywords  to the files you want to have the properties in. In this particular case it would be the service wsdl. This can be done with Tortoise SVN by right clicking the file, and choose TortoiseSVN->Properties. Then clicking the new button you can choose for Keywords:


 After that you can check the SVN properties you like to use. For most cases ID gives you all the info you need.
 Clicking OK will get you back to the properties screen, where you'll see:

Mark that in the list of checkboxes the Id-keyword is all in capitals, while in the comma-seperated list of keywords in the properties pane, the Id-property is in the correct spelling (one capital I).
The trick is to add the property as a namespace declaration as:

  xmlns:svnid="$Id$"
  xmlns:version="1.1"

After a SVN-commit this will expand to:

  xmlns:svnid="$Id: ImportEquipment.wsdl 765 2012-06-08 13:07:10Z makker $"
  xmlns:version="1.1"

Like such:

The reason I added a "version" namespace as well is that your wsdl will not change every time the service changes. Often you change a bit of BPEL or XSL or something like that, while your interface, the wsdl, stays unchanged. To force SVN increase the revisionid in your wsdl, you can change the xmlns:version namespace.

Here and there migrate/upgrade projects for SoaSuite10g to SoaSuite11g are running. Most of the time the source is committed to Subversion. It turns out that JDeveloper makes a full copy of the project folder at upgrade.
This means that also the .svn folders are copied. And you probably don't want that. I would have the new project in a different branch in my subversion folder.

At a former customer there was a registry file that creates a menu item in the Windows explorer pop-up menu. This would hierarchically delete all .svn folders in the selected folder. But not allways you're able to install such a shell-command.

So I created a little ant script. Since we're working with JDeveloper11g, we have an Ant install. I also created a windows bat file to run the ant script with a folder that can be given as a command line parameter.

The build.xml:

<?xml version="1.0" encoding="windows-1252" ?>
<project default="run">
  <target name="run">
    <tstamp/>
    <property environment="env"/>
    <property name="scan.folder" value="${env.SCAN_FOLDER}" />
    <!--<property file="./build.properties"/>-->
    <echo message="Delete all .svn from ${scan.folder}"></echo>
    <delete includeemptydirs="true"  verbose="true">
      <fileset dir="${scan.folder}" includes="**/.svn/**,**/.svn" defaultexcludes="false"/>
    </delete>
  </target>
</project>

The fileset in the delete can be found as an example in the doc of the Ant Delete Task. However, I found that the example did not work as such, for .svn folders with content. So I expanded the includes property to "**/.svn/**,**/.svn" to delete the content of .svn folders, before deleting them.
I set the verbose attribute, to see which folders/files are actually deleted.

The delete deleteSVNFolders.bat file is:

@echo off
cls
set ORACLE_HOME=d:\oracle\Product\JDeveloper11116\Middleware
set ANT_HOME=%ORACLE_HOME%\jdeveloper\ant
set PATH=%ANT_HOME%\bin;%PATH%
set JAVA_HOME=%ORACLE_HOME%\jdk160_24
set SCAN_FOLDER=%1
ant

You'll have have to change the ORACLE_HOME setting to point to your JDeveloper middleware home.
Of course this works on linux as well, but than you'll have to transform the bat file to a bash script. But that's no rocket science...

In a SOA application there will be many services that are dependent on each other. Naturally one would develop a service, deploy it to a server and in a next service refer to that deployed service. That means that in the new project a reference is created based on a concrete WSDL that resides on a remote server. Often the WSDL and related XSD’s are copied to the referencing project. This causes several copies of basically the same XSD and WSDL throughout the whole SOA application system. Maintaining these xsd’s is a tedious job. At compilation of a project the server delivering the deployed service should be up and running. And at the end the deployment of the whole application to a new server (System Test, Acceptance Test, Production) is constrained in the order of deploying the different components of the application.

The solution in SOASuite 11g is to use the Meta Data Store (MDS). There are a few blog-entries on how to relate to XSD’s/WSDL’s in the MDS on the server and how to synchronize the XSD’s and WSDL’s. For a good starting point the following two blog entries are helpful:

• Clemens Utschig Utschig: Re-using common metadata (wsdl / xsd / edl) in SOA Suite 11g 
• Edwin Biemond: Soa Suite 11g MDS deploy and removal ANT scripts

However, these blog entries don’t provide an overall description on how to setup your project/application for using the MDS. Also these entries don’t show how to relate the application to a shared local “MDS” folder elsewhere besides in the Jdeveloper install folder. In a regular project you would place the artifacts in a subversion (SVN) server. So the references to the XSD’s and WSDL’s would be to a folder structure in the SVN working copy and that won’t (should not) reside in the Jdeveloper install folder.
That leaves me to tie the pieces together. So I created a demo application to work-out the details and wrote a whitepaper about it. You can download the whitepaper from our site.