Applet-JMS design issue

[jason adam]

I hate GUIs
Now that I got that off my chest, I have a problem with an applet receiving a JMS issue. The problem stems from the fact that we will be running the application in both a web browser as well as Web Start.
As it stands, when init() is called, the applet registers itself as a listener to a JMS destination. When destroy() is called, the applet unsubscribes.
In Web Start, there is a panel that holds the applet. This gets initialized when the application starts up, since even though the panel isn't visible, it's still there. The user also has the option of opening up a separate window for each panel, which causes a new applet to be initialized. This caused multiple listeners for the one JMS destination to exist, therefore one client was receiving the same message multiple times. A simple static boolean and an if block took care of this.
However, the browser is a different story. The applet doesn't get initialized unless the person clicks on a link. This works the first time, but if they leave and go back to the link, destroy() is called causing the applet to unsubscribe. And when you click on the link to go back to the applet, it isn't subscribing again because the static boolean was set to think it already subscribed. So messages are received once, then not again.
So I had destroy() set the static boolean to false, so it would reinitialize. This caused the duplicate messages to appear again in Web Start (since destroy() was being called when the "second" applet was created).
And finally, in the browser, you still want the user to receive messages even if they aren't in that applet. So there has to be some check at destroy time to find out if they are still waiting to receive a message, and only unsubscribe when that message is received.
And of course the requirements don't want to force the user to stay in the applet until they receive a message, or to only have one version of the applet up in Web Start, such as the panel.
I'm trying to play with a way to design the least amount of counters or checkers to ensure that both versions of the application send only one message to the client, even if the client isn't in the applet, or has multiple versions of the applet up.
JMS messages are filtered by session ID.
So, if you actually comprehended all that, I'd be glad to hear any suggestions.
Thanks!
[ August 18, 2003: Message edited by: jason adam ]

[jason adam]

Well, I'm going to end up using a Singleton listener object and having each instance of the applet register itself with the listener, checking to make sure only one instance per session ID is registered.
Problem was the original author of the code used an anonymous inner class to define the listener, which normally would work, but since the possibility exists that the applet will be destroyed before the message is received, this isn't an effective solution.

[Ilja Preuss]

Why do you use the *applet* in the webstart application? Perhaps you would be better off having one core application and two different frontends - one for the applet, another for webstart?

[jason adam]

Ummm... I don't know, cause that's the way they do things here? I'm not a GUI kind of guy, I just got forced to deal with it (usually deal with the backend server work) because our team got down-sized and things are tight.
I thought Web Start was a way to run browser applications outside of a browser. We do have a stand-alone client, but that's different from Web Start.
The browser is the biggest problem, and it just seems logical in my opinion to have a Singleton listener to receive messages anyway, but that's me. Anonymous classes are nice as long as they're used to fire off operations that occur while the applet is active.
So are you saying there should be separate applications, one that uses applets and one that just uses frames and panels? Isn't that causing a lot of duplicate code to exist?

[Ilja Preuss]

Originally posted by jason adam:
I thought Web Start was a way to run browser applications outside of a browser.

No, it's a way to start vanilla desktop applications through the web.

We do have a stand-alone client, but that's different from Web Start.

Do you know why?

So are you saying there should be separate applications, one that uses applets and one that just uses frames and panels?

Basically, yes.

Isn't that causing a lot of duplicate code to exist?

Not necessarily. Both applications can share most of the code. You only need to factor the *differences* into different places.

[jason adam]

Honestly, not sure why they do what they do. Even the stand-alone application instantiates the various applets and uses them with its content pane. Never said it was pretty.
I'm guessing that it was for code reuse. Write it as an applet, and use it in the browser and applications.