Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of lightguard.jp@gmail.com
 designates 209.85.213.41 as permitted sender)
MIME-Version: 1.0
From: Jason Porter <lightguard.jp@gmail.com>
Date: Fri, 29 Jun 2012 10:56:28 -0400
Message-ID: 
 <CAF9TksNLeuSHwNg=50J5hcKe--Sb+AL-5FbQfuQGBDdf30d6FA@mail.gmail.com>
Subject: Early security IDM prototype feedback
To: deltaspike-dev@incubator.apache.org
Cc: Anil Saldhana <asaldhan@redhat.com>
Content-Type: multipart/alternative; boundary=e89a8f234ec15cf5b904c39da8fc

--e89a8f234ec15cf5b904c39da8fc
Content-Type: text/plain; charset=UTF-8

== Security IDM prototype feedback ==

* Fold PermissionQuery into PermissionManager to give the developers a
similar model as JPA.

* Because a Group is an IdentityType, I wonder if it would be better to
just have one set of methods and pass in the IdentityType sub interface you
would like to receive back

* I feel the methods on UserQuery are restricting how the IDM can be used.
We can't always guarantee that there will be a first name, last name,
email, etc. However, being completely open and free form like what was done
in the PicketLink IDM is too much. Perhaps we can find some sort of balance
or meta model similar to JPA?

* Maybe we could have a base no method interface for things and fold all
the Query and Manager objects into one (similar to above about JPA)

* We probably don't want to go down the route of create a query language,
but we almost have a DSL with a fluent API here. Maybe we should think
about about JPA the names out a bit more and actually create a fluent API
for the Query objects

* I believe we should remove some of the exception constructors and make a
message required (this would probably be good to have in all of
DeltaSpike). Adding a cause is great, but being able to create an exception
without a message is less helpful for everyone.

* Is there a point for having addObject and addObjects type methods? Would
one that's simply a varag be enough? We could check the type that comes in
if thy send us a collection, or simply have varags and collection
addObjects methods.


-- 
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

--e89a8f234ec15cf5b904c39da8fc--