Headless Client Madness

Classic Servoy
1

So I have recently started using the headless client plugin.

I’ve just spent the majority of the past day trying to figure out why my headless clients were not behaving as expected.

When I run the code that the HLC will run from either developer OR a smart client, everything works fine.

When the same code runs in a HLC, it will silently fail in the middle. No errors, no callback, no nothing. The clients remain open on the server, but the code just stops running.

So, I spent a good long while plastering logging all over my code in order to determine exactly where it was failing. I discovered it was running all code right up to right before a form method (forms.zERevWeekly.processERevByWeeklySpotTypeHLC). There was a log right before running, and there should have been a log as soon as it entered the method, but it seems like it attempted to run the method and just failed, and stopped running code altogether. I was fairly sure that this form and method should be visible from the module I was running code from, but just to be sure I added logging to check for the existence of the form and method, as follows:

forms.zERevWeekly;
var bForm = 'zERevWeekly' in forms;
var bMeth = 'processERevByWeeklySpotTypeHLC' in forms.zERevWeekly

Interestingly enough trying to log bForm and bMeth ALSO failed.

My first instinct is to exclaim “What? You can’t access forms in headless clients?”

HOWEVER, I know for a fact that I have at least one form method that runs prior to this. That being said, I’m not above putting “processERevByWeeklySpotTypeHLC” into the global context just for fun. It doesn’t actually need to be on a form, it’s just there for organizational purposes. So, copy-paste that code out, re-run my headless clients, and voila! We finally have a log message stating that we’ve entered “processERevByWeeklySpotTypeHLC”.

Of course, it doesn’t finish, it actually just barely enters the method before dying. Having some idea of what’s going on now, I check it out, and there are a few other form based methods scattered throughout the code, and luckily none of them actually have to be where they are. So, I port all the form based code this uses out to the global scope, and try it all again.

It works! Huzzah.

Ok, so, it seems like we can’t use form based code in HLC…at least, nothing except the ONE method I KNOW is running.

It looks like so:

function autoinitialize()
{
	try
	{
		if ( application.__parent__.adHoC )
		{
			return;
		}
		else
		{
			initialize();
		}
	}
	catch (e)
	{
		return;
	}

}

As you can see, simple code. It checks to see if the initialize() code within has already been run, and if not, it runs it (also a form method). I know this code is running because if it doesn’t, nothing else I ever try to run in our application will work (literally).

So.

What is going on? :D

2

I think the answer to your riddle is in the name of the client: Headless means no UI!

So if there is no UI, it cannot instantiate forms, or rather, it could, but since it cannot render them there are some things that will not happen and will most probably throw exceptions.

The one method that you say is working is really executed before the form’s UI is rendered, as is the case for onLoad methods of forms.

Now why does the headless client behave differently when loaded from developer? Because in that case, the server is launched from Eclipse Developer and thus java is not running in headless mode.

When launched from the command line or as a service/daemon, the server is launched with the “java.awt.headless” property set to true so any calls to UI rendering will fail, this is so that for example a linux server without X graphics engine will still work as planned…

3

While what Patrick says is technically correct, you should still be able to use forms in Headless Clients.

The entire scripting API is exactly the same between normal (SC/WC) and Headless Clients.

So, why you are experiencing what you are experiencing? No idea. Would need to see some more code I guess.

Paul

4

Checking a little closer there were a few instances of things like hiding form elements in some of the code I was calling.

Ok, so I can see that failing in a headless context, since there is no rendering going on.

I would think this kind of behavior would prompt some sort of exception being thrown, instead of failing silently however?

5

i think there should be an exception
else your script wouldnt stop in the middle of something

Do you have an global error handler that maybe swallows this?

6

Definitely not.

Most of the code IS wrapped in try/catch statements, but they all contain logging so I would know about them that way…and even if it wasn’t contained in a try/catch the exception would show up (I believe) in the server log, right?

7

it should yes, you cant catch all exceptions in js, some real java exceptions will pass through everything
But those are catched by us and given to an onErrorHandler and if there is no error handler configured or the error handler returns true we will also report it and it should go into the log.