Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24753 > unrolled thread

What would stop Applet from re-loading after page refresh?

Back to article view | Back to comp.lang.java.programmer

Contents

  What would stop Applet from re-loading after page refresh? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-18 22:36 +0800
    Re: What would stop Applet from re-loading after page refresh? Knute Johnson <nospam@knutejohnson.com> - 2013-07-18 17:42 -0700
      Re: What would stop Applet from re-loading after page refresh? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 09:00 +0800
        Re: What would stop Applet from re-loading after page refresh? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-22 17:48 +0800
          Re: What would stop Applet from re-loading after page refresh? Arne Vajhøj <arne@vajhoej.dk> - 2013-07-22 22:03 -0400

#24753 — What would stop Applet from re-loading after page refresh?

Hi,

I have an Applet that is loaded dynamically at run-time with the 
<object> tag loaded into a DIV with innerHTML. Everything seems peachy 
and all works well until I refresh the page and then after what appears 
to be a very successful destroy() method, I get nothing more in the Java 
console with logging set to 5. My own console.log() message in 
Javascript tell me the ERROR java_status_event is called when trying to 
reload the Applet (no init() activity).

Via a simple SSCcE I tested STATIC variable LiveConnect/JSObject, 
SYNCHRONIZED Methods, and delaying the destroy() but the light versions 
all refresh and reload without issue. (BTW there is no on-screen 
footprint/output for the Applet).

So my question is does anyone have an idea what is causing the 
full-version of the Applet to have problems reloading on a refresh?

Is there something being left-behind that is stopping the new version?

Cheers Richard Maher

PS. Classloader cache is shared/default. There are additional Threads 
created. It is unsigned and sand-boxed. Java 7.

[toc] | [next] | [standalone]

#24754

On 7/18/2013 7:36 AM, Richard Maher wrote:
> Hi,
>
> I have an Applet that is loaded dynamically at run-time with the
> <object> tag loaded into a DIV with innerHTML. Everything seems peachy
> and all works well until I refresh the page and then after what appears
> to be a very successful destroy() method, I get nothing more in the Java
> console with logging set to 5. My own console.log() message in
> Javascript tell me the ERROR java_status_event is called when trying to
> reload the Applet (no init() activity).
>
> Via a simple SSCcE I tested STATIC variable LiveConnect/JSObject,
> SYNCHRONIZED Methods, and delaying the destroy() but the light versions
> all refresh and reload without issue. (BTW there is no on-screen
> footprint/output for the Applet).
>
> So my question is does anyone have an idea what is causing the
> full-version of the Applet to have problems reloading on a refresh?
>
> Is there something being left-behind that is stopping the new version?
>
> Cheers Richard Maher
>
> PS. Classloader cache is shared/default. There are additional Threads
> created. It is unsigned and sand-boxed. Java 7.

What exactly do you do in the destroy() method?  Have you tried not 
destroying it?

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#24767

On 7/19/2013 8:42 AM, Knute Johnson wrote:
  created. It is unsigned and sand-boxed. Java 7.
>
> What exactly do you do in the destroy() method?  Have you tried not
> destroying it?
>

Nah, I sort of need that.

My guess is Java.util.logging which I'm replacing with my own logger anyway.

I'm in the middle of a whole lot of other changes at the mo and will hit 
it again later but 7.25 seemed to have big changes with JUL so that's 
where my money is anyway.

It's just a shame when the java_status_events call ERROR and the status 
is a definite 3 that we can't get the error somewhere.

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#24801

On 7/20/2013 9:00 AM, Richard Maher wrote:
> On 7/19/2013 8:42 AM, Knute Johnson wrote:
>   created. It is unsigned and sand-boxed. Java 7.
>>
>> What exactly do you do in the destroy() method?  Have you tried not
>> destroying it?
>>
>
> Nah, I sort of need that.
>
> My guess is Java.util.logging which I'm replacing with my own logger
> anyway.
>
> I'm in the middle of a whole lot of other changes at the mo and will hit
> it again later but 7.25 seemed to have big changes with JUL so that's
> where my money is anyway.
>
> It's just a shame when the java_status_events call ERROR and the status
> is a definite 3 that we can't get the error somewhere.
>
> Cheers Richard Maher
>
If anyone is interested is does look like JUL was causing the problem. I 
added it to my SSCcE and it also failed to refresh only this time I got 
some console output: -

