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
Created attachment 549052 [details] Proposed patch against release-3.0.1 branch
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
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)
This fix was not committed until after candidate #2 was built. So, we will need to wait for candidate #3.
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.
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.
I have unpackWARs="true" (did not change it) and I am using EWS 1.0.2.
and yes, correct application is /myapps/helloworld - shown in JON as available and also reachable on tomcat under same resource.
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;
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.
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE