> 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 >
