Return-Path: X-Original-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 86816982C for ; Wed, 1 Feb 2012 11:35:28 +0000 (UTC) Received: (qmail 80782 invoked by uid 500); 1 Feb 2012 11:35:28 -0000 Delivered-To: apmail-incubator-deltaspike-dev-archive@incubator.apache.org Received: (qmail 80732 invoked by uid 500); 1 Feb 2012 11:35:27 -0000 Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltaspike-dev@incubator.apache.org Delivered-To: mailing list deltaspike-dev@incubator.apache.org Received: (qmail 80708 invoked by uid 99); 1 Feb 2012 11:35:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 11:35:27 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [77.238.189.67] (HELO nm14.bullet.mail.ird.yahoo.com) (77.238.189.67) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 01 Feb 2012 11:35:22 +0000 Received: from [77.238.189.52] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 01 Feb 2012 11:34:59 -0000 Received: from [212.82.108.116] by tm5.bullet.mail.ird.yahoo.com with NNFMP; 01 Feb 2012 11:34:59 -0000 Received: from [127.0.0.1] by omp1025.mail.ird.yahoo.com with NNFMP; 01 Feb 2012 11:34:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 886577.45681.bm@omp1025.mail.ird.yahoo.com Received: (qmail 35994 invoked by uid 60001); 1 Feb 2012 11:34:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1328096099; bh=7iyKIZOH4aVAxTUnrLsuaRI0jfk4Y+6dkYg+pf6f8ok=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5jnQHbvF3C9rwAwe1Kmh2B44SuFnHA4vpXffjk9ve4C7EwMmwbpHMhxhwrd8qB0EYFHIfsQOp4qhVBd7EySEvDO8ODKwR4iekQ2dOLEmKu0HBeWpG3iTZwT7x92KD9e15KnCBO3Kh+0bwsVyBFgh7BROi6O27nGFX72NtA3IK8c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nMehSLcYyEMQji1FyUf7xOnJ7w6nPipSPa/NcGwDYLP7CSunYviexIl8/54n/jL70621HOTfx0iXnWIkbTPk58OcA7L4tdeRIDKTro6SBnXyfFrzIHinai9zYlwqihnfIGr1hVfq5+O59NJoYsSur/lOsZDN68t7hnYck+3mb6o=; X-YMail-OSG: h4NpjBEVM1nyJulZSJYdW9AS57zsspcv4QWwCWBBZycnfws RBOGD6uiN Received: from [80.108.122.184] by web171517.mail.ir2.yahoo.com via HTTP; Wed, 01 Feb 2012 11:34:58 GMT X-Mailer: YahooMailWebService/0.8.116.331537 References: <20120131122106.2BD781649E6@mx01.openknowledge.de> <1328016464.3075.YahooMailNeo@web171510.mail.ir2.yahoo.com> <4F27FC72.7090309@redhat.com> <4F2861A8.7020708@redhat.com> <20120131215440.3934F16466D@mx01.openknowledge.de> <4F290936.6070408@redhat.com> Message-ID: <1328096098.35952.YahooMailNeo@web171517.mail.ir2.yahoo.com> Date: Wed, 1 Feb 2012 11:34:58 +0000 (GMT) From: Mark Struberg Reply-To: Mark Struberg Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured To: "deltaspike-dev@incubator.apache.org" In-Reply-To: <4F290936.6070408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Slightly OT FYI: there is also currently a new incubation project being dis= cussed which handles 'Identity Management' [1]=0A=0A=0A=0A=0ALieGrue,=0Astr= ub=0A=0A=0A[1] http://wiki.apache.org/incubator/SyncopeProposal=0A=0A=0A---= -- Original Message -----=0A> From: Shane Bryzak =0A> T= o: deltaspike-dev@incubator.apache.org=0A> Cc: Christian Kaltepoth =0A> Sent: Wednesday, February 1, 2012 10:43 AM=0A> Subject= : Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured=0A> =0A>T he problem= with this solution is it doesn't allow you to specify any =0A> member valu= es for the annotations.=A0 I.e.=0A> =0A> @InGroup("manager")=0A> public boo= lean promoteStaff(Staff staff) {=0A> =A0 ...=0A> }=0A> =0A> I would probabl= y rather defer any complex authorization logic to the =0A> developer.=A0 We= 're already giving them a lot of power with the typesafe =0A> annotations, = it would be really easy for them to define authorization =0A> methods for a= ny non-trivial privilege checks themselves.=A0 Here's a =0A> (contrived) ex= ample:=0A> =0A> @MemberOfRole(mode =3D MemberOf.ANY, roles =3D {"admin", = =0A> "manager", =0A> "superuser"})=0A> public void doSomethingPrivileged() = {=0A> =A0 ...=0A> }=0A> =0A> Everything here would be provided by the deve= loper - the @MemberOfRole =0A> annotation, the MemberOf enum and the author= izer method to process the =0A> authorization logic.=0A> =0A> On 01/02/12 1= 6:13, Christian Kaltepoth wrote:=0A>> What about something like this:=0A>>= =0A>> =A0 =A0 public @interface AnyOf {=0A>> =A0 =A0 =A0 =A0 Class[] value();=0A>> =A0 =A0 }=0A>> =0A>> Usage:=0A>> =0A>> =A0 = =A0 @AnyOf({User.class, Admin.class})=0A>> =A0 =A0 public void doSomething(= ) {=0A>> =A0 =A0 =A0 =A0 // something=0A>> =A0 =A0 }=0A>> =0A>> It's not = as nice as @AnyOf({@User, @Admin}) but it's valid Java =0A> syntax. :)=0A>>= =0A>> Christian=0A>> =0A>> =0A>> 2012/1/31 Arne Limburg:=0A>>> Yes, that would work, but that annotation is not tha= t nice. I would =0A> have expected something like=0A>>> @AnyOf({@User, @Ad= min})=0A>>> which unfortunately is no valid Java syntax.=0A>>> Instead of= that someone could write something like=0A>>> @AnyOf(role1 =3D @User, rol= e2 =3D @Admin)=0A>>> which could be used like Shane suggests. Sadly enough= there is no easy =0A> way to provide a default @AnyOf annotation. So the u= sers have to write their own =0A> versions any time they need one.=0A>>> = =0A>>> Any better ideas?=0A>>> =0A>>> Cheers,=0A>>> Arne=0A>>> =0A>>> -= ----Urspr=FCngliche Nachricht-----=0A>>> Von: Shane Bryzak [mailto:sbryzak= @redhat.com]=0A>>> Gesendet: Dienstag, 31. Januar 2012 22:48=0A>>> An: de= ltaspike-dev@incubator.apache.org=0A>>> Cc: Jason Porter=0A>>> Betreff: R= e: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured=0A>>> =0A>>> I would a= pproach the "or" use case by simply providing =0A> another annotation:=0A>>= > =0A>>> @SecurityBindingType=0A>>> @Retention(RetentionPolicy.**RUNTIME)= =0A>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface = =0A> AdminOrUser {=0A>>> =0A>>> }=0A>>> =0A>>> =0A>>> public boolean @Sec= ures @AdminOrUser isAdminOrUser() {=0A>>> =A0 =A0 return isAdmin() || isUse= r();=0A>>> }=0A>>> =0A>>> =0A>>> =0A>>> =0A>>> On 01/02/12 07:44, Jason P= orter wrote:=0A>>>> Looks like I responded to the wrong thread as well.=0A= >>>> =0A>>>> I personally like the binding approach a little better. It se= ems to =0A> be=0A>>>> more similar to the CDI way of doing interceptors (w= hich, at the =0A> end=0A>>>> of the day is essentially what we're doing). = However, we have =0A> seen a=0A>>>> need of doing @Admin || @User or @Admi= n&&=A0 =A0 @User. The and =0A> is fairly=0A>>>> easy, but the or is curren= tly not covered and we need to be able to =0A> do that.=0A>>>> =0A>>>> I'm= pretty much at a +0 for both as well. As long as we have a =0A> way of=0A>= >>> doing the feature I described above, I don't really care which =0A> wa= y we go.=0A>>>> =0A>>>> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek=0A= >>>> wrote:=0A>>>> =0A>>>>> hi shane,=0A>>>>>= =0A>>>>> that's one of the reasons why i won't block it right =0A> now.= =0A>>>>> if the majority prefers custom annotations, we should just =0A> i= ntroduce=0A>>>>> it=0A>>>>>> after<=A0 =A0 v0.1 and prototype the missing= parts (and test =0A> it with the=0A>>>>> supported servers).=0A>>>>> =0A>= >>>> my vote is +0 right now (for both).=0A>>>>> =0A>>>>> regards,=0A>>>>= > gerhard=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> 2012/1/31 Shane Bryzak=0A>>>>> =0A>>>>>> On 01/02/12 00:21, Gerhard Petracek wrote= :=0A>>>>>> =0A>>>>>>> hi mark,=0A>>>>>>> =0A>>>>>>> thx for the heads-up.= i just talked with shane about =0A> all those details.=0A>>>>>>> =0A>>>>>>= > i don't see an issue with view-configs. codi just =0A> extracts the=0A>>= >>>>> @Secured annotation during the bootstrapping process in =0A> case of= view-configs.=0A>>>>> that=0A>>>>>>> would be the "same" for such custom= =0A> annotations meta-annotated with=0A>>>>>>> @SecurityBindingType.=0A>>= >>>>> =0A>>>>>>> what we need in case of intercepted beans:=0A>>>>>>> 1) = access to InvocationContext=0A>>>>>>> 2) easy access to the information if= a security check =0A> is on-going=0A>>>>>>> 3) possibility to configure a= default error-view =0A> (needed later on)=0A>>>>>>> 4) possibility to pro= vide a custom message + an =0A> integration with=0A>>>>>>> the upcoming i1= 8n module=0A>>>>>>> =0A>>>>>>> shane said that it should be possible to ad= d all needed =0A> features.=0A>>>>>>> (for=0A>>>>> me=0A>>>>>>> that mea= ns we need a prototype if the majority prefers =0A> custom=0A>>>>>>> annot= ations.)=0A>>>>>>> =0A>>>>>>> in the end both approaches are similar. both= are =0A> generic enough to=0A>>>>>>> integrate 3rd party security framewo= rks.=0A>>>>>>> =0A>>>>>>> @SecurityBindingType is just more generic and us= ers =0A> need an=0A>>>>>>> additional step to find secured beans (/views) = in a =0A> project.=0A>>>>>>> furthermore, meta-data inheritance with the m= entioned =0A> view-configs=0A>>>>>>> is a bit harder for users.=0A>>>>>>> = imo it's just a matter of taste. custom annotations =0A> as additional=0A>= >>>>>> indirection vs. a specific annotation with inline =0A> information.= =0A>>>>>>> =0A>>>>>>> with the approach provided by codi, users can't =0A>= introduce a custom=0A>>>>>>> annotation. however, i know a lot of users w= ho prefer =0A> one given=0A>>>>> annotation=0A>>>>>>> instead of implemen= ting x custom annotations. and i =0A> guess shane=0A>>>>>>> knows a lot of= users who prefer custom annotations. the =0A> goal of=0A>>>>>>> codi was = to make it easy, intuitive and flexible enough =0A> to=0A>>>>>>> integrate= 3rd party security-frameworks (instead of =0A> creating a new=0A>>>>>>> s= ecurity-framework). i wouldn't block the custom =0A> annotation=0A>>>>>>> = approach if 1)-4) are possible -=0A>>>>> it's=0A>>>>>>> a bit more flexib= le but also a bit more complex for =0A> users.=0A>>>>>>> =0A>>>>>> The bea= uty with the custom annotations is, if you like you =0A> can just=0A>>>>> = define=0A>>>>>> a single annotation if you want and use that throughout = =0A> your application.=0A>>>>>> =A0 =A0 I.e. you could similate the behavio= r of CODI:=0A>>>>>> =0A>>>>>> =0A>>>>>> @SecurityBindingType=0A>>>>>> @Re= tention(RetentionPolicy.**RUNTIME)=0A>>>>>> @Target({ElementType.TYPE, Ele= mentType.METHOD}) public =0A> @interface=0A>>>>>> Secured {=0A>>>>>> =A0 = =A0 @Nonbinding Class[] voters() default {};=0A>>>>>> =0A>>>>>> }=0A>>>>>>= =0A>>>>>> =0A>>>>>>> regards,=0A>>>>>>> gerhard=0A>>>>>>> =0A>>>>>>> =0A= >>>>>>> =0A>>>>>>> 2012/1/31 Mark Struberg=0A>>>>>>> = =0A>>>>>>> =A0 =A0 Gerhard, for explaining this you will probably need =0A>= to also=0A>>>>>>> explain the=0A>>>>>>>> TypeSafe Navigation as we have = it in CODI [1].By =0A> using custom=0A>>>>>>>> annotations, you would loos= e lots of functionality =0A> in this area.=0A>>>>>>>> =0A>>>>>>>> I know t= hat this is not the current topic, but =0A> discussing security=0A>>>>>>>> = mechanisms without discussing the stuff which needs =0A> to get secured=0A= >>>>>>>> is only half of the truth ;)=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> = =0A>>>>>>>> LieGrue,=0A>>>>>>>> strub=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> = =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> [1]=0A>>>>>>>> https://cwiki.apache.o= rg/**EXTCDI/jsf-usage.html#**=0A>>>>>>>> JSFUsage-TypesafeViewConfig<=0A>>= >>> =0A> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeVi= ewC=0A>>>>> onfig=0A>>>>>>>> =0A>>>>>>>> ----- Original Message -----=0A>= >>>>>>> =0A>>>>>>>>> From: Gerhard =0A> Petracek>>>> gerhard.petracek@gmail.com>=0A>>>>>>>>> To: deltaspike-dev@i= ncubator.**apache.org<=0A>>>>> deltaspike-dev@incubator.apache.org>=0A>>>>= >>>>> Cc:=0A>>>>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM=0A>>>>>>>>>= Subject: Re: [DISCUSS][SECURITY-API] =0A> [DELTASPIKE-64] @Secured=0A>>>>= >>>>> =0A>>>>>>>>> in case of myfaces codi it's also used for =0A> secured= view and it is=0A>>>>>>>>> integrated with the default-error-view concept= =0A> (as mentioned in=0A>>>>>>>>> the=0A>>>>>>>>> =0A>>>>>>>> ticket=0A>= >>>>>>> =0A>>>>>>>>> we will postpone this part).=0A>>>>>>>>> furthermore= it's used by codi-scopes to =0A> avoid a different=0A>>>>>>>>> expiration= behaviour of beans cause by a =0A> security check (see the=0A>>>>>>>>> me= ntioned AccessDecisionVoterContext).=0A>>>>>>>>> =0A>>>>>>>>> regards,=0A>= >>>>>>>> gerhard=0A>>>>>>>>> =0A>>>>>>>>> =0A>>>>>>>>> =0A>>>>>>>>> 2012/= 1/31 Arne =0A> Limburg>>>> arne.limbu= rg@openknowledge.de>=0A>>>>>>>>> =A0 =A0 Hi,=0A>>>>>>>>>> =A0 =A0 My first= objection when I saw the CODI =0A> feature the first time,=0A>>>>>>>>>> w= as=0A>>>>>>>>>> =0A>>>>>>>>> that it=0A>>>>>>>>> =A0 =A0 maybe is too basi= c: When I have to implement =0A> the Voter anyway=0A>>>>>>>>> (or my=0A>>>= >>>>>>> =A0 =A0 security-framework of choice delivers =0A> it), why should = I use=0A>>>>>>>>>> @Secured at=0A>>>>>>>>>> =A0 =A0 all? I mean, what is t= he REAL benefit of =0A> using @Secured over a=0A>>>>> custom=0A>>>>>>>>>> = =A0 =A0 annotation implemented by myself or =0A> delivered by my=0A>>>>> s= ecurity-framework=0A>>>>>>>>> of=0A>>>>>>>>> =A0 =A0 choice.=0A>>>>>>>>>> = =A0 =A0 The only benefit I see is when using =0A> different security=0A>>>>= >>>>>> sources, but=0A>>>>>>>>>> =0A>>>>>>>>> this=0A>>>>>>>>> =A0 =A0 is= a rare use case imho.=0A>>>>>>>>>> =A0 =A0 Cheers,=0A>>>>>>>>>> =A0 =A0 Ar= ne=0A>>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 -----Urspr=FCngliche Nachricht-----= =0A>>>>>>>>>> =A0 =A0 Von: Gerhard Petracek =0A> [mailto:gerhard.petracek@*= *gmail.com<=0A>>>>> gerhard.petracek@gmail.com>=0A>>>>>>>>>> ]=0A>>>>>>>>= >> =A0 =A0 Gesendet: Dienstag, 31. Januar 2012 =0A> 13:14=0A>>>>>>>>>> =A0 = =A0 An: =0A> deltaspike-dev@incubator.**apache.org<=0A>>>>> deltaspike-dev= @incubator.apache.org>=0A>>>>>>>>>> =A0 =A0 Betreff: Re: [DISCUSS][SECURITY= -API] =0A> [DELTASPIKE-64] @Secured=0A>>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 that= 's one option. a 2nd option is =0A> to use a=0A>>>>> deltaspike-security-i= mpl.=0A>>>>>>>>>> =A0 =A0 module which can provide e.g. an adapter =0A> for= 3rd party=0A>>>>>>>>>> =0A>>>>>>>>> security-framework.=0A>>>>>>>>> =A0 = =A0 or users just add a possible =0A> deltaspike-add-on provided by an=0A>>= >>> external=0A>>>>>>>>>> =A0 =A0 community e.g. by a security-framework = =0A> itself.=0A>>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 regards,=0A>>>>>>>>>> =A0 = =A0 gerhard=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 = 2012/1/31 John D. =0A> Ament=0A>>>>>>>>>> =0A>>>>>>= >>>> =A0 =A0 >=A0 =A0 Is it up to the developer to =0A> define the bean th= at implements an=0A>>>>>>>>>> =A0 =A0 interface?=0A>>>>>>>>>> =A0 =A0 >=0A>= >>>>>>>>> =A0 =A0 >=A0 =A0 On Tue, Jan 31, 2012 at 6:59 =0A> AM, Gerhard P= etracek<=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 gerhard.petracek@gmail.com>=A0 =0A> = =A0 wrote:=0A>>>>>>>>>> =A0 =A0 >=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 = hi @ all,=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 = >=A0 =A0 imo this feature of =0A> myfaces codi-core is a nice starting poi= nt=0A>>>>>>>>>> =0A>>>>>>>>> for=0A>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 = =A0 >=A0 =A0 the security-api =0A> discussion, because the basic idea beh= ind it=0A>>>>> is=0A>>>>>>>>> a=0A>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 = =A0 >=A0 =A0 very thin integration =0A> layer (which can be used by other= =0A>>>>>>>>>> modules).=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=0A>>>>>>>>>> =A0 = =A0 >=A0 =A0 >=A0 =A0 the basic concept:=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >= =A0 =A0 a cdi interceptor =0A> invokes (inline) voters to secure the targe= t=0A>>>>>>>>>> =A0 =A0 method/s.=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 a= voter is a (custom) =0A> cdi bean which implements a specific=0A>>>>>>>>>>= =0A>>>>>>>>> interface=0A>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 = =A0 and therefore has =0A> access to the InvocationContext.=0A>>>>>>>>>> = =A0 =A0 >=A0 =A0 >=A0 =A0 furthermore, a voter =0A> detects 0-n violation= s and>can<=A0 =A0 be=0A>>>>>>>>>> =0A>>>>>>>>> used to=0A>>>>>>>>> =0A>>>= >>>>>>> =A0 =A0 >=A0 =A0 integrate=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0= 3rd party =0A> security-frameworks.=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 = =A0 [1] provides a bit =0A> more details of the basic concept as well=0A>>= >>> as=0A>>>>>>>>> the=0A>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 = =A0 basic usage of =0A> @Secured.=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=0A>>>>>= >>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 please send=0A>>>>>>>>>> =A0 =A0 >=A0 =A0= >=A0 =A0 +1, +0 or -1 =0A> because...=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >= =A0 =A0 for the>basic =0A> concept<.=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=0A>>= >>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 (please =0A> add>basic<=A0 =A0 object= ions also to [2]. we can discuss=0A>>>>>>>>>> =0A>>>>>>>>> details e.g.=0A= >>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 further objections =0A>= about the concrete implementation (e.g.=0A>>>>>>>>>> =0A>>>>>>>>> interna= l=0A>>>>>>>>> =0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 classes,...) as soo= n =0A> as we agreed on including this concept.)=0A>>>>>>>>>> =A0 =A0 >=A0 = =A0 >=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 regards,=0A>>>>>>>>>> =A0 = =A0 >=A0 =A0 >=A0 =A0 gerhard=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=0A>>>>>>>>= >> =A0 =A0 >=A0 =A0 >=A0 =A0 [1] =0A> https://issues.apache.org/**jira/br= owse/DELTASPIKE-64<=0A>>>>> https://issues.apache.org/jira/browse/DELTASPI= KE-64>=0A>>>>>>>>>> =A0 =A0 >=A0 =A0 >=A0 =A0 [2]=0A>>>>>>>>>> =A0 =A0 >= =A0 =A0 >=0A>>>>>>>>>> =A0 =A0 >=0A>>>>>>>>>> =0A>>>>>>>>> =0A> https://cw= iki.apache.org/**confluence/display/DeltaSpike/**=0A>>>>>>>> SE+Feature+Ra= nk<=0A>>>>> =0A> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+= Feature+Ran=0A>>>>> k>=0A>>>>>>>>> =A0 =A0 >=A0 =A0 ing=0A>>>>>>>>>> =A0 = =A0 >=A0 =A0 >=0A>>>>>>>>>> =A0 =A0 >=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>> = =0A>> =0A>> =0A>