Re: LDAP Annotation and Database Hashing Proposal

Will Hopkins

Not sure I care that much about the details of the implementation, although I'm starting to feel like CDI for this use case may be making things more complicated, not less, relative to simply newing up an instance of the type specified in the hashAlgorithm attribute and passing hashProperties to the constructor ...

What I think I'd like to see in terms of behavior is:
  • Hash algorithm and hash properties can be specified on the annotation.
  • Multiple instances of the annotation/idstore -- is that supported? -- could specify different hash algorithms, or, they could specify the same algorithm type, but different properties.
  • At runtime, each identity store instance gets its own instance of the hash algorithm type, even if other identity store instances are using the same hash algorithm.
  • The hash algorithm is initialized onced, up front, with the configured properties.
It's possible to make an argument for deferred evaluation of properties, etc., but that complicates things considerably and I think doing only the above provides plenty of flexibility. An implementation of HashAlgorithm could certainly do its own deferred evaluation internally.

My $0.02 (or maybe $2.00).


On 07/24/2017 08:41 AM, Arjan Tijms wrote:

On Mon, Jul 24, 2017 at 2:21 PM, Will Hopkins <will.hopkins@...> wrote:
>The one in the annotation is basically the base version of that. The
>producer could be dependent scoped indeed.

Not sure I follow what you mean.

Sorry, I meant the data that directly comes from the annotation instance and is converted into a Map here:

(ps, that's also an example showing the static import of unmodifiableMap)

I think the value of having it dependent scoped is that there could be more than one instance, each configured with different parameters. For any given instance, the parameters would never change, but if you had multiple identity stores, each one could have an instance of the algorithm that was configured differently, even if they all used the same algorithm. If it was application scoped, then every identity store in the app that wanted to use the same algorithm would have to use the same instance, and therefore the same parameters.

For the injection it would need an extra qualifier to get the right version of the parameters, which is indeed one of the extra complications. Since qualifier annotation attribute values can be binding, these qualifiers can be created more or less dynamically. I think it should be doable, but it's not super trivial.

Kind regards,
Arjan Tijms

Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Join to automatically receive all group messages.