Issues with @CssImport, setSrc() and DownloadHandler in Jmix 3.0.0 — anyone else?

After upgrading to Jmix 3.0.0, several things stopped working for me, especially related to Vaadin resources.
Features like @CssImport and setSrc() for images no longer work as they did before. I also tried switching to the new DownloadHandler, but image loading still doesn’t work at all.

At the moment, the only workaround that actually works for me is to encode images as Base64 strings and set them directly, which is obviously not ideal.

I also don’t want to go back to enabling a web servlet whitelist, because that introduces potential insecurity in my addons — especially if other users don’t want to enable such a servlet in their own environments.

@Configuration
public class SimplePublicSecurityConfiguration {

    @Bean
    @Order(JmixSecurityFilterChainOrder.CUSTOM)
    SecurityFilterChain publicFilterChain(HttpSecurity http) throws Exception {
        http.securityMatcher("/public/**")
                .authorizeHttpRequests(authorize ->
                        authorize.anyRequest().permitAll()
                );
        return http.build();
    }
}

Is anyone else experiencing similar problems with resource handling in Jmix 3.0.0?
Did you find a reliable solution for loading images or custom CSS with the new Vaadin/Jmix setup?

For context: I believe CSS import always worked fine in the past, but I already had issues with static images before. Now with Jmix 3.0.0 the situation seems even more restrictive.

Using Paths “./system/”, “/system/”, “system/” not working.

PS: Please add tag jmix-v3 to the forum :wink:

Hi Jan

Perhaps Update Lumo to Aura in an existing project helps a little bit ?

I do not have problems, displaying static images; do you have a testproject ?

Regards

Felix

Hello,

I’ve investigated your add-on and there are some conclusions:

  1. Your path in Image.setSrc("icons/some_icon.png") is not allowed by Spring security. More precisely, the path isn’t “forbidden” by a specific rule, it simply doesn’t fall under any rule, and the default for everything else in Vaadin 25 is now denyAll.

    The difference with Jmix 2: there, the fallback was authenticated, so the logged-in user was served the static file at a random path.

    If you don’t want to enable it by web servlet whitelist, use DownloadHandler.forClassResource(). For instance:

    public void setImage(String imageSrc) {
        titleImage.setSrc(DownloadHandler.forClassResource(
                StatisticsCardTitle.class, "/META-INF/resources/" + imageSrc));
    
        clearWrapperAndSet(titleImage);
    }
    
  2. Your @CssImport is correct. The selectors should be applied, check them in dev-tools, after fixing Image.

That’s strange—I’m sure I did it that way; the path must have been correct, because otherwise I would have gotten an error message. :open_mouth:

Unfortunately, I hadn’t pushed it to GitHub, otherwise I could check it now. I got it from the Vaadin Docs page, but in my opinion, it was exactly the same as what you sent me—except that instead of .class, it was getClass().

Unfortunately, the CSS isn’t loading; I can’t find it in the Dev Tools or in the site source.

I tried to install add-on to fresh Jmix 3.0 project and CSS is applied.

Most likely the cause is a stale frontend bundle. Try to run command:

./gradlew vaadinClean

And launch the application.

It doesn’t work for me on either macOS or Windows; I set up a brand-new project on both systems and cleared the cache.

I colored the background for testing purposes; when I set it via Dev Tools, it accepts the option without any problems, but it doesn’t apply it when I set it via the CSS file.

Hello,

Please note that your theme in the application screenshot is Aura, but the .statistics-card selector uses Lumo variables.

Also, in the screenshot you select an element with the class statistics-card-title. Could you please check whether the selector actually applies to the element with the .statistics-card class at all?

@byte-store

Hello Jan

According to the 3.0 documentation it is …

./gradlew clean vaadinClean

and not

./gradlew vaadinClean

So maybe you should try this again. Just an idea.

Best regards

Chris