Pending core split

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Bill Burke


On 7/1/2014 8:48 AM, Stan Silvert wrote:

> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
>>
>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     My impression is Keycloak does not belong into the categories
>>     above, but maybe I don't know all the details.
>>
>>
>>
>> You don't have all details, but your reasoning is completely sound.
>>
>> Idea is to have keycloak auth mechanism as an option to have SSO for
>> admin console.
>> But that doesn't mean it needs all those dependencies in the core.
>>
>> We need to distinguish between, auth mechanism that should go to
>> domain-http
>> and keycloak subsystem which is completely different beast and should
>> go to probably full distro.
> We don't necessarily need the keycloak subsystem in order to use
> keycloak for authenticating domain-http.  But keycloak subsystem is not
> the thing that pulls in all the dependencies.  It's the keycloak adapter
> that does this.
>
> So if we want keycloak to authenticate domain-http out of the box then
> we have to include all this stuff with it.  That wasn't a problem before
> the split.  Almost everything it needed was already there.
>

"All this stuff" is really just Apache Http Client, Jackson and
Bouncycastle.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
On 7/1/2014 9:33 AM, Bill Burke wrote:

>
> On 7/1/2014 8:48 AM, Stan Silvert wrote:
>> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
>>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      My impression is Keycloak does not belong into the categories
>>>      above, but maybe I don't know all the details.
>>>
>>>
>>>
>>> You don't have all details, but your reasoning is completely sound.
>>>
>>> Idea is to have keycloak auth mechanism as an option to have SSO for
>>> admin console.
>>> But that doesn't mean it needs all those dependencies in the core.
>>>
>>> We need to distinguish between, auth mechanism that should go to
>>> domain-http
>>> and keycloak subsystem which is completely different beast and should
>>> go to probably full distro.
>> We don't necessarily need the keycloak subsystem in order to use
>> keycloak for authenticating domain-http.  But keycloak subsystem is not
>> the thing that pulls in all the dependencies.  It's the keycloak adapter
>> that does this.
>>
>> So if we want keycloak to authenticate domain-http out of the box then
>> we have to include all this stuff with it.  That wasn't a problem before
>> the split.  Almost everything it needed was already there.
>>
> "All this stuff" is really just Apache Http Client, Jackson and
> Bouncycastle.
>
>
Resteasy got pulled in as well.  Maybe that was an error on my part?
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2
"Stuff", that Bill said, sounds ok to be part of core.
At least in its most bare versions (as all 3 libs can have many modules)


RestEasy should never get pulled in, as it requires servlets again...


On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <[hidden email]> wrote:
On 7/1/2014 9:33 AM, Bill Burke wrote:
>
> On 7/1/2014 8:48 AM, Stan Silvert wrote:
>> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
>>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      My impression is Keycloak does not belong into the categories
>>>      above, but maybe I don't know all the details.
>>>
>>>
>>>
>>> You don't have all details, but your reasoning is completely sound.
>>>
>>> Idea is to have keycloak auth mechanism as an option to have SSO for
>>> admin console.
>>> But that doesn't mean it needs all those dependencies in the core.
>>>
>>> We need to distinguish between, auth mechanism that should go to
>>> domain-http
>>> and keycloak subsystem which is completely different beast and should
>>> go to probably full distro.
>> We don't necessarily need the keycloak subsystem in order to use
>> keycloak for authenticating domain-http.  But keycloak subsystem is not
>> the thing that pulls in all the dependencies.  It's the keycloak adapter
>> that does this.
>>
>> So if we want keycloak to authenticate domain-http out of the box then
>> we have to include all this stuff with it.  That wasn't a problem before
>> the split.  Almost everything it needed was already there.
>>
> "All this stuff" is really just Apache Http Client, Jackson and
> Bouncycastle.
>
>
Resteasy got pulled in as well.  Maybe that was an error on my part?
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas
In reply to this post by Stan Silvert


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, 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.

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
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Bill Burke
In reply to this post by Stan Silvert


On 7/1/2014 9:36 AM, Stan Silvert wrote:
>> "All this stuff" is really just Apache Http Client, Jackson and
>> Bouncycastle.
>>
>>
> Resteasy got pulled in as well.  Maybe that was an error on my part?

Resteasy is not required for the adapter.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Bill Burke
In reply to this post by Tomaž Cerar-2
Oh and net.iharder, which is just 1 class.  A Base64 encoder/decoder.

