2012/1/29 Gerhard Petracek gpetra...@apache.org:
@Lukasz: Please add yourself to the Parent-POM [1].
Done, thanks!
Regards
--
Łukasz
On 30 Jan 2012, at 01:01, Shane Bryzak wrote:
On 27/01/12 16:55, Gerhard Petracek wrote:
hi @ all,
(i planned to send this mail after starting the release procedure for v0.1.
however, the review phase for v0.1 is going to end soon and we have seen
several other discussions already.)
+1 for a thin integration layer for third party based on CDI mechanisms.
+1 for default implementation.
I'd suggest Shiro or ESAPI.
ESAPI[1] doesn't seem to be very known, but it's an API that should be
considered since it's the API developed by OWASP[2] team, based on the
lines and concerns
by default implementation I meant a default integration.
On Mon, Jan 30, 2012 at 9:16 AM, José Rodolfo Freitas
joserodolfo.frei...@gmail.com wrote:
+1 for a thin integration layer for third party based on CDI mechanisms.
+1 for default implementation.
I'd suggest Shiro or ESAPI.
ESAPI[1]
hi jose,
that isn't a discussion about a default implementation.
the suggestion is that we can agree on a default implementation if we
implement different approaches and for the other implementations we use cdi
alternatives. this concept allows to switch between the implementations.
in case of
ok, got it.
On Mon, Jan 30, 2012 at 9:35 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi jose,
that isn't a discussion about a default implementation.
the suggestion is that we can agree on a default implementation if we
implement different approaches and for the other
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
Hi,
+1 for providing a ready-to-use security implementation (i.e. supporting
authentication and @RolesAllowed), but
-1 for not providing integration for other frameworks. At least we should
provide a rich set of extension points for them. There are so many parts of
security that we should not
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
There would of course be extension points for pluggable authentication
and authorization, something that has existed in Seam Security for many
years already. I think our existing design in this area is already
quite robust, and gives the developer a choice whether to use one of the
built-in
Hi Pete,
At least that sounds like that what I am thinking of ;-)
-Ursprüngliche Nachricht-
Von: Pete Muir [mailto:pm...@redhat.com]
Gesendet: Montag, 30. Januar 2012 13:58
An: deltaspike-dev@incubator.apache.org
Cc: Shane Bryzak
Betreff: Re: supporting different approaches,...
I think
Sorry, yes, I was to specific calling out Gerhard ;-)
On 30 Jan 2012, at 12:57, Pete Muir wrote:
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
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
So basically there are two things to decide:
1. IF we provide an implementation for a certain part (i.e. authorization)
2. if that part is default and can be overridden by alternatives OR if there is
no default and that part is just a module that can be enabled via putting it
into the classpath.
Btw, Gerhard on IRC made me aware that the whole security discussion is already
heavily Off Topic ^^
It is an important discussion but the current context is:
How to make different impls for various situations possible in DeltaSpike?
So, back to the original topic.
there are 2 ways
a.) use
I want to chime in just to let you know that I am looking into
recommendations for improving the testing structure as well.
I don't have anything concrete yet, and will likely be playing around with
the suggestions Christian has laid out in addition to whatever comes to my
mind. I also need to
hi dan,
thx! if you think about a) or b) mentioned by christian we should discuss
it before you spend a lot of time on it. (because there are/were good
reasons for not doing that.)
@all:
the only issues i saw (as well):
- right now moving resources is broken. e.g.
short addition:
imo it's easier/faster to discuss this special topic in our irc channel and
post a summary to the list.
@christian:
it's quite a long story - so i skipped the details for now to avoid that
dan spends a lot of time on it before mark or i have some time to answer
your mail
Awesome! Welcome Christian! :D
On Sat, Jan 28, 2012 at 7:47 AM, Gerhard Petracek gpetra...@apache.orgwrote:
The DeltaSpike PPMC is proud to announce a new addition to our community.
Please welcome Christian Kaltepoth as the newest DeltaSpike committer!
@Christian: Please add yourself to the
Thanks for getting us back on track Mark, I noticed that as I was reading
the thread :)
I'm at +1 for not having any default in DeltaSpike. I think it makes it
easier for the users to consume, this also takes some tasks off our plate
for maintaining any default implementation, which could become
I'm at +1 for not having any default in DeltaSpike.
That was not exactly what I'm saying ;)
I'm for having a default in _any_ case, but it should be the one which is
mostly basic and requires no additional dependencies.
DeltaSpike should be usable out of the box, even if it's only a hand
+1 (and no defaults only if we provide optional extension points)
regards,
gerhard
2012/1/31 Mark Struberg strub...@yahoo.de
I'm at +1 for not having any default in DeltaSpike.
That was not exactly what I'm saying ;)
I'm for having a default in _any_ case, but it should be the one which
Yeah, Gerhard and I spoke in IRC. I'm understanding things correctly now.
I'm at a +1 for a very basic impl in DeltaSpike.
Sorry all, everyone in my family is sick right now, I may be lacking a bit
in the brain power department.
On Tue, Jan 31, 2012 at 00:15, Mark Struberg strub...@yahoo.de
23 matches
Mail list logo
