+1
On 01/04/13 02:35, Mark Struberg wrote:
yes, let's drop them. annotations are like interfaces nowadays. So this is just
superfluous.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Sunday,
lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504235#comment-13504235
]
Shane Bryzak commented on DELTASPIKE-292:
-
While there are some niggling
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501784#comment-13501784
]
Shane Bryzak commented on DELTASPIKE-292:
-
My apologies, you are correct
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501635#comment-13501635
]
Shane Bryzak commented on DELTASPIKE-292:
-
I'm not so sure that is a good idea
[
https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500600#comment-13500600
]
Shane Bryzak commented on DELTASPIKE-292:
-
I understand what you're saying
I think we have to support creation of new beans. Take a look at [1],
which is a blog post on configuring Drools within Spring. A little way
down, under the sessions.xml heading he has an example showing a Drools
configuration. We need to be able to support the same kind of
configuration
It might help if I include the link
[1]
http://lucazamador.wordpress.com/2010/05/27/drools-server-spring-configuration/
On 12/10/12 09:01, Shane Bryzak wrote:
I think we have to support creation of new beans. Take a look at [1],
which is a blog post on configuring Drools within Spring
/confluence/display/DeltaSpike/Drafts
On 18/09/12 09:06, Jason Porter wrote:
That works for me, shall we start a new thread or continue with this one?
On Mon, Sep 17, 2012 at 4:40 PM, Shane Bryzak sbry...@redhat.com
mailto:sbry...@redhat.com wrote:
I think we need to take a step back
Oh, and just to be clear I think we should by all means discuss the
required features on the mailing list first, we just need to ensure that
any features we agree upon are collated on the wiki.
On 18/09/12 18:07, Shane Bryzak wrote:
I think that a more formal list like we had on the wiki
I think we need to take a step back and define some requirements. One
that I'm aware of is the ability to wire up beans, something that Drools
(in particular, though this is a generally useful feature) needs to be
able to provide proper CDI support.
On 18/09/12 07:17, Jason Porter wrote:
I had a quick chat with Pete and Jason and they brought me up to speed.
After much consideration I think the best way to proceed would be 4.b),
with the more complex features such as IDM and permission management
handled external to DS.
On 27/07/12 08:41, Mark Struberg wrote:
Oki, here we
] - Documentation
T he answer to both these questions really that the CMS creates
websites, some details on that below
I'll note that the CMS is svn based -- maybe undesirable given the use of
git.
On Jul 24, 2012, at 4:54 PM, Shane Bryzak wrote:
Does the choice of Apache CMS for hosting documentation
On 26/07/12 06:29, Jason Porter wrote:
I'll do a separate email for impl review / feedback
== Security Feedback ==
=== API ===
* SecurityConfigurationException has no args constructor and also one with
just a throwable, should we remove these? Same with SecurityException.
Yep, you're
I'd like to re-open the discussion on documentation format, as there
seems to have been a decision slip through the cracks on this that many
of us missed. My greatest concern is that the selected tool needs to
meet the requirements stated in DELTASPIKE-13 [1]. Does the choice of
Apache CMS
In Solder we had a Property Query feature which allowed you to specify
certain criteria for scanning class properties. I've ported this into
the security prototype for the time being [1] and it will probably end
up getting moved into DeltaSpike core. Usage is pretty straight forward:
We're hardly starting from scratch, much of the DeltaSpike security
design is an improved re-visiting of Seam Security, which has been
actively developed and improved for a number of years. I've also taken
a look at Shiro and while it has many cool features, it also seems to be
missing some
module into
idm and non-idm jars/submodules?
On Mon, Jul 9, 2012 at 2:24 AM, Boleslaw Dawidowicz
boleslaw.dawidow...@gmail.com wrote:
On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
As far as Identity Management related features are concerned, I've
purposefully kept that separate except
Hi all,
I've put together a list of many of the changes I've made to the
security module in relation to authorization, specifically Permissions
and Permission Management. You can find a prototype with these changes
in my github repo here:
https://github.com/sbryzak/DeltaSpike/tree/security
On 02/07/12 16:42, Mark Struberg wrote:
Hi!
What about planing a release in ~2 weeks?
We shall do a review of the new/existing parts and cleanup stuff we know to not
be perfect.
* JPA module. We had a few discussions about how to split those functionality
and if we shall add new features
Fantastic idea, +1.
On 27/06/12 05:39, Jason Porter wrote:
Hey everyone!
I wanted to bring up the idea of having a sandbox to add bits and
other non-core extensions. We have a great bunch of people from the
Seam development group looking to add their extensions, but they're
either not on
+1, with the proviso that we have the option of adding it later. One of
the use cases for this is Remoting (invoking server-side beans from
JavaScript) which does a lot of type conversion.
On 14/06/12 14:44, Mark Struberg wrote:
a.) What is this for? - no one knows
b.) Do we need it in
of pagination. The idea that appeals to me the most would be to
implement a Query API similar to what Bolek has proposed for IDM, except
for permissions. This would allow us much greater flexibility and allow
us to support pagination, etc.
Thanks,
Marek
On 23.4.2012 11:56, Shane Bryzak
:
ListPermission listPermissions(Object resource, Identity String
operation, int offset, int pageSize);
Thanks,
Marek
On 23.4.2012 11:56, Shane Bryzak wrote:
Following up to the recent outline of object permissions, I'd like
to continue with a description of the permission management API.
At the centre
On 24/04/12 20:19, Marek Posolda wrote:
On 24.4.2012 11:17, Boleslaw Dawidowicz wrote:
On Apr 24, 2012, at 10:56 AM, Marek Posolda wrote:
3) Another potentially missing thing is pagination. I assume that we
can have thousands of users in DB and thousands of resource objects,
which in next
On 23/04/12 18:03, Marek Posolda wrote:
Hi all,
On 22.4.2012 19:27, Christian Kaltepoth wrote:
I prefer the method signature Shane suggested in his initial mail.
Providing a single method with an object parameter makes most sense to
me:
Identity.hasPermission(Object resource, String
Following up to the recent outline of object permissions, I'd like to
continue with a description of the permission management API.
At the centre of this API is the PermissionManager bean. This bean
provides all of the operations required to grant, deny and query object
permissions. Here's
One of the missing pieces from the current discussion on the
Authorization API is the identity model. At present we have a very
simplistic User class, however we still need to add support for Group
and Role. My recommendation for this is to base it roughly on the
design of the PicketLink
On 23/04/12 20:51, Gerhard Petracek wrote:
hi shane,
imo we just need a solution for your @CheckPermission example.
e.g. a custom annotation which can use the custom Operation (e.g. the
custom enum) directly. the custom annotation would be meta-annotated with a
marker annotation.
The issue
On 19/04/12 20:15, Marek Posolda wrote:
On 19.4.2012 00:56, Shane Bryzak wrote:
On 19/04/12 08:03, Marek Posolda wrote:
Hi all,
I am Marek Posolda and i am working on GateIn portal project
together wth Bolek Dawidowicz. Some of my notes inline:
On 18.4.2012 00:52, Shane Bryzak wrote:
I'd
On 19/04/12 06:35, Bruno Oliveira wrote:
On Tue, Apr 17, 2012 at 7:52 PM, Shane Bryzaksbry...@redhat.com wrote:
I'd like to kick off a discussion around the Authorization API,
specifically object permissions. This API is used to determine whether the
currently authenticated user has the
On 19/04/12 08:03, Marek Posolda wrote:
Hi all,
I am Marek Posolda and i am working on GateIn portal project together
wth Bolek Dawidowicz. Some of my notes inline:
On 18.4.2012 00:52, Shane Bryzak wrote:
I'd like to kick off a discussion around the Authorization API,
specifically object
+1
On 16/04/12 06:30, Mark Struberg wrote:
Hi folks, I'd like to call a VOTE on releasing Apache DeltaSpike
0.2-incubating. The Maven staging repository:
https://repository.apache.org/content/repositories/orgapachedeltaspike-051/
Source release:
my suggestion above.
regards,
gerhard
2012/3/26 Pete Muirpm...@redhat.com
On 25 Mar 2012, at 22:03, Shane Bryzak wrote:
On 25/03/12 09:09, Gerhard Petracek wrote:
hi shane,
@ #1#2:
i'm ok with it -please provide a concrete suggestion for #1
As I said previously I think
2012, at 22:03, Shane Bryzak wrote:
On 25/03/12 09:09, Gerhard Petracek wrote:
hi shane,
@ #1 #2:
i'm ok with it - please provide a concrete suggestion for #1
As I said previously I think that Identity should be in the base
package, i.e. org.apache.deltaspike
in the IDM API between all roles (including session ones) and
persisted roles (identity store level).
Bolek
On Mar 5, 2012, at 11:45 PM, Shane Bryzak wrote:
Ok I've been thinking about this over the last few days (and come up
with a number of solutions I wasn't happy with), however there is one idea
means auditing can be performed all in
one class.
On 02/03/12 06:41, Boleslaw Dawidowicz wrote:
On Feb 29, 2012, at 10:25 PM, Shane Bryzak wrote:
currently i'm thinking about the dis-/advantages of moving those methods to
User (or something like AuthenticatedUser)
I think this would create
most of the Authenticator methods and simply allows the subclass to invoke
setStatus / setUser / addGroup etc to set the user's authentication state.
On 29/02/12 08:15, Shane Bryzak wrote:
With the basic implementation of Identity now in place, it's now a good
time to discuss authentication
With the basic implementation of Identity now in place, it's now a good
time to discuss authentication. The authentication API comes into play
during the user authentication process, and is responsible for ensuring
that the user is who they claim to be, and providing the application
with the
that implements
most of the Authenticator methods and simply allows the subclass to
invoke setStatus / setUser / addGroup etc to set the user's
authentication state.
On 29/02/12 08:15, Shane Bryzak wrote:
With the basic implementation of Identity now in place, it's now a
good time to discuss
All taken care of now.
On 22/02/12 16:27, Gerhard Petracek wrote:
hi @ all,
i had to revert 1177d4a7fd3e669eb84ce3987368d5ceaebfeb6a because shane
didn't add
Submitted on behalf of a third-part: Red Hat, Inc. under the terms of the
ALv2
to the commit message of the initial import.
On 13/02/12 19:47, Boleslaw Dawidowicz wrote:
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
Some particular points to review:
1. Should we attempt to use the security classes provided by Java SE, such as
Principal, Subject, etc or use our own User API - this will affect what is
returned
On 13/02/12 18:15, Rudy De Busscher wrote:
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an
#login
uses string as return type instead of an enum.
ingeneral: we should define a general rule for the usage of exceptions
which should be used by most deltaspike apis.
This method returns a String to make it easy to write navigation rules for
JSF. The three possible values are
Reporter: Shane Bryzak
Assignee: Gerhard Petracek
We need to discuss and review the various bits that make up the security API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org
review and discuss Authentication API
-
Key: DELTASPIKE-78
URL: https://issues.apache.org/jira/browse/DELTASPIKE-78
Project: DeltaSpike
Issue Type: Sub-task
Reporter: Shane Bryzak
Reporter: Shane Bryzak
Assignee: Gerhard Petracek
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see
review and discuss Authorization API
Key: DELTASPIKE-79
URL: https://issues.apache.org/jira/browse/DELTASPIKE-79
Project: DeltaSpike
Issue Type: Sub-task
Reporter: Shane Bryzak
[
https://issues.apache.org/jira/browse/DELTASPIKE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Bryzak reassigned DELTASPIKE-78:
--
Assignee: Shane Bryzak (was: Gerhard Petracek)
review and discuss
review and discuss external authentication
--
Key: DELTASPIKE-82
URL: https://issues.apache.org/jira/browse/DELTASPIKE-82
Project: DeltaSpike
Issue Type: Sub-task
Reporter: Shane Bryzak
[
https://issues.apache.org/jira/browse/DELTASPIKE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Bryzak reassigned DELTASPIKE-79:
--
Assignee: Shane Bryzak (was: Gerhard Petracek)
review and discuss
[
https://issues.apache.org/jira/browse/DELTASPIKE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Bryzak reassigned DELTASPIKE-80:
--
Assignee: Shane Bryzak (was: Gerhard Petracek)
review and discuss built
[
https://issues.apache.org/jira/browse/DELTASPIKE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Bryzak reassigned DELTASPIKE-76:
--
Assignee: Shane Bryzak (was: Gerhard Petracek)
Discuss and review security
I've created an umbrella issue to track the work we do on the security
module [1], and the first task is to review and discuss the Identity
API. This API forms the core of the security module, and all other
features build on top of it to implement a complete security framework.
The Identity
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:sbry...@redhat.com]
Gesendet: Dienstag, 31. Januar 2012 22:48
An: deltaspike-dev
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:sbry
[
https://issues.apache.org/jira/browse/DELTASPIKE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196852#comment-13196852
]
Shane Bryzak commented on DELTASPIKE-64:
In Seam Security we have a system
Oops, I posted my respone on the JIRA issue - copying to this thread
instead:
In Seam Security we have a system of typesafe security annotations.
Essentially, it's up to the developer to create the annotations required for
the authorization checks in their application. The security binding
into the
@Secures method?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Shane Bryzak [mailto:sbry...@redhat.com]
Gesendet: Dienstag, 31. Januar 2012 13:25
An: deltaspike-dev@incubator.apache.org
Cc: Gerhard Petracek
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Oops, I posted my
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
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() ||
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
Nachricht-
Von: Shane Bryzak [mailto:sbry...@redhat.com]
Gesendet: Montag, 30. Januar 2012 13:15
An: deltaspike-dev@incubator.apache.org
Cc: Gerhard Petracek
Betreff: Re: supporting different approaches,...
On 30/01/12 18:57, Gerhard Petracek wrote:
hi @ all,
as discussed at [1] the current
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.)
imo with v0.2 we should start working on multiple
+1
On Sun, Dec 18, 2011 at 10:58 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
Hi,
I asked [1] to add alternative settings to DELTASPIKE-12, since we have
seen several different opinions (about details).
Nobody added an alternative set. So I start the formal vote with the
sbryzak
On Tue, Dec 13, 2011 at 6:15 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
short addition:
@all initial committers:
please send your jira-username.
regards,
gerhard
2011/12/12 Gerhard Petracek gpetra...@apache.org
hi @ all,
i've created a jira project [1] for
66 matches
Mail list logo
