I actually like it not using CDI/EJB as it should be simpler to create a wildfly subsystem
for it, if it ever comes to that?
What about using a ThreadLocal for the KeycloakSession, then close it in a servlet filter.
Something like this:
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 2 August, 2013 12:47:37 PM
Subject: Re: [keycloak-dev] latest commits and next steps
On 8/2/2013 4:41 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 2 August, 2013 12:33:05 AM
>> Subject: [keycloak-dev] latest commits and next steps
>>
>> I had to refactor my code a bit to support Picketlink 2.5.Beta6 and the
>> picketlink abstraction we have. So you may have issues when you merge.
>> Another thing I had to do was disable all of your modules because it
>> depended on an earlier version of Picketlink. I would have fixed your
>> code, but I'm not sure what you're doing with it, or if it will just be
>> deprecated and removed as we move forward.
>
> No problem, I'll sort it out. Social should definitively be a separate
> module, in fact I'd like there to be one social module, then one separate
> module per social site we integrate (social, social-facebook,
> social-twitter, etc.). There's quite a lot of stuff in UI, and this could
> also be deployed separately, so it makes sense to leave that as a separate
> module. Sdk-html I'm not 100% sure about, maybe we can leave it as a
> separate module until it's closer to finished then see whether or not it
> would make sense to merge it into services.
>
I don't doubt you'd need separate modules.
>>
>> Do you mind if I hook your UI into the services I wrote? I'd really
>> like to get a better hold on angular and this would be a good task for
>> me to do. Do you have enough work that wouldn't conflict with this
>> work? I'll have to expand my REST interfaces and refactor your code a
>> bit too. I'd probably just copy it.
>
> Feel free. BTW if you're very fresh to Angular I'd highly recommend going
> through the tutorial on the website (
http://docs.angularjs.org/tutorial).
> My plan was going to finish the social stuff, then start doing the
> login/registration forms. We also need a JavaScript SDK. At the very least
> it has to be able to parse/validate the bearer token.
>
Ya, I skimmed the tutorial and walked through eventjuggler code a few
weeks ago and got a good idea.
> What code are you talking about refactoring? If you're referring to the UI
> REST endpoints, those where really intended as throw-away, so you can do
> whatever you want with that.
>
The REST endpoints and will probably have to add to refactor the admin
UI too.
BTW, eventually we might also want to introduce EJBs/CDI to at least
manage the persistence session/transactions. I couldn't do it with
JAX-RS filters because response filters aren't run after a resource
locator is invoked, nor are do they run if a servlet forward has been
done. Instead I've been using the old inner-class wrapper pattern.
Honestly its much easier and faster to test code this way. Arquillian
is a beast, IMO, but this inner class approach is error prone.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com