Looking at the code of https://github.com/keycloak/keycloak/blob/master/integration/undertow/src/main/java/org/keycloak/adapters/undertow/KeycloakServletExtension.java

i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http.
It can stay as is for subsystem stuff.

Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*)
as there will be no servlet requests coming that way.

In short I think just moving some code around and modifying few classes we could get rid of many dependancies.



On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert <ssilvert@redhat.com> wrote:
On 7/1/2014 8:49 AM, Stuart Douglas wrote:
>
>
> Stan Silvert wrote:
>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:
>>> It really sounds like this should not be part of core, but should be
>>> something extra that just integrates with the core.
>> That may be true, but it's not a decision that should depend on how many
>> modules must be added.
>>
>> The central question is, do we want Keycloak to work out of the box?
>> Before this issue was known, everyone answered "yes".
>>
>> Should we really determine our feature set based on how many modules it
>> requires? I don't think we want do that, which is why I'm having doubts
>> about the current approach.
>
> This has nothing to do with 'working out of the box', e.g. Servlet and
> EJB will 'work out of the box', as long as you pick a distribution
> that includes them.
I understand.  Perhaps I should have said, 'working out of the box on
core'.  domain-http is currently in core, which is what I'm talking
about here.
>
>
>
>
>>
>>>
>>> In all honesty we are highly unlikely to ever have accepted a PR that
>>> added all these dependencies to the core in any case, so it is a
>>> problem that would have had to be solved at some point anyway.
>>>
>>> Stuart
>>>
>>> Stan Silvert wrote:
>>>> I'm starting to have doubts about this split.
>>>>
>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter
>>>> into build-core so that the web console can use Keycloak for
>>>> authentication. The problem is that there is a huge web of
>>>> dependencies
>>>> that must be moved over from build to build-core.
>>>>
>>>> What exactly is the split trying to solve?
>>>>
>>>> Stan
>>>>
>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
>>>>> Hi all,
>>>>>
>>>>> So I am moderately confident that we will be ready to split out
>>>>> Wildfly
>>>>> core into a separate repository early next week (I'm not saying
>>>>> that it
>>>>> will definitely happen in this time frame, just that it should be
>>>>> possible).
>>>>>
>>>>> Once this is ready to go I think the basic process will be:
>>>>>
>>>>> - Code freeze on Master
>>>>> - Create the core repo, push new rewritten core history
>>>>> - Release core 1.0.0.Beta1
>>>>> - Create PR against core WF repo that deletes everything in core, and
>>>>> uses the core 1.0.0.Beta1 release
>>>>> - End of code freeze
>>>>>
>>>>> Stuart
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev