Name Virtualhost scenario

[matutano6]

Hi,
I'm trying to configure a name based virtualhost with Apache Web Server doing reverse proxy to Tomcat where the Activiti Explorer is deployed.

The "important" part of web server configuration is as follows:

ProxyPass /activiti-explorer/ http://127.0.0.1:8080/activiti-explorer/
ProxyPassReverse /activiti-explorer/ http://127.0.0.1:8080/activiti-explorer/


With that configuration, I tried to mask the application context path, but the context path is present in many parts of the response:


vaadin.vaadinConfigurations["activitiexplorerui-1528442030"] = {appUri:'/activiti-explorer/ui', standalone: true, themeUri:"/activiti-explorer/VAADIN/themes/activiti", versionInfo :


So I decide to expose the application context path with the following configuration:

ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/


but a following problem arises: the action URL of the login form has an absolute URL indicating protocol, host and port:

<form id="loginf" method="post" onkeypress="submitOnEnter(event)" target="logintarget" action="http://127.0.0.1:8080/activiti-explorer/ui/1/loginHandler">


When I try to login, the browser gets a "404 Not Found" (seen with firebug) because that URL does not match the virtualhost (in fact, it neither reaches the web server).

I tried using "ProxyPreserveHost On" (that makes the reverse proxy to include the Host: header with the appropriated hostname in the HTTP request made to Tomcat) and using the hostname on the ProxyPass and ProxyPassRevers URLs with the same results.

¿Is there any way to configure Activiti Explorer to use relative URLs as much as possible? At least, I need to eliminate full absolute URLs and can handle with full path relative URLs (i.e. starting from /activiti-explorer/...).

Thanks in advance!
M.

[matutano6]

Hi,
after a couple of days, I retry the login to investigate further and the login HTML was correct. I mean, the URL is still absolute, but the domain and port (and I assume that protocol will follow them if it were https) are the same as in the browser URL bar.

To be clear: none of the configurations were changed nor any component was restarted between the missbehavior of the last weekend and the correct one of today. I think then, it has something to do with some cachè mechanism. ¿Could you please tell me something about that to know as much as possible about the internals?

Thanks,
M.

[jbarrez]

hmmm that sounds very odd. There is no caching whatsoever going on …

Can't it be an apache sync issue … ie it didn't know the server was online … or something in that area… just guessing.

[matutano6]

No, I don't think it was an apache issue because I made test directly to Tomcat using telnet/netcat and I was seeing that behavior.

It's solved now and working as expected. Nevertheless, I'd like to know how the absolute URL is build inside the Java application in case there's a J2EE container issue (with Tomcat?). Why not to use a relative URL?

Thanks,
M.

[jbarrez]

The url is not absolute, it is dynamically built up, see the org.activiti.explorer.ui.login.ExplorerLoginForm class.

[matutano6]

I saw in Explorer's code that the URL is obtained by invoking com.vaadin.ui.LoginForm.getApplication().getURL(), so it's a Vaadin matter.

I have not look at Vaadin's code yet, but at least in the version of Vaadin distributed with Explorer 5.14, it returns an absoulte URL (begining from protocol). IMHO I would like to have a relative URL (without protocol and host, begining at the path part) in case of a scenario where the discovered absolute URL may be incorrect as in some cluster architectures.

With the information you gave me I know were to look at if I get in trouble with it, so thanks for your help!

Regards,
M.

[jbarrez]

thanks for the information, an absolute URL there would indeed not be very good practice!