[keycloak-dev] latest commits and next steps

[Bill Burke]

On 8/2/2013 4:41 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at 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