Fun with login prompts

[pendell]

Gentles,

I am having difficulties with what your documentation states is a common problem: The
humble login prompt. I have attempted all the solutions outlined in your Multithreading
guide, without success. So I'm posting here in the hopes of getting out of this jam.

The legacy Swing application is a client-server implementation that works as follows:

1) The client starts an initial 'connecting to server' dialog box and initiates a
behind the scenes connection. This is the only window explicitly connected to by the client.
2) The server , when it connects, instructs the client to shut down the original window
and open a login prompt.
3) The user enters the login information and presses the 'OK' button to log in.
4) The server instructs the client to hide the logon window and display a temporary
'logging in...' window.   Once logon is complete, the server instructs the client to
hide the intermediate window and open the MainFrame. 

You can instantly see what's going to go wrong. There is no top-level window on the
client once the server instructs the client to hide the first one. So AjaxSwing raises
the 'no windows are visible' exception.

**As a temporary measure only** I circumvented this error by removing the instruction
to hide the original first window. I now see -- in Ajax -- the initial window and the
login window on the same screen.  I enter my login information and press the 'OK' button
on the login window.  The hourglass comes up, and I never get a response back from the
application. As a bonus, my entire system slows to a crawl as JVM after JVM starts up and goes into
timeout. 

Reading through your instructions, I added properties to the logon button telling it that
the operation would not be finished until the next window appeared. No change.

I then added AjaxSwingManager programmatic constructs to the code, beginning the operation
after the button is  pressed and ending the operation when MainFrame is generated.

The logon window disappeared, but the Mainframe was not rendered.

I'm out of ideas.  Do you have any to get out of this conundrum?

Respectfully,

Brian P.

[Dev Team]

Try calling AjaxSwingManager.beginOperation() before closing first window and then AjaxSwingManager.endOperation() after showing new window.

Also if you're saying it works when you remove hide instruction on first window, you can call "hide" after you show second window, it would work same way as before, but you'll always have at least one window visible.

As of:

The hourglass comes up, and I never get a response back from the
application.

