Thanks for your kind comments towards this design decision :)
Just curious - in 1.x I made it partly to have single instance of IdentityStore reused in
different context/realm - so purely stateless design. Do you plan the same way or still
handle some state in single IdentityStore instance?
On Oct 25, 2012, at 5:33 AM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Just to add to the previous changes, I've also made a change to
the IdentityStore API so that each method includes an IdentityStoreInvocationContext
parameter. This API was first introduced by Bolek in PicketLink 1.x [1] and offers a
robust method of passing context-specific state to individual IdentityStore invocations.
I can't think of any more elegant design that addresses this requirement or improves
on the work Bolek has already done, so beyond any minor tweaks to the API I think we
should stick with the motto "if it ain't broke, don't fix it".
I've gone ahead and updated both (JPA and LDAP) IdentityStore implementations to
include these parameters. Along the way though, it seems I've broken a couple of the
LDAP tests; Pedro or Anil, could you please take a look at these as my LDAP is a little
rusty - I've attached the stack trace output from the test run.
[1]
https://github.com/picketlink/picketlink-idm/tree/1.4/picketlink-idm-spi/...
<org.picketlink.test.idm.internal.mgr.DefaultLDAPIdentityManagerTestCase.txt>_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev