deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <>
Subject AW: supporting different approaches,...
Date Mon, 30 Jan 2012 13:25:23 GMT
So basically there are two things to decide:
1. IF we provide an implementation for a certain part (i.e. authorization)
2. if that part is default and can be overridden by alternatives OR if there is no default
and that part is just a module that can be enabled via putting it into the classpath.


-----Urspr√ľngliche Nachricht-----
Von: Pete Muir [] 
Gesendet: Montag, 30. Januar 2012 14:13
Cc: Shane Bryzak
Betreff: Re: supporting different approaches,...

Yes, I certainly agree with the basic approach :-)

On 30 Jan 2012, at 13:09, Gerhard Petracek wrote:

> yes - since i wrote:
>> the following part is just an example and is >not< a suggestion to
> use/integrate the mentioned frameworks:
>> ...
> it's just about the basic topic how we support different approaches. 
> there are 2 points:
> #1 we provide multiple implementations in one module - e.g. different 
> persistence strategies -> we have one default impl. and the rest are 
> cdi alternatives
> #2 we don't have an explicit default implementations (we have 0-n "equal"
> modules - e.g. in case of the security module we might have multiple impl.
> modules) or users aren't interested in using one of our impl. module 
> at all, but the other deltaspike modules need an api/spi to use it - 
> >if< the user adds an impl module to the application)
> regards,
> gerhard
> 2012/1/30 Pete Muir <>
>> 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 <>
>>>> 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]
>>>>> [2]

View raw message