Please, attach your log files (AjaxSwing/logs/*).

Can you give us installation of your application to reproduce this issue?

We also have Professional Services that can help with integration.

[Support Team]

In addition to the suggestions by the dev team, you can try 2 approaches.

Operation Control
From your description it seems that you only really need 2 windows - Login Dialog and MainFrame. Everything in the middle is just to give user some feedback while he's waiting. You don't really need the "Connecting to the server..." dialog because AjaxSwing shows Initializing... page. So you can begin operation at the very beginning of your main() method, and call endOperation() when the LoginDialog is shown. That is step 1.

You can use the same approach for MainFrame. Call beginOperation() after OK button is pressed in Login dialog, and endOperation() when MainFrame is shown. There won't be intermediate feedback to the user, but it should work fine.

The advantage of this approach is that it is simple and efficient. Disadvantage is that you have find all places to call endOperation (exception handling etc) and if the server doesn't call the client the browser will just hang until it times out.

Server Push
Another alternative is to push changes from the server to the browser. You can programmatically set updateInterval to 1 second at the beginning of your main() method. Then any time you show a new window you say ClientAgent.getCurrentInstance().setUpdateBrowser(true). It's already done for dialogs. You can read more about it at http://www.creamtec.com/products/ajaxswing/doc/multithreading.html, although we need to add better examples.

Server push is a better approach then operation control but it may be a bit more tricky to get working initially. It's better because it doesn't block the client.

RMI
Potentially you may have issues with RMI, because AjaxSwing wouldn't know what client agent to associated with the server calls. So if ClientAgent.getCurrentInstance() fails from server methods, you need store the association between the client agent and some object returned by the server, so that inside the client callback method you can lookup the client agent instance and then say ClientAgentManager.setMyAgent(Thread.currentThread(), agent).

Code:

You can instantly see what's going to go wrong. There is no top-level window on the
client once the server instructs the client to hide the first one. So AjaxSwing raises
the 'no windows are visible' exception.

I've actually created an enhancement request to show empty page instead of throwing an exception, but are you not showing the next window from the thread that closed the previous window? As long as it's done on the same thread it should work.

All in all, it definitely looks like an easily solvable problem once you understand what is going on. As mentioned, you can contact our Professional Services to do it for you because they've done it many times.

[Support Team]

BTW, when you hit browser Refresh button, does it all work?

[pendell]

Please, attach your log files (AjaxSwing/logs/*).

Done. I've included my .properties file in the attached .zip as well, for good measure.
Actually, I will need 4 posts to circumvent the 300kb restriction.  This is post 1 of 4. Yes, all of this was generated in under 2 minutes, suggesting heavy traffic and something being wrong.

Can you give us installation of your application to reproduce this issue?

Regrettably, no. The 'server' end of the application is tied to a whole bunch of proprietary stuff
as well as robotics firmware.   I'd have to either ship you a full set of our products or find the
emulator software ... which is well buried. 

We also have Professional Services that can help with integration.

I'm assuming this would cost a fee, yes?  Please e-mail me at the associated address with a price quote
and I'll consider it. But I'd prefer to do this myself, if possible.

BTW, when you hit browser Refresh button, does it all work?

I'm afraid it does not.  When I initially log in with a client via the web, it fails to respond. When I try
a second time with a second browser, I get the login prompt and the initial window. When I press the 'logon'
button, I never receive another response from the client.

 
Many thanks for your suggestions. I will start working my way through them. 


Respectfully,

Brian P.

[pendell]

attachment 2 of 4:

[pendell]

attachment 3 of 4

[pendell]

attachment 4 of 4. Happy reading 

Respectfully,

Brian P.

[Support Team]

Brian,

Thanks for the log files. Nothing gives us more pleasure then reading thru exceptions in the log files (sarcasm).

OK, the first thing you need to do is read them. For instance, I see that AjaxSwing is not able to start JVM for application "Copy of SmartCube". You probably don't even mean to have this app, so either delete this file or remove #AjaxSwing properties file from the header. That would prevent your system and log files from being overwhelmed.

I don't see much else in the log file.

You should probably remove agent.appStartWindow since you are using beginOperation().

I don't see any calls to endOperation() so the request is just hanging. Can you make sure that you are calling endOperation() on the right client agent?

Regarding Professional Services, it's is completely up to you. You should absolutely be able to get this working yourself. We just mentioned it to give you options because we would hate for you to get an impression that the product doesn't work:-)

[pendell]

OK, the first thing you need to do is read them. For instance, I see that AjaxSwing is not able to start JVM for application "Copy of SmartCube". You probably don't even mean to have this app, so either delete this file or remove #AjaxSwing properties file from the header. That would prevent your system and log files from being overwhelmed.

Agree. That comes from making a backup copy of the original wizard-generated smartcube .properties file before modifying it by hand, but leaving the backup copy in the same directory. Easily corrected.  

I don't see any calls to endOperation() so the request is just hanging. Can you make sure that you are calling endOperation() on the right client agent?

I'm beginning to suspect that myself.  I did some reading of the code, and the entire client consists of about 6 lines of code.

Consider the following:

   public static void main(String[] args) {


       AjaxSwingManager.beginOperation();

[snip preliminaries ]

      // Run the actual client loaded from the server
        try {
            Class<?> clientClass = RMIClassLoader.loadClass(URL.toString(), "[package spec].ClientApplicationRunnable");
            Method m = clientClass.getDeclaredMethod("start", String.class);
            m.invoke(null, hostname);
        }

So what's happening here is that the client is a mere stub.  It activates, and loads the
*entire client* via an RMI connection.  I'll wager the legacy developers were thinking that
by doing so they could ease maintainability by having only one 'real' program.  

So the *entire client* is being run via an RMI/RPC connection.  

I'll wager that's why we're getting the error we're seeing.  The beginOperation()
is indeed in the client, but the endOperation() call is buried in a server RMI call as above.
So we see beginOperation but not endOperation().  Resulting in a permanent hangup.

I'll betcha anything that moving the beginOperation() to the server RMI results in *both*
calls disappearing from the log files.  I'll try it anyway, but I think we both know
already what the result will be.  

...

Now that we've discussed this, I believe that this application cannot be made to work
programmatically with AjaxSwing unless it is significantly re-engineered to get rid of the entire
'stub client with RMI classloading' concept.  Am I wrong?  

If I am right ... is there another possible solution? I'll have a look at the 'server push'
concept that the previous poster discussed.  Are there other possibilities?


Respectfully,

Brian P.

[Support Team]

Brian,

Now that we've discussed this, I believe that this application cannot be made to work
programmatically with AjaxSwing unless it is significantly re-engineered to get rid of the entire
'stub client with RMI classloading' concept.  Am I wrong? 

As long as the application runs as a Swing client it should run in AjaxSwing. Just because the classes are loaded via RMIClassLoader and ran thru reflection shouldn't prevent them from working in AjaxSwing. It just makes it harder to debug for you, but you still have options.

1. Does it really need to be loaded via RMIClassLoader in Ajax mode? Your client and the server would be running on the same host, wouldn't they?  Even if they don't for Ajax mode you can probably load the class directly, and you can fork this using AjaxSwingManager.isAjaxSwingRunning(). This would help in isolating one web user data from another.

2. The key for endOperation() is that it should be called inside the same JVM that runs AjaxSwing and for the same client agent that issued beginOperation(). You can probably print a message using System.out before you call endOperation() and then find it in the log file. If you don't see it (and we didn't see it in the log file) that means that you probably didn't put it in the right place. The client changes Swing UI somewhere in response to the server call, and that's where you want to put endOperation().

If I am right ... is there another possible solution? I'll have a look at the 'server push'
concept that the previous poster discussed.  Are there other possibilities?

I am not sure there is another solution. You have to understand how the UI works and add some AjaxSwing code to those parts that do not work. From our experience that shouldn't require re-engineering of the application, but of course it's hard to say without looking at its code.

[Support Team]

Brian,

We've added support for auto-detecting updates from background threads. Why don't you give our dev build a try - you can download it from http://www.creamtec.com/products/ajaxswing/install/3.0.4/ajaxswing304.zip. Just make sure you use the latest distro and copy your files into it.

Our expectation is that you wouldn't have to put any begin/end operation calls. Only thing you may have to do is set the client agent instance in thread of the server callback method.