deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: AW: supporting different approaches,...
Date Mon, 30 Jan 2012 22:21:59 GMT
Thanks 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 <struberg@yahoo.de> 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 <struberg@yahoo.de>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> > 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 <arne.limburg@openknowledge.de>
> >>  To: "deltaspike-dev@incubator.apache.org"
> > <deltaspike-dev@incubator.apache.org>
> >>  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:pmuir@redhat.com]
> >>  Gesendet: Montag, 30. Januar 2012 13:58
> >>  An: deltaspike-dev@incubator.apache.org
> >>  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 <sbryzak@redhat.com>
> >>>
> >>>>   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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message