New pattern to toggle features in JSP

From: Thompson, Sonya (HAL)
Sent: Thursday, May 24, 2012 9:19 AM
To: Ruckman, Maurice (HAL); Fillman, Eric (HAL); Phatak, Sheetal (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: RE: New feature to toggle features in JSP

I've also created a FeatureToggleHelper.java with getFeatureToggle() and getFeatureToggleAsString() methods.
This helper knows where the featureToggles.xml file is located & appends the "toggles.{environment}." To the front of whatever key is passed in.
However, this will not be avail until I merge it into 12.23

From: Ruckman, Maurice (HAL)
Sent: Thursday, May 24, 2012 7:31 AM
To: Fillman, Eric (HAL); Thompson, Sonya (HAL); Phatak, Sheetal (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: RE: New feature to toggle features in JSP

To supplement this effort, here is an example of how to access our XML in the back-end Java code to drive logic:
Refer: hal-ejb/src/main/java/com/hal/sf/olci/page/AcceptPrintTermsPage.java

if ( StaticXmlDataList.getInstance().getStaticXmlFileMap().get(
"web.copy.olci.acceptTerms_logic.xml" ).get(
"page.EUTerms." + guestCountry ) != null )
{
setEuropeanUnion( true );
}
else
{
setEuropeanUnion( false );
}
From: Fillman, Eric (HAL)
Sent: Friday, May 18, 2012 4:09 PM
To: Thompson, Sonya (HAL); Phatak, Sheetal (HAL); Ruckman, Maurice (HAL); Klein, Brian (HAL); Bojja, Sridhar (HAL Contractor)
Cc: Augustine, Anila (HAL)
Subject: New feature to toggle features in JSP

Hi.

Sonya and I put together a little process that will allow you to control when a new feature or new code will be used.
It starts with a  file in Teamsite called featureToggles.xml, and it's in the web/copy/features directory.

Here's a very condensed sample of what the file looks like:

<toggles>

<!-- Use the following section to control how features will be enabled in the non-production environments -->

<nonProd>
<displayGroupExcursions><![CDATA[true]]></displayGroupExcursions>
</nonProd>

<!-- Use the following section to control how features will be enabled in the PRODUCTION environment -->

<prod>
<displayGroupExcursions><![CDATA[false]]></displayGroupExcursions>
</prod>

</toggles>

Essentially there are two sections - <nonProd> and <prod>.  <prod> would be used for production, <nonProd> will be used for everything else.  Within each you define an element and indicate whether that feature will be used/displayed/etc. within the JSP.  In the example above, <displayGroupExcursions> can be used to control the group excursion functionality.  It's currently set to true for nonProd so group excursion features will display there, but false for prod.

This way we can push code to dev, test, and prod, and have the features available in dev and test, but not prod.  Once the OK is given for prod, we just need to change the XML and push that through Teamsite.  If we need to shut a feature off for some reason in prod, we can do that too.

To use the featureToggles.xml, you just need to include a reference to it in the JSP like we do for all the static content XML files:

<s:set var="featureMap" value="#application.staticXmlDataList.staticXmlFileMap['web.copy.features.featureToggles.xml']"/>

Then in the JSP code, add an if statement to check the value of your feature name:

<s:if test="#featureMap['toggles.' + featureEnv + '.displayGroupExcursions'] == 'true'">
<!-- These are Group Excursions!-->
<s:if test="%{!getShxGroupTourBizList().isEmpty()}">

// Do something here

</s:if>
</s:if>

Notice the featureEnv variable in the highlighted line above.  We added a method to the BaseAction class called getFeatureEnv() that will return a string value of either nonProd or prod depending on the environment variable set in the System Properties.  If environment is prd, it returns prod, otherwise it returns nonProd.  As long as your JSP is called from an Action that extends BaseAction (which I think everything is the new flows do), your JSP should have access to featureEnv.

You should also be capable of accessing the XML file directly from an action if you want to control which methods are being called from a service or something, but we didn't get that far with it.

The code is in 12.21-RC, so it should go to prod next week.

Let me or Sonya know if you have any questions.

Thanks.

Eric

256 bit encryption for Safenet

-----Original Message-----
From: Guillaume Radde [mailto:guillaume.radde@redhat.com]
Sent: Tuesday, May 22, 2012 6:11 PM
To: Ruckman, Maurice (HAL)
Cc: Hoggard, Chad (HAL); Augustine, Anila (HAL); HAL DistList: IS UNIX
Subject: 256 bit encryption for Safenet

(Added missing link)

Below are the steps to enable 256 bits encryption. This would need to be done on all JBoss servers and developer-vms.

1) Don't listen to instruction from non-RedHat sources, they pretty much all make you break your RHEL java rpm install, which will cause problem during the next java update.

2) Download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" from [1]. Accept the license on the page and download jce_policy-6.zip.

3) Unzip the zip content into /opt. Your folder structure should look like this:

/opt/jce
/opt/jce/local_policy.jar
/opt/jce/US_export_policy.jar

3a) After you copy the files into /opt/jce you should change the ownership to root
chown -R root.root jce

4) Run the following command as root:
sudo su -
rm -f /usr/lib/jvm/jre-1.6.0-sun.x86_64/lib/security/{local,US_export}_policy.jar && update-alternatives --install /usr/lib/jvm/jre-1.6.0-sun.x86_64/lib/security/local_policy.jar jce_1.6.0_sun_local_policy.x86_64 /opt/jce/local_policy.jar 160200 --slave /usr/lib/jvm/jre-1.6.0-sun.x86_64/lib/security/US_export_policy.jar jce_1.6.0_sun_us_export_policy.x86_64 /opt/jce/US_export_policy.jar

5) Now update to the new links, choose option 2:

update-alternatives --config jce_1.6.0_sun_local_policy.x86_64

6) That's it :-)

[1] http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

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

Notes: You are updating the links with step #4.  For example, before changes:

[root@haldevjbs04 /opt/jce]$  ls -l /etc/alternatives | grep -i jce
lrwxrwxrwx 1 root root 71 Feb  1 12:41 jce_1.6.0_sun_local_policy.x86_64 -> /usr/lib/jvm-private/java-1.6.0-sun.x86_64/jce/vanilla/local_policy.jar
lrwxrwxrwx 1 root root 75 Feb  1 12:41 jce_1.6.0_sun_us_export_policy.x86_64 -> /usr/lib/jvm-private/java-1.6.0-sun.x86_64/jce/vanilla/US_export_policy.jar

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");