>
> but it is not the core task of the EG to ensure every container or
> framework out there supports it as Arjan said.
I Agree, and like Arjan said, we shouldn't make compatibility a core
requirement.
But since there are a lot of frameworks out there today performing
security, and probably most of the developers are using them (instead of
the standards of today), it will ease the adaption if our API can be
integrated in those frameworks.
And that was the main goal of my example, that the IdentityStore can be
integrated due to the CDI nature of it.
Rudy
On 29 December 2015 at 09:50, Werner Keil <werner.keil_at_gmail.com> wrote:
> All,
>
> I guess aside from simply keeping those kinds of 3rd party examples or PoC
> projects in everybody's seperate repositories, we could imagine something
> along the lines of what JSR 354 did in "Shelter"
> https://github.com/JavaMoney/javamoney-shelter
>
> It was meant to foster initiatives like "Adopt a JSR" (hence the name) but
> is not restricted to JUGs or their members adopting the JSR. If David and
> Alex think, something similar (under whatever name, at the moment
> "proposals" is also more or less a "sandbox" but it's for the actual JSR
> components themselves) was a good idea to have in the GitHub organization,
> I'm sure, they should be able to create something. Similar to using some or
> all aspects of certain JSRs Spring may or will use this JSR sooner or later
> (to become "somewhat compatible;-) but it is not the core task of the EG to
> ensure every container or framework out there supports it as Arjan said.
>
> Kind Regards,
> Werner
>
> On Tue, Dec 29, 2015 at 1:07 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi Rudy,
>>
>> Thanks for the effort you put in that example.
>>
>> The identity store proposal should indeed be usable by many technologies,
>> since it really only defines the {credential in -> name/groups out}
>> function. Like a (generic) DAO interface, it doesn't itself have much
>> dependencies.
>>
>> On the other hand, I think we should watch out that "should be usable
>> outside EE, should be usable by Spring, Shiro, what have you" doesn't
>> become a core requirement. The problem is that wanting to be everything for
>> everyone is what too often has made designs too abstract and too
>> complicated.
>>
>> So IMHO this JSR should first and foremost make security easier and more
>> straightforward to use in Java EE.
>>
>> But that said, nice example that you provided ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 28, 2015 at 11:55 AM, Rudy De Busscher <rdebusscher_at_gmail.com
>> > wrote:
>>
>>> Hi all,
>>>
>>> I think an important aspect of the work we do, is that it is
>>> compatible/can be used in existing 3th party security libraries.
>>> Because a lot of developers are using them today and if the security
>>> library is integrating the JSR375 code, the adoption will be
>>> faster/smoother/better/....
>>>
>>> Therefore, I tried the integration between *Octopus* (the Java EE
>>> security framework that I have developed over the last few years) and the *Identity
>>> store proposal Arjan made* (
>>> https://github.com/arjantijms/mechanism-to-store-x)
>>>
>>> I used the jsr375 module and wrote a *CredentialsMatcher* that uses the
>>> *IdentityStore* defined by a definition annotation (in the example the
>>> embedded one but any definition will work)
>>>
>>> The result can be seen in this repostory
>>> https://github.com/rdebusscher/octopus-jsr375 (starterEE7 module)
>>>
>>> It works like a charm, of course due to the CDI nature of the
>>> IdentityStore. :)
>>> The code is quit generic, so I can create in the future a specific maven
>>> artifact for the integration with the IdentityStore.
>>>
>>> Since the CredentialsMatcher is only depending on *Apache Shiro* (and
>>> not Octopus), also Apache Shiro can make use of the IdentityStore.
>>>
>>> Best regards
>>> Rudy
>>>
>>>
>>>
>>>
>>
>