Keeping a Reintegrated Branch Alive

There is an alternative to destroying and re-creating a branch after reintegration. To understand why it works you need to understand why the branch is initially unfit for further use after it has been reintegrated.

Let's assume you created your branch in revision A. While working on your branch, you created one or more revisions which made changes to the branch. Before reintegrating your branch into trunk, you made a final merge from trunk to your branch, and committed the result of this merge as revision B.

When reintegrating your branch into the trunk, you create a new revision X which changes the trunk. The changes made to trunk in this revision X are semantically equivalent to the changes you made to your branch between revisions A and B.

If you now try to merge outstanding changes from trunk to your branch, Subversion will consider changes made in revision X as eligible for being merged into the branch. However, since your branch already contains all the changes made in revision X, merging these changes can result in spurious conflicts! These conflicts are often tree conflicts, especially if renames were made on the branch or the trunk while the branch was in development.

So what can be done about this? We need to make sure that Subversion does not try to merge revision X into the branch. This can be done using the --record-only merge option, which was introduced in the section called "Blocking Changes".

To carry out the record-only merge, get a working copy of the branch which was just reintegrated in revision X, and merge just revision X from trunk into your branch, making sure to use the --record-only option.

This merge uses the cherry-picking merge syntax, which was introduced in the section called "Cherrypicking". Continuing with the running example from the section called "Reintegrating a Branch", where revision X was revision 391:

$ cd my-calc-branch
$ svn update
$ svn merge --record-only -c 391 ^/calc/trunk
$ svn commit -m "Block revision 391 from being merged into my-calc-branch."

Now your branch is ready to soak up changes from the trunk again. After another sync of your branch to the trunk, you can even reintegrate the branch a second time. If necessary, you can do another record-only merge to keep the branch alive. Rinse and repeat. It should now also be apparent why deleting the branch and re-creating it has the same effect as doing the above record-only  merge. Because revision X is part of the natural history of the newly created branch, Subversion will never attempt to merge revision X into the branch, avoiding spurious conflicts.

Testing Sabre Connectivity

From: tkonar@princesscruises.com
Sent: Friday, February 10, 2012 3:10 PM
To: Ruckman, Maurice (HAL)
Cc: Augustine, Anila (HAL); Fernan, Diana (HAL Contractor); Tonks, Kristen (HAL); Harrington,
Scott (HAL Contractor)
Subject: RE: Please bounce WAS for ezAir on WebTst
Attachments: Rundemo.zip

Maurice,
You can try running SABRE rundemo tool (details provided below) from your PC. If it works then you will have to run
same command from that unix server where eZair is running. If you also get timeout error, then you will have to contact
your network group to check if there is any block in the HAL firewall. Let me know how these tests goes so that can
decide where to go from there.
From Command prompt run these commands to test web service:
- Unzip the file in a folder. I unzipped in "C:DownloadsSABRE Rundemo" location.
- Then run these commands. Make sure you set JDK in your path. My JDK bin location was "C:j2sdk1.5_01jdkbin".

- Rundemo 1 will execute create session service.
cd C:DownloadsSABRE RundemoRundemobin
path=C:j2sdk1.5_01jdkbin
rundemo 1

From: tkonar@princesscruises.com
Sent: Friday, February 10, 2012 3:10 PM
To: Ruckman, Maurice (HAL)
Cc: Augustine, Anila (HAL); Fernan, Diana (HAL Contractor); Tonks, Kristen (HAL); Harrington,
Scott (HAL Contractor)
Subject: RE: Please bounce WAS for ezAir on WebTst
Attachments: Rundemo.zip
Follow Up Flag: FollowUp
Flag Status: Flagged
Maurice,
You can try running SABRE rundemo tool (details provided below) from your PC. If it works then you will have to run
same command from that unix server where eZair is running. If you also get timeout error, then you will have to contact
your network group to check if there is any block in the HAL firewall. Let me know how these tests goes so that can
decide where to go from there.
From Command prompt run these commands to test web service:
- Unzip the file in a folder. I unzipped in "C:DownloadsSABRE Rundemo" location.
- Then run these commands. Make sure you set JDK in your path. My JDK bin location was "C:j2sdk1.5_01jdkbin".
- Rundemo 1 will execute create session service.
cd C:DownloadsSABRE RundemoRundemobin
path=C:j2sdk1.5_From: tkonar@princesscruises.com
Sent: Friday, February 10, 2012 3:10 PM
To: Ruckman, Maurice (HAL)
Cc: Augustine, Anila (HAL); Fernan, Diana (HAL Contractor); Tonks, Kristen (HAL); Harrington,
Scott (HAL Contractor)
Subject: RE: Please bounce WAS for ezAir on WebTst
Attachments: Rundemo.zip
Follow Up Flag: FollowUp
Flag Status: Flagged
Maurice,
You can try running SABRE rundemo tool (details provided below) from your PC. If it works then you will have to run
same command from that unix server where eZair is running. If you also get timeout error, then you will have to contact
your network group to check if there is any block in the HAL firewall. Let me know how these tests goes so that can
decide where to go from there.
From Command prompt run these commands to test web service:
- Unzip the file in a folder. I unzipped in "C:DownloadsSABRE Rundemo" location.
- Then run these commands. Make sure you set JDK in your path. My JDK bin location was "C:j2sdk1.5_01jdkbin".
- Rundemo 1 will execute create session service.
cd C:DownloadsSABRE RundemoRundemobin
path=C:j2sdk1.5_

