Le 17 févr. 2018 10:09, "Mark Struberg" <[email protected]> a écrit :
In the test there are 2 classloaders involved. a.) the client side b.) the server (tomcat). with the setExtension using the current TCCL we kind of leak the Tomcat CL into the client it seems. It blows up with the Tomcat ParallelWebAppClassloader already not being active anymore. And the location where this happens is on the client side (transforming the attachment FROM jsonb to object). i've also seen random CL errors in our real world project in the last week. Might have something to do as well... In webapp case then cause in classpath mode it should be the same. Issue is more the client inherit from the default bus instead of using its own bus but it always has been this way. Isnt it a side effect of creating a classloader to run tests in parallel? Are you able to reproduce it deterministicly? LieGrue, strub > Am 17.02.2018 um 09:41 schrieb Romain Manni-Bucau <[email protected]>: > > Le 16 févr. 2018 22:07, "Mark Struberg" <[email protected]> a > écrit : > > Hi Romain! > > Reinhard managed to reproduce the issue when running the latest MW source > on his box. > > With git-bisect we figured it has to do with r1822816 > > MeecrowaveBus > "simplifying MeecrowaveBus and enforcing the classloader to avoid to rely > on resource in ServletController when unneeded" > > The main change is to move the TCCL resolution and calling setExtension. > This seems to break the Tomcat ParallelWebAppClassLoader. > Rather it seems that the cleanup then is being performed on the tomcat > side, even if the server is already shut down. > > I gonna revert this change for now to make all tests pass again. > But tbh I have no clue what setExtension does in detail so plz review it. > > > > This is the classloader usee by the cxf deployment everywhere. If not det > it is trivial not have a broken setup during all the other loading and > deployment. > > How does it lock parallel loading? I cant reproduce it. > > > > > > > LieGrue, > strub & Reinhard > > >> Am 16.02.2018 um 15:42 schrieb Mark Struberg <[email protected]>: >> >> -DreuseForks=false indeed lets the problem go away. >> >> Now we need to find out where this side effect is coming from. >> >> LieGrue, >> strub >> >>> Am 16.02.2018 um 14:31 schrieb Romain Manni-Bucau <[email protected] >> : >>> >>> Hi Mark, can't reproduce it but used a johnzon 1.1.6 created from the >>> 1.1.7-SNAPSHOT since the tag is not pushed on asf yet. Not sure it has an >>> impact or if it is the test order which is responsible of it.Maybe try >>> forcing reuseFork=false in surefire to validate this hypothesis >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ > rmannibucau> | >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java- > ee-8-high-performance> >>> >>> 2018-02-16 13:56 GMT+01:00 Mark Struberg <[email protected]>: >>> >>>> no worries, we first have to fix a seemingly random test failure in MW >>>> anyway >>>> >>>> Tests in error: >>>> MultipartTest.configBinding:51 » ResponseProcessing Problem with reading >>>> the d... >>>> >>>> happens only when this test is executed with all other tests. >>>> Wenn running the test alone all is green. >>>> >>>> Anyone want's to take that up? >>>> I'm offline for the next few hours now. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>>> Am 16.02.2018 um 13:49 schrieb Romain Manni-Bucau < > [email protected] >>>>> : >>>>> >>>>> +1 >>>>> >>>>> Side note: can you ensure it is either not deployed or staging repo are >>>> in >>>>> the pom to not break early consumers please? >>>>> >>>>> >>>>> Le 16 févr. 2018 13:19, "Mark Struberg" <[email protected]> a >>>>> écrit : >>>>> >>>>>> will roll a MW release in the afternoon. >>>>>> >>>>>> Currently testing the updates to the staged versions. >>>>>> >>>>>> LieGrue, >>>>>> strub
