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. > MultipartTest$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( > MultipartTest.java:53) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.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( > ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively( > FrameworkMethod.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( > BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild( > BlockJUnit4ClassRunner.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 > >>> > >>> >
