On 09 Dec 2013, at 19:46, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Hi Marek,
>
> On 09/12/2013 11:04 AM, Marek Potociar wrote:
>> Hello Gili,
>>
>> Your comment does not seem to be fair at all. I'm also not sure that rants like this would help you achieve any improvement or do any good whatsoever.
>>
>> Jersey 2.x has been rewritten from scratch in order to address some of the design issues of Jersey 1.x, esp. around ability to support asynchronous server side invocations and out of the box JSR330 injection. This rewrite means that some things work differently then previously, most of the time things significantly improved. And while we are aware that we are still missing a few features that are available in Jersey 1.x, we're making a constant progress in porting existing Jersey 1.x features into 2.x while making fixes and improvements to these features at the same time. Over the last 5 months we're close to a 5th release of Jersey 2.x continuously resolving the priority-ordered lists of tasks and issues. We have also recently released Jersey 1.18 with many bug fixes for those people who cannot afford to migrate to Jersey 2.x yet. We have also moved all source code to github (both Jersey 1.x and 2.x) to improve and encourage community involvement. Additionally, after years we managed to scrub all old unevaluated issues from our Jira - a pile that has been slowly accumulating since the early days of Jersey project. We have also rolled out a much nicer web site and significantly expanded and improved Jersey user guide documentation and Jersey API javadoc. So, in fact, we have been doing quite a lot for the community around Jersey lately and we're also happy to see community contributions steadily flowing back to Jersey code base.
>
> I am not questioning your hard work, nor the importance of the changes made in Jersey 2.x. I just wish that there was more transparency (two-way communication). For example, until this post I didn't know that you were under the impression that the HK2 bridge problem was specific to Guice and that there was a workaround for it. I believe there is a misunderstanding there (which I discuss below).
>
> While I know that you guys plan to work on the missing Jersey 1.x features, I don't have an idea of when this will be done. I'm not asking for specific dates but it would make a world of a difference if I knew whether we're talking about a month, 3 months or 12 months from now.
Hard to say in general - we do planning from sprint to sprint, always reevaluating issue priorities before planning a new sprint. I know this is a vague response, but I do not have dates that I can commit to. I am also just guessing what features are you interested in. As I told, you, we will invest some more effort into the Guice integration issues after 2.5 release, but I cannot make any promises about the outcome as the problem seems to really be on Guice side.
>
> Sometimes you close bug reports prematurely (before allowing me to justify why the issue should remain open) and you don't respond when I ask you to reopen the issue (e.g. https://java.net/jira/browse/JERSEY-2257).
You created a new issue, which is what I asked you to do and I have responded to it. I do not see a reason to respond to the old issue.
> Ideally, I'd like issues to remain open until there is a consensus (between the reporter and assignee) that they can be closed. Alternatively, reporters should have the ability to reopen issues. Most projects I've seen work this way and people rarely abuse it.
I would certainly support this, but it is not in my hands - please try to contact java.net jira administrators - perhaps you will have a better luck convincing them. The more people are telling them, the better.
> Lastly, I understand your frustration with people telling you HOW to fix a problem instead of explaining WHAT the problem is, but it is not meant to offend. When I propose a specific solution, it is meant as "one way to implement this is..." and nothing else. I won't take offense if you ask me for more information about the problem, nor if you choose to implement it differently than I proposed. All that I ask is that you please check whether your alternate solution actually solves my problem before closing the issue, and I will do my best to provide you with the WHAT for any issues I report.
Understood.
>
>> <skippable-technical-detail>
>> As for the issue Guice integration issue, let me recap the broader perspective - esp. for other observers new to the topic:
>>
>> When we started the Jersey rewrite, we knew that most of the time spent in maintaining Jersey 1.x code has been burned on resolving Jersey 1.x proprietary injection framework issues, so the decision was to get rid of the code and use a dedicated provider instead. And so we switched to HK2 and decided to also delegate any injection framework integration support to HK2 layer. This works well in most cases, however in case of Guice we are running into limitations on Guice end that we are not able to resolve without help from Guice developers, and they do not seem to be willing to make any changes in Guice at the moment. So we're quite stuck. To be specific, Guice does not seem to support delegation of resolving an @Inject-annotated injection point in Guice-managed POJOs to other framework (in our case to HK2). So while HK2-managed POJOs can inject Guice-managed POJOs into their fields (since HK2 has the SPI for delegating the injection resolution to Guice), the opposite way does not work. Guice-managed POJOs cannot inject any HK2-managed POJOs into @javax.inject.Inject annotated injection points as there is no injection resolver delegation SPI for @javax.inject.Inject in Guice. The only available workaround at the moment is to use @Hk2Inject instead of @Inject in Guice-managed POJOs in those places where HK2-based components have to be injected.
>> </skippable-technical-detail>
>
> Actually, @Hk2Inject does not work for this common use-case: https://java.net/jira/browse/HK2-139
IIUC, this is the one aspect of the issue in Guice that I'm talking about - Guice is not calling the HK2 in this case. There's nothing we can do AFAIK unless Guice folks fix the problem. Please correct me if I'm missing something.
> I looked through JIRA and found the following Spring-related 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.1%22%2C+%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+key+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.1%22%2C+%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+key+DESC>
>
> I would like to hear from multiple people using Jersey with Spring because it is genuinely not clear to me whether the HK2-Spring bridge suffers from the same design-level problems as the HK2-Guice bridge or not. Right now I am under the impression that both Guice and Spring support has serious problems.
>
>> So to your issue - I'm sure you remember that we have spent quite some time together in discussions about how to fix the issues you are facing wrt. Guice integration. At the moment however we do not have cycles do more as we're finishing up tasks that have higher priority for us and are planned for Jersey 2.5 release. We will still get back to your issues as soon as we resolve all the higher priority issues in our queue. So I'd like to ask you for patience.
>>
>> Hope this puts things into a broader perspective.
>
> Conversations like this help a lot. Thank you.
Frankly, I wish we could avoid the unnecessarily pointed starts in the future. It would make the conversation more enjoyable on our end :)
Marek
>
> Gili
>
>>
>> Cheers,
>> Marek
>>
>>
>> On 06 Dec 2013, at 20:09, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> I feel your pain. Somewhere between Marc Hadley and Paul Sandoz leaving this project, both the JAX-RS and Jersey 2.0 communities have become quite dysfunctional. About the only response you'll get on this list is "No. We're not dead!" and even then it'll only show up a few days after your post. Contrast this to projects like HK2 where I get an answer within 15 minutes of posting a question, and bugs that I report get fixed within the next release cycle. There are many other projects that are amazing this way. Jersey 1.0 used to be such a project.
>>>
>>> And we're not the only ones who noticed that something is broken. See https://groups.google.com/d/msg/dropwizard-user/w7jqlCqU-00/7EA228e5Ps4J
>>>
>>> There seems to be a strong consensus that Jersey 2.0 is missing critical features from 1.0 and yet they are not receiving top priority. I'd love to see some genuine action to close these gaps. I tried digging into the code myself, in the hopes of producing pull requests, but some of these problems are design-level which make them difficult to fix as an outsider.
>>>
>>> Gili
>>>
>>> On 06/12/2013 10:29 AM, Rodrigo Lopes wrote:
>>>> Has Oracle just abandoned this project?
>>>>
>>>>
>>>> I was checking open tickets for JAX projects; 63 tickets unassigned (100%).
>>>>
>>>> https://java.net/jira/browse/JAX_RS_SPEC/fixforversion/14716
>>>>
>>>> "So what..."
>>>>
>>>> It is in fact worse: You can find junks and SPAMs within the tickets:
>>>>
>>>> https://java.net/jira/browse/JAX_RS_SPEC-276
>>>>
>>>> Has Oracle no more interesting in this spec?
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Rodrigo di Lorenzo Lopes