JCE cannot authenticate the provider IngrianProvider

Could not get Safenet working and kept getting the following error, one solution found was to explode the EAR file.

JCE cannot authenticate the provider IngrianProvider

Caused by: java.util.jar.JarException:
Cannot parse jar:file:/home/jboss1/programs/jboss-eap-5.1/jboss-as/server/haldev-vm-template-safenet/deploy/hal-ear-1.0-SNAPSHOT.ear!/hal-web-1.0-SNAPSHOT.war

Refer: https://access.redhat.com/knowledge/solutions/34813

Java security file location in JBoss

Did not need to implement this solution but this is where the changes would go:

/usr/lib/jvm/java-1.6.0/jre/lib/security/java.security
security.provider.10=com.ingrian.security.nae.IngrianProvider

Set location of SafeNet properties file

Where you specify the properties file in JBoss:
/home/jboss1/programs/jboss-eap-5.1/jboss-as/server/haldev-vm-template/deploy/properties-service.xml

In the template you need to also have the properties file itself:
./conf/props/IngrianNAE.properties

Set the system property in the application:

System.setProperty(
"com.ingrian.security.nae.IngrianNAE_Properties_Conf_Filename",
"home/java/IngrianNAE.properties");

Safenet Code Sample

The following code stub can be used to encrypt/decrypt with the Safenet appliance.  Refer: CryptoTool.java

private static String doEncrypt( final String plainText ) throws Exception
{
NAESession naesession = NAESession.getSession( "mlrtest", "asdf1234" );
SecretKey secretkey = NAEKey.getSecretKey( "test128", naesession );

Cipher cipher =
Cipher.getInstance( "AES/CBC/PKCS5Padding", "IngrianProvider" );
byte [] iv = new byte [16];
String ivString = "1234567890123456";
iv = ivString.getBytes();
cipher.init( Cipher.ENCRYPT_MODE, secretkey, new IvParameterSpec( iv ) );

byte [] outputByteArray = cipher.doFinal( plainText.getBytes() );

return IngrianProvider.byteArray2Hex( outputByteArray );
}

private static String doDecrypt( final String encryptedText )
throws Exception
{
NAESession naesession = NAESession.getSession( "mlrtest", "asdf1234" );
SecretKey secretkey = NAEKey.getSecretKey( "test128", naesession );

Cipher cipher =
Cipher.getInstance( "AES/CBC/PKCS5Padding", "IngrianProvider" );
byte [] iv = new byte [16];
String ivString = "1234567890123456";
iv = ivString.getBytes();
cipher.init( Cipher.DECRYPT_MODE, secretkey, new IvParameterSpec( iv ) );

byte [] decryptedByte =
cipher.doFinal( IngrianProvider.hex2ByteArray( encryptedText ) );
String decrypted = new String( decryptedByte );

return decrypted;
}

Using Third-party jars with Maven

Refer: 20120512 Using Third-party jars with Maven

To use third party jars in a maven project, the steps are as follows:

1) Upload the jar into a repository (either your local repository if it's just for you, or into the shared Nexus repository if you want other people to access the jar as well)
2) Add a section in your pom.xml to tell maven that your application depends on this jar.

Here are the commands to implement those steps:

To upload a jar in your local repository (your local repository is on your vm in ~/.m2/repository):

mvn install:install-file
-Dfile= -DgroupId=com.hal.thirdparty
-DartifactId=
-Dversion=
-Dpackaging= -DgeneratePom=true

Where: the path to the file to load
the group that the file should be registered under
the artifact name for the file
the version of the file
the packaging of the file e.g. jar

To upload a jar into the shared Nexus Repository:

Option A: Command line

mvn deploy:deploy-file -Durl=file://C:m2-repo
-DrepositoryId=some.id
-Dfile=your-artifact-1.0.jar
[-DpomFile=your-pom.xml]
[-DgroupId=org.some.group]
[-DartifactId=your-artifact]
[-Dversion=1.0]
[-Dpackaging=jar]
[-Dclassifier=test]
[-DgeneratePom=true]
[-DgeneratePom.description="My Project Description"]
[-DrepositoryLayout=legacy]
[-DuniqueVersion=false]

See here for the detail of the options: http://maven.apache.org/plugins/maven-deploy-plugin/usage.html

Option B: Using the web interface from Nexus at http://halsvn01:8081/nexus/index.html#view-repositories;thirdparty~uploadPanel

See the attached screenshot.

In both options, you will need Nexus admin credentials to upload artifacts (jars in maven terms) into the shared repository.

2) In your pom.xml, inside the section, add:
com.hal.thirdparty
your-artifact
your-artifact-version

-------------------------------------
Guillaume Radde
Senior Consultant, Red Hat Consulting
guillaume.radde@redhat.com
http://www.redhat.com
-------------------------------------