Home

ToDo

• Need some additional basic validators.
• Need some additional basic ConfigPointTypes.
• Validators should describe their criteria so it can be included in sample files.
• WOULD LIKE TO HAVE A REQUIRE-ONE TYPE ConfigGroup
• As a convience, CP.getValue() should accept a default value.
• Aliases should throw an error if they contain commas
• Aliases should show a warning if they contain dots. This could be used to match legacy names, so no warning if contained in a fixed name Group.
• All ConfigPoints needs direct testing. Not sure the best way to directly test.
• Are there AppConfig tests that blowup due to unconvertable values (can't turn it to an int)?
• Need to add blocking on getting App instances that are not ready.
• LoaderErrors need to be handled in the same way as the other errors in AppConfig.
• There needs to be a way to use AH for ServletConfig in an isolated scope. These will need to be initiated out of sequence from the main AppConfig. They may have no relation to the AppConfig. Perhaps a separate instance- based AppConfig (one that you create and hold a reference too, instead of a static single instance one).
• Direct ConfigPointGroups to be written to SytemProps (or other). This would expose writable system properties to the system. For instance, if there is a system level connection timeout that reads a system property to find a default value, creating a ConfigPoint and marking is as 'write to sys props' with a specific name would provide a way to config that thru AH. The need for this is known at the group level, so perhaps groups would extend interfaces that include a static method that handles the disposition?
• Create a JNDI loader. This will expose some issues w/ dealing w/ configed values that are non-string. For instance, a JNDI param may already be an Integer, instead of needing to be converted from a string.
• All loaders should complain bitterly if there is an unmatched value. Since some apps must deal w/ legacy params, there should be a ConfigPointGroup subclass FixedNameConfigPointGroup that uses only the default name or explicit name w/o any package prefix.
• Explicitly handle the case of ConfigPointGroups extending other ConfigPointGroups. This might be allows to build up and easily register nested groups of params, but if two Groups extend the same base group, the 2nd child will bomb during registration b/c the super points would attempt to register twice under different names. Super group w/ multiple child groups == bad / not allowed. One place that might aggregate (many super groups into a single subclass Group) would be a module that has several logical groups. When exposing those groups to a larger app, it would be nice to roll those all into a single Uber-Group so the parent app only has one group to register for that module. In that case, the registration should register names based on the most super-classy Group.
• Redirect AppConfig errors during tests to some place other than out.
• Add Password string that doesn't spew its values to the log.
• Need to define how multiple entries for the same point are handled, even from the same loader (ie two entries in a prop file). Right now I think the first would win, but maybe that should just throw an error? What about multi- entries on the cmd-line?
• Separate from forcedValues, the AppConfig should accept default values for cases where the app wants to create defaults if nothing is spec'ed. This would be implemented by adding a FixedValueLoader at the end of the chain.
• AppConfigDefinition might be better named AppConfigRuntimeDefinition, b/c it is not a full definition - only the needed def for runtime (ie. no Loader info).
• .builder() should be a static method on ConfigPoint classes.
• The SecurityProblem ConstructionProblem is untested, however, this may not be needed if the logic for finding child points is moved to a static method of ConfigPointGroup.

Error / Problem Handling

These are the different major types of problems w/ subtypes:

• ConstructionProblem (App level construction issue)
  • NonUniqueNames exception (non-unique names)
  • Duplicate point addition
  • Duplicate Loader
  • Security exception - unable to read fields in ConfigGroups
  • Default value is invalid
  • Validation configuration is invalid
• LoaderProblem (Loader only context)
  • read IO error
  • Parse error where the point is unknown
  • Unfound file (but is indicated to be required)
  • Unrecognized point name
• PointValueProblem (Point and Loader context)
  • Not valid
  • String conversion error
  • Coersion error (from jndi objects)
• RequirementsProblem (App level configuration issue)
  • Required Point exception
  • Req group

Design Choices

• Use statics over Enums. Enums are a natural fit for groups of static final constants, however, Enums do not allow generic types at the individual level. That is, all enums of an Enum type have the same class signature, and thus, cannot be made to return different types from their getValue() method.