OK. In that case, the JSON storage is the easiest one as it just requires a file system...
Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-12-09 14:58 GMT+01:00 Dmitriy Kopylenko <dkopyle...@unicon.net>: > The goal is to provide the least intrusive durable storage option, to be > used in conjunction with web UI, so the svc definitions survive server > restarts. > > D. > > Sent from my iPhone > > On Dec 9, 2014, at 07:52, Jérôme LELEU <lel...@gmail.com> wrote: > > Hi, > > For modest CAS deployment, the list of services in the > deployerConfigContext.xml file is the easiest solution, isn't it? > > Best regards, > > Jérôme LELEU > Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org > > 2014-12-08 19:07 GMT+01:00 Misagh Moayyed <mmoay...@unicon.net>: > >> Sure. I am personally leaning more towards the JSON option because: >> >> >> >> - It can be viewed easily. >> >> - Changes can be done to the file system either directly, or via >> the management interface >> >> - It is also easily consumed by other 3rd party tools that wish >> to generate/lint the files >> >> - “Eat your own dog food” so to speak. >> >> >> >> *From:* Scott Battaglia [mailto:scott.battag...@gmail.com] >> *Sent:* Monday, December 8, 2014 10:54 AM >> *To:* cas-dev@lists.jasig.org >> *Subject:* Re: [cas-dev] Persistent service registry options as default >> >> >> >> I would recommend the one which has less manually configured external >> dependencies as we want to make getting that demo instance up as fast as >> possible. >> >> >> >> >> >> >> >> On Mon, Dec 8, 2014 at 12:29 PM, Misagh Moayyed <mmoay...@unicon.net> >> wrote: >> >> Team, >> >> It turns out that the ability for a CAS registry to persist changes >> between redeployments is a needed and pretty useful change for a relatively >> modest CAS deployment. I would like to propose that we swap out the default >> memory-based implementation with one that is able to carry changes across >> server restarts, so the behavior would become less confusing and more >> natural for new adopters who may not immediately realize the fact that >> changes may be lost. We have several options with JSON and embedded >> databases each with their own pros and cons. What makes the most sense? >> >> >> >> Misagh >> >> -- >> >> 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: lel...@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: > dkopyle...@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: lel...@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
