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
