works on my machine too ;) thx romain
lg reini > Am 18.02.2018 um 18:01 schrieb Romain Manni-Bucau <[email protected]>: > > 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 >>>>>> >>>>>> >>> >>