FYI, Resteasy core doesn't require servlets (we have netty3, netty4, and
jdk http adapters), but the jaxrs deployer does.

On 7/1/2014 9:39 AM, Tomaž Cerar wrote:

> "Stuff", that Bill said, sounds ok to be part of core.
> At least in its most bare versions (as all 3 libs can have many modules)
>
>
> RestEasy should never get pulled in, as it requires servlets again...
>
>
> On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 7/1/2014 9:33 AM, Bill Burke wrote:
>      >
>      > On 7/1/2014 8:48 AM, Stan Silvert wrote:
>      >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
>      >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
>     <mailto:[hidden email]>
>      >>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >>>
>      >>>      My impression is Keycloak does not belong into the categories
>      >>>      above, but maybe I don't know all the details.
>      >>>
>      >>>
>      >>>
>      >>> You don't have all details, but your reasoning is completely sound.
>      >>>
>      >>> Idea is to have keycloak auth mechanism as an option to have
>     SSO for
>      >>> admin console.
>      >>> But that doesn't mean it needs all those dependencies in the core.
>      >>>
>      >>> We need to distinguish between, auth mechanism that should go to
>      >>> domain-http
>      >>> and keycloak subsystem which is completely different beast and
>     should
>      >>> go to probably full distro.
>      >> We don't necessarily need the keycloak subsystem in order to use
>      >> keycloak for authenticating domain-http.  But keycloak subsystem
>     is not
>      >> the thing that pulls in all the dependencies.  It's the keycloak
>     adapter
>      >> that does this.
>      >>
>      >> So if we want keycloak to authenticate domain-http out of the
>     box then
>      >> we have to include all this stuff with it.  That wasn't a
>     problem before
>      >> the split.  Almost everything it needed was already there.
>      >>
>      > "All this stuff" is really just Apache Http Client, Jackson and
>      > Bouncycastle.
>      >
>      >
>     Resteasy got pulled in as well.  Maybe that was an error on my part?
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Bill Burke
On 7/1/2014 9:46 AM, Bill Burke wrote:

>
> On 7/1/2014 9:36 AM, Stan Silvert wrote:
>>> "All this stuff" is really just Apache Http Client, Jackson and
>>> Bouncycastle.
>>>
>>>
>> Resteasy got pulled in as well.  Maybe that was an error on my part?
> Resteasy is not required for the adapter.
>
>
Then we've got a problem in a module.xml somwhere.

jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

jtgreene
Administrator
In reply to this post by Tomaž Cerar-2
The only thing on the list that can be done with the libraries already provided in Core (and the JDK itself) is bouncy castle, which might very well get added eventually.

If you go back and read the proposals though, the eventual plan is to make WildFly extensions remotely downloadable. So if you want KeyCloak integration you will be able to run a prov tool to download and install it. The plan is also to be able to create your own dist from an XML file assembled by that tool (or by editing). So in a nutshell it will be very easy for thirdparty distributions to pull in a keycloak-adapter extension, should that be the direction. No matter we can definitely include this in the primary WildFly distro.

Anyway the choose is basically live with a very limited set of deps, or target one of the higher layers.

Note that everyone can make an argument that core should include their favorite small set of libs. The aggregate of everyone doing that is a full distribution.


On Jul 1, 2014, at 8:39 AM, Tomaž Cerar <[hidden email]> wrote:

> "Stuff", that Bill said, sounds ok to be part of core.
> At least in its most bare versions (as all 3 libs can have many modules)
>
>
> RestEasy should never get pulled in, as it requires servlets again...
>
>
> On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <[hidden email]> wrote:
> On 7/1/2014 9:33 AM, Bill Burke wrote:
> >
> > On 7/1/2014 8:48 AM, Stan Silvert wrote:
> >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
> >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
> >>> <mailto:[hidden email]>> wrote:
> >>>
> >>>      My impression is Keycloak does not belong into the categories
> >>>      above, but maybe I don't know all the details.
> >>>
> >>>
> >>>
> >>> You don't have all details, but your reasoning is completely sound.
> >>>
> >>> Idea is to have keycloak auth mechanism as an option to have SSO for
> >>> admin console.
> >>> But that doesn't mean it needs all those dependencies in the core.
> >>>
> >>> We need to distinguish between, auth mechanism that should go to
> >>> domain-http
> >>> and keycloak subsystem which is completely different beast and should
> >>> go to probably full distro.
> >> We don't necessarily need the keycloak subsystem in order to use
> >> keycloak for authenticating domain-http.  But keycloak subsystem is not
> >> the thing that pulls in all the dependencies.  It's the keycloak adapter
> >> that does this.
> >>
> >> So if we want keycloak to authenticate domain-http out of the box then
> >> we have to include all this stuff with it.  That wasn't a problem before
> >> the split.  Almost everything it needed was already there.
> >>
> > "All this stuff" is really just Apache Http Client, Jackson and
> > Bouncycastle.
> >
> >
> Resteasy got pulled in as well.  Maybe that was an error on my part?
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Bill Burke
In reply to this post by Stan Silvert


