incubator-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 Tue, 31 Jan 2012 07:20:12 GMT
Yeah, Gerhard and I spoke in IRC. I'm understanding things correctly now.

I'm at a +1 for a very basic impl in DeltaSpike.

Sorry all, everyone in my family is sick right now, I may be lacking a bit
in the brain power department.

On Tue, Jan 31, 2012 at 00:15, Mark Struberg <struberg@yahoo.de> wrote:

> > 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 <lightguard.jp@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> > 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 <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
> >
>



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