[wildfly-dev] Pending core split

Bill Burke bburke at redhat.com
Tue Jul 1 10:54:35 EDT 2014



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


More information about the wildfly-dev mailing list