[keycloak-dev] WildFly integration (READ ME!)

[Pedro Igor Silva]

>From a product perspective, I think we should focus on WildFly and push for using it as a standalone server.

However, for community I believe we need to be flexible and support different containers. That will allow us to reach a wider audience and collect important feedbacks that will help to improve the project as whole. Here is where innovation really happens ...

----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, February 19, 2015 11:50:03 AM
Subject: Re: [keycloak-dev] WildFly integration (READ ME!)

I think most of the answers to Stian's questions depend on what Keycloak 
is going to be.  In other words, what is our strategy?

If we decide that the auth server is a strictly WildFly-based product 
then the answer will always be "Do it the WildFly way". If we want the 
auth server to run on other containers then we need to be a lot more 
careful about cross-platform compatibility in everything we do.

I don't think the answer is to have a scaled-down version of the auth 
server for other platforms.  It's just too hard to constantly be 
thinking about what is essentially two flavors of our product.

There definitely are advantages to being container agnostic.  But I 
think we need to decide this question and put a stake in the ground as 
soon as possible.  Then the answers will  become clear.


On 2/19/2015 3:32 AM, Stian Thorgersen wrote:
> No comments?!
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>
>> All,
>>
>> We have a few decisions to make in the not so far future. I'm away from
>> Thursday, so let's have a hangout when I get back on the 17th February if
>> that works for everyone.
>>
>> The list of things to discuss includes:
>>
>> * Drop keycloak-server.json - Should we drop our own configuration file and
>> use DMR (standalone.xml)
>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>
>> * Admin operations exposed over DMR - Should we expose none, some or all
>> admin operations over DMR? If we expose all should we deprecate the current
>> REST endpoints?
>>
>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>    - Full WildFly
>>    - Core/web WildFly
>>    - Overlay/installer/feature-pack to install to existing WF and EAP
>>    - WAR bundle
>>
>> * How should we deal with providers, themes and keycloak-server.json in
>> domain-mode
>>
>> * MSC all the way - We can deploy directly through the Undertow sub-system
>> instead of deploying a WAR from the sub-system
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
>>
>> * Deployable to other containers - Should it be possible to deploy Keycloak
>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>> in other containers (for example no client-cert)
>>
>> Please add any other relevant topics.
>>
>> Next big discussion I want to have is about distribution of adapters, but
>> let's do one at a time ;)
>> _______________________________________________
>> 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

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev