deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Rodolfo Freitas <joserodolfo.frei...@gmail.com>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 11:47:35 GMT
ok, got it.

On Mon, Jan 30, 2012 at 9:35 AM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:

> hi jose,
>
> that isn't a discussion about a default implementation.
> the suggestion is that we can agree on a default implementation if >we<
> implement different approaches and for the other implementations we use cdi
> alternatives. this concept allows to switch between the implementations.
>
> in case of the security module we see multiple suggestions and if we
> integrate multiple frameworks, we need a module per framework. in such a
> case we don't really need a default implementation.
> users just add the impl. module of their choice (to an application) and it
> gets activated automatically.
>
> regards,
> gerhard
>
>
>
> 2012/1/30 José Rodolfo Freitas <joserodolfo.freitas@gmail.com>
>
> > +1 for a thin integration layer for third party based on CDI mechanisms.
> > +1 for default implementation.
> > I'd suggest Shiro or ESAPI.
> >
> > ESAPI[1] doesn't seem to be very known, but it's an API that should be
> > considered since it's the API developed by OWASP[2] team, based on the
> > lines and concerns gathered by that open security group.
> >
> > [1] http://code.google.com/p/owasp-esapi-java/
> > [2] https://www.owasp.org/index.php/Main_Page
> >
> > On Mon, Jan 30, 2012 at 8:57 AM, Gerhard Petracek <
> > gerhard.petracek@gmail.com> 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
> > >
> > > 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
> > >
> >
>

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