[rfc][icedtea-web] Fix CacheReproducerTest

Jiri Vanek jvanek at redhat.com
Wed Sep 4 09:21:48 PDT 2013

On 09/04/2013 06:15 PM, Andrew Azores wrote:
> On 09/04/2013 10:49 AM, Jiri Vanek wrote:
>> On 09/04/2013 04:40 PM, Andrew Azores wrote:
>>> On 09/02/2013 05:22 AM, Jiri Vanek wrote:
>>>>> Nope, rather make it public. Anyaway, as others suggested, Can you
>>>>> tray to use DeploymentConfiguration singleton to get real location of
>>>>> cache. If you think it is good idea, then go with it.
>>> I've just gone and put it back to using the value out of the Defaults
>>> class. Maybe the DeploymentConfiguration idea can be put into a
>>> different test, but for now I'll just leave it with the "safe" Defaults
>> Why so?
> That way these existing tests should be testing whether or not the
> caching mechanism in general is working properly, since the path
> specified in Defaults is very likely to be a workable cache location
> (read/write allowed for example). I'd like there to be a test using the
> DeploymentConfiguration values just to ensure that caching truly is
> working on a system, not just "in theory", but the more I think about it
> the more it seems like this is an additional responsibility that this
> test shouldn't necessarily be taking on.

More and more I think about it I think the usage of DeploymentConfiguration is the right way even there.

But nvm, ok for head.

Also I would place the

+        String messageResourcePath = "net/sourceforge/jnlp/resources/Messages.properties";
+        PropertyResourceBundle messageBundle = new

as public static (final) (at lease the messageResourcePath  made no harm) and messageBundle would be
loaded in constructor or in static{} block. But do as you wish. For this test case I do not insist.

>>> value. Also fixed some indentation and changed
>>> ServerAccess.ProcessResult to the non-deprecated ProcessResult - figured
>>> I might as well clear out the deprecation warnings while I was tinkering
>> Sure :)
>>> in there.
>>> Thanks,
>>> -- Andrew A
>>> CacheReproducerTest.patch
>> ...
>>>                    }
>>> @@ -269,7 +271,7 @@
>>>            t.start();
>>>            Thread.sleep(1000);
>>>            pr = tryToClearcache();
>>> -        String q = "Can not clear cache at this time";
>>> +        String q = "Can not clear the cache at this time";
>> To aovid this in future I would suggest to load properties file and search by key. (yes you can
>> directly load messages.properties to local Properties variable) You can find inspiration in
>> Localisation tests.
>> ...snip...
>> Otehrwise looks good.
> Ah yes, of course. Thanks, added that.

More information about the distro-pkg-dev mailing list