Bug 769470

Summary: TomcatWarDiscoveryComponent excludes valid WAR deployments due to eager host name regular expression
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: PluginsAssignee: Larry O'Leary <loleary>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 3.0.1, 4.0.0, 4.1, 4.2, 4.3CC: hrupp, lzoubek
Target Milestone: ---   
Target Release: JON 2.4.2   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 2.4.2.CR3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 771495 (view as bug list) Environment:
JON 2.4.1
Last Closed: 2012-02-07 19:22:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 771495, 784000    
Attachments:
Description Flags
helloworld.war that should be deployed to non-standard location
none
Proposed patch against release-3.0.1 branch none

Description Larry O'Leary 2011-12-20 23:14:29 UTC 
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:

"//([^:/\\s]+)(/.*)"



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

How reproducible:
Always

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 15:31:26 UTC 
Created attachment 549052 [details]
Proposed patch against release-3.0.1 branch
Comment 2 Larry O'Leary 2012-01-03 22:53:37 UTC 
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 15:42:42 UTC 
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 15:51:05 UTC 
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 16:42:35 UTC 
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 16:55:16 UTC 
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 19:09:11 UTC 
I have unpackWARs="true" (did not change it) and I am using EWS 1.0.2.
Comment 8 Libor Zoubek 2012-01-09 19:11:14 UTC 
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 23:54:01 UTC 
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-10 00:11:36 UTC 
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 19:22:54 UTC 
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE