Enterprise Client Community

Many of you have never been in touch with selecting the right parser on server side... this information for these ones who are.

By default CaptainCasa uses the crimson-SAX-parser even though the default parser of the java environment is another one. This is the reason why there is a crimson.jar delivered in WEB-INF/lib.

Why don't we use the default parser which is part of the java runtime from 1.5 on? ...because it has a severe bug! We could not believe it ourselves, but the result of parsing does sometimes not reflect the document that is parsed. We did isolate the error into a mini-Java program and published a message within the Xerces forums - getting back a response 3 hours after posting (!!), that Sun branched from the Xerces parsers some years ago. And: in the repsonse they did test against Xerces and checked that Xerces does not have this error. So we posted a message to Sun (3 months ago), ...well, no repsonse yet.

We also tested with crimson, which is smaller than Xerces, and crimson also is fine. So we decided for crimson.

Now, in some situations you want to explicitly define the parser on your own. We know some users who have problems with crimson.jar being around when using Spring. In this case you need to specify the parser in the configuration file /eclntjsfserver/config/system.xml. But: pay attention - do not specify the defaulf parser of the java runtime (com.sun.xerces....), this is the one with the bug. You may also remove crimson.jar completely when specifying to use an other parser.

A "nice" symptom that a wrong parser is used on server side is, that popups are shown with wrong dimensions (very small height). So, check the parser settings in this case!

Björn

...yes, will be added short term...

Björn Müller

...seems to me that the eclntjsfserver.jar is not up to date... could you please check? Maybe it was locked while updating...?

Björn

Hi,

the null pointer is called deep inside within the Swing Document processing... By debugging we saw that a certain font metrics within the JTextField Component was null - for what reason ever.
We now found a way tp bypass: before setting a text in the JTextField we check if the font is null, if so we set it to the default font. Result: it now works (at least in the scenario we can reproduce).

We are not fully happy yet, but the error seems to have gone... Will be part of next update.

Björn

You are right. It was renamed by accident. We never noticed because our demo applications always received an addon-copy of the webappaddons directory, so the right icon was available "by history".

Thank you very much + is corrected.

Björn

...good (?) news: I found a way to rely-ably reproduce on our systems...

Björn

Hi,

we now tackled the problem from the symptom side - if there is a null pointer then just avoid passing null... Maybe this just shifts the problems to the next level, but we somehow must react. So: we avoid this null pointer now, hoping that this will solve all problems.

(We are still in the situation that we never got the error on our side...)

Björn

We published an interim version http://www.CaptainCasa.com/download/setup_2_1_20080828.exe or http://www.CaptainCasa.com/download/EnterpriseClient_2_1_20080828.zip in which this bug is corrected. (The interim version is not part of the DevZone. The solution will be part of the next official update as well.)

...bug corrected...

Björn

We published an interim version http://www.CaptainCasa.com/download/setup_2_1_20080828.exe or http://www.CaptainCasa.com/download/EnterpriseClient_2_1_20080828.zip in which this bug is corrected. (The interim version is not part of the DevZone. The solution will be part of the next official update as well.)

...thanks for the details + also the explanations how to work-around!

We corrected the bug, so directories are created properly when previewing/saving jsp files now...

We published an interim version http://www.CaptainCasa.com/download/setup_2_1_20080828.exe or http://www.CaptainCasa.com/download/EnterpriseClient_2_1_20080828.zip in which this bug is corrected. (The interim version is not part of the DevZone. The solution will be part of the next official update as well.)

Björn

So, I try to summarize what we will do...:

Provide a component HTTPRECEIVER which opens up a micro-http server on client side. The component is not visible.

Attributes:
PORT ==> port of client http server
ACTIONLISTENER ==> method on server side to be invoked

The method gets an event of type BaseActionEventHttpReceived, which itself passes the full URL that was received on client side.

The application on server side is responsible for parsing the request and for doing securtiy management. The application needs to be aware about that the client side http server could be potencially called from any http-caller as well. E.g. it needs to define a certain token that always needs to be passed as part of the URL.

We will provide this component quite short term...

Björn

...I assue this is somehow related with the missing directory... Is it?
Björn

Ok, you are right: if the directory does not exist yet then there is a problem. You need to create the directory in the deployed environment first.

Will be fixed with next update.

Björn

Hi,

pleeeeease: tell me more details.

What does "crash" mean? Is there a stack trace?
Does it always happen?
Is there any log output on client or server side?

...THANKS!!!!

Björn

Well, the other application on client side still is another Java process. So we need some inter-process communication (I think, solutions like "constant polling against file system" are not really the direction we should target for...).

I see http base access as simplest way... (compared to RMI or native TCP/IP). ...or?

Björn

...yes, we simply have to add the "height" attribute to the component tag library definition. We just did so... so it is part of next Monday's update.

If you need it more urgent: please contact us, we can provide an interim build easily.

Björn