deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 11:13:40 GMT

On 30 Jan 2012, at 10: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
> 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]
> [2]

View raw message