basic: Starting applet teardown
Shutting down
basic: PluginMain.unregisterApplet: 1 from mananger 
sun.plugin2.applet.Applet2Manager@1ddf47e
basic: Finished applet teardown
basic: Added progress listener: 
sun.plugin.util.ProgressMonitorAdapter@1bd2c04
basic: Plugin2ClassLoader.addURL parent called for 
http://1.2.3.4/tier3Client.jar
basic: Plugin2ClassLoader.addURL parent called for 
http://1.2.3.4/LocalGUI.jar
security: SSV validation: running: 1.7.0_25, requested: 1.7.0.25, range: 
null
network: Created version ID: 1.7.0.25
network: Created version ID: 1.7.0.25
security: continue with running version
basic: exception: java.lang.reflect.InvocationTargetException.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
                 at 
com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.runOnEDTAndWait(Unknown 
Source)
                 at 
com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.instantiateApplet(Unknown 
Source)
                 at 
sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
                 at 
sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown 
Source)
                 at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
                 at 
com.sun.deploy.uitoolkit.impl.awt.OldPluginAWTUtil.invokeAndWait(Unknown 
Source)
                 ... 5 more
Caused by: java.lang.NullPointerException
                 at java.util.logging.Logger.doSetParent(Unknown Source)
                 at java.util.logging.Logger.getAnonymousLogger(Unknown 
Source)
                 at java.util.logging.Logger.getAnonymousLogger(Unknown 
Source)
                 at tier3Client.TestApp.<init>(TestApp.java:21)
                 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
                 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
                 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
                 at java.lang.reflect.Constructor.newInstance(Unknown 
Source)
                 at java.lang.Class.newInstance(Unknown Source)
                 at 
com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter$1.run(Unknown Source)
                 at java.awt.event.InvocationEvent.dispatch(Unknown Source)
                 at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
                 at java.awt.EventQueue.access$200(Unknown Source)
                 at java.awt.EventQueue$3.run(Unknown Source)
                 at java.awt.EventQueue$3.run(Unknown Source)
                 at java.security.AccessController.doPrivileged(Native 
Method)
                 at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
                 at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
                 at java.awt.EventQueue$4.run(Unknown Source)
                 at java.awt.EventQueue$4.run(Unknown Source)
                 at java.security.AccessController.doPrivileged(Native 
Method)
                 at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
                 at java.awt.EventQueue.dispatchEvent(Unknown Source)
                 at 
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
                 at 
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
                 at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
                 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
                 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
                 at java.awt.EventDispatchThread.run(Unknown Source)
Ignored exception: java.lang.RuntimeException: 
java.lang.reflect.InvocationTargetException
basic: Dialog type is not candidate for embedding


Line:21 in the Applet is: -
     private final    Logger               logger
                                         = Logger.getAnonymousLogger();

[toc] | [prev] | [next] | [standalone]

#24806

On 7/22/2013 5:48 AM, Richard Maher wrote:
> On 7/20/2013 9:00 AM, Richard Maher wrote:
>> On 7/19/2013 8:42 AM, Knute Johnson wrote:
>>   created. It is unsigned and sand-boxed. Java 7.
>>> What exactly do you do in the destroy() method?  Have you tried not
>>> destroying it?
>>
>> Nah, I sort of need that.
>>
>> My guess is Java.util.logging which I'm replacing with my own logger
>> anyway.
>>
>> I'm in the middle of a whole lot of other changes at the mo and will hit
>> it again later but 7.25 seemed to have big changes with JUL so that's
>> where my money is anyway.
>>
>> It's just a shame when the java_status_events call ERROR and the status
>> is a definite 3 that we can't get the error somewhere.
>>
> If anyone is interested is does look like JUL was causing the problem. I
> added it to my SSCcE and it also failed to refresh only this time I got
> some console output: -
>

> Line:21 in the Applet is: -
>      private final    Logger               logger
>                                          = Logger.getAnonymousLogger();

Time to switch to log4j?

:-)

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web