I agree. Whatever we think is the best course of action is probably a 4.1 or later change. On Sep 16, 2013 4:34 AM, "Jérôme LELEU" <lel...@gmail.com> 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 <scott.battag...@gmail.com> > >> 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: 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: > 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
