You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pid <pi...@pidster.com> on 2011/08/21 00:06:26 UTC
[OT] Re: How to handle the AWT-Windows thread?
On 19/08/2011 15:45, Christopher Schultz wrote:
> Dan,
>
> On 8/18/2011 5:22 PM, Dan Armbrust wrote:
>> Toolkit.getDefaultToolkit().createImage(new byte[]{});
>
> Simply calling getDefaultToolkit will do the trick: you don't have to
> waste time creating an image.
>
> I'll implement this in the JreLeakPreventionListener, but it will be
> /disabled/ by default because it creates an extra thread.
For this type of problem would it be useful to intercept the call to
load the class & then trigger the protection 'on demand'?
It might be a bit of a stretch to make it happen safely, admittedly.
p
Re: [OT] Re: How to handle the AWT-Windows thread?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 8/21/2011 4:53 AM, Pid wrote:
> On 21/08/2011 01:19, Christopher Schultz wrote:
>> I'm not sure how one would intercept the call, though. I've
>> never looked into it, but I would guess that
>> Toolkit.getDefaultToolkit can be configured to return an object
>> of a different class -- one that would presumably temporarily set
>> the CCL to the system ClassLoader.
>
> Hmm. Modifying the loadClass(str) method might suffice, on the
> basis that a call to load Toolkit.class is likely to result in a
> Toolkit.getDefaultToolkit() - rather than trying to intercept the
> method call.
Meh. Explicit configuration beats guessing IMHO.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5UHG8ACgkQ9CaO5/Lv0PBPXwCglxYZHLmcnQb4eRyvwmFZ4H4l
kSYAn184s7Mmm1Jr9yrj7FSRmdAfPUbi
=mXUj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: How to handle the AWT-Windows thread?
Posted by Pid <pi...@pidster.com>.
On 21/08/2011 01:19, Christopher Schultz wrote:
> Pid,
>
> On 8/20/2011 6:06 PM, Pid wrote:
>> On 19/08/2011 15:45, Christopher Schultz wrote:
>>> Dan,
>>>
>>> On 8/18/2011 5:22 PM, Dan Armbrust wrote:
>>>> Toolkit.getDefaultToolkit().createImage(new byte[]{});
>>>
>>> Simply calling getDefaultToolkit will do the trick: you don't
>>> have to waste time creating an image.
>>>
>>> I'll implement this in the JreLeakPreventionListener, but it will
>>> be /disabled/ by default because it creates an extra thread.
>
>
>> For this type of problem would it be useful to intercept the call
>> to load the class & then trigger the protection 'on demand'?
>
> I'm not sure how one would intercept the call, though. I've never
> looked into it, but I would guess that Toolkit.getDefaultToolkit can
> be configured to return an object of a different class -- one that
> would presumably temporarily set the CCL to the system ClassLoader.
Hmm. Modifying the loadClass(str) method might suffice, on the basis
that a call to load Toolkit.class is likely to result in a
Toolkit.getDefaultToolkit() - rather than trying to intercept the method
call.
p
>> It might be a bit of a stretch to make it happen safely,
>> admittedly.
>
> +1
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: [OT] Re: How to handle the AWT-Windows thread?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 8/20/2011 6:06 PM, Pid wrote:
> On 19/08/2011 15:45, Christopher Schultz wrote:
>> Dan,
>>
>> On 8/18/2011 5:22 PM, Dan Armbrust wrote:
>>> Toolkit.getDefaultToolkit().createImage(new byte[]{});
>>
>> Simply calling getDefaultToolkit will do the trick: you don't
>> have to waste time creating an image.
>>
>> I'll implement this in the JreLeakPreventionListener, but it will
>> be /disabled/ by default because it creates an extra thread.
>
>
> For this type of problem would it be useful to intercept the call
> to load the class & then trigger the protection 'on demand'?
I'm not sure how one would intercept the call, though. I've never
looked into it, but I would guess that Toolkit.getDefaultToolkit can
be configured to return an object of a different class -- one that
would presumably temporarily set the CCL to the system ClassLoader.
> It might be a bit of a stretch to make it happen safely,
> admittedly.
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5QTxEACgkQ9CaO5/Lv0PCNDwCeIwTKF9JKampBWCuns642qw2T
VOkAn0bFLTeLlSEurbj7mK9NHVeG1F3u
=xK1L
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org