On 06/02/2016 05:47 AM, Rostislav Svoboda wrote:
------------------------------------------------------------------------
Il 01/06/2016 19:27, Ron Sigal ha scritto:
On 06/01/2016 04:16 AM, Alessio Soldano wrote:
Il 01/06/2016 03:14, Ron Sigal ha scritto:
Hi guys,
After slogging through as many bug JIRAs as possible
for 3.0.17.Final, I felt like I needed to do something
different for a while, so I started looking at
non-blocking IO for JAX-RS 2.1. One of the issues I
ran into is the servlet version problem. Even though
resteasy-jaxrs declares a dependency on servlet 3.1,
its dependency on tjws brings in servlet 2.5, which
gets in the way of using servlet 3.1. I've done some
refactoring:
1) moved everything related to tjws from
resteasy-jaxrs to tjws
2) moved all tests (except i18n tests) from
resteasy-jaxrs to resteasy-jaxrs-testsuite (so
resteasy-jaxrs doesn't depend on tjws)
3) removed the dependency of resteasy-jaxrs on tjws
4) created a dependency of tjws on resteasy-jaxrs
I thought I'd ask for comments before I create a pull
request. Two points come to mind:
1) Originally, resteasy-jaxrs-testsuite was created to
hold tests specifically related to JAX-RS 2.0 (hence
the nextgen packages). The plan was to upgrade all of
the old tests to use JAX-RS 2.0 stuff like the new
client framework, but it never happened. This might be
a good time to do that.
+1, we should try to get rid of all those warnings about
old client stuff in the build. And given we're working on
a new minor and that stuff was deprecated in 3.0.x, we
could actually think about removing the old client framework.
Given that we have some large pieces pieces ready to deprecate
(old client framework, TJWS, old validation (see my previous
note on mailing list), maybe we should do a 3.0.18.Final
release in which all this stuff is deprecated so that we can
start 3.1.0.Final with a clean slate. Just a thought.
Yeah, that would be nice.We should then backport
https://github.com/resteasy/Resteasy/pull/821/commits/db988a936fef4a7c602...
to the 3.0.x branch as well as the commit that will deprecate the
old validation stuff. Perhaps the 3.0.18.Final release should also
include few bug fixes, so we could wait some weeks and see if
there's anything really relevant to be backported there (and
better justify the release) ;-)
Don't forget that EAP 7.0.z will need RESTEasy 3.0.z releases and
there are quite strict rules for CP stream to limit scope and prevent
regressions. Things which should be fixed must be approved via CP
triage and are usually proposed by GSS.
So 3.0.18.Final should be release for deprecation of stuff ++ bug
fixes requested via EAP 7.0.z CP stream.
Ok, so we could wait a little to see if any EAP 7.0.z bugs show up. I
think I have one to propose, in fact, but I have to look a little more
closely.
Rostislav
2) I know we've talked about what to do with tjws, but
I don't know if we reached a conclusion. This would be
a good time to deprecate it, if we're going to do that.
+1, sure.
I'd be glad to review your PR on this. It should be the
first step to revisiting the testsuite to default to using
WFLY as container.
I created RESTEASY-1410 "Segregate TJWS from resteasy-jaxrs"
and PR
https://github.com/resteasy/Resteasy/pull/821. Since
you agree that we should deprecate TJWS, I'll do one more
commit in which all of the TJWS classes are @deprecated.
Cool thanks.
I'm testing the PR on top of current HEAD and merging if
everything is fine (and I think it is)
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
My company's smarter than your company (unless you work for Red Hat)