One new change (was Re: 2nd round code review request: 7055363: jdk_security3 cleanup)

[Xuelei Fan]

No better solution. The update sounds fine to me.

Xuelei

On 8/7/2011 11:19 AM, Weijun Wang wrote:
> 
> 
> On 08/04/2011 10:38 AM, Xuelei Fan wrote:
>> On 8/4/2011 10:34 AM, Weijun Wang wrote:
>>> Oh, that's true.
>>>
>>> I'll add it back. Why did I remove it at the first place?
>>>
>> You may not have to add it back, the library tag may help to build the
>> dependent classes. Maybe, we have some incorrect understand of the
>> "build" tag.
> 
> A @build is needed here. The ResetModule file is loaded as a JAAS
> configuration provider. The class is not directly referenced in the test
> and will not be automatically compiled.
> 
> In fact, JAAS uses the thread context class loader to load a
> Configuration provider, so even if ResetModule is built, it still cannot
> be loaded.
> 
> I've update the test with a dirty hack:
> 
> --- a/test/javax/security/auth/login/LoginContext/ResetConfigModule.java
> +++ b/test/javax/security/auth/login/LoginContext/ResetConfigModule.java
> @@ -25,7 +25,6 @@
>   * @test
>   * @bug 4633622
>   * @summary  bug in LoginContext when Configuration is subclassed
> - *
>   * @build ResetConfigModule ResetModule
>   * @run main ResetConfigModule
>   */
> @@ -40,32 +39,40 @@
> 
>      public static void main(String[] args) throws Exception {
> 
> +        Thread.currentThread().setContextClassLoader(
> +                ResetConfigModule.class.getClassLoader());
> 
> Please confirm this is OK. Or, do you have a better solution?
> 
> BTW, I've asked about this in another mail but no reply yet:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007286.html
> 
> 
> Thanks
> Max
> 
>>
>> Xuelei
>>
>>> Thanks
>>> Max
>>>
>>> On 08/04/2011 10:11 AM, Xuelei Fan wrote:
>>>> . test/javax/security/auth/login/LoginContext/ResetConfigModule.java
>>>>
>>>> You removed the "run" tag, and "build" tag is the last tag. It seems
>>>> that the test will only run building, but not run the class.main(). I
>>>> got the strange behavior when I run some tests with build tag with
>>>> jtreg
>>>> 4.1 b03. Did you come into the same issue?
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 8/3/2011 11:50 AM, Weijun Wang wrote:
>>>>>
>>>>>
>>>>> On 08/03/2011 12:43 AM, Alan Bateman wrote:
>>>>>> Weijun Wang wrote:
>>>>>>> Hi All
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/
>>>>>> I went through the changes to the tests and they look okay to me.
>>>>>> It's
>>>>>> good to see so many tests removed from the problem list and the tests
>>>>>> updated to work in samevm or agentvm mode.
>>>>>>
>>>>>> Is there a bug created for the ec tests that are failing on
>>>>>> solaris-i586? If so then it would be good to include the bugID for
>>>>>
>>>>> I thought there was one but I cannot find it. *Vinnie*, do you know
>>>>> it?
>>>>>
>>>>>> future edits to the problem list. Also I see you've commented out
>>>>>> two ec
>>>>>> tests and I wonder if these lines should be removed or uncommented.
>>>>>
>>>>> I don't understand why these 2 pass now. Maybe they still fail on some
>>>>> platforms not in JPRT? Anyway, I just don't want to purge the lines.
>>>>>
>>>>>>
>>>>>> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no
>>>>>> problem
>>>>>> with your change but I notice this test using URL's getFile which
>>>>>> isn't
>>>>>> the right way to get to a file path. Could this be changed to using
>>>>>> File(URI)?
>>>>>
>>>>> This test is a compatibility check, see
>>>>>
>>>>>      http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b
>>>>>
>>>>> I remember there were some strange things on Windows, say, UNC, \
>>>>> vs /,
>>>>> that made some hand-crafted URL illegal. We cannot support all of
>>>>> them,
>>>>> so just make sure the old supported ones are still supported.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>>
>>>>>> -Alan.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>