cannot load pages with 6.6.7

Hi all,

When I switch one of my apps from v6.6.6 to v6.6.7, the page no longer renders. With this change (and no other), this is what I’m seeing in the log:

[#|2011-09-28T20:57:34.987-0400|INFO|glassfish3.1.1|com.vaadin.terminal.gwt.server.AbstractApplicationServlet|_ThreadID=21;_ThreadName=http-thread-pool-8080(3);|Requested resource [VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js]
not accessible in the VAADIN directory or access to it is forbidden.|#]

[#|2011-09-28T20:57:35.042-0400|INFO|glassfish3.1.1|com.vaadin.terminal.gwt.server.AbstractApplicationServlet|_ThreadID=19;_ThreadName=http-thread-pool-8080(2);|Requested resource [VAADIN/themes/reindeer/styles.css]
not accessible in the VAADIN directory or access to it is forbidden.|#]

[#|2011-09-28T20:57:35.075-0400|INFO|glassfish3.1.1|com.vaadin.terminal.gwt.server.AbstractApplicationServlet|_ThreadID=23;_ThreadName=http-thread-pool-8080(5);|Requested resource [VAADIN/themes/reindeer/favicon.ico]
not accessible in the VAADIN directory or access to it is forbidden.|#]

This looks like
issue 7670
. Is it the case that we should no longer map /* to our application but should copy the VAADIN directory to our web root and only map “/” (or whatever we’re using)? While this is a good practice, you may want to note in the general news forum that simple applications will have to change to use 6.6.7. I still see the /* mapping in web.xml in the example in the Book of Vaadin.

Thanks,
Bobby

Hi

same problem here. But i updated from 6.6.5 to 6.6.7

[#|2011-09-29T08:20:23.448+0200|INFO|sun-appserver2.1|com.vaadin.terminal.gwt.server.AbstractApplicationServlet|_ThreadID=18;_ThreadName=httpSSLWorkerThread-80-1;|Requested resource [VAADIN/themes/style/styles.css]
not accessible in the VAADIN directory or access to it is forbidden.|#]

[#|2011-09-29T08:20:28.616+0200|INFO|sun-appserver2.1|com.vaadin.terminal.gwt.server.AbstractApplicationServlet|_ThreadID=17;_ThreadName=httpSSLWorkerThread-80-0;|Requested resource [VAADIN/themes/style/img/bg_header_logo.png]
not accessible in the VAADIN directory or access to it is forbidden.|#]

Greets

Hi,

Same problem (…not accessible in the VAADIN directory or access to it is forbidden…) here. Would be good to know how it is supposed to be configured now.

Regards,
/mareks

Investigating this - do you see it with application servers other than GlassFish?

As a quick workaround, you can override AbstractApplicationServlet.isAllowedVaadinResourceURL().
It would also be helpful to see the URL that comes in there.

Same problem here. As I have my widgetset with some addons I create a jar with some core code of mine where I also put the widgetset and our base theme. It would be great if I could continue to use this kind of approach.

Regards,
Bruno

Same here on tomcat 7.0.21

Copying the resources out of the JAR is recommended for production environments - especially those under heavy load. However, it should not be required and “/*” should work to make development and lower load deployment easier.

It looks like GlassFish extracts the JAR contents upon deployment of a WAR rather than use them directly. The integration tests we have run with GlassFish and other servers have had the resources directly in the project rather than in JARs, so serving them via the servlet context worked in the tests and the class loader fallback was never used in them.

I’ll look into this in more detail.

Even the resources inside vaadin-6.6.7.jar (also happens with vaadin-6.7.0.rc1.jar) are not accessible…

I just tried taking everything out of the jar (themes & widgetset) and everything works

Maybe something wrong on the ApplicationServlet class because of those last security fixes?

Regards
Bruno

Overriding AbstractApplicationServlet.isAllowedVaadinResourceURL() cures the problem for now.

URL that comes in there is like (resourceUrl.toString()):

file:/export/home/mareks/opt/glassfish3/glassfish/domains/domain1/generated/jsp/TestApplication/loader_15971352/VAADIN/themes/runo/styles.css

Appserver is glassfish (3.1) and TestApplication is a war application.

/mareks

Thanks for looking into it. I saw here that someone saw the same issue on Tomcat as well.

I have a related question. This is the first time I’ve actually added the VAADIN dir to my project rather than serving the content through the servlet. It’s working fine with my servlet mapped to /* (to work around the above issue). But when I map simply / to my application I get the following error from the browser after a few seconds:

Is it supposed to work to only map “/” to my application servlet, or should I map /* or /VAADIN as well? From the browser I can load the js file, I think. E.g., I can see the source with this URL (in Chrome, with my app’s context root mapped to /):


view-source:http://localhost:8080/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js

So the nocache.js file can being found externally, but my application is failing to load anyway. I can start a new thread about this, but if the simple answer is “no you need to still have some processing happen in the servlet” then I won’t bother with a new thread.

Thanks,
Bobby

I have a similar problem after upgrading from 6.6.6 to 6.6.7. My Icons can’t be loaded anymore:

Sep 29, 2011 10:55:46 AM com.vaadin.terminal.gwt.server.AbstractApplicationServlet serveStaticResourcesInVAADIN
INFO: Requested resource [VAADIN/icons/plus_32.png]
 not accessible in the VAADIN directory or access to it is forbidden.
Sep 29, 2011 10:55:52 AM com.vaadin.terminal.gwt.server.AbstractApplicationServlet serveStaticResourcesInVAADIN
INFO: Requested resource [VAADIN/icons/delete_16.png]
 not accessible in the VAADIN directory or access to it is forbidden.

I’m using Tomcat 7.0.19

Could you retest this with the latest 6.6 nightly build? It only has two changes, one of which should hopefully fix this problem.

As for mappings, Vaadin applications do also access URLs such as …/APP/… so a mapping of either “/" or "/myapp/” is needed. In the latter case, also resources in /VAADIN/* (relative to the context path of the application) have to be available, either by being mapped to the servlet or served directly as static resources by the server.

The widgetset consists of the “loader” JS you see and a browser-specific part. Nevertheless, the application should work if they are available directly from the server at the correct location. Do you have your application running in the root context in your test?

Hi,

Latest 6.6.8 nightly fixes this problem (no need to override isAllowedVAADINResourceUrl). At least on glassfish.

/mareks

I’m sorry I didn’t get back to this in time to test right away. Everything works with the 6.6.8 build, but if there’s a specific nightly jar you’d like me to test anyway I’d be happy to.

Yes, I was running with the root context. Thank you for the information about the mappings. I’ve always had a question about that, but hadn’t yet tried to serve the static resources directly from my web root. One last time to be clear: if I’m running with the root context, and if I’ve copied the VAADIN files to my web root, then I should map “/" to my application servlet and "/VAADIN/” to not use the servlet (assuming I can figure out how to write that descriptor properly). Is that correct? It would be nice to have something more specific to map to the servlet, such as / and /APP/, so that the static content doesn’t have to be listed. I’m ok with / though.

Cheers,
Bobby

No need anymore if 6.6.8 works for you.

In development environments, if running in root context, I would recommend simply mapping “/*” to the servlet.

In production environments, especially ones with high load, you might want to have the static resources served before the servlet sees them.

If you have a web server in front of the servlet container, that would be the best place to do it. If not, you could e.g. map “/VAADIN/*” to a default servlet - I believe the one from Tomcat is included in GlassFish but perhaps not declared by default:

<servlet>
    <servlet-name>DefaultServlet</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
</servlet>