Upgrading to a new version should not automatically warrant experiencing some pain. People upgrade because they expect some benefit to upgrading (or there's a critical bug fix they want, etc.), and are willing to accept some pain for a significant gain.
I don't believe making people re-configure an existing method that worked for them satisfies that criteria. You may not like JNDI, but its satisfying some people's needs at the moment. If you want to encourage people to upgrade to the latest version, removing their easiest migration path is not the way to do that. On Thu, Mar 14, 2013 at 9:49 AM, Misagh Moayyed <mmoay...@unicon.net> wrote: > One motivation is to push adopters of course to use the new methods of > course. Upgrading to the next major client version should warrant > experiencing some pain but I can’t imagine that would be any more painful > than the maintenance of JNDI configuration itself :) As far as I can tell, > JNDI only serves to provide external configurability and with other methods > in place, support for it should be deprecated IMHO. As for filter specific > configuration, other than ease of upgradability, do we have use cases that > would warrant config to be defined at the filter level as opposed to the > context? **** > > ** ** > > *-*Misagh* > > * > > ** ** > > *From:* Scott Battaglia [mailto:scott.battag...@gmail.com] > *Sent:* Wednesday, March 13, 2013 11:09 AM > > *To:* cas-dev@lists.jasig.org > *Subject:* Re: [cas-dev] Externalizing CASC's configuration**** > > ** ** > > There is no reason to drop existing methods of configuring the client. > I'm not quite sure what the motivation is to make it more difficult for > future clients to upgrade.**** > > ** ** > > Cheers,**** > > Scott**** > > ** ** > > ** ** > > On Wed, Mar 13, 2013 at 1:57 PM, Misagh Moayyed <mmoay...@unicon.net> > wrote:**** > > > Ideally the external configuration could be hooked in via a very thin > > abstraction layer, which still allows for implementation of different, > custom > > configuration sources.**** > > That's certainly the intention. If we can extract out the current > configuration options into various providers, then you'd certainly be able > to plug in your own "config provider" adapter. Before that, I'd like to > put together a basic design doc that outlines the approach and decisions > to be made and ask for feedback. I'll post back in a little bit with notes > and hopefully diagrams :) > > I am leaning more towards the following: > > - Drop support for JNDI > - Drop support for configuring settings at the filter level > - Switch the default provider to look at the servlet context > - Provide an extra provider that works off of a URI, which could be a > external properties file > - Reasonable level of abstraction, such that custom providers can be > plugged in with ease. > > -Misagh**** > > > > > > -----Original Message----- > > From: Koedderitzsch, Lars (L.) [mailto:lkoedderitz...@mazdaeur.com] > > Sent: Tuesday, March 12, 2013 4:32 AM > > To: cas-dev@lists.jasig.org > > Subject: AW: [cas-dev] Externalizing CASC's configuration > > > > 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: > > 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: > 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: > 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: > 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
