DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39663>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39663


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |




------- Additional Comments From [EMAIL PROTECTED]  2006-06-07 21:19 -------
I've been looking at this for the past few hours - and there is something not
quite consistent here. I believe it has to do with how the
ProxyDirContext.contextName gets setup. When this gets setup to "" - ie. blank
context then everything works as expected. However, when the context is set to
"/meshcms" then this causes the misery.

As far as I can tell this occurs under the following conditions - which I
suppose amounts to the same thing:

  Host's appBase == Context's docBase || docBase == ""

... if appBase is set to anything else (a non-existent dir or even "") and
docBase is set to the exact path then contextName is "" - otherwise it
interprets the first bit of the path as the context, ie. "/meshcms". In this
event the web.xml is not found - hence the warning about web.xml not found - and
the taglib is not setup. The "/admin/..." path is a red-herring - I can't
remember why it happens - but it's not important - the failure occurs from
trying to find web.xml at /meshcms/WEB-INF/web.xml - and failing.

This does seem a little inconsistent to me - if the docBase is set to a
particular value - either derived as it is "", a relative path or a
fully-qualified path then this should probably take prority - even if the
appBase points to the same dir. Working as it currently does gives the following
behaviour that I think is confusing:

#  appBase    docBase   contextName  Works?
-  -------    -------   -----------  ------
1  /tmp/wa1   ""        "/wa1"       fails
2  /tmp/wa1   /tmp/wa1  "/wa1"       fails
3  /tmp/bb    /tmp/wa1  ""           works
4  ""         /tmp/wa1  ""           works

It seems in .12 - contextName == "" - for at least the scenario outlined by
Luciano - scenario 1, above - hence why this worked in .12 - and does not now
work in .16.

Having re-read the definitions for the above - Filip is of course correct - that
this is an inconsistent use of these properties - having the webapps' parent and
a webapp pointing to the same directory - but the confusing element is that this
behaviour has changed between .12 and .16  - this has bitten several of us here
- me included.

I suspect the change lies somewhere in the code that sets the
"ContainerBase.resources" (ProxyDirContext) .contextName - by examining the
defined values for appBase and docBase - but  I presume this change has been
made for good reason - I have not attempted to track-down the details of this
change.

I have re-opened this bug (sorry Filip) - so that it can be investigated further
- I believe there either needs to be an exception thrown to indicate the fact
that the context has the same base as the webapps so at least a visible
exception is thrown - or it needs to behave as it did in .12 - ie. the context's
docBase setting takes priority when determining the webapp's context.

As a simple workaround - set the appBase="" and the docBase to the
fully-qualified path of the webapp - works for me. A better, more-robust
solution may be to follow Filip's advice given for putting the webapp in a
directory under the appBase.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to