Hi, As maintainer/customizer of our company's CAS installation and long time mailing list lurker, please allow my 2 cents on this:
When refactoring the CAS client config please foresee not to tie directly to a specific implementation (e.g. properties files) to provide the external configuration. Ideally the external configuration could be hooked in via a very thin abstraction layer, which still allows for implementation of different, custom configuration sources. For instance for our internal systems we have a "configuration database" of sorts, which centralizes such external configuration options, in order to mitigate a mess of different configuration files lying around at various places for our in-house applications. In this case I'd write and hook a custom adapter which uses this internal "configuration database" to provide the settings to the CAS client. Thanks for considering this and keep up the good work! :-) Best regards, Lars Ködderitzsch Mazda Motor Europe GmbH, Hitdorfer Straße 73, D-51371 Leverkusen Geschäftsführer: Jeffrey H. Guyton, Matthew Tomilo, Philip J. Waring, Amtsgericht Köln HRB Nr. 49390, USt-Id. Nr.: DE812430583 -----Ursprüngliche Nachricht----- Von: Misagh Moayyed [mailto:mmoay...@unicon.net] Gesendet: Montag, 11. März 2013 21:45 An: cas-dev@lists.jasig.org Betreff: RE: [cas-dev] Externalizing CASC's configuration Team, I have just merged the final leg of the pending pull on CASC-180 [1]. With that in place, I can go ahead and start working on externalizing CASC's config. I just wanted to revisit the topic and this thread once more to inquire if there is any other feedback or suggestions that should be taken into account. Generally, the following points that Scott had summarized are sought after: 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. Please share if you have any reservations about this proposal. Just to recap, this is just going to allow CASC settings to be pulled from an external resource in addition to what's already in place. P.S: Personally, I think this should just be a single way of configuring settings, and this potentially is the low hanging fruit with the less configuration headache, but I don't know/think we have reached consensus on allowing the external resource to be the only option. -Misagh [1] https://issues.jasig.org/browse/CASC-180 > -----Original Message----- > From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] > Sent: Monday, February 04, 2013 12:20 PM > To: cas-dev@lists.jasig.org > Subject: Re: [cas-dev] Externalizing CASC's configuration > > +1 > > On Mon, Feb 4, 2013 at 1:23 PM, Andrew Petro <ape...@unicon.net> wrote: > > cas.properties, externalized from the .war, has been a successful > > pattern in CAS server. I look forward to similar advantages in > > externalized properties-file based CAS client configuration. At the > > least, this helps adding the CAS client to applications to not make > > the applications worse as regards war-embedded environment-specific > configuration. > > > > Misagh, you have a fine idea here for improvement to the Java CAS client. > > > > > > On Sat, Feb 2, 2013 at 5:16 AM, Marvin Addison > > <marvin.addi...@gmail.com> > > wrote: > >> > >> > 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]. > >> > >> Strong +1 from me. I anticipate this will simplify configuration, > >> with consequent reduction in support traffic for the Java CAS Client. > >> > >> M > >> > >> -- > >> You are currently subscribed to cas-dev@lists.jasig.org as: > >> ape...@unicon.net > >> > >> 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: > > wgt...@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: > mmoay...@unicon.net 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: lkoedderitz...@mazdaeur.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