On 7/1/2014 9:51 AM, Stan Silvert wrote:

> On 7/1/2014 9:46 AM, Bill Burke wrote:
>>
>> On 7/1/2014 9:36 AM, Stan Silvert wrote:
>>>> "All this stuff" is really just Apache Http Client, Jackson and
>>>> Bouncycastle.
>>>>
>>>>
>>> Resteasy got pulled in as well.  Maybe that was an error on my part?
>> Resteasy is not required for the adapter.
>>
>>
> Then we've got a problem in a module.xml somwhere.
>
> jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs

Adapter doesn't depend on jackson-jaxrs either.

<module xmlns="urn:jboss:module:1.1"
name="org.keycloak.keycloak-undertow-adapter">
     <resources>
         <!-- Insert resources here -->
     </resources>
     <dependencies>
         <module name="javax.api"/>
         <module name="org.bouncycastle"/>
         <module name="org.codehaus.jackson.jackson-core-asl"/>
         <module name="org.codehaus.jackson.jackson-mapper-asl"/>
         <module name="org.codehaus.jackson.jackson-xc"/>
         <module name="org.apache.httpcomponents" />
         <module name="javax.servlet.api"/>
         <module name="org.jboss.logging"/>
         <module name="io.undertow.core"/>
         <module name="io.undertow.servlet"/>
         <module name="org.keycloak.keycloak-adapter-core"/>
         <module name="org.keycloak.keycloak-core"/>
     </dependencies>

</module>


I think you did some work to refactor the undertow adapter right?  So it
didn't need the servlet dependency?


Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
On 7/1/2014 9:55 AM, Bill Burke wrote:

>
> On 7/1/2014 9:51 AM, Stan Silvert wrote:
>> On 7/1/2014 9:46 AM, Bill Burke wrote:
>>> On 7/1/2014 9:36 AM, Stan Silvert wrote:
>>>>> "All this stuff" is really just Apache Http Client, Jackson and
>>>>> Bouncycastle.
>>>>>
>>>>>
>>>> Resteasy got pulled in as well.  Maybe that was an error on my part?
>>> Resteasy is not required for the adapter.
>>>
>>>
>> Then we've got a problem in a module.xml somwhere.
>>
>> jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs
> Adapter doesn't depend on jackson-jaxrs either.
>
> <module xmlns="urn:jboss:module:1.1"
> name="org.keycloak.keycloak-undertow-adapter">
>       <resources>
>           <!-- Insert resources here -->
>       </resources>
>       <dependencies>
>           <module name="javax.api"/>
>           <module name="org.bouncycastle"/>
>           <module name="org.codehaus.jackson.jackson-core-asl"/>
>           <module name="org.codehaus.jackson.jackson-mapper-asl"/>
>           <module name="org.codehaus.jackson.jackson-xc"/>
>           <module name="org.apache.httpcomponents" />
>           <module name="javax.servlet.api"/>
>           <module name="org.jboss.logging"/>
>           <module name="io.undertow.core"/>
>           <module name="io.undertow.servlet"/>
>           <module name="org.keycloak.keycloak-adapter-core"/>
>           <module name="org.keycloak.keycloak-core"/>
>       </dependencies>
>
> </module>
>
>
> I think you did some work to refactor the undertow adapter right?  So it
> didn't need the servlet dependency?
Right.  But it looks like I moved too many of the jackson dependencies
from build to core-build.  I'll clean this up and come up with a
proposal based on the minimum that needs to be moved.

>
>
> Bill
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

jtgreene
Administrator

