Red Hat Bugzilla – Bug 126476
Wild Chars don't seem to work
Last modified: 2007-04-18 13:09:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Description of problem:
I have used your release notes
example to set up tomcat
info=Map the Manager web application
I can access access manager through a web browser
(http://127.0.0.1/manager) and it show a page containing the two html
files and the images directory, but when I click on either the html
files or the images directory, I get unable to find error message.
Should the wild char do all files and all sub dirs?
The base OS is RHEL 3.0 update 1
Also had a couple of issues installing :-
1. The install does not create the tomcat4 & bhcompile users
2. Need to install the RPMs twice (second time with --force) to get
the tomcat to start without errors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Follow instructions from your webpage to install
2. Start tomcat4 and httpd
3. Browse to http://127.0.0.1/manager
4. Try to load one of the html files
Actual Results: unable fto find page
Expected Results: should open page, works ok when accessing tomcat
Can you reproduce the manager problem with the tomcat5 package? The
tomcat4 one has been deprecated, we are not going to support it in the
GA (unless Marketing says otherwise). Anyway, as it works with tomcat
directly, this would be a bug against mod_jk2 I think.
But it may not be it at all: some jpackage.org folks that run
production servers tightened up the permissions of some tomcat
directories for security reasons. This may very well be the cause
(and in this case there is nothing we can do but change the
documentation -- security takes precedence).
I also need to know what was in the system before the update. Several
packages (RHUG and jpackages alike) had improper code in the %post
section of their spec files. If you did all the 'rpm -e' recommended
in the Release Notes and still saw this problem, please open a bug
report for this. Note that if you had a previous version of the
tomcat4 package you are supposed to remove it with 'rpm -e' first as
Product Manager decided not to support updates from Beta (so you have
to remove the old and then install the new).
W.r.t. the tomcat4 userid, we are not going to have tomcat4 or tomcat5
users. The user for tomcat will always be tomcat. The versioned
username is a jpackage.org folly that we are not accepting (it has
been discussed with rel-eng already). No file should be owned by
bhcompile -- if there are still files owned by it in the tomcat5
package please file a separate bug as there must be some problem in
the spec file's %files section.
1. Where is the tomcat5 package?
I did the correct rpm -e commands as per release notes, I will open a
separate bug for the if I still have the problem with the tomcat5
Humm, it should be in that same beta channel...
Doesn't 'up2date tomcat5' bring it in?
Unfortunatly the machine I am testing on does not have direct access
to the internet. Is there another way to download it?
Searching on rhn for tomcat in packages returns nothing
Not that I know of. :-( How did you get the tomcat4 in?
Downloaded the ISO image from the RHN and followed the release notes
for installing from RPM's
RHN only show :-
mod_jk2 Tomcat mod_jk2
You are absolutely right. The Tomcat 5.0 was not included in the Beta
:-( Will be in the final release.
I will have to try and reproduce that for you. I will do that and get
back to you.
BTW, before I forget, thanks for the report.
Is there going to be another beta release?
When will the final release be available?
We are trying to upgrade from AS 2.1 with Stronghold to RHEL 3.0 and
Is there no way for me to download the tomcat5 and help you with the
We decided to update the rpms in this beta. This should happen soon.
Before that I don't know how to get you a tomcat5 RPM. But someone
is setting up a scenario to reproduce the problem you've described in
a machine here.
The final release should occur sometime this Summer. Sorry if I can't
be more precise.
I will get back to you as soon as we get some data from the tests.
Just to confirm that we were able to reproduce this problem. We are
proceeding to investigate the cause and the best solution.
Again, thanks for bringing this to our attention.
This is not a bug per se. This deals more with the specifics of using
If your intention with:
was to forward everything under manager to tomcat, then a better way
would be to use the explicit regular expression mapping directive.
This can be done by prefixing your uri directive with a $, i.e:
info=Map the Manager web application
This will allow apache to treat everything that follows the $ as
aregular expression and will forward all requests that match to tomcat.
Alternatively you will need to be more explicit with your uri mapping
directives and add subsequent directives for mapping individual parts
of the manager web application.
According to O' Reilly's Tomcat-DefinitiveGuide, Apache will try to
fulfill requests for any URI that isnt specifically configured to be
passed through to Tomcat and the error that you see is a result of
Apache's failure in resolving the request.
If you have any other concerns, please feel free to contact me.