[wildfly-dev] Pending core split

[Darran Lofthouse]

On 01/07/14 14:42, Stuart Douglas wrote:
>
>
> Stan Silvert wrote:
>> On 7/1/2014 9:01 AM, Stuart Douglas wrote:
>>>
>>>> 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.
>>>
>>> I don't follow your logic here. You are basically saying that unless
>>> we can have keycloak in core then there is no point having a core?
>> Of course that's not what I'm saying. I'm saying that domain-http is
>> currently in core. Web console and other clients use domain-http. If we
>> want keycloak to authenticate domain-http then keycloak must also be in
>> core.
>>
>
> I don't follow your logic. If we want web console and other clients to
> use keycloak then keycloak must be present, but I really can't see why
> you think it *must* be in core.
>
> IMHO the way this should work is that we identify the extension points
> you need to integrate keycloak,

WildFly Elytron would be the fundamental core of this.

> looking at your kcauth branch this looks
> fairly simple, basically just a way to add some handlers and
> Authentication mechanisms. You then have the keycloak module use these
> extension points to integrate with core. IMHO this will give a much
> cleaner result and keeps all the keycloak related stuff in the keycloak
> module.
>
>
>> There are many possible solutions:
>> * Don't do the split
>
> The split has been on the table for over 6 months, it is going ahead.
>
>> * Do the split, but allow core to see the full set of modules.
> This makes no sense. If it has all the modules it is not core.
>
>> * Move domain-http out of core.
>> * Allow the extra dependencies.
>> * Redesign domain-http
>
> If by redesign you mean add some extension points to allow keycloak to
> hook into it without requiring keycloak code in domain-http then this is
> exactly what we should do.
>
> If you want a hand with this I should be able to help you out.

Just keep in mind the security code that exists today is being re-worked 
and a lot will be replaced.

We will be having one security solution that applies to the whole app 
server whether that be management or ee.

>
> Stuart
>
>> * others?
>>
>>>
>>> Core can't actually do anything out of the box, it is a runtime that
>>> other distributions will build on.
>>>
>>> Stuart
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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 at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>