[keycloak-dev] examples/distro reworked/improved/finalized PLEASE TRY!

[Marek Posolda]

On 10.1.2014 17:05, Bill Burke wrote:
>
>
> On 1/10/2014 10:27 AM, Marek Posolda wrote:
>> On 10.1.2014 15:23, Bill Burke wrote:
>>>
>>>
>>> On 1/10/2014 5:51 AM, Marek Posolda wrote:
>>>> Just a small note that there is a typo in
>>>> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md 
>>>>
>>>>
>>>> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" 
>>>> when
>>>> currently it talks about "keycloak-as7-adapter-dist.zip" .
>>>>
>>>
>>> Good catch.
>>>
>>>> Another possible good thing would be to have "quickstart" appliance 
>>>> for
>>>> everything bundled in single ZIP (wildfly server with auth-server,
>>>> datasource, adapters, test-realm installed and all examples deployed).
>>>> This will enable possibility for users to start really quickly playing
>>>> with Keycloak without need to import realm in admin-console and
>>>> build/deploy examples with maven. Of course, this may not be 
>>>> possible if
>>>> examples will be moved to separate repo.
>>>>
>>>
>>> That's a *REALLY* good idea.  I'll do that.
>>>
>>> BTW, not sure about your addition to CDI yet to one of the examples.
>>> We will be trimming down the Wildfly distro in the near future and CDI
>>> will be one of the subsystems that will be removed.
>> oops, I did it this way as you asked for it:-) You mentioned CDI or
>> Spring in another thread.
>>
>
> I didn't think it all the way through, its my fault.  We can re-use 
> the file configuration stuff though you did.
np, good that we clarify how to do it. So I will try to update my PR by 
Monday and will update both as7 and wildfly examples. Hope that 3rd 
attempt will be successful:-)
>
>> So not sure what to do? I am seeing options like:
>> - Left the original "third-party" example and convert my stuff into
>> something like "third-party-cdi" example. This example won't be part of
>> WildFly appliance distribution, but IMO it can be just in WAR
>> distribution as this is used for people, who want to add examples into
>> their own AS7/Wildfly and so we can assume that it will be full
>> AS7/Wildfly with support of CDI and JSF.
>
> That works.
>
>> - Example won't be part of keycloak codebase, but it will be in separate
>> repo. This assumes that we will have separate repo with
>> examples/quickstarts as suggested by Stian in another mail.
>>
>
> Not sure about a separate repo for examples.  Examples tend to change 
> and evolve as you do more releases so you'll want to bind them to a 
> particular release of keycloak.  Also requires an extra step from the 
> user to go to github and get them.  I also liked your idea of having 
> the demo pre-configured into the appliance so you can just run the 
> demo out of the box.
yup, quickstart appliance seems to be good advantage. On the other it 
has disadvantages as well. Approach with quickstarts used for some other 
projects like JBossAS/JDF/GateIn showed us that separate branch could 
work. People, who want to try examples and look at source code, won't 
need to clone whole Keycloak project but just examples. They can of 
course download ZIP distribution with examples, but still some may 
prefer to directly clone from github. It can also simplify IDE support.

In GateIn we have few very simple examples (like hello-world portlets), 
which are part of GateIn portal itself and for more "advanced" things we 
have separate repo with quickstarts. Maybe we can have something 
similar? On the other hand, Keycloak is a bit specific as there are some 
differences between AS7 and Wildfly examples, but this can be handled 
with 2 example branches (one for as7 and one for wildfly).  Which could 
simplify things in the end as you will just need to update "wildfly" 
branch and then use the same stuff for "as7" and just cherry-pick one 
commit, which will contain differences between as7 and wildfly examples 
(It seems to me that only difference is name of adapter module in 
jboss-deployment-structure.xml).

Still not sure what is best, just throwing out possible 
advantages/disadvantages...

For now, I will use "third-party-cdi" directly as part of keycloak.
>
>> So only thing to change in original "third-party" example will be the
>> addition of JSON configuration, instead of hard-coded stuff in the code.
>> But there will be still ServletOAuthClient kept as attribute of
>> ServletContext. WDYT?
>>
>
> Or you could just rebuild ServletOAuthClient with every request and 
> get rid of the Listener etc.
hmm... but isn't that expensive? As start of ServletOAuthClient would 
require reading config and bootstrap of underlying HttpClient. Probably 
not good approach to do this in every request?

Marek
>
> Bill
>