Override VAADIN/* url?

General
1

Hi.

First I would like to say that Vaadin looks great! Have just started to look at it and have a bunch of things I would like to do with it.

Have a problem deploying vaadin on other urls other than the root (/). If I deploy it on /console/ then vaadin looks for all VAADIN files under /VAADIN/. I would like to override this behaviour and serve VAADIN files under /console/VAADIN/. Is this possible?

Regards,
Sten Roger Sandvik

2

I’m not sure if this helps, but we map our Vaadin application to /vaadin/* using web.xml like:

<servlet>
  	<servlet-name>Open eSignForms Application</servlet-name>
  	<servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>
  	<init-param>
  		<description>Vaadin application class to start</description>
  		<param-name>application</param-name>
  		<param-value>com.esignforms.open.vaadin.EsfVaadinApplication</param-value>
  	</init-param>
</servlet>

<servlet-mapping>
  	<servlet-name>Open eSignForms Application</servlet-name>
  	<url-pattern>/vaadin/*</url-pattern>
</servlet-mapping>

But we still have the /VAADIN/ path in the webcontext like they recommend because it should not cause any conflict. That is, the URL you use can have different webapp context path bases, but within that context, it should be rooted at /VAADIN/.

I mean, my URL reads something like this for login: http://localhost/open-eSignFormsVaadin/

And when my Vaadin app runs (our login page is a regular JSP outside of Vaadin):
http://localhost/open-eSignFormsVaadin/vaadin/#MessageView

Clearly the webapp name here is /open-eSignFormsVaadin in this example, so any webapp name can be used.

3

Thanks, but no, that does not help. I know how to mount it on different paths, but the problem is the /VAADIN/* resources. I need this path to be under my “real” app.

Example: App is mounted on /system under context-root / (root). Then the /VAADIN/* resources should be under /system/VAADIN/*. Requesting reindeer styles.css should then request /system/VAADIN/themes/reindeer/styles.css.

Regards,
Sten Roger Sandvik

4

Hmmm… Sounds like it would be trouble from the little I’ve seen of Vaadin so far. I’m not sure what the purpose of a “real” app is, but it sounds like you somehow are segmenting a webapp even further than web server containers do, and I’m not sure why you can’t just put it in /VAADIN instead of /system/VAADIN. I mean, you could URL Rewrite so everything that points to /VAADIN is mapped to /system/VAADIN (I’d guess, but who knows what that would trigger down the line?), but if you can do that mapping, why not just put it in /VAADIN in the first place. It’s like wanting /WEB-INF to be located somewhere else. Anyway, hope you find a solution to your problem and sorry I can’t help. :frowning:

5

The reson is that we have different vaadin apps that each uses different VAADIN resource directories and does not see each other. All apps are deployed using OSGi HttpService and adds itself to a mount url. So it would be easy for us if all of vaadin was served using a single “base-path” instead of two. Or, just that the VAADIN resource directory could be renamed to something else.

Regards,
Sten Roger Sandvik

6

But, anyway. I will manage without this, but it would be nice if it’s easy to serve VAADIN theme and widgetset files from other paths. Probably a complex thing to do with all the GWT client stuff.

7

Currently it is possible to add a (single, portal-wide) path prefix in front of /VAADIN in the portlet case, but not for servlets.

Implementing support for this would require touching several private methods of AbstractApplicationServlet, including at least isStaticResourceRequest(), serveStaticResourceRequest() and getWebApplicationsStaticFileLocation().

Making such changes and making sure they work both for servlets and JSR-168 portlets in all configurations is not for the faint of heart. JSR-286 portlets should be unaffected by any changes in AbstractApplicationServlet.


This ticket
 may also be related to the same issue.