Hi,
I'm not 100% sure yet. How is it really different from
@DataSourceDefinition?
A bit of the issue is that Java EE has problems scaling down, because it
historically has been holding the hands of the developers a bit too much.
I.e. having your services in a separate module and giving them an interface
was seen as a best practice, so EJB mandated this.
Reading files was seen as bad, so EJB prohibited this.
But all of that was seen as heavy and cumbersome, so developers avoided EJB
and used "lighter" alternatives. Then in EJB 3.1 and 3.2 these restrictions
were lifted.
The EmbeddedIdentityStoreDefinition is already used by people for demos
(including by my friend Rudy :P), because it's simply much easier to setup
than a database version, let alone an LDAP store.
The proposal for the EmbeddedIdentityStoreDefinition came from Reza Rahman,
so perhaps it's best if he could comment here.
Kind regards,
Arjan Tijms
On Thu, Feb 23, 2017 at 7:46 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> I agree that we should move the
>
> EmbeddedIdentityStoreDefinition
>
> To the Soteria implementation (not part of the spec itself) as it is not
> something that we should promote from the EG.
>
> Best regards
>
> Rudy
>
>
>
> On 21 February 2017 at 16:09, Brian Demers <brian.demers_at_gmail.com> wrote:
>
>> 2.7 Build-in Identity Store Beans
>>>>
>>>> - Embedded -- annotation only? No support for deploying a file or
>>>> other mechanism? Safety of embedding passwords in file or in code
>>>> (annotation)?
>>>>
>>>>
>>> Good points! For the moment it's annotation only, but files are indeed
>>> very common (I put some examples of those here: https://dzone.com/refcar
>>> dz/getting-started-java-ee).
>>>
>>> It should indeed be made abundantly clear that the annotation is
>>> intended for testing / demo purposes, and not normally suited for
>>> production usage.
>>>
>>>
>>> Agreed.
>>>
>>
>> I disagree, I think these should be removed, anything that can be used
>> will be used. This would force other implementations to _support_ these
>> annotations, which seems superficial (only used for demos), and a bad
>> idea. I personally think, if this annotation is to be kept at all it
>> should be moved into a different package (org.glassfish.soteria).
>>
>> Embedding passwords in code like this (which I'm sure would be posted in
>> blogs and forums) will shine a bad light onto this effort, and the results
>> will be negative, and thus hurt adoption.
>>
>
>