On 10/29/2012 05:22 AM, Boleslaw Dawidowicz wrote:
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?

Exactly the same way, except for the IdentityStore configuration itself.  We'll also use the invocation context to provide the event SPI, acting as a bridge to allow the IdentityStore to raise events for multiple environment types.


On Oct 25, 2012, at 5:33 AM, Shane Bryzak <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/src/main/java/org/picketlink/idm/spi/store
<org.picketlink.test.idm.internal.mgr.DefaultLDAPIdentityManagerTestCase.txt>_______________________________________________
security-dev mailing list
security-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev