Thoughts on system properties for startup

[Cantor, Scott]

On 6/18/14, 12:31 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>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}.

My thought, which I think I expressed, was to assume idp.home is a path
(and yes, a system property), but create an alternate property to set that
would hijack the entire lookup process and point directly at
idp.properties via URL, and then one would define idp.home there as well.
Otherwise we can't allow for a classpath resource to load the properties.
In such a case, I doubt the paths to the Spring context files would be
parameterized anyway.

I think Brent had some other idea that might have been cleaner, but that
was all I had in mind.

>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.

Not surprising I guess.

>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.

I think you end up there if you set idp.home to a path, but can't prefix
the uses of idp.home with an extra slash. I'd rather avoid that by setting
the necessary properties in idp.properties that handle the cases that
aren't working. If we need idp.webflow.base=file:///${idp.home}/conf I'd
rather just do that.

I think adding normalization gets into situations where we try and use a
normalized property, find reasons that doesn't work, and then have to
define more of them for different buggy code. I'd rather just call them
what they are, new properties targeted at specific needs.

>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.

That shouldn't be necessary if DataSealer takes a Resource, I think it's a
consequence of not having the file-system-favoring app context as the root
web app context.

-- Scott