On Jul 1, 2014, at 9:03 AM, Stan Silvert <[hidden email]> wrote:

> On 7/1/2014 9:55 AM, Bill Burke wrote:
>>
>> On 7/1/2014 9:51 AM, Stan Silvert wrote:
>>> On 7/1/2014 9:46 AM, Bill Burke wrote:
>>>> On 7/1/2014 9:36 AM, Stan Silvert wrote:
>>>>>> "All this stuff" is really just Apache Http Client, Jackson and
>>>>>> Bouncycastle.
>>>>>>
>>>>>>
>>>>> Resteasy got pulled in as well.  Maybe that was an error on my part?
>>>> Resteasy is not required for the adapter.
>>>>
>>>>
>>> Then we've got a problem in a module.xml somwhere.
>>>
>>> jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs
>> Adapter doesn't depend on jackson-jaxrs either.
>>
>> <module xmlns="urn:jboss:module:1.1"
>> name="org.keycloak.keycloak-undertow-adapter">
>>     <resources>
>>         <!-- Insert resources here -->
>>     </resources>
>>     <dependencies>
>>         <module name="javax.api"/>
>>         <module name="org.bouncycastle"/>
>>         <module name="org.codehaus.jackson.jackson-core-asl"/>
>>         <module name="org.codehaus.jackson.jackson-mapper-asl"/>
>>         <module name="org.codehaus.jackson.jackson-xc"/>
>>         <module name="org.apache.httpcomponents" />
>>         <module name="javax.servlet.api"/>
>>         <module name="org.jboss.logging"/>
>>         <module name="io.undertow.core"/>
>>         <module name="io.undertow.servlet"/>
>>         <module name="org.keycloak.keycloak-adapter-core"/>
>>         <module name="org.keycloak.keycloak-core"/>
>>     </dependencies>
>>
>> </module>
>>
>>
>> I think you did some work to refactor the undertow adapter right?  So it
>> didn't need the servlet dependency?
> Right.  But it looks like I moved too many of the jackson dependencies
> from build to core-build.  I'll clean this up and come up with a
> proposal based on the minimum that needs to be moved.

Please also keep in mind the relative complexity of what this does to the dependency set it brings in. For example, I imagine you essentially have a small number of cookie cutter HTTP requests, with the most complex aspect being processing a token. Do you really need jackson object bindings for that? I realize this argument may seem counter-intuitive because its basically an argument against reuse, but thats the challenge we have in core.

Here are some other options already in core that you could potentially use:

- DMR - While it’s primary purpose is not JSON processing it gives you a detyped map like API that can be used for this purpose
- JDK URL connections - While not the best API, it can get the job done
- Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs.
- FlexBase64 - This is a one class base64 encoder/decoder that is already in core, is fast, and can be used with buffers, streams, and arrays.

As mentioned in another email, there is really no replacement for bouncy castle, and so is a good candidate to be added.

Again, I totally get it if you don’t want to hack something together *just* for wildfly to be in wildfly core, but thats not a bad thing IMO.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Bill Burke


On 7/1/2014 10:26 AM, Jason Greene wrote:
>
> Please also keep in mind the relative complexity of what this does to the dependency set it brings in. For example, I imagine you essentially have a small number of cookie cutter HTTP requests, with the most complex aspect being processing a token. Do you really need jackson object bindings for that? I realize this argument may seem counter-intuitive because its basically an argument against reuse, but thats the challenge we have in core.
>

There's no need for anything (other than bouncycastle).  I could of
course hand code everything if need be.  But Jackson, Apache HTTP Client
sure make life a little easier.


> Here are some other options already in core that you could potentially use:
>
> - DMR - While it’s primary purpose is not JSON processing it gives you a detyped map like API that can be used for this purpose
> - JDK URL connections - While not the best API, it can get the job done

I remember some peculiarities with JDK URL Connections in which some
configuration is done globally through static methods and could be
overridden by user code.  (Like connection caches and content caches
cookies, etc.).  Maybe my memory is faulty there though.


> - Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs.

If it supports SSL with the ability to enable/disable a trust manager,
then ya, it could be used.

> - FlexBase64 - This is a one class base64 encoder/decoder that is already in core, is fast, and can be used with buffers, streams, and arrays.
>
> As mentioned in another email, there is really no replacement for bouncy castle, and so is a good candidate to be added.
>
> Again, I totally get it if you don’t want to hack something together *just* for wildfly to be in wildfly core, but thats not a bad thing IMO.
>

