[wildfly-dev] Configurable implicit module imports

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

[wildfly-dev] Configurable implicit module imports

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



--
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: [wildfly-dev] Configurable implicit module imports

David Lloyd-2
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.)


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

Re: [wildfly-dev] Configurable implicit module imports

Bill Burke


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



--
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: [wildfly-dev] Configurable implicit module imports

David Lloyd-2
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").


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

Re: [wildfly-dev] Configurable implicit module imports

Bill Burke


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

Re: [wildfly-dev] Configurable implicit module imports

Tomaž Cerar-2
Bill,

I know guys just don't want to say this, but you can expose configuration about implicit imports.
it is mostly up to subsystem developer what it wants to do.
And that would result in jax-rs subsystem actualy having some configuration at all :)


On Thu, Sep 12, 2013 at 5:07 PM, Bill Burke <[hidden email]> 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.



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


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

Re: [wildfly-dev] Configurable implicit module imports

jtgreene
Administrator
In reply to this post by Bill Burke

On Sep 12, 2013, at 10:07 AM, Bill Burke <[hidden email]> 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


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

Re: [wildfly-dev] Configurable implicit module imports

Stuart Douglas
In reply to this post by Bill Burke
You can, you can just use jboss-deployment-structure.xml to exclude any hard coded dependency, and then add the one you want via the same file.

Sent from my iPhone

On 12/09/2013, at 16:07, Bill Burke <[hidden email]> 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.
>
>
>
> --
> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev