Mark Thomas wrote:
The complications I referred to in the SSI commit are:
1. The definition of uripath says it is a context path which for the
root context would be "". In the method description it says uripath
must always start with "/". This is not consistent.
2. The definition of uripath says "uripath - a String specifying the
context path of another web application in the container.". The spec
is silent as to what the behaviour should be if uripath is the context
path for the current context, ie not "another web application".
I think there is room for interpretation in point 2 and we can safely
return the current context if that is what the caller has asked for.
My current thinking for point 1 is to treat the root context as a
special case and, crossContext permitting, to return the root context
for getContext("/")
This doesn't change any of the points I made below.
I am going to think about this for a few more days before I make any
changes.
Bill Barker wrote:
I can't really dispute the interpretation of the spec, but the change
is likely to break many more webapps then it fixes :(.
I thought this too. However, I think we should implement the spec as is.
If we start relaxing it here, then where else do we relax it? If other
Servlet containers start relaxing the specs in their own ways it rapidly
defeats the object of having a spec in the first place.
As it happens, the SSI functionality depends on the incorrect
getContext() implementation and I intend to use the current getContext()
implementation as the basis for a fix to the SSI code. This fix should
be transferable to other web-apps that have similar dependencies on
getContext().
My preference is to post a 'heads-up' to the users list that this change
is coming in the next release along with a link to the SSI changes so
users can start to look at their apps ahead of the next release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
