I didn't mean just using it to create I'd generators. That doesn't add anything of value. The feature branch does a lot more to consolidate how services are created. On Sep 14, 2013 8:11 AM, "Misagh Moayyed" <mmoay...@unicon.net> wrote:
> The change I have in mind, mostly arose out of me attempting to write a > Service extension. Agreed that things are pretty comfortable as they are, > [and really, how often do you get to come up with a new Service type?!] but > it potentially could be improved to reduce work. In my case, I had to write > an argument extractor to create a new special service (MfaEnabledService, > etc). Given that services are looked up by class name to locate their id > generator, I also had to create one of those for my service type, even > though it was really no different than the default provided for a given CAS > service. This, I have in mind, can be refactored to make writing such > extensions easier. > > I looked at the 4.0 feature branch and do see the factory instances. > Drawing on the same idea, one possible approach would be to come up with > factory instances for protocols, (CAS, OpenId, GoogleApps, Saml, etc) where > each derived factory would then be able to create the proper instance of > the id generator...and we can provide sensible defaults for those that are > missing or are yet to come as extensions. > > ------------------------------ > *From: *"Scott Battaglia" <scott.battag...@gmail.com> > *To: *cas-dev@lists.jasig.org > *Sent: *Friday, September 13, 2013 9:10:21 AM > *Subject: *Re: [cas-dev] Thoughts on CAS-1312 > > I'm all for consolidating/better association though I don't like it being > attached to the service. We did some work in the feature branch for 4.0 > though brought in factories and such that managed this. Not sure if we can > pull any of that over. > > > On Thu, Sep 12, 2013 at 12:40 PM, Misagh Moayyed <mmoay...@unicon.net>wrote: > >> Team, >> Started to evaluate the feasibility of implementing CAS-1312: >> https://issues.jasig.org/browse/CAS-1312 >> >> Currently, ticket id generators [for services] are looked up by name from >> a map, particularly by class name. This implies of course that as service >> extensions are developed, corresponding generators need to be added to this >> map. I was thinking to remove this dependency, by allowing each service >> type [CAS, Saml, etc] to define its own ticket id generator based on the >> current configuration, so that we might be able to define something like: >> service.getTicketIdGenerator(), and remove the need for the lookup. >> >> The caveat is that, in order to inject settings into ticket id generators >> some refactoring needs to be done so that settings such as maxLength and >> suffix are passed along to the right argument extractor, that is >> responsible for creating the service instance...or perhaps instead of >> injecting settings, we'll "set" the id generator instance as a whole for >> the service by passing it to the argument extractor directly. This latter >> approach is cleaner IMO, and allows also for defining alternative >> implementations of the id generator to be set on the service. Plus, better >> to pass the entire object as a whole, rather than individual pieces that >> construct it. >> >> What are your thoughts on this JIRA and options above? >> >> 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: > 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
