0

Listbox behaves differently on two identical tomcat servers

asked 2022-09-27 18:24:25 +0800

FrankSteiner gravatar image FrankSteiner
101 1

Hi,

we have two tomcat servers (9.0.36) running which are configured identically, except for one running SSL, on two host with the same software packages installed (SuSE Linux Enterprise 15 SP3). After we upgraded zkoss from 8.5.0 to 9.6.0.2 we realized a problem on one server with listboxes using vflex="true". Their size was the max size needed to show all elements, so no scrollbar was created, but the overflow was hidding. Before the size would be what was available in the window and a scrollbar would be generated, just like vflex="true" is supposed to work. I created a minimal test,zul

<?xml version="1.0" encoding="ISO-8859-1"?>  
<zk>  
<window border="normal" title="hello" height="500px">
<listbox id="bew_list" multiple="true"  vflex="true">
  <listhead sizable="true">
    <listheader label="test"/>
  </listhead>
  <zk forEach="1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1">
    <listitem >
      <listcell label="somesomesomesomesomesome${each}"/>
    </listitem>
  </zk>
</listbox> 
  </window> 
</zk>

and created two absolutely identical webapps directories on both servers with the zkoss 9.6.0.2 jars. The directories are really 1:1 copies, but they behave as shown in the two images. Hmm, as I can post neither images nor links to them due to missing karma I can just post the links as text, sorry for that:

www.bio.ifi.lmu.de/~steiner/zkoss1.jpg
www.bio.ifi.lmu.de/~steiner/zkoss2.jpg

As you can see, server2 doesn't create the scrollbar but just cuts the content off. The styling already proves that sth. must be different on the servers, but as the webapp directories are identical, I've no idea where these differences could come from. Looking at the source codes I can see that one server has zk.themeName='breeze', the other one has iceblue. And the two css files that are linked in the webpages are identical execpt for the working server has an additional line at the very end:

.z-flex{display:flex}.z-flex>:not(.z-flex-item){flex-shrink:0}.z-flex-row{flex-direction:row}.z-flex-column{flex-direction:column}.z-flex-item{flex:1 1 0;min-height:0;min-width:0}

Why is this line created on the one server but not on the other?

Do you have any ideas what could cause this different behaviour?

cu, Frank

delete flag offensive retag edit

4 Answers

Sort by ยป oldest newest most voted
1

answered 2022-09-27 22:58:52 +0800

MDuchemin gravatar image MDuchemin
2298 1 5
ZK Team

Hey there,

You should be good to post links now ;)

Regarding the screenshots, #1 appear to use the current default ZK theme (iceblue), or a custom theme using similar colors. The edges are not rounded, but that could be specific to your web browser.

screenshot #2 appear to use a classic theme, most likely breeze.

You did mention that the 2 servers contents are a direct 1-to-1 copy. How do you deploy these applications? Are they copied directly manually in the webapps folders on each server? Or do you deploy using a war file as packaging, or other approach?

If you deployed manually, I would recommend redeploying the ZK libraries, especially breeze.jar. At the same time, make sure that the theme match the ZK version of the other ZK dependencies. (don't put a ZK 8.5.0 breeze.jar into a 9.6.0.2 application).

In ZK 9, iceblue is the default, and will be applied if the configured theme (breeze) is not found. If the jar file was corrupted during transfer, or unable to be loaded for any reason, this could explain this difference.

In any case, I'd recommend checking the server logs (catalina.out on tomcat, or other depending on server software), and see if you find any loading error related to theme, as that would also explain it.

Lastly, if you have middleware in front of the server (load-balancer, reverse proxy, etc.), there could be a cached document in that network element. It would also be possible that the browser is caching something that it shouldn't.

Regarding the z-flex code: Since ZK 9, ZK has switched from internal px calculation when setting vflex/hflex to flexbox calculation. Not sure why it shows on one server, and not the other though.

Lets see if this help

link publish delete flag offensive edit
1

answered 2022-09-28 16:59:46 +0800

MDuchemin gravatar image MDuchemin
2298 1 5
ZK Team

Hey Frank, thanks for the answer ;)

