deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 11:35:17 GMT
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