ZK9 internationalization java.lang.IllegalStateException

answered 2020-02-12 15:01:22 +0800

MDuchemin
2390 ● 1 ● 6

Hi there,

Does this always happen when you load the page? Or is it a "sometime" issue?

Does this only happen when you run the project from Netbeans in the tomcat container? If you package the project as a war file and deploy it to tomcat manually, do you get the same error?

It looks like this issue could be caused by the webapp trying to access some resources while still redeploying / restarting the container. If you have auto-deploy on change, it would be possible that the app tried to access some resource while being restarted / redeployed.

answered 2020-07-24 22:50:41 +0800

54patman
13 ● 3

updated 2020-07-25 05:41:11 +0800

This never appears in production because the server is always restarted. I'm using 9.0.1

I have the same issue (maybe bug) and it's only during development and when the spring boot internal tomcat restarts due to a code/file change.

Basically I hunted the issues down: ZkAutoConfiguration.httpSessionListener()

Has a HttpSessionListener anonymous class where the line: webManager = new WebManager(ctx, zkProperties.getUpdateUri());

is called when the servelet context is reloaded without a server restart.

Eventually in the constructor of WebManager you get to this block:

String[] labellocs = config.getLabelLocations();

if (labellocs.length == 0)

   Labels.register(new ServletLabelLocator(_ctx));

which will register the new label location, the problem is the old stale one was not cleared.

So when the label tries to resolve and load the properties files it first finds the old stale ServletLabelLocator as it saved in a LinkedHashSet. Then tries to load but because the context is closed and unavailable it throws an exception.

see in LabelLoaderImpl: private final Set

answered 2020-07-28 12:08:50 +0800

cor3000
6280 ● 2 ● 7

updated 2020-07-28 12:17:06 +0800

As you pointed out this doesn't happen in production, where a (re)deployed war file has a separate class loader - and ZK can initialize it's static members correctly.

What you didn't mention is the way/method you are starting your spring-boot application (so I am guessing you are using spring-boot-devtools as well). I could reproduce your exception adding spring-boot-devtools to the zkspringboot-demo-jar project

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <version>${springboot.version}</version>
    <optional>true</optional>
</dependency>

Then start it the Main class from the IDE, open http://localhost:8080/mvvm (which uses i18n labels).

Then change a java class -> recompile -> which triggers spring boot to reload the application, causing the error next time you access the same url.

During startup ZK assumes to be on a clean class loader (also in other places) so that I'd not try to change the ZK code.

Instead you can configure spring-boot-devtools accordingly to include the zk-jars during an application restart/reload.

Spring docs go quite into detail on how to use the devtools

In the restart-vs-reload section they mention 2 different class loaders which can be customized to include/exclude certain jar files (8.2.6).

Following the docs adding a spring-devtools.properties to include zk jars (brute force the ones starting with z*.jar) into the "restart"-classloader fixes the problem (might be fine tuned to only certain jars)

Besides that I personally don't like the devtools in this scenario, the benefits are marginal (the application still needs to restart - the start time is not reduced by a lot). It even restart the application too often for every css/js/zul/properties file change, when it's definitely not needed. ZK can reload those resources without restarting by simply disabling the caches as demonstrated in DevelopmentConfig.java. So many changes just get slower when restarting the application too eagerly.

Often the built-in hot code replacement is good enough when running in debug mode. And if needed a fresh start of the application is not much slower (maybe there are cases where the difference is significant which I haven't encountered so far).