No, I don't want to hack something together when there is a high
probability Keycloak is going to be excluded anyways.  Our roadmap is
long and deep and we need to pick our battles.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas

>> - Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs.
>
> If it supports SSL with the ability to enable/disable a trust manager,
> then ya, it could be used.
>

It does, however the main issue you will have is that is designed for
use with Undertow proxy, so it can basically only be used from an Xnio
IO thread (basically in the proxy the incoming and outgoing request
shares the same IO thread, which is much faster as there is no thread
safety constructs required).

If you are just sending requests from inside an Undertow HttpHandler
then this should be ok, otherwise it would be possible to just write a
simple thread safe wrapper around it.

Stuart
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Stuart Douglas
On 7/1/2014 9:42 AM, Stuart Douglas wrote:

>
> There are many possible solutions:
>> * 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.
>
> Stuart
Yes, that's pretty much what I was thinking.  Thanks for the offer to help.

If there are no objections, I'll pursue the "redesign domain-http"
solution.

This means:
* By default, Keycloak is not available in core.  But it could possibly
be added.
* Keycloak will be available in web-build and full build.
* Approximately 20 modules will be moved from full build to web-build.
* Delivery of Keycloak integration will be delayed.  I don't know by how
much yet.

Sound OK?
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas

>>
>> Stuart
> Yes, that's pretty much what I was thinking. Thanks for the offer to help.
>
> If there are no objections, I'll pursue the "redesign domain-http"
> solution.
>
> This means:
> * By default, Keycloak is not available in core. But it could possibly
> be added.
> * Keycloak will be available in web-build and full build.
> * Approximately 20 modules will be moved from full build to web-build.

Do you know which modules? Web build is supposed to be a lightweight
build that basically just provides a web server, that can be used as a
Tomcat equivalent or as the base for a product that only requires a web
server.

Stuart

> * Delivery of Keycloak integration will be delayed. I don't know by how
> much yet.
>
> Sound OK?
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
On 7/2/2014 1:23 PM, Stuart Douglas wrote:

>
>>>
>>> Stuart
>> Yes, that's pretty much what I was thinking. Thanks for the offer to
>> help.
>>
>> If there are no objections, I'll pursue the "redesign domain-http"
>> solution.
>>
>> This means:
>> * By default, Keycloak is not available in core. But it could possibly
>> be added.
>> * Keycloak will be available in web-build and full build.
>> * Approximately 20 modules will be moved from full build to web-build.
>
> Do you know which modules? Web build is supposed to be a lightweight
> build that basically just provides a web server, that can be used as a
> Tomcat equivalent or as the base for a product that only requires a
> web server.
>
> Stuart
It's six (very small) keycloak modules, plus the following:
ch/qos/cal10n/main/module.xml
net/iharder/base64/main/module.xml
org/apache/commons/codec/main/module.xml
org/apache/commons/logging/main/module.xml
org/apache/httpcomponents/main/module.xml
org/apache/james/mime4j/main/module.xml
org/bouncycastle/main/module.xml
org/codehaus/jackson/jackson-core-asl/main/module.xml
org/codehaus/jackson/jackson-mapper-asl/main/module.xml
org/codehaus/jackson/jackson-xc/main/module.xml
org/slf4j/ext/main/module.xml
org/slf4j/jcl-over-slf4j/main/module.xml

However, this assumes I can remove these two transitive dependencies
from jackson:
module.xml for jackson-mapper-asl declares a dependency on org.joda.time
module.xml for jackson-xc declares a dependency on javax.xml.bind.api

I can't find evidence that these dependencies are actually needed.

>
>> * Delivery of Keycloak integration will be delayed. I don't know by how
>> much yet.
>>
>> Sound OK?

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Stan Silvert

 > The central question is, do we want Keycloak to work out of the box?
 > Before this issue was known, everyone answered "yes".

I think here we had reached the point we were answering the question "do
we want it enableable out of the box?" and the answer to that was "yes"

What has not been defined since the split started is what "out of the
box" actually means now, are we talking out of the box for the core or
out of the box for a complete assembled server?

On 01/07/14 12:55, 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.
>
>>
>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Tomaž Cerar-2
On 01/07/14 13:32, Tomaž Cerar wrote:

>
> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     My impression is Keycloak does not belong into the categories
>     above, but maybe I don't know all the details.
>
>
>
> You don't have all details, but your reasoning is completely sound.
>
> Idea is to have keycloak auth mechanism as an option to have SSO for
> admin console.
> But that doesn't mean it needs all those dependencies in the core.
>
> We need to distinguish between, auth mechanism that should go to domain-http
> and keycloak subsystem which is completely different beast and should go
> to probably full distro.

+1

Just to clarify one point, the current security infrastructure within
the server be that management or ee is being replaced with Elytron and
anything that is integrated such as PicketLink and KeyCloak will be
integrated on top of that so what we are learning at the moment is more
proof of concept rather than final solution when it comes to the
KeyCloak integration.

The approach that we are moving to for Elytron is that it will entirely
be contained within a subsystem.  So for our distributions we are most
likely going to want security out of the box so would include the
Elytron subsystem - however as advisable as it is I don't see it's
inclusion by default as a base requirement on a core of the sever.

> --
> tomaz
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2
In reply to this post by Darran Lofthouse
I think that for start we can make it by default enablable in full distro.

Once this is done, and extra work is done on trimming down dependencies to go as near JDK as possible
it could be moved to core distro.

Rome was not build in a day, why would KeyCloak integration / implementation be done in just one step.

Isn't it better that we start somewhere to get it out to the people to test it as soon as possible
and when it is ready we decide where it is best resting place and how to get there.




On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse <[hidden email]> wrote:

 > The central question is, do we want Keycloak to work out of the box?
 > Before this issue was known, everyone answered "yes".

I think here we had reached the point we were answering the question "do
we want it enableable out of the box?" and the answer to that was "yes"

What has not been defined since the split started is what "out of the
box" actually means now, are we talking out of the box for the core or
out of the box for a complete assembled server?

On 01/07/14 12:55, 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.
>
>>
>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Darran Lofthouse
In reply to this post by Bill Burke


On 01/07/14 14:50, Bill Burke wrote:
> Oh and net.iharder, which is just 1 class.  A Base64 encoder/decoder.

For that one we must already have a few Base64 encoder/decoder
implementations available in the core ;-)

> FYI, Resteasy core doesn't require servlets (we have netty3, netty4, and
> jdk http adapters), but the jaxrs deployer does.
>
> On 7/1/2014 9:39 AM, Tomaž Cerar wrote:
>> "Stuff", that Bill said, sounds ok to be part of core.
>> At least in its most bare versions (as all 3 libs can have many modules)
>>
>>
>> RestEasy should never get pulled in, as it requires servlets again...
>>
>>
>> On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      On 7/1/2014 9:33 AM, Bill Burke wrote:
>>       >
>>       > On 7/1/2014 8:48 AM, Stan Silvert wrote:
>>       >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
>>       >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]
>>      <mailto:[hidden email]>
>>       >>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>       >>>
>>       >>>      My impression is Keycloak does not belong into the categories
>>       >>>      above, but maybe I don't know all the details.
>>       >>>
>>       >>>
>>       >>>
>>       >>> You don't have all details, but your reasoning is completely sound.
>>       >>>
>>       >>> Idea is to have keycloak auth mechanism as an option to have
>>      SSO for
>>       >>> admin console.
>>       >>> But that doesn't mean it needs all those dependencies in the core.
>>       >>>
>>       >>> We need to distinguish between, auth mechanism that should go to
>>       >>> domain-http
>>       >>> and keycloak subsystem which is completely different beast and
>>      should
>>       >>> go to probably full distro.
>>       >> We don't necessarily need the keycloak subsystem in order to use
>>       >> keycloak for authenticating domain-http.  But keycloak subsystem
>>      is not
>>       >> the thing that pulls in all the dependencies.  It's the keycloak
>>      adapter
>>       >> that does this.
>>       >>
>>       >> So if we want keycloak to authenticate domain-http out of the
>>      box then
>>       >> we have to include all this stuff with it.  That wasn't a
>>      problem before
>>       >> the split.  Almost everything it needed was already there.
>>       >>
>>       > "All this stuff" is really just Apache Http Client, Jackson and
>>       > Bouncycastle.
>>       >
>>       >
>>      Resteasy got pulled in as well.  Maybe that was an error on my part?
>>      _______________________________________________
>>      wildfly-dev mailing list
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123