<div dir="ltr"><div><div><div><div>Looking at the code of <a href="https://github.com/keycloak/keycloak/blob/master/integration/undertow/src/main/java/org/keycloak/adapters/undertow/KeycloakServletExtension.java">https://github.com/keycloak/keycloak/blob/master/integration/undertow/src/main/java/org/keycloak/adapters/undertow/KeycloakServletExtension.java</a><br>
<br></div>i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http.<br>It can stay as is for subsystem stuff.<br></div><br>Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*) <br>
</div>as there will be no servlet requests coming that way.<br><br></div>In short I think just moving some code around and modifying few classes we could get rid of many dependancies.<br><div><div><div><br></div></div></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 7/1/2014 8:49 AM, Stuart Douglas wrote:<br>
><br>
><br>
> Stan Silvert wrote:<br>
>> On 6/30/2014 10:43 PM, Stuart Douglas wrote:<br>
>>> It really sounds like this should not be part of core, but should be<br>
>>> something extra that just integrates with the core.<br>
>> That may be true, but it's not a decision that should depend on how many<br>
>> modules must be added.<br>
>><br>
>> The central question is, do we want Keycloak to work out of the box?<br>
>> Before this issue was known, everyone answered "yes".<br>
>><br>
>> Should we really determine our feature set based on how many modules it<br>
>> requires? I don't think we want do that, which is why I'm having doubts<br>
>> about the current approach.<br>
><br>
> This has nothing to do with 'working out of the box', e.g. Servlet and<br>
> EJB will 'work out of the box', as long as you pick a distribution<br>
> that includes them.<br>
</div>I understand. Perhaps I should have said, 'working out of the box on<br>
core'. domain-http is currently in core, which is what I'm talking<br>
about here.<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
>><br>
>>><br>
>>> In all honesty we are highly unlikely to ever have accepted a PR that<br>
>>> added all these dependencies to the core in any case, so it is a<br>
>>> problem that would have had to be solved at some point anyway.<br>
>>><br>
>>> Stuart<br>
>>><br>
>>> Stan Silvert wrote:<br>
>>>> I'm starting to have doubts about this split.<br>
>>>><br>
>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter<br>
>>>> into build-core so that the web console can use Keycloak for<br>
>>>> authentication. The problem is that there is a huge web of<br>
>>>> dependencies<br>
>>>> that must be moved over from build to build-core.<br>
>>>><br>
>>>> What exactly is the split trying to solve?<br>
>>>><br>
>>>> Stan<br>
>>>><br>
>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:<br>
>>>>> Hi all,<br>
>>>>><br>
>>>>> So I am moderately confident that we will be ready to split out<br>
>>>>> Wildfly<br>
>>>>> core into a separate repository early next week (I'm not saying<br>
>>>>> that it<br>
>>>>> will definitely happen in this time frame, just that it should be<br>
>>>>> possible).<br>
>>>>><br>
>>>>> Once this is ready to go I think the basic process will be:<br>
>>>>><br>
>>>>> - Code freeze on Master<br>
>>>>> - Create the core repo, push new rewritten core history<br>
>>>>> - Release core 1.0.0.Beta1<br>
>>>>> - Create PR against core WF repo that deletes everything in core, and<br>
>>>>> uses the core 1.0.0.Beta1 release<br>
>>>>> - End of code freeze<br>
>>>>><br>
>>>>> Stuart<br>
>>>>> _______________________________________________<br>
>>>>> wildfly-dev mailing list<br>
>>>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> wildfly-dev mailing list<br>
>>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>><br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>