Hi, Beyond the technical debatte on this, we should certainly think about releasing RC2 soon and avoiding to start new complex change.
Among our last 8 remaining tickets : https://issues.jasig.org/browse/CAS-1322?jql=project%20%3D%20CAS%20AND%20affectedVersion%20in%20(%224.0%22%2C%20%224.0%20RC1%22)%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened), I've commented some (and Misagh also) just to figure out what we need to do about them. To alleviate the burdeon of the release process, I'm willing to do the next RC2 (after addressing CAS-1322) as soon as all tickets will be in a clear status. Best regards, Jérôme 2013/9/14 Scott Battaglia <[email protected]> > 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" <[email protected]> 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" <[email protected]> >> *To: *[email protected] >> *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 <[email protected]>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 [email protected] as: >>> [email protected] >>> >>> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >>> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
