Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] RE: productionizing grouper

Subject: Grouper Developers Forum

List archive

[grouper-dev] RE: productionizing grouper


Chronological Thread 
  • From: Nathan Kopp <>
  • To: Grouper Dev <>
  • Subject: [grouper-dev] RE: productionizing grouper
  • Date: Wed, 28 Mar 2012 13:00:23 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

We recently went live with our identity management system based on Grouper 1.6.3, and we made some modification to handle deploying Grouper to multiple environments.

 

Our goal was to allow the exact same Grouper JAR and WAR files to be deployed to any environment.  We would then add environment-specific configuration files to a consistent location on each server, separated from the Grouper deployment location, so that fresh deployments would not overwrite these files.  Any settings found in the environment-specific configuration files will override settings found in the default configuration files.  This is similar in concept to how morphstring allows passwords to be externalized.

 

We identified six locations that needed to handle these externalized settings:

1) grouper.properties

2) grouper-loader.properties

3) grouper.hibernate.properties

4) sources.xml

5) log4j.properties

6) web.xml for the CAS contrib plugin for Grouper UI

 

The first 3 are handled by GrouperUtil.java.

The fourth is handled by SoruceManager.java (part of subject.jar).

Log4J was straight-forward using JVM options.

The UI’s web.xml was a little trickier.

 

To achieve our goal, we made the following modifications to Grouper:

 

1) Create a custom sub-class of java.util.Properties which can load multiple properties files.  One file contains default settings, and the other contains environment-specific “override” settings.  Our custom properties file also has the ability to internally (and invisibly) handle encrypted property values using Jasypt (to achieve a similar goal as morphstring).

2) Modify GrouperUtil.java to use our custom Properties class instead of the default.

3) Modify SourceManager.java (part of subject.jar) to also load an overlay file, and changed the XML parsing slightly so that it properly merges the overlay settings before initializing sources.

4) We used the “-D” option on the JVM command line to pass environment-specific variables for use in log4j.properties.

5) Since we use CAS for authentication, we wrapped the CAS filter in a delegating filter.* The delegating filter creates a proxy of the filter init-params, allowing variable values to be pulled from external sources using the standard ${} syntax.

 

*Basic code for creating a delegating filter that allows externalizing of init-params can be found here: http://www.coderanch.com/t/79094/Websphere/environment-variable-referance-Web-xml

 

-Nathan

 

From: [mailto:] On Behalf Of Chris Hyzer
Sent: Wednesday, March 28, 2012 12:18 PM
To: Grouper Dev
Subject: [grouper-dev] productionizing grouper

 

Here is what we do at penn to manage grouper in different environments.

 

https://spaces.internet2.edu/display/Grouper/Managing+Grouper+in+several+environments

 

Note, the long term direction is probably maven, and this is done in ant.

 

Thanks,

Chris




Archive powered by MHonArc 2.6.16.

Top of Page