users@jersey.java.net

[Jersey] Re: osgi issues with Jersey 2.0

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 7 Nov 2013 16:49:09 +0100

Hi Gili,

On 05 Nov 2013, at 22:32, cowwoc <cowwoc_at_bbs.darktech.org> wrote:

> On 05/11/2013 3:03 PM, Marek Potociar wrote:
>>
>> What CORE functionality is missing? Can you please send us the list?
>> As for contributed extensions of Jersey 1.x still missing in Jersey 2.x, we are doing as much as we can (at the fastest pace that we can), but it is certainly not the highest priority for us. We do always welcome community contributions though ;-)
>
> Hi Marek,
>
> Here is a list I am personally aware of (I'm sure there are others):

Thanks for the list.

> https://java.net/jira/browse/JERSEY-1950
> This covers Guice-specific issues.
> Related HK2 issues
> https://java.net/jira/browse/HK2-121
> https://java.net/jira/browse/HK2-139
> Countless Spring-specific issues: https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JERSEY+AND+%28summary+~+spring+OR+description+~+spring%29+AND+resolution+%3D+Unresolved+AND+affectedVersion+in+%28%222.4%22%2C+%222.3.1%22%2C+%222.3%22%2C+%222.2%22%2C+%222.1%22%2C+%222.0%22%29+ORDER+BY+priority+DESC
For the issues above, note that Guice and Spring support are not considered to be core part of Jersey functionality. (And yes, I understand that for people who are used to working with Guice or Spring, the integration is important. My answer to that is - get involved and give us a hand in the effort to improve the integration of these two worlds.)

> https://java.net/jira/browse/JERSEY-2172
I need to take some quiet time to look at this deeper. There may be a better way to do what you want. (But, again, maybe there isn't.)
> https://java.net/jira/browse/JERSEY-2184
Has been targeted for 2.5 already.
> https://java.net/jira/browse/JERSEY-1564
Unless we receive a GitHub pull request, we will not do it in the near future. The reason is that we do not plan to actively invest effort in adding more new functionality to Jersey 1.x codebase. (Same for JERSEY-1561) Obviously, fixing bugs, esp. in core Jersey is a different story; we will continue take care of fixing bugs and accepting contributions. All the new features will however be mainly targeted to Jersey 2.x codebase.
> https://java.net/jira/browse/JERSEY-1893
Can you please submit the patch as a GitHub pull request? (I assume you have already signed OCA, right?)
> https://java.net/jira/browse/JERSEY-2175
Has been targeted for 2.5.
> Most of these use-cases were covered by the Jersey 1.x unit tests. Instead of migrating these tests to Jersey 2.x, it looks like many of them were simply thrown out :(

As you can tell, migrating Jersey 1.x unit tests is not completely straightforward and certainly not a low-effort task. We have already migrated majority of the tests, but there is still a number of tests awaiting migration.

> I know you mentioned some cases where the committers didn't understand the use-case and couldn't agree on a good way to implement it so the feature was tossed out. I wish you would have brought these features to the community's attention because we would have explained to you how these features were used and why they could not be tossed out.

I believe this is what we are doing right now, aren't we.

>> FWIW, we have not retired Jersey 1.x yet. We still actively sustain it. We are actually investing 100% of all our resources currently to slate Jersey 1.18 release in the next couple of weeks.
>
> I understand, but I've seen quite a bit of issues closed as WON'T FIX with a comment "this feature has changed in 2.x, as such we don't plan to address it in 1.x". It feels like you're pushing users to upgrade but 2.x isn't actually ready for production due to the aforementioned issues. I don't think you should be pushing users to 2.x until all 1.x features are migrated. It feels like we're being stuck between a rock and a hard place.

As much as we try to provide support to Jersey community, I strongly disagree with your view on Jersey 2.x not being production ready. Just because we currently lack extension support of a few of your favourite libraries, which have been somewhat (but not necessarily in all the main scenarios) supported in Jersey 1.x, that does not make Jersey 2.x less production ready. Why don't you complain at Spring or Guice forums why they do not become CDI compliant? Or why don't you complain at Guice forum to release the JSR-330 ownership to JCP community so that someone can pick up that specification and add the missing standard injection binding definition API?

In general, if you want a feature (or a fix) and we do not seem to consider it to be the top priority, feel free to contribute the feature. We have switched Jersey 1.x to git last week and mirrored it on GitHub to make contributions as simple as possible.

Marek

>
> Gili