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:32:34 GMT
by default implementation I meant a default integration.

On Mon, Jan 30, 2012 at 9:16 AM, José Rodolfo Freitas <
joserodolfo.freitas@gmail.com> wrote:

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