MySQL Bugs: #29038: If the Tomcat url is given, you aren't re-directed to the Dashboard login page

Bug #29038	If the Tomcat url is given, you aren't re-directed to the Dashboard login page
Submitted:	12 Jun 2007 1:36	Modified:	16 Apr 2009 0:03
Reporter:	Bill Weber	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S3 (Non-critical)
Version:	1.2.0.5891	OS:	Any
Assigned to:	BitRock Merlin	CPU Architecture:	Any

Description:
With the Apache/PHP versions (1.0, 1.1), if you gave the Apache url (ie http://127.0.0.1:88), we re-directed you to the Dashboard login page. In the JSP/Struts version (1.2+), we aren't redirecting you to the Dashboard login page if you give the Tomcat url (ie http://127.0.0.1:8080).

How to repeat:
see above

This is because all activity specific to an application happens within its context, in this case 'merlin'. In order to implement the requested behavior, we'll have to hijack the default context, which is not necessarily a bad idea.

I'll investigate this further, it's likely to be part of the install process.

I talked to sloan about this and he has no problem with it. The tomcat manager should still be available through the "/manager" context.

After looking into this, I think our best bet is to create an xml fragment in webapps that describes the context configuration and sets the path to "". I believe the war would still be unpacked for you but you get the chance to create the context yourself instead of having tomcat create one based on the name of the war file.

See section 3 number 2 on http://www.onjava.com/pub/a/onjava/2003/06/25/tomcat_tips.html

Josh,

So this sorta works, but there are some problems that maybe you know
how to fix (my knowledge of Tomcat and contexts is limited).

1) I installed 1.2 on a box.

2) Before launching the services I added the following to server.xml:

3) I forget exactly where BitRock directed me when it started the
browser, but I went to http://localhost:18080 and *eventually* got
the first-time setup page. I say *eventually* because it took
quite a while to load and this is not a slow box. Don't know why.
Maybe it was exanding merlin.war again, even thought it had already
been expanded.

4) Filled out all the info, pressed save, saw the user settings page,
selected a timezone and locale, pressed save, and was in the app.
Eureka! Note that I was at http://localhost:18080/Monitor.action.

5) Started an agent. Kept waiting for it to show up on screen, but it
didn't. Checked the DB and saw the expected data in inv_agents.
inv_servers, and dc_integer, but no agents on screen.

6) So instead of http://localhost:18080/Monitor.action, I browsed to
http://localhost:18080/merlin/Monitor.action. Got the login screen
and logged in and there was my agent! However, there was also the
first-time user settings screen. Tried entering a timezone and
locale, but kept getting an error message:

com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationExcep
tion: Duplicate entry '1-user.timezone' for key 1

This is because I'd already logged in as that user at
http://localhost:18080/Monitor.action, but now I was at
http://localhost:18080/merlin/Monitor.action

So it seems like some parts of the app are context-aware. I hope you
can fix this or know what is going on. A reasonable compromise, to
me, is to make http://localhost:18080/merlin the base URL of our app
rather than http://localhost:18080/merlin.

Thanks,

Andy

Please deploy merlin.war in webapps/ROOT rather than webapps/merlin so Merlin is the default web app.

Javier,  Here's a bit more info so you have more context.

Hi Andy,

Basically, BitRock needs to install our app in webapps/ROOT instead of webapps/merlin

_We_ need add the following bit in web.xml (but we'll check it in to our sources, I'll pull the trigger on this later today):

	<servlet-mapping>
		<servlet-name>main</servlet-name>
		<url-pattern>/merlin/main</url-pattern>
	</servlet-mapping>

	<servlet-mapping>
		<servlet-name>heartbeat</servlet-name>
		<url-pattern>/merlin/heartbeat</url-pattern>
	</servlet-mapping>

	<servlet-mapping>
		<servlet-name>rest</servlet-name>
		<url-pattern>/merlin/rest</url-pattern>
	</servlet-mapping>

We'll need to have them change the URLs generated in the _agent_ and service-manager installers to remove "/merlin/", and let the docs team know that the URLs have been changed. We can leave the URLs as-is in agent.inis which are being upgraded.

The only goofy thing for developers will be that when running under the tomcat plugin in eclipse, the servlets will be available under "/merlin/merlin", but that won't be a big deal.

	-Mark

Patch sent to Keith. I've provided as well a web.xml file that worked in our tests. Please note that the installer xml project files will not work without the proper changes in web.xml.

Per Merlin Bug Council we are deferring this to a later release.

Noted as a "Known Issue" in the docs version 1.2.

move our stuff to root (and early enough so we don't decide it's too late)

Patch sent to Keith.

Fixed via re-direct, should we review for 2.0?

verified fixed