Enterprise Client Community

We would like to show nested popups in html mode (ht controls).

We are having a popup which wants to open a simple DefaultScreens.getSessionAccess().getOkPopup().
It looks like this does not work, only one HT popup can be open at a time.

This may be an acceptable limitation for "complicated popups", but a simple message should be possible on top of a popup application.

b.t.w. would it possible to display such simple messages by the browser via javascript.alert()?

Manfred

using ht controls,
we are including one jsp page into another (as is typical for captain casa layouts), using the t:rowinclude tag.
this works well in principle, however it looks like all tags not related to jsf are silently discarded. In case of normal (captain casa) controls, this looks appropriate, since the client does not understand arbitrary html content.

However in case of ht, it is easy to insert other html tokens like specially formatted divs. Such content is rendered without problem when the page is invoked directly. So it should also render in case of captain's rowinclude.

Found by experiment (avoiding xml parser errors), we can live with the assumptions that the including apparently discards everything outside of the h:form tags, and also assumes that there is exactly one tag below the h:form (namely the f:subview); and our insertions have to be well-formed xml.

regards
Manfred

Here is one more update of our findings regarding class loaders and java.exe's and applets:

When a page contains two applets (invoked from different servers), or contains one location where an applet is switched between two servers (so that there is only one applet active at one time), we again have the situation that the core java classes like String and Logger exist only once, but there are two class loaders which each load the different eclient classes.

So in this situation we have again the sitation that CLog registers two output handlers for logger "org.eclnt.clientlog", and never removes them.

Contrary to the situation described in the first message, when we now use the flag classloader_cache=true this duplication only occurs once for every different server a user visits, and since these are probably very few (two, three,...), this duplication is not getting ever more severe as a user repeatedly starts and stops the eclient applet during her daily work.

Still we would appreciate some code in CLog class that first examines if the logger already has a suitable appender, and only create a new one if none is found.

regards
Manfred

we sometimes create temporary files which are presented to the user via Desktop.open(). Then there is no secure point when to delete such files, so using the shutdown of the client was one option.

Then there is the issue of
http://www.captaincasademo.com/forum/posts/list/1470.page - we also have our own log appender which should be cleaned "at the end of the session".

In the meantime we have come to a possibility to implement such feature on our own: we can create our own version of the t:sessioncloser element, include in the our main page, and can implement our code there.
So if you don't consider this shutdown hooking as being of general interest to the community, we might as well withdraw this feature request.

Manfred

update of current state:
the problem was not gone with the 10/10/2011 update.
Since we are also adding a customized appender (...which of course has the same problem...), we first thought that it is indirectly causing this problem on the console logger, but this was not the case.

Then playing further with our applet code we found the applet property Code:

classloader_cache=aBoolean

. It was set to false in our original scenario when the problem appears. When we change it to true, the duplication is gone. This new setting also has the advantage that the eclient loads faster, but we are not yet sure about complications we might face at other places.

Manfred

Being a swing novice hopefully you can help me with the following issue.
Is it possible to hook into the shutdown of the client? It is relatively easy for applets - we can establish our own applet class as a subclass of PageApplet, and then have the standard lifecycle methods like stop().
But I don't know of such a thing for webstart. Hopefully there is a solution which works uniformly for all client modes.

Manfred
p.s. just to avoid misunderstandings: this is not an issue of server programming, where we have the t:sessioncloser element, but of client programming; we are adding some custom stuff into the client jar, and for this we need the hook.

I am afraid the problem is there all the time, regardless of the file log parameter. Probably caused by the static initializer of class CLog.

Manfred

To enhance repeated opening of the eclnt applet, we use the option separate_jvm=false.
Now the user can close the captain applet, move to a different page, then come back to a page containing the captain applet. When there was not too much delay between invocations, the 1.6-sun-java-plugin keeps the java.exe in memory and reuses it - this saves 1-2 sec startup time.

Now to our problem:
with each new eclnt applet, the console output is duplicated, since each applets adds a console handler to java's logger, but never removes it when the applet is closed.

Manfred

This may seem quite out of topic, but the issue came up several times lately, so I (mis)use this forum to publish our findings.

Casabac applications fail to load using IE9 (latest beta). Some debugging revealed that IE9 brings changes to how javascript is interpreted.

