[rfc][icedtea-web] save runn urls to property

[Jiri Vanek]

On 03/05/2014 05:23 PM, Jiri Vanek wrote:
> On 03/05/2014 03:16 PM, Andrew Azores wrote:
>> On 03/05/2014 09:19 AM, Jiri Vanek wrote:
>>> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>>>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>>>> hi!
>>>>>
>>>>> As java abrt connector is sending quite good reports, the url, on which I can reproduce the
>>>>> issue is missing. So always my first question in bug is "may you please post url" ?
>>>>>
>>>>> Also java connector is printing out system properties. So it crossed my mind to store the
>>>>> launched jnlps/htmls for this usage. I have quite mixed feelings about it but do not have it
>>>>> makes java-abrt-connector a bit useless (users donot care to much about auto generated bugs)
>>>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>>>
>>>>> This needs also some more work on java-abrt-conenctor - see
>>>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>>>
>>>>> J.
>>>>
>>>> I like the intent behind the patch but I don't know if I really like using system properties for
>>>> this :/
>>>
>>> I'm not sure with them too:(
>>>
>>> > not that I have any better ideas off the top of my head.
>>>
>>> The abrt agent can actually do anything. My another idea is to store it in some static (private)
>>> variable. The whitleist in issue 34 will then be package.class fieldName
>>
>> I didn't know that this would be an option. This sounds much, much better to me.
>>
>>>
>>> > But this just does not seem to me like what the properties are meant to be used for.
>>>
>>> Agree. And my concern is that with this, *maybe* (but probably) all appelts which can read
>>> properties, will be able to spy history.
>>
>> Yea, and this is really not a good mechanism to be providing.
>>
>>>
>>> I have commented also https://github.com/jfilak/abrt-java-connector/issues/34
>>>> It seems like nobody else is chiming in with any better ideas, and you're right that the
>>>> automatic bug reports are a little bit useless without something like this, so if you have no
>>>> better implementations in mind then I suppose this will have to suffice.
>>>
>>> What do you thnk about this approach? (otherwise it will be same)
>>> Thank you!
>>>
>
> So here is version with field.

  So here is version with method. We agreed on it today With Jakub.

Andrew, I.m still using the string. Although I was thinking about usage of:
         if (!history.contains(documentBase)){
             JNLPRuntime.history += " " + documentBase + " ";
         }
I think it can be interesting to know number of reloads.
Also I wont to have string since begining (not set - method -> sting) as any logic after OOM error, 
can be undoable. But String will be still possible to dig.


>
> the whitelist then will be:
> netx.net.sourceforge.jnlp.runtime.JNLPRuntime history

netx.net.sourceforge.jnlp.runtime.JNLPRuntime getHistory

(or whatever, but it is still private method)

The comment is added as Omair wonted. The synchronization was *not* added.  I really think it do not 
belongs here.


J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abrtMethod.diff
Type: text/x-patch
Size: 2655 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140307/4b5b6027/abrtMethod.diff