Fixed, was related to some test order. A test was using cxf in a close callback and creating a default bus since we already cleaned out bus. Issue was that the default bus doesnt have johnzon etc and the test was using jsonb.
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-17 22:16 GMT+01:00 Romain Manni-Bucau <[email protected]>: > Java8 131 ubuntu and mvn 3.5.2 or idea 2017.2. > > Le 17 févr. 2018 20:12, "Mark Struberg" <[email protected]> a écrit : > >> and broke it again ;) >> >> NFORMATION: Setting the server's publish address to be / >> [20:09:15.645][INFO ][ main][ifecycle.WebContainerLifecycle] >> OpenWebBeans Container has started, it took [23] ms. >> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup] >> REST Application: / -> org.apache.cxf.cdi.DefaultApplication >> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup] >> Service URI: /MultipartTest -> org.apache.meecrowave.Multipar >> tTest$MultiEndpoint >> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup] >> GET /MultipartTest/ -> Map<String, Object> getBooks() >> [20:09:16.659][INFO ][ main][ifecycle.WebContainerLifecycle] >> OpenWebBeans Container was stopped for context path, [] >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.135 sec >> <<< FAILURE! - in org.apache.meecrowave.MultipartTest >> configBinding(org.apache.meecrowave.MultipartTest) Time elapsed: 1.135 >> sec <<< ERROR! >> java.lang.NullPointerException >> at org.apache.meecrowave.MultipartTest.configBinding(MultipartT >> est.java:53) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >> ssorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >> thodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( >> FrameworkMethod.java:50) >> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl >> ectiveCallable.java:12) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr >> ameworkMethod.java:47) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >> InvokeMethod.java:17) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >> 4ClassRunner.java:78) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >> 4ClassRunner.java:57) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> >> >> We need to figure out why your box is green. >> Which jdk do you use? and OS? >> >> Been here on MacBook + Java8-144 and Linux (Fedora27) also java8. >> Both broken.. >> >> LieGrue, >> strub >> >> >> On Saturday, 17 February 2018, 19:00:07 CET, Romain Manni-Bucau < >> [email protected]> wrote: >> >> >> pushed a fix reverting the revert ;) >> >> changes are >> >> 1. we take the classloader from the servlet context instead of the tccl -> >> should be noop but way more secured >> 2. if there is no default bus we set one, avoids the server one to ends up >> being a default classloader and leaking, we also reset it if we set it >> >> hope it should fix most of the issues >> >> >> 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-17 16:48 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> >> > Can you share the 2 locking threads plz? >> > >> > Le 17 févr. 2018 16:41, "Romain Manni-Bucau" <[email protected]> a >> > écrit : >> > >> >> What do you run? Always green here :( >> >> >> >> Le 17 févr. 2018 11:51, "Mark Struberg" <[email protected]> a >> >> écrit : >> >> >> >>> Yes, been deterministic. At my own box but also on Reinhards. Broken >> >>> 100% of all runs. >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> > Am 17.02.2018 um 11:16 schrieb Romain Manni-Bucau < >> >>> [email protected]>: >> >>> > >> >>> > 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 >> >>> >> >>> >> >
