[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