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

[Jim Ma]

On 05/05/2016 09:21 PM, Rostislav Svoboda wrote:
>> They go into the distribution zip file.
>>
> ok, proper isolation in project as suggested by Alession is probably the best option.
> And there will be no regression in stuff delivered in zip.
Should we move these examples under distribution module ? These examples 
should not be placed in same level with core module.


>
>>>>     -- find . | grep pom.xml | grep -v arquillian | grep -v exam | grep -v
>>>>     test | wc -l reports 58 pom.xml files
>>>> - not clear where is the real code and what is just add-odd like examples,
>>>> book stuff
>>>> - naming of modules in not in sync, some are starting resteasy-*, some do
>>>> not have such prefix
>>>>
>>>> Commits:
>>>> - commit messages do not follow same/similar format - see
>>>> https://github.com/resteasy/Resteasy/commits/master
>>>>     -- I would expect jira id at the beginning of the commit message, it's
>>>>     there sometime but in different format - e.g. RESTEASY-1328 vs.
>>>>     [RESTEASY-1331]
>> Even better is the whole URL, so you can click and go there.
> Not so sure, [RESTEASY-xxx] is the best option from my side, jira can handle integration / parsing of commit messages
Agree. [RESTEASY-XXX]: with some description should be enough. We are 
composing
commit message this way for wildfly, cxf and jbossws-cxf.
>
>>>> - massive commit message like
>>>> https://github.com/resteasy/Resteasy/commit/fdd1f9f31edb894fa6f8684f2608224c39519e6c
>>>> - commit related to RESTEASY-1323 are really "fun"
>>>>     -- https://github.com/resteasy/Resteasy/pull/756/files
>>>>     -- one fix in code (4 lines removed) + two tests done in 7 commits :(
>>>>     -- these commits should have been squashed
>>> +1
>>>
>>>> Versions:
>>>> - will leave this to Tomaz :)
>>>>
>>>> TS:
>>>> - unit tests are mixed with integration tests
>>>>     -- integration tests should be in separate module
>>>>     -- tests should be running in different maven phases
>>>> - there are only few tests against WF
>>>> - such tests are not executed against latest WF, but mainly against WF 8
>> At some point I started adding new arquillian tests to RESTEASY-TEST-WF8
>> to reduce the number of times wildfly starts up. I have a
>> RESTEASY-TEST-WF10, but it depends on JDK 1.8, so it's not activated yet.
> Shouldn't be JDK 8 the default ?
> Public JDK 7 is not receiving updates for 1 year - see http://www.oracle.com/technetwork/java/eol-135779.html or http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
> Last release was April 2015
>
>>>> - 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
>
>> tests only when the environment seems to matter. I agree it would be
>> nice to use undertow, but who's going to take the time to do that?
> There is product TS which can be reused / pulled back.
>
>>>> EAP 7 situation for TS:
>>>> - we migrated upstream ts to use ARQ and run against EAP 7 and not tjws
>>>> - we discovered half of reported issues thanks to this migrated TS, these
>>>> issues wouldn't be noticed bu community TS executed against tjws
>>> Totally removing TJWS is also not possible, because many users are using
>>> this 'internal' feature in their production env. We can't estimate how the
>>> impact will be.
> Well, I'm surprised about tjws use in production environment
>
> quick check shows this:
> resteasy-jaxrs-3.0.16.Final-redhat-1.jar | grep tjws
>          0  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/
>       2015  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/TJWSServletDispatcher.class
>       2110  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/TJWSServletServer$FileMappingServe.class
>       5244  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/TJWSServletServer.class
>       1467  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/AuthenticatedHttpServletRequest.class
>       3172  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/TJWSRequestPreProcessor.class
>       3136  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/TJWSEmbeddedJaxrsServer.class
>       2854  02-22-2016 03:06   org/jboss/resteasy/plugins/server/tjws/PatchedHttpServletRequest.class
> resteasy-spring-3.0.16.Final-redhat-1.jar | grep tjws
>          0  02-22-2016 03:09   org/jboss/resteasy/springmvc/tjws/
>       2034  02-22-2016 03:09   org/jboss/resteasy/springmvc/tjws/TJWSEmbeddedSpringMVCServer.class
>       1794  02-22-2016 03:09   org/jboss/resteasy/springmvc/tjws/TJWSSpringMVCDispatcher.class
>       2809  02-22-2016 03:09   org/jboss/resteasy/springmvc/tjws/TJWSEmbeddedSpringMVCServerBean.class
>
>
> Do you know more about customer use-cases ?
>
>> Yeah, I learned that only recently. I'm amazed. But it's true: "If it's
>> there, they'll use it."
> Agree, it's bad that we realized that so late :(
Is tjws the thing we have to support for customer? If yes, do we only 
support our forked
tjws , and not the tjws upstream version ?