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 <mailto:sbryzak@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 <mailto:security-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/security-dev