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 13:12:31 GMT
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
>>>>> 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
>>>>> 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<
>>>>> 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