7 Replies Latest reply: Feb 18, 2011 11:20 AM by Boleslaw Dawidowicz RSS

IDM Feedback

Anil Saldhana Master

Bolek,  I am going to list some things on mind wrt IDM.

 

I am currently playing with the Branch_2_0 as you know.  So if you make any serious code bug fixes, do ping me, so I can sync into the branch.

Things on my mind:

  1. We need to provide one repository  (call it  IDMRepository)  where the user can configure a number of stores such as hibernate, ldap etc.  I don;t think the name Fallbackrepo is suitable.  You can have IDMRepository extend FallbackR with no content.
  2. Javadocs for the classes.  At least want to know what the class is supposed to do.
  3. One or more factories.  I will be introducing this in my branch. Once complete, will show it to you.
  • 1. IDM Feedback
    Anil Saldhana Master

    Bolek,  I just created a very rudimentary version of Memory based Identity Store.

    http://viewvc.jboss.org/cgi-bin/viewvc.cgi/picketlink?view=revision&revision=752

     

    Feedback welcome.

  • 2. IDM Feedback
    Boleslaw Dawidowicz Master

    Anil Saldhana wrote:

     

    I am currently playing with the Branch_2_0 as you know.  So if you make any serious code bug fixes, do ping me, so I can sync into the branch.

     

    Well I'm doing some refactorings in trunk (currently marked as 1.3.x) and Sohil started some work on configuration improvements - simplifications for major usecases but full backward compatibility.You should just work in Branch_2_0 and we merge your work later into trunk which can become true 2_0 then. For EPP I need to guard some backward compatibility on the hibernate db schema level, LDAP features and for configuration. I have also some partial work commited in trunk around support for many LDAP stores keeping USER objects which is not possible because of current design. This requires minor SPI changes and slight rewrite of Fallback repo. Go on with your work in Branch_2_0 and later we'll sync and merge.

     

    Anil Saldhana wrote:

     

    1. We need to provide one repository  (call it  IDMRepository)  where the user can configure a number of stores such as hibernate, ldap etc.  I don;t think the name Fallbackrepo is suitable.  You can have IDMRepository extend FallbackR with no content.

     

    FallbackIdentityStoreRepository is exactly such thing. Could you explain the extend part? In fallback the key is one "default" store that supports all features and can sync stuff between other stores with lesser capabilities.

     

    Anil Saldhana wrote:

     

    1. Javadocs for the classes.  At least want to know what the class is supposed to do.
    2. One or more factories.  I will be introducing this in my branch. Once complete, will show it to you.

    Yeah... some core impl classes need more love in this area Agreed.

  • 3. IDM Feedback
    Boleslaw Dawidowicz Master

    Anil Saldhana wrote:

     

    Bolek,  I just created a very rudimentary version of Memory based Identity Store.

    http://viewvc.jboss.org/cgi-bin/viewvc.cgi/picketlink?view=revision&revision=752

     

    Feedback welcome.

     

    Good idea about memory store. As a side note we should also rework stores implementations a bit to have AbstractIdentityStore which would  ease implementing this part of SPI.

  • 4. IDM Feedback
    Boleslaw Dawidowicz Master

    Actually for the Branch_2_0 and trunk it would be good to discuss and merge your work into trunk on regular bases so we keep in sync. I just need one or two more weeks to reshape it a bit.

  • 5. IDM Feedback
    Boleslaw Dawidowicz Master

    Anil, forgot to add in previous post. Could you put the "memory store" as a separate maven module depending on picketlink-idm-core? Just like hibernate and ldap ones. 

  • 6. IDM Feedback
    Anil Saldhana Master

    There is no harm in the memory module residing in the core as it just depends on the JDK and has no external library dependencies. Having too many maven modules in the project is a recipe for confusion.

  • 7. IDM Feedback
    Boleslaw Dawidowicz Master

    True, but having some in core and some outside can also be confusing. We can agree later on keeping stuff like memory and file system stores as part of core but for now for development, refactorings and merges it would be cleaner to have them separated.