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

Reply via email to