So there you are: a production error was reported … in your code (of all places) … but no one knows what release the code came from?

Wouldn’t it be great if it was easy to link deployed composites to their Subversion location and revision?

This article show an approach based on ‘Subversion keywords expansion’. This is illustrated with the following steps:

1. Add properties to the composite.xml file
2. Set Subversion keywords for composite.xml
3. Query the deployed composite with wlst
4. Solve the limitations in Subversion keyword expansion

Let’s get started:

Step 1: add properties to the composite.xml

In composite.xml, add the below lines after the properties for productVersion and compositeID that JDeveloper already added:

<property name=”productVersion” type=”xs:string” many=”false”>12.1.3.0.0</property>
<property name=”compositeID” type=”xs:string” many=”false”>38e4c940-31e8-46ca-90d7-1e56639f6880</property>
<property name=”subVersionURL” type=”xs:string” many=”false”>$URL$</property>
<property name=”subVersionRevision” type=”xs:string” many=”false”>$Rev$</property>

Step 2: set Subversion keywords for composite.xml

On composite.xml, add the Subversion properties ‘Revision’ and ‘URL’ (of type ‘svn-keywords’) .

This can be done using TortoiseSVN:

– check out your project from Subversion

– right-click composite.xml, goto TortoiseSVN –> Properties

– Click on ‘New’ and then ‘Keywords’:

– Select keywords ‘Revsion’ and ‘URL’:

– with result:

 

… and you’re done.

The same could be achieved or using command line:

   svn propset svn:keywords “Revision URL” composite.xml

 

After this is done, subversion will expand the svn keywords $URL$ and $Rev$ when the file is checked out.

Now, commit the composite.xml into Subversion and then check it out again. Examine the properties that now should look like:

<property name=”productVersion” type=”xs:string” many=”false”>12.1.3.0.0</property>
<property name=”compositeID” type=”xs:string” many=”false”>38e4c940-31e8-46ca-90d7-1e56639f6880</property>
<property name=”subVersionURL” type=”xs:string” many=”false”>$URL: svn://192.168.178.50/LGO/sandbox/HelloKeywordApplication/HelloKeyword/SOA/composite.xml $</property>
<property name=”subVersionRevision” type=”xs:string” many=”false”>$Rev: 25 $</property>

 

Now, re-deploy the composite with the new composite.xml

Step 3: query the deployed composite with wlst

After checking out the above code from Subversion and deploying it, the properties can be queried using the wslt script:

# function that returns mbean(s) of all composites
# borrowed from Edwin Biemond and changed

def findMBeans(prefix):
# get a listing of everything in the current directory
mydirs = ls(returnMap=’true’);

# we’re going to use a regular expression for our test
pattern = java.util.regex.Pattern.compile(str(prefix) + str(‘.*name=*’) + str(‘.*$’));

# loop through the listing
beanList = [];
for mydir in mydirs:
x = java.lang.String(mydir);
matcher = pattern.matcher(x);
# if we find a match, add it to the found list
while matcher.find():
beanList.append(x);

return beanList;

print ‘starting the script ….’
username = ‘weblogic’
password = ‘welcome01′
url=’t3://localhost:7001’

connect(username,password,url)

custom();
cd(‘oracle.soa.config’);

#Note the , at the end of the string, so components are not returned…
composites = findMBeans(‘oracle.soa.config:partition=default,j2eeType=SCAComposite,’);

for composite in composites:

cd( composite );

properties = mbs.getAttribute(ObjectName(composite), ‘Properties’);

print ‘Composite : ‘ + mbs.getAttribute(ObjectName(composite), ‘Name’);

for property in properties:
print ‘- property name/value : ‘ + property.get(‘name’) + ‘ / ‘ + property.get(‘value’);

print ‘———-‘;
print

cd(‘..’);

disconnect();

 

Output of the script is ( …. beginning deleted ….)

…

Composite : HelloKeyword [1.0]
– property name/value : productVersion / 12.1.3.0.0
———-
– property name/value : subVersionRevision / $Rev: 25 $
———-
– property name/value : subVersionURL / $URL: svn://192.168.178.50/LGO/sandbox/HelloKeywordApplication/HelloKeyword/SOA/composite.xml $
———-
– property name/value : compositeID / 38e4c940-31e8-46ca-90d7-1e56639f6880
———-

…

Step 4: Solve the limitations in Subversion keyword expansion

Note that the revision number that is displayed is the revision number of the composite.xml file. THIS IS NOT THE CHECKED OUT REVISION NUMBER, but it is THE REVISION NUMBER OF WHEN THE FILE COMPOSITE.XML WAS LAST CHANGED.

The two measures below, will make your composite really traceable:

1. Composites that are released will be first tagged in Subversion
2. A property ReleaseLabel will be added and release labels will only be used once

So, add a property like below in the composite.xml:

<property name=”ReleaseLabel” type=”xs:string” many=”false”>@ReleaseLabelNotSet@</property>

This property can then be set by the script that checks out a release from Subversion (e.g. by an ant search/replace…)

Note that this property is NOT a Subversion keyword, so giving this property a value is something that has to be explicitly done by the script that is used for building a release.

Additional benefit is that if the default value is set at @ReleaseLabelNotSet@ it will be clear when not-officially-released composites are deployed.

Querying of this property works with the same wlst script.

 

Note: the wlst script and properties have been tested with SOA Suite 11.1.1.6, 11.1.1.7 and 12.1.3.