Config layout

[Marvin Addison]

On Fri, Nov 1, 2013 at 3:05 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> We discussed config file issues on the call today. I reviewed the testbed
> again and had forgotten that I had already started to do some of this
> separating of files, so here are some additional notes.
>
> I agree with Marvin that we need to keep imports down, and I don't think
> as a rule any of the files I had meant as editable do any importing of
> their own.
>
> My general intent was that flows/* would not be user-editable under
> ordinary circumstances. If a flow needs to change, I think it should be
> copied to a new flow, and I'd rather we have a separate location for that,
> maybe user-flows and we rename the other to system-flows.
>
> So all the bean files currently in flows/authn/ are of the internal
> variety.
>
> It's conf/ that's a mix of system and user files right now, with some of
> the low level beans there right now. Because of the webflow bug with using
> pattern-based repository lookup of flows in file:// locations, I expect
> webflow-config.xml will need to be editable to add custom flows for login
> methods or other customizing.

Indeed. I'm currently in the process of wiring up the CAS protocol
flows to test them in a running IdP testbed.

> A concrete suggestion:
>
> system-conf/
>         webflow independent Spring files meant to be left alone
> user-conf/
>         Spring and property files meant to be edited
>
> system-flows/
>         SWF definitions and beans for delivered flows
> user-flows/
>         SWF definitions and beans for user-created flows

That reads clearly to me.

> Along with views/, creds/ and /metadata/ of course.

One consideration here is whether views will be reachable inside JAR
packaging by the servlet request dispatcher. I had a use case for that
in the CAS protocol work and the packaging requirements are strict.
Views must be nested under /META-INF/resources, so if you want views
to be generally accessible you're looking at a path of
/META-INF/resources/views. And if you want views at the same depth as
other configuration, that would drag everything under
/META-INF/resources. I tend to like configuration under META-INF,
which is arguably a growing convention (JPA, CDI specs come to mind),
but I can admit it's just more path elements to traverse without much
value other than possibly convention.

M