<init-param>
    <param-name>javax.ws.rs.Application</param-name>
    <param-value>com.pulsepoint.predict.web.JaxRsApplication</param-value>
</init-param>
public class JaxRsApplication extends javax.ws.rs.core.Application {
    @Override
    public Set<Class<?>> getClasses() {
        final Set<Class<?>> classes = new HashSet<>();
        classes.add(com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider.class);
        return classes;
    }
}

JacksonJsonProvider would not be picking up properly as a reader/writer by 
Jersey 1.x with Jackson 2.8. Same works fine with Jackson 2.7. I don't see 
any stacktraces, it just stops picking up.
For sure I'm for continuing support of first major JaxRS and Jersey 
versions, migration would be painful for many projects and they would stick 
with the 2.7 branch.

Maybe I would try to find time to investigate what has been broken in 
providers integration here.

суббота, 8 октября 2016 г., 1:50:10 UTC+3 пользователь Tatu Saloranta 
написал:
>
> Just to make this clear: if anyone can help figure out what is preventing 
> use of jackson-jaxrs-providers on JAX-RS 1.1 platforms, I am willing to 
> work in trying to avoid references to such features. Build and main tests 
> should still use JAX-RS 2.x, but additional 1.x backwards compatibility 
> test (new maven sub-project, f.ex) would be good to verify applicability.
> I don't have interest in either downgrading dependency, or creating 
> separate hierarchies or providers, as this is legacy support.
>
> But as things are, I am unlikely to have time to work on this actively. I 
> can help, but probably not drive the change.
> PRs would be nice; but in absence of that, stack traces from attempts to 
> use with earlier Jersey versions would be useful.
>
> -+ Tatu +-
>
>
> On Fri, Oct 7, 2016 at 12:28 AM, Николай Гриценко <[email protected]> 
> wrote:
>
>> While I am not very familiar with JAX-RS 2.x specification, I assume It 
>> should have backward compatibility with 1.x. If that is true, I cannot see 
>> any problems of enabling 1.x support in Jackson future releases.
>>
>> So my thought on that is using the specific implementation depending on 
>> environment application has. I feel there is no major issue in that, but 
>> gives a flexibility to framework (like give performance improvements, bug 
>> fixes, etc. to the crowd using old one specs). Besides, It could give you 
>> an advantage of using bleeding edge version of Jackson on old and outdated 
>> environments (legacy, not Jersey 1.x I mean :) ), which will not be updated 
>> to JAX-RS 2.x ever.
>>
>> Thanks,
>> Nick
>>
>> пятница, 7 октября 2016 г., 2:55:07 UTC+3 пользователь Tatu Saloranta 
>> написал:
>>>
>>> First of all, I am not against allowing JAX-RS 1.x usage per se, if and 
>>> as feasible. As long as it does not prevent from supporting 2.x usage which 
>>> is increasing via DropWizard and other platforms that insulate users from 
>>> Jersey (and other JAX-RS implementations).
>>> Simple dropping was based on receiving no feedback indicating there was 
>>> significant usage, so assumption was that JAX-RS 1.x usage was a legacy 
>>> thing.
>>>
>>> Do you think it'd be possible to build against 2.x (needed for the new 
>>> `jaxrs-datatype` module with minimal 2.x type support, which is not useful 
>>> for 1.x), but avoid using 2.x api for core jax-rs provider?
>>> My impression is that there should not be many things that are 
>>> problematic.
>>>
>>> If anyone knows specific problems with provider -- and, if possible, an 
>>> easy way to test compatibility? -- wrt JAX-RS 1.x, as of Jackson 2.8, we 
>>> could definitely consider workarounds.
>>>
>>> -+ Tatu +-
>>>
>>>
>>> On Thu, Oct 6, 2016 at 9:11 AM, Николай Гриценко <[email protected]> 
>>> wrote:
>>>
>>>> Your assumptions are not right. As far as I know many people still uses 
>>>> Jersey 1.x (and JAX-RS 1.x), because of many issues the Jersey 2.x has 
>>>> (e.g. own DI framework, which is hardly compatible with Guice). That is 
>>>> the 
>>>> reason, why many developers stick with version 1.x.
>>>>
>>>> I think It would be nice to have an option to use JAX-RS 1.x or 2.x, 
>>>> depend on environment application has. We want new features of Jackson, 
>>>> but 
>>>> Jersey 2 is frustrating and we cannot upgrade to JAX-RS 2.x
>>>>
>>>> четверг, 12 мая 2016 г., 22:38:50 UTC+3 пользователь Tatu Saloranta 
>>>> написал:
>>>>
>>>>> Quick question: currently Jackson JAX-RS only requires JAX-RS (API) 
>>>>> 1.1 version. But there are some 2.x types that would be nice to support, 
>>>>> so 
>>>>> would it be ok to increase minimum baseline to 2.0?
>>>>> I remember that many Jersey versions uses 1.1 JAX-RS, but don't know 
>>>>> if such versions might still be in active use; I assume they aren't.
>>>>> Please let me know if JAX-RS 1.1 is still widely used.
>>>>>
>>>>> -+ Tatu +-
>>>>>
>>>>>
>>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "jackson-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jackson-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to