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. ----- Original Message ----- 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
