Bug 769470 - TomcatWarDiscoveryComponent excludes valid WAR deployments due to eager host name regular expression
TomcatWarDiscoveryComponent excludes valid WAR deployments due to eager host ...
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
All All
high Severity high (vote)
: ---
: JON 2.4.2
Assigned To: Larry O'Leary
Mike Foley
Depends On:
Blocks: 771495 784000
  Show dependency treegraph
Reported: 2011-12-20 18:14 EST by Larry O'Leary
Modified: 2012-02-07 14:22 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.4.2.CR3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 771495 (view as bug list)
JON 2.4.1
Last Closed: 2012-02-07 14:22:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
helloworld.war that should be deployed to non-standard location (866 bytes, application/octet-stream)
2011-12-20 18:14 EST, Larry O'Leary
no flags Details
Proposed patch against release-3.0.1 branch (1.37 KB, patch)
2011-12-21 10:31 EST, Larry O'Leary
no flags Details | Diff

  None (edit)
Description Larry O'Leary 2011-12-20 18:14:29 EST
Created attachment 548949 [details]
helloworld.war that should be deployed to non-standard location

Description of problem:
If a web application is deployed with a context of //localhost/myapps/helloworld it is ignored during service discovery. This is because the discovery logic attempts to confirm that the host name portion of the context path matches that of the Tomcat Virtual Host. This is done by using a regular expression to break the context into its host name and its path. The misbehaving regex is "//(.*)(/.*)" seen at http://git.fedorahosted.org/git?p=rhq/rhq.git;a=blob;f=modules/plugins/tomcat/src/main/java/org/jboss/on/plugins/tomcat/TomcatWarDiscoveryComponent.java;h=f6fa791585c796650e76544ef34917f2c9e07538;hb=6746535317a560e748a3753cb9ff4906ae6a468c#l61

With this regex, the host name becomes everything after the starting // up to the last /.

A more appropriate regex with the minimalist of change would be:


Version-Release number of selected component (if applicable):
plugins-tomcat 3.0.1

How reproducible:

Steps to Reproduce:
1. Create a directory called apps, one directory above where webapps resides
2. Copy helloworld.war into the apps directory
3. Edit server.xml and add:
       <Context docBase="../apps/helloworld.war" path="/myapps/helloworld" />
4. Start the Tomcat server
5. Add the tomcat instance to inventory
Actual results:
All WARs are added to inventory except the helloworld.war

Expected results:
helloworld.war should have appeared as /myapps/helloworld
Comment 1 Larry O'Leary 2011-12-21 10:31:26 EST
Created attachment 549052 [details]
Proposed patch against release-3.0.1 branch
Comment 2 Larry O'Leary 2012-01-03 17:53:37 EST
Updated regular expression used to extract host name from context path in TomcatWarDiscoveryComponent.java. The regular expression now uses the value following the first // and before the next / as the host name. For example, //use.this.value.as.host.name/.

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=8b30ae467afc3840f1703dd55e44b98b17688ecc on release-3.0.1
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=42d3422494523dda7ad6f8036e21fdfed8c5b082 on release_jon2.4.2.GA
Comment 3 Libor Zoubek 2012-01-05 10:42:42 EST
by following steps to reproduce on JON 2.4.2 candidate #2 deployment appears as /myapps#helloworld and is offline ( deployment is reachable on tomcat via http)
Comment 4 Larry O'Leary 2012-01-05 10:51:05 EST
This fix was not committed until after candidate #2 was built. So, we will need to wait for candidate #3.
Comment 5 Libor Zoubek 2012-01-09 11:42:35 EST
when testing on #3 I get different, tough wrong results.

deployment appears twice, first /myapps/helloworld is correct, but at the same time it appears as /myapps#helloworld and is offline

Truth is, that when tomcat stands up, directory myapps#helloworld appears in webapps dir having same content as helloworld.war.
Comment 6 Larry O'Leary 2012-01-09 11:55:16 EST
What version of Tomcat are you using? I think the one difference between my test instructions and what I am seeing is that in my Tomcat configuration I actually have it unpackWARs="false" set in my <Host name="localhost"...> section. Perhaps this is why I didn't see the extra application location.

The correct application should be /myapps/helloworld. Can you confirm this is showing available and working as expected? 

We most likely need a new bug report to dig into what the /myapps#helloworld context path is about.
Comment 7 Libor Zoubek 2012-01-09 14:09:11 EST
I have unpackWARs="true" (did not change it) and I am using EWS 1.0.2.
Comment 8 Libor Zoubek 2012-01-09 14:11:14 EST
and yes, correct application is /myapps/helloworld - shown in JON as available and also reachable on tomcat under same resource.
Comment 9 Larry O'Leary 2012-01-09 18:54:01 EST
Okay. I just tested this myself and see that the issue raised in this BZ is fixed. The issue with /myapps#helloworld being displayed is a result of a different bug that assumes that webapps contains actual web applications instead of what deployments are displayed by the objectName = "Catalina:j2eeType=WebModule,J2EEApplication=none,J2EEServer=none,name=//" + getName() + "/" + contextRoot;
Comment 10 Larry O'Leary 2012-01-09 19:11:36 EST
I have captured the new issue as Bug 772790.

Putting this one back ON_QA. From my perspective, this particular bug seems to be resolved as per Comment 8 and Comment 9.

If QA concurs, it can be moved to verified.
Comment 11 Mike Foley 2012-02-07 14:22:54 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Note You need to log in before you can comment on or make changes to this bug.