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
>>>
>>>
