toggle quoted messageShow quoted text
I think application scoped with non-deferred expressions would work most of the time and it's simpler to understand and explain.
Even being application scoped, the container can create an instance for each one by using a custom qualifier (that could be an implementation detail).
Guillermo González de Agüero
On July 24, 2017 7:52:22 AM EDT, arjan tijms <arjan.tijms@...> wrote:
>On Mon, Jul 24, 2017 at 1:40 PM, Will Hopkins <will.hopkins@...>
>> Could we specify that it's not normal scoped, and inject a new
>> that we remember and use for the lifetime of the process?
>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.
>> There's really no need for this to be fancy, it's a low level crypto
>> operation that will likely always operate one way for the lifetime of
>> given deployment. Doesn't seem like there's a big need for deferred
>> evaluation, etc.
>I'd be okay with that as well, although then we could just as well make
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.
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803