+1 (and no defaults only if we provide optional extension points) regards, gerhard
2012/1/31 Mark Struberg <[email protected]> > > I'm at +1 for not having any default in DeltaSpike. > > That was not exactly what I'm saying ;) > > I'm for having a default in _any_ case, but it should be the one which is > mostly basic and requires no additional dependencies. > DeltaSpike should be usable out of the box, even if it's only a hand > crafted minimal implementation. > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Jason Porter <[email protected]> > > To: [email protected]; Mark Struberg < > [email protected]> > > Cc: > > Sent: Monday, January 30, 2012 11:21 PM > > Subject: Re: AW: supporting different approaches,... > > > >T hanks for getting us back on track Mark, I noticed that as I was reading > > the thread :) > > > > I'm at +1 for not having any default in DeltaSpike. I think it makes it > > easier for the users to consume, this also takes some tasks off our plate > > for maintaining any default implementation, which could become a lot of > > work depending on what we're talking about (persistence and security come > > to mind easily). This also alleviates any issues we have with > @Alternative > > or @Default and BDA (for CDI 1.0 containers, which will be mainstream for > > at least another two years). One other point is we really leave it up to > > the users to make the choice instead of forcing something (our default) > > upon them. > > > > +1 for an API/SPI in DeltaSpike to compile against. > > > > On Mon, Jan 30, 2012 at 06:43, Mark Struberg <[email protected]> wrote: > > > >> Btw, Gerhard on IRC made me aware that the whole security discussion is > >> already heavily Off Topic ^^ > >> > >> It is an important discussion but the current context is: > >> > >> "How to make different impls for various situations possible in > >> DeltaSpike?" > >> > >> > >> So, back to the original topic. > >> > >> there are 2 ways > >> > >> a.) use CDI mechanisms as Gerhard already pointed out. This works in > 95% > >> of the cases and is only limited if we already need to know some > >> 'alternatives' while booting the container. In this case we cannot > > fetch a > >> @Dependent alternative because it just is not available yet > >> > >> b.) some kind of SPI which we implement via a 'ordinal' based > >> configuration approach (for cases where a.) doesn't work out). > >> > >> > >> LieGrue, > >> strub > >> > >> > >> ----- Original Message ----- > >> > From: Mark Struberg <[email protected]> > >> > To: "[email protected]" < > >> [email protected]> > >> > Cc: > >> > Sent: Monday, January 30, 2012 2:31 PM > >> > Subject: Re: AW: supporting different approaches,... > >> > > >> > Oki all good points... > >> > > >> > And all valid points... > >> > > >> > And all pretty heavy points... > >> > > >> > > >> > > >> > Means to ME that we should take a step back and think _really_ _hard_ > >> before > >> > going onti implementing something ;) > >> > > >> > Serious, this is indeed a very complex but also very often needed > >> functionality. > >> > Not sure if we can do all this in 4 weeks (my _personal_ idea for a > > 0.2 > >> > timeline) but rather for 0.3 or so. > >> > > >> > Could you please start setting up a wiki page collecting all the > ideas > >> please? > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > ----- Original Message ----- > >> >> From: Arne Limburg <[email protected]> > >> >> To: "[email protected]" > >> > <[email protected]> > >> >> Cc: > >> >> Sent: Monday, January 30, 2012 2:01 PM > >> >> Subject: AW: supporting different approaches,... > >> >> > >> >> Hi Pete, > >> >> > >> >> At least that sounds like that what I am thinking of ;-) > >> >> > >> >> -----Ursprüngliche Nachricht----- > >> >> Von: Pete Muir [mailto:[email protected]] > >> >> Gesendet: Montag, 30. Januar 2012 13:58 > >> >> An: [email protected] > >> >> Cc: Shane Bryzak > >> >> Betreff: Re: supporting different approaches,... > >> >> > >> >> I think we're suffering from a communication problem here, > > rather than > >> > a > >> >> different philosophy ;-) > >> >> > >> >> What we are proposing is an API/SPI abstraction which delegates > > the > >> actual > >> > work > >> >> to other frameworks (or modules if there isn't a framework > > that does > >> > what is > >> >> needed). The backends could be Shiro, or PicketLink etc. Backends > >> would be > >> >> responsible for providing authentication, authorisation, and > > identity > >> > management > >> >> services. > >> >> > >> >> To put it another way, what we are providing is the *programming > >> model* for > >> > > >> >> security. > >> >> > >> >> Gerhard, does that sound more inline with what you are thinking > > of? > >> >> > >> >> On 30 Jan 2012, at 12:45, Gerhard Petracek wrote: > >> >> > >> >>> hi shane, > >> >>> > >> >>> that's a noble goal. however, i know a lot of users who > > will never > >> > use > >> >>> our security >implementation< - only the api/spi to > > integrate > >> > with > >> >> the > >> >>> other modules of deltaspike (that's >independent< > > of what we > >> > are > >> >>> providing in this area). > >> >>> > >> >>> -> -1 for only providing one way of doing things in this > > case. > >> > users > >> >>> -> should > >> >>> be able to plug in easily. > >> >>> +1 for designing a new and simple module based on ideas of > > existing > >> >>> solutions, >but< based on a thin generic api used by > > the rest of > >> > > >> >>> deltaspike which can be used also for custom integrations of > > 3rd > >> party > >> > > >> >> solutions. > >> >>> +1 for providing adapters for existing security frameworks > > like shiro > >> >>> +(or > >> >>> at least we shouldn't block the possibility to implement > > such > >> > custom > >> >>> adapters easily). > >> >>> > >> >>> regards, > >> >>> gerhard > >> >>> > >> >>> > >> >>> > >> >>> 2012/1/30 Shane Bryzak <[email protected]> > >> >>> > >> >>>> On 30/01/12 18:57, Gerhard Petracek wrote: > >> >>>> > >> >>>>> hi @ all, > >> >>>>> > >> >>>>> as discussed at [1] the current suggestion is to > > start with > >> > new > >> >>>>> modules (esp. the jpa and the security module). > >> >>>>> both will show that we will face very different > > approaches we > >> > need > >> >>>>> to support. e.g. in case of the security module dan > > suggested > >> > an > >> >>>>> integration for apache shiro, shane mentioned > > picketlink idm > >> > and in > >> >> > >> >>>>> myfaces codi we have a very thin integration layer > > for 3rd > >> > party > >> >>>>> frameworks (but no concrete implementation). > >> >>>>> > >> >>>>> in general: > >> >>>>> in myfaces codi we are using cdi mechanisms to > > handle > >> > different > >> >>>>> approaches. > >> >>>>> if we support multiple approaches, we have only one > > default > >> >>>>> implementation or only optional implementations. > >> >>>>> if there is a default implementation, the other > >> > implementations are > >> >> > >> >>>>> cdi alternatives. > >> >>>>> in case of interceptors it's similar - it's > > handled > >> > via > >> >> different > >> >>>>> dependent scoped strategies and the current one > > (default or an > >> > > >> >>>>> activated alternative > >> >>>>> implementation) gets injected in the interceptor. > >> >>>>> (since the interceptor-strategies are dependent > > scoped, there > >> >> is>no< > >> >>>>> additional overhead caused by a proxy.) > >> >>>>> > >> >>>>> i suggest that we also rely on (the same) cdi > > mechanisms. > >> >>>>> > >> >>>>> a 2nd topic is the usage in other modules (e.g. > > security > >> > concepts > >> >> in > >> >>>>> an other deltaspike module). as discussed at [2], we > > can't > >> > use > >> >>>>> optional dependencies easily. > >> >>>>> in myfaces codi we keep such basic interfaces in > > core-api. > >> > however, > >> >> > >> >>>>> the core would grow quickly as soon as we add > > further modules > >> > (+ we > >> >> > >> >>>>> know that we will see more modules in deltaspike > > than we > >> > intended > >> >> to > >> >>>>> have in myfaces codi). therefore we could think > > about a > >> > different > >> >> approach. > >> >>>>> > >> >>>>> imo the security module(s) will be the perfect fit > > to discuss > >> > and > >> >>>>> prototype the basic concept. the following part is > > just an > >> > example > >> >>>>> and is>not< a suggestion to use/integrate the > > mentioned > >> > > >> >> frameworks: > >> >>>>> > >> >>>>> - deltaspike-security-api > >> >>>>> * deltaspike-security-**picketlink-impl > >> >>>>> * deltaspike-security-shiro-**integration-impl > >> >>>>> * deltaspike-security-xyz-**integration-impl > >> >>>>> > >> >>>> > >> >>>> As far as security goes, I don't think we should be > > using any > >> > 3rd > >> >>>> party frameworks. I've looked at Shiro and it's > > quite > >> >> simplistic > >> >>>> compared to what we plan to do, and the existing > > PicketLink IDM > >> > needs > >> >>>> an overhaul to simplify its API. What I envision is a > > new > >> > security > >> >>>> framework, inspired by the best features wherever we > > find them, > >> >>>> designed from the ground up to take advantage of CDI. I > > want > >> > people > >> >>>> to automatically think of DeltaSpike Security as the > > defacto > >> >>>> application security solution when they need to secure > > their Java > >> > EE > >> >>>> apps. We also have JSR-351 (Java Identity API) to > > consider, of > >> > which > >> >>>> both Bolek and I are members of the expert group - > > DeltaSpike > >> > might be > >> >> a good place to implement this new specification also. > >> >>>> > >> >>>> > >> >>>> > >> >>>>> all impl. modules are optional -> there > > wouldn't be a > >> >> dedicated > >> >>>>> default implementation. that means other modules > > only use the > >> >>>>> deltaspike-security-api. since there is no default > >> > implementation, > >> >>>>> we would have to use>e.g.< our BeanProvider > > which > >> > allows to > >> >> resolve > >> >>>>> optional beans easily. that would allow us to > > support > >> > different > >> >>>>> frameworks and an implementation gets activated > > automatically > >> > as > >> >>>>> soon as it gets added to an application -> we > > don't > >> > have to > >> >> choose > >> >>>>> a preferred approach and even possible add-ons for > > deltaspike > >> > can > >> >>>>> provide adapters for 3rd party frameworks easily. > >> >>>>> > >> >>>>> regards, > >> >>>>> gerhard > >> >>>>> > >> >>>>> [1] http://s.apache.org/QUU > >> >>>>> [2] http://s.apache.org/qAK > >> >>>>> > >> >>>>> > >> >>>> > >> >> > >> > > >> > > > > > > > > -- > > Jason Porter > > http://lightguard-jp.blogspot.com > > http://twitter.com/lightguardjp > > > > Software Engineer > > Open Source Advocate > > Author of Seam Catch - Next Generation Java Exception Handling > > > > PGP key id: 926CCFF5 > > PGP key available at: keyserver.net, pgp.mit.edu > > >
