maven-surefire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenney Westerhof <ken...@apache.org>
Subject Re: useSystemClassLoader problems
Date Mon, 04 Jun 2007 12:20:15 GMT


Brett Porter wrote:
> Thanks Kenney!
> 
> Please make sure to merge that up to the 2.3.x branch - this will close 
> out SUREFIRE-335.

Merged trunk to branch. I merged the last 3 revisions from trunk; the one before
that was a merge from you from branch to trunk. It cleanly installs so I hope
I merged the correct things.

Haven't deployed it yet; I'd rather let you do it after you check SUREFIRe-335.

-- Kenney

> 
> Cheers,
> Brett
> 
> On 04/06/2007, at 9:43 PM, Kenney Westerhof wrote:
> 
>>
>>
>> Kenney Westerhof wrote:
>>
>>> Brett Porter wrote:
>>
>> [snip]
>>
>>>> However, I'm rethinking setting it to default (which I did) - seems 
>>>> best to retain it as false. I did it because of another regression 
>>>> where clases in the system classloader weren't found in tests by 
>>>> default any more. I think that's just an omission in creating the 
>>>> isolated classloader that can be fixed differently.
>>
>> I'm setting it back to false now.
>>
>> I found the cause of the regression - due to the fact that the default 
>> for useSystemClassloader was true,
>> this bug was made evident.
>>
>> The combination of forkmode=never and useSystemClassLoader produced 
>> illegal classloaders.
>> Surefirebooter itself didn't check wheter it was forking, and just 
>> used the system classloader,
>> even if it wasn't forking. Ofcourse, when it uses the system 
>> classloader, it can't add the testcases.
>> The usesystemclassloader basically means 'don't construct a 
>> classloader for the tests, they
>> are already present in the system classloader'.
>>
>> I refactored surefirebooter to include the usesystemclassloader in the 
>> forkConfiguration.
>> the 'isUseSystemClassLoader' method checks wheter forking is enabled 
>> in addittion to the useSCL flag.
>>
>> I think this fixes a lot of regressions.
>>
>> Note: by moving the flag to the fork configuration, i have to 
>> construct a new forkconfig in main()
>> otherwise it NPE's. I set the forkmode to never and the useSystemCL 
>> flag accordingly. In the runsuitesinprocess
>> only the forkconfig.useSystemCL is used.
>> Design-wise, the configuration used in the runSuitesInProcess methods 
>> should be different from the
>> global config and ideally the useSystemCL should be present globally, 
>> or wrapped in another class.
>> However, having 2 places to look for a flag is error prone. I know 
>> this design may not be the best
>> avail, but at least now there's no difference anymore between calling 
>> surefirebooter from main() or via run().
>>
>> I deployed new snapshots of surefire for people to test. I hope this 
>> fixes your regressions.
>>
>> -- Kenney

Mime
View raw message