Skip to end of metadata
Go to start of metadata

Some Grouper properties files can have overlays so that only the changes from the defaults of the config files need to be tracked in the institution specific config file.  Also, configs can be centrally stored on a server across multiple webapps or standalone Grouper applications.    There can be a default configuration file, and an override file so that only the changes from the default can be tracked in the overlay.

Using this approach to configuration files can make Grouper more easily deployable across environments, and more easily upgradable.

This is available in Grouper v2.2+ for the following config files:

  • grouper.properties
  • grouper.hibernate.properties
  • grouper-loader.properties
  • grouper-ui.properties
  • grouper-ws.properties
  • grouper.client.properties
  • subject.properties
  • grouper.cache.properties (2.3.0.patch+)

In the future we can add this feature to other config files as well.

How it works

Each of the properties files has a base file, and a config file.  For example, there is a grouper.base.properties, and a grouper.properties.  Both of these are located on the classpath in the default package.  e.g. WEB-INF/classes/grouper.base.properties and WEB-INF/classes/grouper.properties.  Generally all the default settings will be located in the base file, and only the things that are overridden are in the grouper.properties.  This is a change in Grouper  v2.2+ since before that all properties are in the grouper.properties file, and the example file was used just to show what configs are possible.

config overlay high level

Specify the hierarchy

If you do not want to use the base and the overlay in the classpath, you can specify which files are used for the properties.  This must be specified in the base or config file.  Each config file has its own key for this hierarchy, but it is listed in the base config file.  Here is an example for the grouper.properties.  Note, it is recommended to include the classpath base properties, though it is up to you.  You can specify config files by classpath or file location.

grouper config overlay specify hierarchy

Edge cases

If you override a key with an empty value, that will blank out that config value

config overlay edge case 1

Config file reloading

You can specify the number of seconds that the config file will be checked to see if there are differences.  This is not a trivial check, so it is recommended not to be more often than every 60 seconds.  If -1 is specified, then it will never be checked.  If it is 0 then it will be checked each time a config param is referenced.  Note, this is another properties that must be specified in the base or config file, it cannot be put in other places specified in the hierarchy.  Here is an example for grouper.properties:

grouper.config.secondsBetweenUpdateChecks = 60

Expression language in property values

You can specify the property key in such a way that you can have value include expression language scriplets.  The class edu.internet2.middleware.grouperClient.util.GcElUtilsSafe can be referenced as "elUtils".  To specify a key as EL, append this suffix to the config key: .elConfig

config overlay el

To use a custom class in the EL, Write a class with a static method, compile, put in a jar on the classpath.  There should be a default constructor in the class.  Refer to the fully qualified class in EL:

package edu.internet2.middleware.grouperClient.config;

/**
 * some test class for EL
 * @author mchyzer
 *
 */
public class SomeTestElClass {

  /**
   * some method for EL
   * @param a
   * @param b
   * @return the result
   */
  public static String someMethod(String a, String b) {
    return a + b + " something else";
  }
  
}

EL in a properties file:

some.config.2.elConfig = ${edu.internet2.middleware.grouperClient.config.SomeTestElClass.someMethod('start', ' middle')}

This will result in the value (for key: some.config.2): start middle something else

Environment variables

If you want a config to be pulled from an environment variable, do this:

somethingWhatever.elConfig = ${java.lang.System.getenv().get('JAVA_HOME')}

That will cause the property "somethingWhatever" to have the value "c:\dev_inst\java" or whatever it is set to.  Do the following two things:

  1. append   .elConfig     to the propertyName
  2. this is the value: ${java.lang.System.getenv().get('JAVA_HOME')}

Example:

When I have this in grouper.properties:

# in cases where grouper is logging or emailing, it will use this to differentiate test vs dev vs prod
grouper.env.name = GROUPERDEMO_2_2_2

I can print it out in gsh:

gsh 1% edu.internet2.middleware.grouper.cfg.GrouperConfig.retrieveConfig().propertyValueString("grouper.env.name")
GROUPERDEMO_2_2_2

Add an env variable:

[appadmin@i2midev1 bin]$ export GROUPER_ENV=GROUPER_2_2_2_fromEnv
[appadmin@i2midev1 bin]$ echo $GROUPER_ENV
GROUPER_2_2_2_fromEnv

Change grouper.properties

# grouper.env.name = GROUPERDEMO_2_2_2
grouper.env.name.elConfig = ${java.lang.System.getenv().get('GROUPER_ENV')}

Restart GSH, try again

gsh 0% edu.internet2.middleware.grouper.cfg.GrouperConfig.retrieveConfig().propertyValueString("grouper.env.name") GROUPER_2_2_2_fromEnv

Misc

You can use these special vars: $space$ and $newline$ to represent a space or newline.

Refer to other properties in that config file

In both of these cases the value for the property "somethingWhatever1" is: prefix something to be reused suffix 

Pre 2.3.0 patched, you can do this:

somethingWhatever = something to be reused
somethingWhatever1.elConfig = prefix ${edu.internet2.middleware.grouperClient.util.GrouperClientConfig.retrieveConfig().propertyValueString("somethingWhatever")} suffix

Post 2.3.0 you can do this:

somethingWhatever = something to be reused
somethingWhatever1 = prefix $$somethingWhatever$$ suffix

New Configuration File: subject.properties

Note: subject.properties is a new config file in Grouper 2.2 that specifies the location of the sources.xml file.

Use Case

Some sites may choose to have two levels of overlay files above the base file, as follows:

  • grouper.base.properties (unmodified built in properties)
  • grouper.properties (institution-wide)
  • grouper.local.properties (specific to institution and environment, e.g. the “test” env overlays)

See Also

For details on migrating to using the Configuration Overlay files, see Upgrade Instructions to Grouper 2.2 from Grouper 2.1

API Building and Configuration

When I have this in grouper.properties:

 

# in cases where grouper is logging or emailing, it will use this to differentiate test vs dev vs prod

grouper.env.name = GROUPERDEMO_2_2_2

 

I can print it out in gsh:

 

gsh 1% edu.internet2.middleware.grouper.cfg.GrouperConfig.retrieveConfig().propertyValueString("grouper.env.name")

GROUPERDEMO_2_2_2

 

Add an env variable:

 

[appadmin@i2midev1 bin]$ export GROUPER_ENV=GROUPER_2_2_2_fromEnv

[appadmin@i2midev1 bin]$ echo $GROUPER_ENV

GROUPER_2_2_2_fromEnv

 

Change grouper.properties

 

# grouper.env.name = GROUPERDEMO_2_2_2

grouper.env.name.elConfig = ${java.lang.System.getenv().get('GROUPER_ENV')}

 

Restart GSH, try again

 

gsh 0% edu.internet2.middleware.grouper.cfg.GrouperConfig.retrieveConfig().propertyValueString("grouper.env.name")

GROUPER_2_2_2_fromEnv

  • No labels