[wildfly-dev] Configurable implicit module imports

[Jason Greene]

On Sep 12, 2013, at 10:07 AM, Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 9/12/2013 10:54 AM, David M. Lloyd wrote:
>> On 09/12/2013 09:45 AM, Bill Burke wrote:
>>> 
>>> 
>>> On 9/12/2013 10:10 AM, David M. Lloyd wrote:
>>>> On 09/12/2013 08:11 AM, Bill Burke wrote:
>>>>> The whole JSON-JAXRS support is a *bleepin* mess....
>>>>> 
>>>>> * You have old users that want to use Jettison to generate JSON from JAXB.
>>>>> * You have new users that want to use Jackson to generate JSON from JAXB.
>>>>> * Jackson 1.x is a completely different Java package than Jackson 2.x.
>>>>> With that you have old users that want to use 1.x new users that want to
>>>>> use 2.x.
>>>>> 
>>>>> Given that, it would be nice to have one place where they can set up the
>>>>> default implicit imports that come with Resteasy/JAX-RS subsystem.
>>>>> Someplace where they could configure this without it being hardcoded so
>>>>> we can support older apps that are migrating to Wildfly .  Quite
>>>>> honestly I scratch my head trying to figure out why you guys decided it
>>>>> was a good idea to hardcode implicit module imports.
>>>> 
>>>> Hey just be glad we don't have a flat class path :)
>>>> 
>>>> Is there any reason why all three should not be imported by default?  (I
>>>> am completely ignorant of JAX-RS so forgive me if that's a dumb question.)
>>>> 
>>> 
>>> They conflict with one another as JAX-RS binds marshallers based on
>>> media type, target java class and target's annotations.  Jettison and
>>> Jackson have different default JAXB->JSON mappings and there's no way to
>>> pick between the two without a special resteasy annotation.  As for old
>>> vs. new Jackson, there's no way to determine which one to use if no
>>> Jackson annotations are being used.  Its a cluster-bleep...
>> 
>> So that leaves us two options that I can think of:
>> 
>> 1. Add a switch to a per-deployment descriptor which indicates which (if
>> any) JSON strategy to use
>> 2. Add a switch to the jax-rs subsystem configuration which specifies
>> which to include by default
>> 
>> We could also do both.  Either way though the name should be specified
>> in english (i.e. "jackson1"/"jackson2"/"jettison"/"none").
>> 
> 
> Argg....This is a very crappy approach.  Why not just be able to 
> configure the implicit imports of a subsystem.  That makes much more 
> sense than what you are suggesting.

IMO Configuration potability and usability are issues to think through with something like that. We generally try to keep internal implementation stuff out of it as much as possible. For example you might decide to split one of these across two modules, or maybe you refactor the SPI, but now you can't because you have everyone's old configs is hardcoding names. 

On the usability size, if whatever our config says is in the schema as an enum (or in the management descriptions if you are using the management API), then it's pretty easy to just complete whatever value you want without finding a list somewhere of magic module names.

Now this is completely moot if we are talking about a user provided plug-ablity point that is intentionally generic (e.g. some kind of driver construct like jdbc). 


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