Thoughts on system properties for startup

Tom Zeller tzeller at dragonacea.biz
Wed Jun 18 00:31:44 EDT 2014


In my local workspace, I think I have idp.home where we want it.

The "file:" URL scheme will no longer be present in the Spring XML config files.

Although there are other options, I think idp.home needs to be an
absolute file system path system property. I have been thinking that
our Logback configuration should probably use "${idp.home}/logs" in
the FileAppenders, which pretty much rules out idp.home as a URL. I
was a little surprised, but in hindsight should not have been, that
app ctx initializers run after contextConfigLocation property
replacement. So, either idp.home is a system property, or we customize
the web app ctx, or we provide a default value, e.g.
${idp.home:/opt/shibboleth-idp}.

If idp.home is an absolute file system path, then I think we need to
provide a web app ctx subclass which prefers file system resources,
much like the app ctx Scott wrote which is used by SpringSupport. I
toyed with a PreferFilesystemResourceLoader, but overriding
getResourceByPath() seemed simpler.

I spent some time revisiting IDP-352, which boils down to working
around the string comparison that Web Flow uses to map XML flow
definitions on the file system to flow IDs. For Windows, I think one
function of the app ctx initializer will need to be the population of
an idp.home.normalized property which is idp.home with backslashes
replaced with forwardslashes. This normalized or c14n property will be
the base-path of the user flow registry, i.e. :

  <webflow:flow-registry id="userFlowRegistry"
base-path="${idp.home.normalized}/flows" >
     <webflow:flow-location-pattern value="/**/*-flow.xml" />
  </webflow:flow-registry>

Part of what took so long for me to get this figured out was spinning
up a Windows VM, for which VirtualBox and the Windows 2012 evaluation
VHD - and not ISO - seems the quickest. I was flipping back and forth
between Windows and OS X, and thought I had everything with idp.home
right, but then Windows was working and *nix wasn't. I was missing
something obvious but could not see it, so I broke down and added
logging to Spring's FlowDefinitionResourceFactory, which would be nice
if we could subclass but I think we cannot, and still did not see what
was wrong. I took a walk and then finally saw it. I was using
java-idp-integration-tests to test on Windows and *nix because it
packages Jetty and the IdP, so starting the IdP is done via the "java
-Didp.home=... -jar=...start.jar" command, and when I was adding
"-Didp.home=" to the command prompt I pressed tab for replacement -
which adds a "\" on the end of the directory I passed as the value of
idp.home. This meant that ${idp.home.normalized}/flows" effectively
became "${idp.home.normalized}//flows" which is a very different
string to the FlowDefinitionResourceFactory. I have a TODO to make
sure idp.home.normalized does not end with a slash. We probably should
submit some sort of bug report for the FlowDefinitionResourceFactory
to c14n file system paths once time is plentiful.

I needed to make some changes to the DataSealer for it to consume a
keystore Resource rather than a keystore file path, which was not a
big deal but it also involved a trivial
StringToJavaSupportResourceConverter.

The app ctx initializer I wrote so far is messy because I was not sure
what it was supposed to do exactly, so I need to clean it up as well
as some other components before I start making commits.


More information about the dev mailing list