I’m upgrading from Vaadin 6.2 to 6.3. My project has it’s own theme based on reindeer in:
WebContent/VAADIN/themes/blackbelt
beside the blackbelt directory, there are two other directories: “base” and “reindeer”.
I’m not sure from the upgrade notes if I should replace these two directories (with fresh ones from the jar file). They are also included in the vaadin-6.3.0.jar file. Would it be possible to make Vaadin use base/reindeer directories from the jar file?
My styles.css starts with:
@import url(../reindeer/styles.css);
Of course, if I juste delete WebContent/VAADIN/themes/base and reineed directories, the layout is ugly.
I’ve the same question about Widgetsets. My directory WebContent/VAADIN/wedgetsets contains:
blackbelt.ui.widgetset.BlackBeltWidgetset
com.vaadin.terminal.gwt.DefaultWidgetSet
Could Vaadin find the DefaultWidgetSet from the jar file? Can I just delete that directory?
Yes, Vaadin can load the themes and widget sets from the Vaadin Jar. That’s in fact the typical “development” way, as in when you create a new Vaadin project with the Eclipse Plugin. Loading them from the Jar is easier to manage, especially if you upgrade Vaadin frequently during development. Otherwise, you need to re-extract the [tt]
themes
[/tt] and [tt]
widgetsets
[/tt] folders from the Jar every time you upgrade to new Vaadin Jar.
We recommend unzipping the themes and widget sets from the Jar to the VAADIN directory
for production as it is a more efficient to serve them statically.
If you have your own widget set, the DefaultWidgetSet is never loaded (when you’re running your app), so you don’t need to extract it to the [tt]
widgetsets
[/tt] folder. The inheritance in widget sets is handled during widget set compilation and your custom widget set contains all the necessary stuff from DefaultWidgetSet.
Thank you Marko, it’s very clear for the DefaultWidgetSet. I’ve removed it and it still works B)
For the theme, on the other hand, I’ve two questions:
Performance
Is the performance impact noticeable, regarding the communication time to send the css and picture files from the browser to the server, and regarding the caching of them by the browser?
How to
How to you tell Vaadin to take them from the jar file? I’ve deleted the directory but it seems they are not found anymore. Should I change the import statement of my styles.css (see previous post) ?
I don’t know how big the performance impact exactly is, I haven’t done any tests, but it could be significant if you have a lot of users. When loading from the Jar, the Vaadin application loads them with Java class loader, which adds some processing overhead and could take some memory as well. In environments with heavy loads, you could distribute the serving of the themes and widget sets even to another, possibly light-weight non-Java server.
I suspect that the relevance depends a lot on the application, server, and type of use. It would be good to get some figures though.
The themes and widget sets are automatically loaded from the Jar. I suspect that your problem is that you’re running your application in a subcontext with a servlet mapping something like [tt]
/ui/
[/tt]. In this case, you need to add another servlet mapping to map the [tt]
/VAADIN/
[/tt] URL to the servlet as well. You don’t need the mapping if you’re serving the VAADIN folder statically.
For example:
<servlet-mapping>
<servlet-name>Book of Vaadin Examples</servlet-name>
<url-pattern>/book/*</url-pattern>
</servlet-mapping>
<!-- This has to be done because the apps are under a sub-context. -->
<servlet-mapping>
<servlet-name>Book of Vaadin Examples</servlet-name>
<url-pattern>/VAADIN/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/ui/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/VAADIN/*</url-pattern> <!-- To take Vaadin's buildin theme from the jar file (instead of from WebRoot) -->
</servlet-mapping>
and it works. But how the browser finds my theme (which is not in the jar file) ? I guess that Vaadin servlet looks in the file system as an alternative when not found in the classpath.
I’ve changed the mapping, to make Vaadin only look in the jar file for Vaadin built-in reindeer theme (which mine inherits). For my files (widgetset and theme), it goes through the file system:
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/ui/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/VAADIN/themes/reindeer/*</url-pattern> <!-- To take Vaadin's buildin theme from the jar file (instead of from WebRoot) -->
</servlet-mapping>
It works as well. Then it makes me think: how is the /VAADIN/theme/base directory found? I’ve deleted it from the WebContent/VAADIN/theme directory with reindeer. Maybe is it not necessary? Do you know?
Even though Reindeer inherits the Base theme, we concatenate the styles together during our build phase. That makes all three bundled themes, Reindeer, Runo and Base, independent of each other during deployment, since each stylesheet contains all necessary styles for that theme.
This is the reason why it seems that the base folder is found. In reality it is of course never accessed in your environment.
UPDATE: I forgot one crucial detail, which Henri pointed out.
Reindeer and Runo access some common images from the Base theme, such as the shadow images and generic loading indicators.
So you should indeed still provide the base-folder to make everything work seamlessly.
I created a ticket for this issue, maybe we should copy the necessary files to both Reindeer and Runo during build as well:
#4593
<servlet>
<servlet-name>vaadin</servlet-name>
<servlet-class>blackbelt.ui.BBApplicationServlet</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>blackbelt.ui.BbApplication</param-value>
</init-param>
<init-param>
<param-name>widgetset</param-name>
<param-value>blackbelt.ui.widgetset.BlackBeltWidgetset</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/ui/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>vaadin</servlet-name>
<url-pattern>/VAADIN/themes/reindeer/*</url-pattern> <!-- To take Vaadin's buildin theme from the jar file (instead of from WebRoot) -->
</servlet-mapping>
It means that when I’ll upgrade to the next version of Vaadin, I’ve to copy nothing in the VAADIN directory. I just have to:
change the jar file in WEB-INF/lib
maybe upgrade the jar files of GWT to the next version (from the vaadin distribution)
recompile my widgetset.
As Rod Johnson would say, that kind of change on the performance is not noticeable compared to one more or one less DB call. I don’t think there will be any performance impact in production (until somebody prooves me the contrary based on numbers
As stated by John in the previous posts we serve theme/widgetset files from the vaadin jar file (instead of statically).
Looking at logs I regularly see these warnings:
INFO | jvm 3 | 2010/09/12 13:39:54 | Requested resource [VAADIN/widgetsets/blackbelt.ui.widgetset.BlackBeltWidgetset/.cache.html]
not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.
INFO | jvm 3 | 2010/09/12 13:39:55 | Requested resource [VAADIN/widgetsets/blackbelt.ui.widgetset.BlackBeltWidgetset/‘,Vb=’%3Cscript]
not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.
INFO | jvm 3 | 2010/09/12 13:39:56 | Requested resource [VAADIN/widgetsets/blackbelt.ui.widgetset.BlackBeltWidgetset/%22]
not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.
Someone is scanning your site for vulnerabilities, e.g. the “.cache.html” would be for reading a GWT application source code to look for issues there (commonly a problem if the logic is on the client side, unlike Vaadin; in Vaadin, the corresponding files are the widgetset javascript containing files which do not contain application logic).
