+1 for RC2 focus.
On Mon, Sep 16, 2013 at 4:34 AM, Jérôme LELEU <[email protected]> wrote: > 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 -- 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
