On 05/11/2013 3:03 PM, Marek Potociar wrote:
>
> On 29 Oct 2013, at 16:12, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
>> On 29/10/2013 9:41 AM, phil swenson wrote:
>>> are any of these issues on the roadmap? asking for another team as
>>> they say they can't upgrade to jersey 2
>>>
>>> 1. Jersey 2 still does not support the equinox specific bundleentry
>>> URI which is required in order to be able to use the packages
>>> scanning capabilities of Jersey (e.g. list packages containing
>>> resources/providers in web.xml and dynamically register the
>>> containing resources/providers). The same issue was present i
>>> Jersey 1.x but there was an option to register custom URI Schema
>>> Scanner using the
>>> com.sun.jersey.core.spi.scanning.uri.UriSchemeScanner class.
>>> However, Jersey 2 has "TODO" comments for such SPIs and users
>>> are unable to register custom URI Schema Scanners. This means
>>> that equinox users cannot use the packages scanning option and
>>> should list each resource/provider explicitly.
>>> 2. As another solution for the URI issue in 2. and also for faster
>>> resources startup time in Jersey 1.x we used a
>>> CCApplication which uses WebConig and ServletContext injected
>>> with @Context. Using the injected context instances we were able
>>> to get the listed packages from web.xml and dynamically register
>>> the containing providers/resources. However, for some reason
>>> Jersey 2 cannot inject any @Context instances in
>>> ResourceConfig/Application and we cannot get access to the
>>> init-params (including the listed packages) from web.xml file.
>>> 3. OSGI JAX-RS Connector does not work in Jersey 2. Trying to
>>> access a resource fails with "/java.lang.IllegalStateException:
>>> The resource configuration is not modifiable in this context./".
>>> Debugging shows that internally Jersey uses "ImmutableState"
>>> objects which cannot be modified by the OSGi JAX-RS Connector.
>>> Note that the connector works fine in Jersey 1.x.
>>>
>>
>> I echo Phil's sentiments. There is a long line of use-cases that
>> used to work in 1.0 but no longer do in 2.0 (regressions). It would
>> help to receive some official acknowledgment from the committers that
>> these are high-priority and will be addressed before adding other
>> functionality.
>
>
> 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):
*
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>
*
https://java.net/jira/browse/JERSEY-2172
*
https://java.net/jira/browse/JERSEY-2184
*
https://java.net/jira/browse/JERSEY-1564
*
https://java.net/jira/browse/JERSEY-1893
*
https://java.net/jira/browse/JERSEY-2175
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 :( 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.
> 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.
Gili