On 07 Nov 2013, at 18:23, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 07/11/2013 10:49 AM, Marek Potociar wrote:
>> 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.)
>
> Discussed in our other thread ("Re: jersey-guice based on spring-guice"), so I won't respond here.
>
>>
>>> 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.)
>
> Same here. I'll give this some more thought.
>
>>> https://java.net/jira/browse/JERSEY-2184
>> Has been targeted for 2.5 already.
>
> Thank you.
>
>>> 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.
>
> Can you please change Affect
>
>>> 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?)
>
> I'm having serious problems building Jersey2 (see https://java.net/jira/browse/JERSEY-2173). As soon as that's resolved, I'd be glad to do so. I *think* I signed OCA a few years ago, but I don't remember. How do we check?
If you signed, you would be in the signatory list on this page:
http://www.oracle.com/technetwork/community/oca-486395.html (Is this you? "Gili Tzabari - JDK Glassfish java.net - cowwoc")
>
>>> https://java.net/jira/browse/JERSEY-2175
>> Has been targeted for 2.5.
>
> Thank you.
>
>>> 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.
>
> Okay. Is there an issue tracking this task? I'd like to add a Watch to it.
Yes, independently of our discussion, I have added the task about a week ago and targeted it for 2.6 release timeframe -
https://java.net/jira/browse/JERSEY-2194
>
>>
>>> 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.
>
> I meant you should have asked the community *before* tossing out features, like ResourceContext.matchResource(URI) ... but yes, I appreciate the dialogue we are having now.
>
>>
>>>> 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.
>
> Marek, I'm sorry but I don't believe I'm the only one who feels this way. I've discussed this topic off-list and others have expressed the opinion that Jersey 2.x was released prematurely. I'm not saying this to blame anyone. I just want you to understand that although many of us would like to upgrade to 2.0, we feel that we're simply not able to yet.
I am not suggesting that you would be alone in your feelings or that you should not feel that you cannot move your project to Jersey 2.x. I completely understand that Jersey 2.x may not feel ready for those who heavily depends on Guice or Spring or some other contributed Jersey 1.x extension that has not been 1:1 ported to 2.x (yet). And I am not happy that we were not able to fully port all the extensions to Jersey 2.x so far.
Yet, making bold statements about Jersey 2.x not being production ready is something I simply cannot agree. Production readiness is not about being on par with support for community-contributed extensions. There's a big difference between a missing extension feature and production readiness.
Of course, community can expect us to quickly address any functional or performance bugs in the core Jersey modules (as Jersey 2.x is a complete rewrite, mostly "from scratch" to fit in the async server-side support and other features and we have not yet found a way how to write a bug-free code).
OTOH, our resources are not unlimited and as such we expect community to help us with porting some of the non-essential extensions. We are also open to any feedback, suggestions or discussions around design or API improvements.
>> 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?
>
> I've addressed this in our other discussion thread ("Re: jersey-guice based on spring-guice").
>
>> 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.
>
> I've been trying really really hard to do so. Honestly. As I explained above, I'm running into a lot of problems building Jersey.
>
> I don't feel that design-level issues (such as HK2, Guice, Spring) should be addressed via GitHub push requests. We need to agree on a design first, and *then* I will contribute push requests. I hope you agree on this point.
> For all other issues, I will definitely try to contribute push requests.
So what is your design-level proposal? (Let's move it to a new thread, if you have a proposal to discuss.)
Marek
>
> Gili