deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boleslaw Dawidowicz <>
Subject Re: Early security IDM prototype feedback
Date Sun, 01 Jul 2012 15:43:28 GMT
I think it all comes down (again) to use cases [0] which we think this API should address.
Current ones are mainly around typical web application development and proposed API prototype
was focusing on easy usage. My main fear is to go end up with too abstract and generic design
that won't be really appealing to most of developers. If you look at use cases addressed by
JSR 351 [1] it is all about dealing with attributes and scenarios closer to healthcare - and
this so far results in quite different API design. API which I believe will be less appealing
to typical web developer who doesn't care about such use cases.  

More inline below


On Jun 29, 2012, at 4:56 PM, Jason Porter wrote:

> == 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 guess thats a bit matter of taste. We could prepare quick prototype and compare which one
looks more useful to majority of folks here.

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

Would you have time to prepare some simple prototype like this to discuss? I'm not sure how
much generic design are you proposing in fact. Just some bare code snippets would do to back
your suggestions with some example usage.

UserQuery is not something I'm perfectly satisfied with however it is still an attempt to
have something similar to JPA Criteria Query - which is very intuitive and easy to use IMO.
I would love to see more feedback from others on how to improve this part in fact. 

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

Good point. I think this part is simply not really polished yet.

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

Sounds good to me. Again this is probably more matter of taste and consistency with other
APIs in the project. Maybe there should be some general project wide design guideline for
choices like this. 

> -- 
> Jason Porter
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
> PGP key id: 926CCFF5
> PGP key available at:,

View raw message