I'm not against adding another method to configure the clients, but I want to make sure we're (a) doing it for the right reason and (b) actually correcting known difficulties.
1. working with key/value pairs is a lot simpler compared to xml - as someone who writes a configuration file, while XML might be more verbose, I don't know if its exceptionally harder. 2. intricacies of JNDI, context, and filter parameters - these are all standard servlet spec/container items that are relatively straightforward. 3. Configuration can be externalized, removing the need for redeployments and container restarts (Similar to the cas.properties file of the CAS server) - I would assert this is starting to look like a valid reason to add to the existing configuration (though JNDI does satisfy the re-deployment issue). >From what I can see we want the following: 1. utilize a known method of configuration, such that deployers don't need to learn new concepts 2. separate configuration from the WAR such that a WAR does not need to be generated *per* environment. What else? I know there is more we want to solve because technically JNDI solves those but I'm not about to recommend JNDI to everyone :-) So +1 to an improved/easier form of configuration. I'd like to see what else we can come up with before endorsing this method. On Tue, Jan 29, 2013 at 2:10 AM, Misagh Moayyed <mmoay...@unicon.net> wrote: > Team, **** > > In the context of the Java CAS client, parameters can be specified in a > variety ways. I’d like to propose the idea of extracting the client > configuration out of the web.xml file and into a single external property > file resource. Some of that work is already made available via [1]. > Centralizing the config would not only make the process more consistent but > there are also other advantages that I can see:**** > > ** ** > > **- **Working with key/value pairs is a lot simpler compared to xml**** > > **- **No “need” to understand the intricacies of JNDI, context and > filter parameters**** > > **- **Configuration can be externalized, removing the need for > redeployments and container restarts (Similar to the cas.properties file of > the CAS server)**** > > ** ** > > This is not to suggest that the current mechanisms be removed. Specifying > the property file location would be another method of indicating where the > settings live. While filters and mappings are still in the web descriptor > file, I imagine this would in its simplest form boil down to a context > parameter that specifies where the resource exists. **** > > ** ** > > Thoughts and suggestions are most welcomed. **** > > ** ** > > *-*Misagh**** > > ** ** > > [1] https://github.com/Jasig/java-cas-client/pull/36 * > > ***** > > ** ** > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
