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.

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

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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev