[resteasy-dev] RESTEasy and possible "community" contribution

[Weinan Li]

--
Weinan Li / JBoss



> On May 5, 2016, at 10:08 PM, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:
> 
> 
> On Thu, May 5, 2016 at 3:58 PM, Marek Kopecky <mkopecky at redhat.com> wrote:
> Is it really necessary to support RESTEasy with JDK7?
> For WF10: Java 7 support has been discontinued allowing for deeper integration with the Java 8 runtime.
> 
> Definitly not anymore, if we go for new major version aka v3 of RestEasy it can easily require Java 8 as minumum.
>  
>>>>>> - I would like to see ARQ + WF10+ and get rid of tjws
>>>>>> 
>>>>> Get ridding of TJWS is not practical because it will make the test time
>>>>> unacceptable. But replacing them with undertow container would be great
>>>>> :-)
>>>>> 
>>>> A lot of tests just don't depend on the environment. I create arquillian
>>>> 
>>> But there are tests which pass on tjws, but failed with WF10 / EAP7, you can check the jira link I shared in previous email or see below
> 	• I run upstream TS on perf-machine. I build resteasy. Then I run tests: 
> 		• Tests tooks 10 minutes.
Do you mean all the tests or the tests included in default profile?

> 	• I run qe-internal-resteasy-ts on the same perf-machine. Qe-internal-resteasy-ts contains all tests from upstream. These tests are run against EAP.
> 		• Tests tooks 13 minutes.
> So in my point of view, test time with ARQ + WF10 is definitelly acceptable.
> 
> ARQ in general, as we can just configure different profiles  for other containers if we want to.
> 
> Having current mess with each test/ module having their own version of jetty / tjsw is just plain wrong.
> 
> Also keep in mind that tjsw was never fully tested against servlet TCK, so fixing any tests code for bugs found on uncertifed platform is just wrong.
Firstly we all hate TJWS :-) 

Secondly I agree with Ron that we need be careful on this part because we maybe swamped into this task. We may spend a lot of time on merely rewritting the currently working tests. And this year we have more important things like supporting JAX-RS 2.1 with still limited human resources.

At last I totally agree that from long term we need to solve this.


> 
>