incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Thu, 02 Feb 2012 09:31:37 GMT
hi @ all,

since the extended version of @Secured is also nice for codi, i'll improve
the corresponding parts of codi before importing the feature.
as soon as we have the additional features for @SecurityBindingType, i'll
start with the refactoring to build it on top of @SecurityBindingType.

mark started with the release-process for v0.1. since it's the first
release, we should wait with adding new parts until we know that the
approach with a release-branch works for us.

regards,
gerhard



2012/2/1 Christian Kaltepoth <christian@kaltepoth.de>

> +1 for implementing both to see how it works out
> +1 for building @Secured on top of @SecurityBindingType
>
> Christian
>
>
> 2012/2/1 Jason Porter <lightguard.jp@gmail.com>:
> > I'm going to put my vote in with Arne.
> >
> > +1 for @Secured implemented on top of @SecurityBindingType.
> >
> > On Wed, Feb 1, 2012 at 06:52, Arne Limburg <
> arne.limburg@openknowledge.de>wrote:
> >
> >> If we implement @Secured on top of @SecurityBindingType this could even
> be
> >> a permanent solution.
> >> So my +1 for that.
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >> Gesendet: Mittwoch, 1. Februar 2012 12:33
> >> An: deltaspike-dev@incubator.apache.org
> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>
> >> hi @ all,
> >>
> >> i talked with shane about further details of the current implementation.
> >>
> >> -> if we don't see an agreement this week:
> >> +1 for adding both (at least for now).
> >>
> >> we have to add features to >both< @Secured as well as
> @SecurityBindingType.
> >> maybe we will see that one of both is better as soon as we have the
> final
> >> implementation (and therefore all the details) and we can remove the
> other
> >> approach.
> >> if we see that both make sense, we just keep them.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/2/1 Gerhard Petracek <gerhard.petracek@gmail.com>
> >>
> >> > yes - that's possible as well.
> >> >
> >> > short addition - 3b allows:
> >> >
> >> > @TwoOf //introduced by the >user<
> >> > @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
> >> > AccessDecisionVoter3.class})
> >> >
> >> > (i wouldn't do it that way, because i wouldn't use a custom annotation
> >> > for such use-cases. however, users can decide it on their own.)
> >> >
> >> > regards,
> >> > gerhard
> >> >
> >> >
> >> >
> >> > 2012/2/1 Arne Limburg <arne.limburg@openknowledge.de>
> >> >
> >> >> Basically we are discussing, if the access control logic goes into
a
> >> >> class that implements an interface (which is AccessDecisionVoter) or
> >> >> into a method that is annotated with @Secures.
> >> >>
> >> >> Note that both approaches can be built with the other.
> >> >>
> >> >> I prefer the second way since it looks more like the CDI way.
> >> >>
> >> >> Another option is to provide both APIs. Then we only would have to
> >> >> decide which one is "core" and which one is based on the other.
> >> >>
> >> >> Cheers,
> >> >> Arne
> >> >>
> >> >> -----Ursprüngliche Nachricht-----
> >> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >> >> Gesendet: Mittwoch, 1. Februar 2012 08:54
> >> >> An: deltaspike-dev@incubator.apache.org
> >> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >> >>
> >> >> @christian: that's correct. but the advantage of using custom
> >> >> annotation arguments can't be used any more.
> >> >>
> >> >> and that's also one of my concerns - simple cases work (but also
> >> >> simple cases are more complex than the usage of @Secured) and such
> >> "advanced"
> >> >> use-cases are restricted.
> >> >>
> >> >> >in some cases it's worth to add more complexity, because it makes
> >> >> >sense
> >> >> for supporting advanced use-cases!<
> >> >> but right now i don't see it here.
> >> >>
> >> >> it would be possible to extend the approach of @Secured.
> >> >>
> >> >> examples:
> >> >>
> >> >> #1
> >> >>
> >> >> //...
> >> >> @Secured(MyAccessDecisionVoter.class)
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> users who prefer custom annotations can use stereotypes:
> >> >>
> >> >> #2
> >> >> //...
> >> >> @Admin
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(AdminAccessDecisionVoter.class)
> >> >> public @interface Admin
> >> >> {
> >> >> }
> >> >>
> >> >> #3
> >> >> //...
> >> >> //...
> >> >> @AdminOrUser
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> a)
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(oneOf = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class})
> >> >> // @Secured(allOf = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class})
> >> >> // ...
> >> >> public @interface AdminOrUser
> >> >> {
> >> >> }
> >> >>
> >> >> or
> >> >>
> >> >> b)
> >> >> //...
> >> >> @Stereotype
> >> >> //users could even provide a custom interceptor strategy and
> >> >> introduce custom versions of @OneOf or other annotations @OneOf
> >> >> @Secured({AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
> >> >>
> >> >> or
> >> >>
> >> >> c)
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(value = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
> >> >> AdminOrUser { }
> >> >>
> >> >> regards,
> >> >> gerhard
> >> >>
> >> >>
> >> >>
> >> >> 2012/2/1 Christian Kaltepoth <christian@kaltepoth.de>
> >> >>
> >> >> > What about something like this:
> >> >> >
> >> >> >  public @interface AnyOf {
> >> >> >      Class<? extends Annotation>[] value();  }
> >> >> >
> >> >> > Usage:
> >> >> >
> >> >> >  @AnyOf({User.class, Admin.class})
> >> >> >  public void doSomething() {
> >> >> >       // something
> >> >> >  }
> >> >> >
> >> >> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
> >> >> > syntax. :)
> >> >> >
> >> >> > Christian
> >> >> >
> >> >> >
> >> >> > 2012/1/31 Arne Limburg <arne.limburg@openknowledge.de>:
> >> >> > > Yes, that would work, but that annotation is not that nice.
I
> >> >> > > would have
> >> >> > expected something like
> >> >> > > @AnyOf({@User, @Admin})
> >> >> > > which unfortunately is no valid Java syntax.
> >> >> > > Instead of that someone could write something like
> >> >> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used
like
> >> >> > > Shane suggests. Sadly enough there is no easy
> >> >> > way to provide a default @AnyOf annotation. So the users have
to
> >> >> > write their own versions any time they need one.
> >> >> > >
> >> >> > > Any better ideas?
> >> >> > >
> >> >> > > Cheers,
> >> >> > > Arne
> >> >> > >
> >> >> > > -----Ursprüngliche Nachricht-----
> >> >> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> >> >> > > Gesendet: Dienstag, 31. Januar 2012 22:48
> >> >> > > An: deltaspike-dev@incubator.apache.org
> >> >> > > Cc: Jason Porter
> >> >> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >> >> > >
> >> >> > > I would approach the "or" use case by simply providing another
> >> >> > annotation:
> >> >> > >
> >> >> > > @SecurityBindingType
> >> >> > > @Retention(RetentionPolicy.**RUNTIME)
> >> >> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> >> >> > AdminOrUser {
> >> >> > >
> >> >> > > }
> >> >> > >
> >> >> > >
> >> >> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
> >> >> > >   return isAdmin() || isUser();
> >> >> > > }
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On 01/02/12 07:44, Jason Porter wrote:
> >> >> > >> Looks like I responded to the wrong thread as well.
> >> >> > >>
> >> >> > >> I personally like the binding approach a little better.
It seems
> >> >> > >> to be more similar to the CDI way of doing interceptors
(which,
> >> >> > >> at the end of the day is essentially what we're doing).
However,
> >> >> > >> we have seen a need of doing @Admin || @User or @Admin&&
 @User.
> >> >> > >> The and is fairly easy, but the or is currently not covered
and
> >> >> > >> we need to be able to do
> >> >> > that.
> >> >> > >>
> >> >> > >> I'm pretty much at a +0 for both as well. As long as
we have a
> >> >> > >> way of doing the feature I described above, I don't really
care
> >> >> > >> which way we
> >> >> > go.
> >> >> > >>
> >> >> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> >> >> > >> <gerhard.petracek@gmail.com>wrote:
> >> >> > >>
> >> >> > >>> hi shane,
> >> >> > >>>
> >> >> > >>> that's one of the reasons why i won't block it right
now.
> >> >> > >>> if the majority prefers custom annotations, we should
just
> >> >> > >>> introduce it
> >> >> > >>>> after<  v0.1 and prototype the missing parts
(and test it with
> >> >> > >>>> the
> >> >> > >>> supported servers).
> >> >> > >>>
> >> >> > >>> my vote is +0 right now (for both).
> >> >> > >>>
> >> >> > >>> regards,
> >> >> > >>> gerhard
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> 2012/1/31 Shane Bryzak<sbryzak@redhat.com>
> >> >> > >>>
> >> >> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> >> >> > >>>>
> >> >> > >>>>> hi mark,
> >> >> > >>>>>
> >> >> > >>>>> thx for the heads-up. i just talked with
shane about all
> >> >> > >>>>> those
> >> >> > details.
> >> >> > >>>>>
> >> >> > >>>>> i don't see an issue with view-configs. codi
just extracts
> >> >> > >>>>> the @Secured annotation during the bootstrapping
process in
> >> >> > >>>>> case of
> >> >> > view-configs.
> >> >> > >>> that
> >> >> > >>>>> would be the "same" for such custom annotations
> >> >> > >>>>> meta-annotated with @SecurityBindingType.
> >> >> > >>>>>
> >> >> > >>>>> what we need in case of intercepted beans:
> >> >> > >>>>> 1) access to InvocationContext
> >> >> > >>>>> 2) easy access to the information if a security
check is
> >> >> > >>>>> on-going
> >> >> > >>>>> 3) possibility to configure a default error-view
(needed
> >> >> > >>>>> later
> >> >> > >>>>> on)
> >> >> > >>>>> 4) possibility to provide a custom message
+ an integration
> >> >> > >>>>> with the upcoming i18n module
> >> >> > >>>>>
> >> >> > >>>>> shane said that it should be possible to
add all needed
> >> features.
> >> >> > >>>>> (for
> >> >> > >>> me
> >> >> > >>>>> that means we need a prototype if the majority
prefers custom
> >> >> > >>>>> annotations.)
> >> >> > >>>>>
> >> >> > >>>>> in the end both approaches are similar. both
are generic
> >> >> > >>>>> enough to integrate 3rd party security frameworks.
> >> >> > >>>>>
> >> >> > >>>>> @SecurityBindingType is just more generic
and users need an
> >> >> > >>>>> additional step to find secured beans (/views)
in a project.
> >> >> > >>>>> furthermore, meta-data inheritance with the
mentioned
> >> >> > >>>>> view-configs is a bit harder for users.
> >> >> > >>>>> imo it's just a matter of taste. custom annotations
as
> >> >> > >>>>> additional indirection vs. a specific annotation
with inline
> >> >> information.
> >> >> > >>>>>
> >> >> > >>>>> with the approach provided by codi, users
can't introduce a
> >> >> > >>>>> custom annotation. however, i know a lot
of users who prefer
> >> >> > >>>>> one given
> >> >> > >>> annotation
> >> >> > >>>>> instead of implementing x custom annotations.
and i guess
> >> >> > >>>>> shane knows a lot of users who prefer custom
annotations. the
> >> >> > >>>>> goal of codi was to make it easy, intuitive
and flexible
> >> >> > >>>>> enough to integrate 3rd party security-frameworks
(instead of
> >> >> > >>>>> creating a new security-framework). i wouldn't
block the
> >> >> > >>>>> custom annotation approach if 1)-4) are possible
-
> >> >> > >>> it's
> >> >> > >>>>> a bit more flexible but also a bit more complex
for users.
> >> >> > >>>>>
> >> >> > >>>> The beauty with the custom annotations is, if
you like you can
> >> >> > >>>> just
> >> >> > >>> define
> >> >> > >>>> a single annotation if you want and use that
throughout your
> >> >> > application.
> >> >> > >>>>   I.e. you could similate the behavior of CODI:
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> @SecurityBindingType
> >> >> > >>>> @Retention(RetentionPolicy.**RUNTIME)
> >> >> > >>>> @Target({ElementType.TYPE, ElementType.METHOD})
public
> >> >> > >>>> @interface Secured {
> >> >> > >>>>   @Nonbinding Class[] voters() default {};
> >> >> > >>>>
> >> >> > >>>> }
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>>> regards,
> >> >> > >>>>> gerhard
> >> >> > >>>>>
> >> >> > >>>>>
> >> >> > >>>>>
> >> >> > >>>>> 2012/1/31 Mark Struberg<struberg@yahoo.de>
> >> >> > >>>>>
> >> >> > >>>>>   Gerhard, for explaining this you will probably
need to also
> >> >> > >>>>> explain the
> >> >> > >>>>>> TypeSafe Navigation as we have it in
CODI [1].By using
> >> >> > >>>>>> custom annotations, you would loose lots
of functionality in
> >> this area.
> >> >> > >>>>>>
> >> >> > >>>>>> I know that this is not the current topic,
but discussing
> >> >> > >>>>>> security mechanisms without discussing
the stuff which needs
> >> >> > >>>>>> to get secured is only half of the truth
;)
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> LieGrue,
> >> >> > >>>>>> strub
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> [1]
> >> >> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> >> >> > >>>>>> JSFUsage-TypesafeViewConfig<
> >> >> > >>>
> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-Typesaf
> >> >> > >>> eVi
> >> >> > >>> ewC
> >> >> > >>> onfig
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> ----- Original Message -----
> >> >> > >>>>>>
> >> >> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> >> >> > >>> gerhard.petracek@gmail.com>
> >> >> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> >> >> > >>> deltaspike-dev@incubator.apache.org>
> >> >> > >>>>>>> Cc:
> >> >> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31
PM
> >> >> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API]
[DELTASPIKE-64]
> >> >> > >>>>>>> @Secured
> >> >> > >>>>>>>
> >> >> > >>>>>>> in case of myfaces codi it's also
used for secured view and
> >> >> > >>>>>>> it is integrated with the default-error-view
concept (as
> >> >> > >>>>>>> mentioned in the
> >> >> > >>>>>>>
> >> >> > >>>>>> ticket
> >> >> > >>>>>>
> >> >> > >>>>>>> we will postpone this part).
> >> >> > >>>>>>> furthermore it's used by codi-scopes
to avoid a different
> >> >> > >>>>>>> expiration behaviour of beans cause
by a security check
> >> >> > >>>>>>> (see the mentioned AccessDecisionVoterContext).
> >> >> > >>>>>>>
> >> >> > >>>>>>> regards,
> >> >> > >>>>>>> gerhard
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> >> >> > >>> arne.limburg@openknowledge.de>
> >> >> > >>>>>>>    Hi,
> >> >> > >>>>>>>>   My first objection when I saw
the CODI feature the first
> >> >> > >>>>>>>> time, was
> >> >> > >>>>>>>>
> >> >> > >>>>>>> that it
> >> >> > >>>>>>>   maybe is too basic: When I have
to implement the Voter
> >> >> > >>>>>>> anyway (or my
> >> >> > >>>>>>>>   security-framework of choice
delivers it), why should I
> >> >> > >>>>>>>> use @Secured at
> >> >> > >>>>>>>>   all? I mean, what is the REAL
benefit of using @Secured
> >> >> > >>>>>>>> over a
> >> >> > >>> custom
> >> >> > >>>>>>>>   annotation implemented by myself
or delivered by my
> >> >> > >>> security-framework
> >> >> > >>>>>>> of
> >> >> > >>>>>>>   choice.
> >> >> > >>>>>>>>   The only benefit I see is when
using different security
> >> >> > >>>>>>>> sources, but
> >> >> > >>>>>>>>
> >> >> > >>>>>>> this
> >> >> > >>>>>>>   is a rare use case imho.
> >> >> > >>>>>>>>   Cheers,
> >> >> > >>>>>>>>   Arne
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   -----Ursprüngliche Nachricht-----
> >> >> > >>>>>>>>   Von: Gerhard Petracek
> >> >> > >>>>>>>> [mailto:gerhard.petracek@**gmail.com<
> >> >> > >>> gerhard.petracek@gmail.com>
> >> >> > >>>>>>>> ]
> >> >> > >>>>>>>>   Gesendet: Dienstag, 31. Januar
2012 13:14
> >> >> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> >> >> > >>> deltaspike-dev@incubator.apache.org>
> >> >> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API]
[DELTASPIKE-64]
> >> >> > >>>>>>>> @Secured
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   that's one option. a 2nd option
is to use a
> >> >> > >>> deltaspike-security-impl.
> >> >> > >>>>>>>>   module which can provide e.g.
an adapter for 3rd party
> >> >> > >>>>>>>>
> >> >> > >>>>>>> security-framework.
> >> >> > >>>>>>>   or users just add a possible deltaspike-add-on
provided
> >> >> > >>>>>>> by an
> >> >> > >>> external
> >> >> > >>>>>>>>   community e.g. by a security-framework
itself.
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   regards,
> >> >> > >>>>>>>>   gerhard
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   2012/1/31 John D. Ament<john.d.ament@gmail.com>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   >   Is it up to the developer
to define the bean that
> >> >> > implements an
> >> >> > >>>>>>>>   interface?
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>   >   On Tue, Jan 31, 2012
at 6:59 AM, Gerhard Petracek<
> >> >> > >>>>>>>>   >   gerhard.petracek@gmail.com>
  wrote:
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>   >   >   hi @ all,
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   imo this feature
of myfaces codi-core is a nice
> >> >> > starting point
> >> >> > >>>>>>>>
> >> >> > >>>>>>> for
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   the security-api
discussion, because the basic
> idea
> >> >> > behind it
> >> >> > >>> is
> >> >> > >>>>>>> a
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   very thin integration
layer (which can be used
> by
> >> >> other
> >> >> > >>>>>>>> modules).
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   the basic concept:
> >> >> > >>>>>>>>   >   >   a cdi interceptor
invokes (inline) voters to
> secure
> >> >> the
> >> >> > target
> >> >> > >>>>>>>>   method/s.
> >> >> > >>>>>>>>   >   >   a voter is a
(custom) cdi bean which implements
> a
> >> >> > specific
> >> >> > >>>>>>>>
> >> >> > >>>>>>> interface
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   and therefore
has access to the
> InvocationContext.
> >> >> > >>>>>>>>   >   >   furthermore,
a voter detects 0-n violations
> >> and>can<
> >> >> > be
> >> >> > >>>>>>>>
> >> >> > >>>>>>> used to
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   integrate
> >> >> > >>>>>>>>   >   >   3rd party security-frameworks.
> >> >> > >>>>>>>>   >   >   [1] provides
a bit more details of the basic
> >> concept
> >> >> as
> >> >> > well
> >> >> > >>> as
> >> >> > >>>>>>> the
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   basic usage of
@Secured.
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   please send
> >> >> > >>>>>>>>   >   >   +1, +0 or -1
because...
> >> >> > >>>>>>>>   >   >   for the>basic
concept<.
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   (please add>basic<
  objections also to [2]. we
> can
> >> >> > discuss
> >> >> > >>>>>>>>
> >> >> > >>>>>>> details e.g.
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   further objections
about the concrete
> >> implementation
> >> >> > (e.g.
> >> >> > >>>>>>>>
> >> >> > >>>>>>> internal
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   classes,...)
as soon as we agreed on including
> this
> >> >> > concept.)
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   regards,
> >> >> > >>>>>>>>   >   >   gerhard
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   [1]
> >> >> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> >> >> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> >> >> > >>>>>>>>   >   >   [2]
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>
> >> >> > >>>>>>>
> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >> >> > >>>>>> SE+Feature+Rank<
> >> >> > >>>
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Featu
> >> >> > >>> re+
> >> >> > >>> Ran
> >> >> > >>> k>
> >> >> > >>>>>>>   >   ing
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>
> >> >> > >>
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Christian Kaltepoth
> >> >> > Blog: http://chkal.blogspot.com/
> >> >> > Twitter: http://twitter.com/chkal
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Jason Porter
> > http://lightguard-jp.blogspot.com
> > http://twitter.com/lightguardjp
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at: keyserver.net, pgp.mit.edu
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message