Regarding theme switching, there are a lot of way a theme can be set as "default" or active in a ZK application. Most obvious is the zk.xml file, which you already checked, but it can also be set programatically in Java by using the Themes.setTheme, or Library.setProperty, or with a theme resolver... just saying, there are options :D

More reading about switching themes can be found here https://www.zkoss.org/wiki/ZKDeveloper%27sReference/ThemingandStyling/Switching_Themes

Regarding sapphire 6: The most likely explanation (which I didn't test locally, just a guess), would be that it somehow causes the themeloader to fail at loading the theme. If that's the case, you should see an error message in the server's log. ("Couldn't read theme descriptor", "Theme version invalid" or something to that effect)

In general, you will want to avoid having ZK dependencies from different versions in the same deployement, as it always causes issues. I'm assuming that this must have been a remnant from a previous version which was not cleaned up during a version update, or similar situation (as opposed to putting it there on purpose). It's just a good thing to check ;)

One thing you could check regarding why both servers are acting differently is if they have any Java arguments / start parameters. Generally, I'd say checking if you have different content in CATALINAOPS and JAVAOPS between these tomcats would be a good start. Maybe one of them have some custom "-D zk-theme-preferred=breeze" (not a default ZK argument, but could be looked-up by a custom class in your application which would then set the theme accordingly) and not on the other tomcat.

link publish delete flag offensive edit
0

answered 2022-09-28 03:31:40 +0800

FrankSteiner gravatar image FrankSteiner
101 1

Hi MDuchemin,

thanks for the karma :)

And thanks even more for your answer! Mentioning the breeze.jar got me on the right track.

The test services (in the screenshots) were deployed manually by just copying the directory of the real webservice in question and removing all zul files and creating test.zul in it. However, the WEB-INF/lib directory of the real webservice were kept, an they contained a breeze.jar. However, it was not set in zk.xml, and removing it and reloading the webservice (or even restarting tomcat) didn't remove the breeze theme from the test server in screenshot 2...

Then I inspected the rest of the jars (the guy who wrote the webservice is no longer at our chair, so nobody knows which of the jars are needed...) and found a sapphire.jar in version 6.5.0. Removing this jar made the webservice switch to iceblue theme, restoring the sapphire.jar switched it back to breeze.

No idea how that happens, somehow the existence of this old sapphire.jar must confuse zkoss. But I've no idea where it got the breeze theme from (which I could see was loaded by inspecting the page source), as the breeze.jar was no longer there.

Why this effect happens on one of the tomcat servers but not on the other (as I said, the directories and so also the lib/ subdir are 1:1 copies done with rsync) remains mysterious.

Anyway, after learning about selecting themes I added breeze to our pom.xml, downloaded the 9.6.0.2 and set it via zk.xml (it's needed because the gui is very very compact, so that even iceblue_c doesn't even show half of the things in place :)). And now the test and the real webservice use the up-to-date breeze, and listboxes behave as they should :)

Many thanks again for your very helpful hints!!!

cu, Frank

link publish delete flag offensive edit
0

answered 2022-09-28 17:29:15 +0800

FrankSteiner gravatar image FrankSteiner
101 1

I'm going to check your proposals, thanks a lot! And I will try to figure out which jars, that are currently in the WEB-INF dir, are really needed. Likely half of them are not. At the moment we just leave the webapps running "as is" and only update jars when grype reports security problems. But as we saw now, old and unneccessary jars might cause problems. So a cleanup is the first I will do. But trying to figure out the difference between the servers is important, too, in case it ever happens again, so I will follow you apporach and check the environment settings.

Thank you very much again :)

link publish delete flag offensive edit
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools

Follow
1 follower

RSS

Stats

Asked: 2022-09-27 18:24:25 +0800

Seen: 9 times

Last updated: Sep 28

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More