9:06 a.m.
Jackson 2 has a different package name from Jackson 1, so they are
completely incompatible. My suggestion?
* Ship with both jackson 1 and jackson 2 modules
* Ship with both Restasy jackson 1 and 2 providers
* Make Jackson2 the default Resteasy provider
For resteasy-based apps, the negative is that anybody relying on
jackson1 apis directly will have to either upgrade (which I think is as
easy as changing package names) or manually set up the apropriate
jboss-module includes/excludes.
Thoughts? Let me know if you have any objections to this approach as I
want to document this within Resteasy and push the appropriate changes
to Wildfly.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:28 a.m.
On 05/06/2013 09:06 AM, Bill Burke wrote:
Jackson 2 has a different package name from Jackson 1, so they are
completely incompatible. My suggestion?
* Ship with both jackson 1 and jackson 2 modules
* Ship with both Restasy jackson 1 and 2 providers
* Make Jackson2 the default Resteasy provider
For resteasy-based apps, the negative is that anybody relying on
jackson1 apis directly will have to either upgrade (which I think is as
easy as changing package names) or manually set up the apropriate
jboss-module includes/excludes.
Thoughts? Let me know if you have any objections to this approach as I
want to document this within Resteasy and push the appropriate changes
to Wildfly.
Are RestEasy providers selected on a serverwide basis or by deployment?
--
- DML
9:32 a.m.
On 5/6/2013 10:28 AM, David M. Lloyd wrote:
On 05/06/2013 09:06 AM, Bill Burke wrote:
> Jackson 2 has a different package name from Jackson 1, so they are
> completely incompatible. My suggestion?
>
> * Ship with both jackson 1 and jackson 2 modules
> * Ship with both Restasy jackson 1 and 2 providers
> * Make Jackson2 the default Resteasy provider
>
> For resteasy-based apps, the negative is that anybody relying on
> jackson1 apis directly will have to either upgrade (which I think is as
> easy as changing package names) or manually set up the apropriate
> jboss-module includes/excludes.
>
> Thoughts? Let me know if you have any objections to this approach as I
> want to document this within Resteasy and push the appropriate changes
> to Wildfly.
Are RestEasy providers selected on a serverwide basis or by deployment?
There are implicit default imports for resteasy. Json (jackson) support
is one of them. Does that answer your question?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:49 a.m.
On 05/06/2013 09:32 AM, Bill Burke wrote:
On 5/6/2013 10:28 AM, David M. Lloyd wrote:
> On 05/06/2013 09:06 AM, Bill Burke wrote:
>> Jackson 2 has a different package name from Jackson 1, so they are
>> completely incompatible. My suggestion?
>>
>> * Ship with both jackson 1 and jackson 2 modules
>> * Ship with both Restasy jackson 1 and 2 providers
>> * Make Jackson2 the default Resteasy provider
>>
>> For resteasy-based apps, the negative is that anybody relying on
>> jackson1 apis directly will have to either upgrade (which I think is as
>> easy as changing package names) or manually set up the apropriate
>> jboss-module includes/excludes.
>>
>> Thoughts? Let me know if you have any objections to this approach as I
>> want to document this within Resteasy and push the appropriate changes
>> to Wildfly.
>
> Are RestEasy providers selected on a serverwide basis or by deployment?
>
There are implicit default imports for resteasy. Json (jackson) support
is one of them. Does that answer your question?
I just had a sort of a vague idea that if you could import both
implicitly (since the packages don't conflict) with the preferred impl
coming in first, and if the deployment CL is used to select the
implementation to use, the user could maybe put in some kind of
ServiceLoader file to prefer the other one if they want, or something.
It's probably not really a big deal, I just don't like making users have
to hack in to jboss-deployment-structure.xml to make things work.
--
- DML
11:31 a.m.
On 5/6/2013 10:49 AM, David M. Lloyd wrote:
On 05/06/2013 09:32 AM, Bill Burke wrote:
>
>
> On 5/6/2013 10:28 AM, David M. Lloyd wrote:
>> On 05/06/2013 09:06 AM, Bill Burke wrote:
>>> Jackson 2 has a different package name from Jackson 1, so they are
>>> completely incompatible. My suggestion?
>>>
>>> * Ship with both jackson 1 and jackson 2 modules
>>> * Ship with both Restasy jackson 1 and 2 providers
>>> * Make Jackson2 the default Resteasy provider
>>>
>>> For resteasy-based apps, the negative is that anybody relying on
>>> jackson1 apis directly will have to either upgrade (which I think is as
>>> easy as changing package names) or manually set up the apropriate
>>> jboss-module includes/excludes.
>>>
>>> Thoughts? Let me know if you have any objections to this approach as I
>>> want to document this within Resteasy and push the appropriate changes
>>> to Wildfly.
>>
>> Are RestEasy providers selected on a serverwide basis or by deployment?
>>
>
> There are implicit default imports for resteasy. Json (jackson) support
> is one of them. Does that answer your question?
I just had a sort of a vague idea that if you could import both
implicitly (since the packages don't conflict) with the preferred impl
coming in first, and if the deployment CL is used to select the
implementation to use, the user could maybe put in some kind of
ServiceLoader file to prefer the other one if they want, or something.
That would also break backward compatibility as in AS7 it was automatic
with no extra config.
It's probably not really a big deal, I just don't like making
users have
to hack in to jboss-deployment-structure.xml to make things work.
Me either. But this hacking would be for getting at an older version.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4802
days inactive
4802
days old
4 comments
2 participants
participants (2)
-
Bill Burke -
David M. Lloyd