Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pmuir@redhat.com designates
 209.132.183.28 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
Subject: Re: supporting different approaches,...
From: Pete Muir <pmuir@redhat.com>
In-Reply-To: 
 <CAGJtJfF6qLvHb8iZT=JyiB4qo=TDi4zyJ1sNdBwveXk1NCCo=w@mail.gmail.com>
Date: Mon, 30 Jan 2012 11:13:40 +0000
Content-Transfer-Encoding: 7bit
Message-Id: <D6871365-8389-4EC3-8FD4-08AEC9CE1057@redhat.com>
References: 
 <CAGJtJfF6qLvHb8iZT=JyiB4qo=TDi4zyJ1sNdBwveXk1NCCo=w@mail.gmail.com>
To: deltaspike-dev@incubator.apache.org


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.

+1

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