Static reindeer theme with dynamic custom theme

General
1

I’ve been using Vaadin for some internal company users, and I’m about ready to deploy for my first larger group of external users. I’ve got Apache fronting Tomcat for this application. Following the advice in the Book of Vaadin, I’ve extracted the /VAADIN/* resources from the vaadin .jar file so that Apache can serve them statically. Along with this, Apache intercepts /VAADIN/* requests and prevents those requests from going to Tomcat.

This would work great assuming I was only using the default (reindeer) theme. Also, when it came time to upgrade my Vaadin version, I would just remove and re-extract the static /VAADIN/* files.

But, things seem to get much more complicated when I’m also using a custom theme, let’s call it “mytheme”. This theme inherits from reindeer. The only way I can think to make this work is to also extract the files from /VAADIN/themes/mytheme to my static Apache file location. This has two serious downsides:

  • For deployment, I must both deploy my .war file to Tomcat, and extract my custom /VAADIN/themes/mytheme to Apache
  • To upgrade Vaadin versions, I must both remove and re-extract VAADIN files, and extract my custom mytheme to Apache

Those are some redundant and error prone steps to have to follow for any deployment or Vaadin upgrade. Not so good.

So, I could get fancier with my request routing and have /VAADIN/* requests go to Apache, but have /VAADIN/themes/mytheme/* requests go to Tomcat. This is also a bit complicated, and I’m not even sure it would work. The mytheme styles.css file would say @import url(…/reindeer/styles.css), but I’m not sure that would work as that file would not be available to Tomcat, but only available to Apache.

I would greatly appreciate guidance on the best solution to this question.

Thanks, -Todd

2

That’s about how I’ve understood the “best practices” to be. If/when you want to serve theme files statically in production, you just

  • copy the Vaadin theme files from the Vaadin zip-package (easier than extracting from JARs) to Apache
  • copy your own theme to Apache

And when upgrading Vaadin just override the old Vaadin theme with the new one, checking for possible regressions in your own theme.

3

Risto, thanks for the reply. I can work with that. I wanted to make sure I wasn’t missing some alternate way of dealing with the static theme files.

4

Hi,

I’d add that I’d only move the files to Apache when I knew that it was causing a performance issue - i.e. I’d leave it all sitting in my WAR up and until that causes a problem.

Cheers,

Charles

5

I found a solution that works better for me than static files with Apache. It turns out I’m better off dealing with this issue during the build.

In my own project, I maintain just my own theme:


  <WebContent>/VAADIN/themes/mytheme/styles.css
                                ... /img, more ...

During the build, I merge this directory with the /VAADIN directory from the Vaadin .jar file into one top-level VAADIN directory in my war file.

Since I’m using maven, this looks like this:


  <build>
    <plugins>
      <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-dependency-plugin</artifactId>
      <executions>
        <execution>
        <id>unpack</id>
        <phase>process-resources</phase>
          <goals>
            <goal>unpack</goal>
          </goals>
          <configuration>
            <artifactItems>
              <artifactItem>
                <groupId>com.vaadin</groupId>
                <artifactId>vaadin</artifactId>
                <overWrite>true</overWrite>
                <outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
                <includes>**/VAADIN/**</includes>
              </artifactItem>
            </artifactItems>
          </configuration>
        </execution>
      </executions>
      </plugin>
    </plugins>
  </build>

This approach has a number of advantages for me:

  • I get the performance benefit of serving static files (not from .jar file)
  • I get everything I need in one war file
  • I don’t have to deal with separate deployments to Apache and Tomcat (it’s all Tomcat)
  • I don’t have to keep separate configurations for Apache vs no Apache (prod vs dev)
  • I keep the VAADIN files out of my source control
  • To update Vaadin version, I update my jar file (pom.xml for me), and my next build gets the updated files
  • It fixes an annoying “file in use” problem when redeploying to Tomcat while serving VAADIN via servlet mapping

None of this precludes me from serving static files from Apache if I want to. But as Charles mentions, that’s probably overkill anyway.

Thanks, -Todd