It looks like the implicit merging of properties of the "window" and "document" object into the current scope of the javascript interpreter does not always work as it did before.

We had to modify the file central.js. The specialty about this file is that it's functions are "transferred" into other pages/frames, they are not only used on the page where it is included via script tag. This may be the situation where IE9 has changed how to interpret properties, but I did not read any IE9 docu so don't take this as definitive knowledge.

In the file central.js any reference to a property of window or document has to be made explicitly, e.g. change parent.doSomething() with window.parent.doSomething().

It looks like it is not possible to attach js files in this forum (probably for security reasons), so I leave it up to you to puzzle out the necessary changes.

Hope this was helpful for some of you
Manfred

using Something:SomethingElse was our first try, but we came upon the double replacement problem you mention. We then found some code handling double stuff containing if's about replacement string starting with #{d.

So it worked better the way described, and with some special codes we could even trick your removeDoubleReplacements method so currently the code is working (though with much pain).

But we might try Something:SomeElseThing, or even do some more refactoring and check if the PageBean stuff is useful for our problem.

in some complex pages we have rowdynamic, using rowinclude, with the attribute contentReplace set to some value.

This is not rencered correctly, it passes through ROWINCLUDEComponent.removeDoubleReplacements(), where in our case the argument list contains two elements:

Code:

 
 #{d.:#{d.d_55.
 
 #{d.d55.Something:#{d.d55.SomethingElse

This method in question removes the first item since it is considered as double, but clearly it is not.

While it might be a good idea from performance point of view it is probably best to discard this method altogether (as seems to be done in RowIncludeComponent.initContentReplaceList()), since there are many complex scenarios where a simple string checking can be tricked by possible replacement settings, when one might be constructed to explicitly take into account the effects of a previous replacements.

Manfred

the server log contains many lines about each single request, but we are missing a line which tells what is actually being invoked. If I remember correctly such information was provided in earlier captain releases.

Currently we find one line containing
Code:

queueing new ActionEvent (invoke())

another line contains
Code:

executing ActionEvent (org.eclnt.jsfserver.elements.events.BaseActionEventInvoke)

which is not very helpful.

There are other types of events like rowexecute(0,1) which show that an element in a list has been doubleclicked, and since lists do not occur very often, this allows to identify what was clicked. But for standard button events nothing helpful is shown to identify the function. It would be really helpful if the string behind this event (e.g. #{d.d_123.Bean.method}

were logged as well. Similar output is provided for setting properties in the updateModelValues phase, although it only contains the last element of the access path which in our special case is also not really helpful since it mostly reads #value being a generic component, the complete path is e.g. #{d.d_123.Bean.wonderfulprop.value}, and we would be interested in 'wonderfulprop', also 'Bean', so why not log the whole path.
b.t.w. the same applies to the invoke problem, we also have a generic object here and the path reads #{d.d_123.Bean.coolmethod.clicked}, so the last element would always be "clicked".

regards
Manfred

We have been using session in various places, given that our server must be able to handle both casabac and captaincasa scenario. It would be a formidable task to go through all our application end ensure that every url passed to the client is enhanced via url-rewriting, so I am afraid that disabling session cookies is not a short term option.

In my concrete testcase the session is created via a /favicon.ico request which returns 404-not found and in creating the error response tomcat creates a session, setting a cookie to path "/".

regards
Manfred

We are using BufferedContentServlet and ...Mgr to store files to be displayed in browser which is opened by the captaincasa client via jshowurl.

The url that is passed contains the session id via url rewriting (somefile.ccbuffer;jsessionid=xyz).

If there is already an open browser which has accessed stuff on our server, whereby a session id has been set via cookie, the new window will inherit this cookie and send both the (incorrect) cookie session id and the (correct) session id in the url. It seems that tomcat extracts both ids, but the cookie will win, so the request for the buffered content will be handled in the wrong session, and nothing is retrieved.

regarding server errors this is probably enough; and we are just about to assemble some elements to provide the required information.
Will send you some more issues encountered with the "try-to-reconnect-to-current-session" stuff.

Next thing is client triggered errors (typically connection errors), where currently the possibilities are rather limited. The log mentioned was the log of the client, typically written onto (invisible) stdout of the client.
This was mainly what we had in mind when looking for a developer's hook (of course this will require client programming; but then this is likely to be the only option since every one has different requirements).

regards
Manfred