[keycloak-dev] Appliance dist and WildFly feature packs

Stan Silvert ssilvert at redhat.com
Tue Sep 16 09:29:03 EDT 2014


On 9/16/2014 8:54 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 16 September, 2014 2:49:46 PM
>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>
>> On 9/16/2014 8:34 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 16 September, 2014 2:20:44 PM
>>>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>>>
>>>> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>>>>> WildFly 9 introduces features packs which seams ideal for us to build
>>>>> Keycloak upon.
>>>>>
>>>>> I'd like to start a "wildfly-9" branch of Keycloak that uses
>>>>> feature-packs
>>>>> and WildFly's built in mechanism to create the appliance distro. This
>>>>> would replace our current custom appliance-dist.
>>>> I'm already working on this and I've found out that we're just a little
>>>> bit early.  See
>>>> http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html
>>> Great :)
>>>
>>> Are you providing this directly in Keycloak, or do you have it somewhere
>>> else?
>> The plan is to have it all live in the Keycloak project.  But perhaps we
>> should talk about whether or not it makes sense as a Keycloak subproject
>> or as just a Maven submodule.
> I'd say it should be a Maven submodule as then we can use it to build our appliance(s)
We can still do that if it is a Keycloak subproject.

The issue is about release schedules.  If it is a Keycloak subproject 
then the feature pack can have its own releases.  This might be 
necessary in order to keep up with changes in WildFly and EAP releases.  
If it is a subproject then we would probably do a feature pack release 
every time we do a Keycloak release.  However, let's say WildFly does a 
release that breaks our feature pack.  We might not be ready to do a 
Keycloak release but we could do a feature pack release to fix the problem.

On the other hand, I'm not sure if it's worth the overhead to have the 
subproject.  Maybe we should start it out as a submodule and move it 
later if needed.
>
>> The Keycloak Feature Pack definitely will not live in WildFly. WildFly
>> itself is breaking up into more and more subprojects.
>>>> We need Stuart to implement a feature to solve issue #2 and I'm working
>>>> on issue #3 right now so that we can properly install the auth server in
>>>> a domain environment.
>>>>> Further I'd like us to have two flavours of Keycloak:
>>>>>
>>>>> * "appliance-lite": minimum Keycloak server only dist. For those that
>>>>> want
>>>>> a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we
>>>>> need to add Hibernate, RestEasy and Connectors (datasources) as well
>>>>> * "appliance": full WildFly dist. For those that want to co-locate their
>>>>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>>>> We need to think long and hard about this one.  Do we really want two
>>>> appliance downloads?
>>> I think we'll want to at least have a standalone Keycloak server. However,
>>> only having that will make it harder for developers and also for anyone
>>> that wants to try our examples.
>> What are you thinking of that will be harder if we only have one appliance?
> If we only provide a standalone Keycloak server dist (built on web-lite) that would mean that developers would have to either have a separate WildFly running to deploy examples and their own JavaEE apps
This is where the provisioning tool might come to our rescue.  I think 
the way it will play out is that we keep the appliance as a 
downloadable, pre-configured, standalone auth server.

If you want to combine an auth server with other services then you use 
the provisioning tool to add Keycloak to your favorite flavor of WildFly.
>
>>>> The answer might come when the WildFly provisioning tool is finished.
>>>> This is a tool that lets you "roll your own" server.  So it's possible
>>>> that we rely on that.   One option might be that we let you download
>>>> "appliance-lite" and then you use the provisioning tool to add other
>>>> things you might want.
>>>>> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and
>>>>> it
>>>>> works fine. Only thing I had to do was to include RestEasy and Hibernate
>>>>> jars in auth-server.war and configure the database directly in
>>>>> keycloak-server.json instead of using a datasource.
>>>> Right now it won't run on the web profile.  I've submitted a patch to
>>>> WildFly, so that should be fixed in the next release.
>>> What doesn't work? It seemed to work fine for me.
>> I thought my patch didn't make it into the release.  I was wrong. False
>> alarm.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>



More information about the keycloak-dev mailing list