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
> <mailto: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
>> o This covers Guice-specific issues.
>> o Related HK2 issues
>> + https://java.net/jira/browse/HK2-121
>> + https://java.net/jira/browse/HK2-139
>> o 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
>> <https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JERSEY+AND+%28summary+%7E+spring+OR+description+%7E+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
> <http://www.oracle.com/technetwork/community/oca-486395.html>, 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?
>> * 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.
>
>> 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.
> 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.
Gili