You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gary Lawrence Murphy <ga...@teledyn.com> on 2010/12/14 21:49:30 UTC
troubleshooting getPathInfo in jsp files
I am using Tomcat 6.0.20-2ubuntu2.2 on an AWS-hosted 64-bit Ubuntu 9.10
running on Java SE Runtime Environment (build 1.6.0_15-b03) and I am having
difficulty emulating getPathInfo() behaviour that works in other servlet
containers (jetty and resin)
I have a JSP file under ROOT:
<%@page language="java" contentType="text/plain"
session="false" buffer="2kb"
%>
<path-info><%= request.getPathInfo() %></path-info>
<path-translated><%= request.getPathTranslated() %></path-translated>
<query-string><%= request.getQueryString() %></query-string>
when called with http://localhost:8080/test.jsp it reports three nulls
when called with http://localhost:8080/test.jsp?query it reports the
query-string
however when called with http://localhost:8080/test.jsp/this it fails as a
404 not found
by comparison, on a resin-4 server running the same jsp code, same os and
java version
when called with http://localhost:8080/test.jsp it reports
<path-info>/test</path-info>
<path-translated>/opt/resin-4/webapps/ROOT/test</path-translated>
<query-string>null</query-string>
and when called with http://localhost:8080/test.jsp/this?query it gives the
expected
<path-info>/test</path-info>
<path-translated>/opt/resin-4/webapps/ROOT/test</path-translated>
<query-string>query</query-string>
what could I have messed up in the installation? could tomcat6 be
encountering a conflicting jar file before its expected version? do I need
to enable some feature to get pathinfo parsing on jsp files?
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
I was guessing it was an error, or a mis-parsing; there was no trace
printed, but the webapp containing that servlet-mapping was listed in the
admin as not-loaded. Correcting that line in the web.xml, the webapp loaded
fine. I can investigate further.
On Wed, Dec 15, 2010 at 11:33 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gary,
>
> On 12/14/2010 5:56 PM, Gary Lawrence Murphy wrote:
> > oh, and I did try /test.jsp/* even though needing to explicitly match
> every
> > jsp in the project would be prohibitively inflexible, but there again, it
> > produced a parsing error and the webapp would not load.
>
> If that produced a parse error, I'd like to see the configuration and
> the stack trace: Tomcat should allow a url-pattern of "/test.jsp/*".
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0I7bwACgkQ9CaO5/Lv0PAtZgCff+zt/4/R3gDk4ljaCUM68p9x
> w6wAmgJT3LI26JGfEJDU5VSias8pfLvr
> =0YPY
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/14/2010 5:56 PM, Gary Lawrence Murphy wrote:
> oh, and I did try /test.jsp/* even though needing to explicitly match every
> jsp in the project would be prohibitively inflexible, but there again, it
> produced a parsing error and the webapp would not load.
If that produced a parse error, I'd like to see the configuration and
the stack trace: Tomcat should allow a url-pattern of "/test.jsp/*".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0I7bwACgkQ9CaO5/Lv0PAtZgCff+zt/4/R3gDk4ljaCUM68p9x
w6wAmgJT3LI26JGfEJDU5VSias8pfLvr
=0YPY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
oh, and I did try /test.jsp/* even though needing to explicitly match every
jsp in the project would be prohibitively inflexible, but there again, it
produced a parsing error and the webapp would not load.
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
with the latest resin the pro and unpro are the same code, just with code
disabled until unlocked (which also sounds like the oldschool pricing models
:( but the parsing of the jsp is the same as before, the pathinfo after the
.jsp/ is accessible. It is a very elegant syntax actually.
I'll look into the TC7 code and see what I'm up against.
On Wed, Dec 15, 2010 at 11:58 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gary,
>
> On 12/15/2010 11:40 AM, Gary Lawrence Murphy wrote:
> > Resin will only work on single CPU although it will use all the cores of
> > that CPU; to work with multiple CPU we could license the pro version, but
> > the cost for us is prohibitive.
>
> That's interesting that Resin constrains you to a single CPU (but up to
> 4 cores). I didn't know that Java code could impose that requirement.
> Perhaps they play some games at the native level. Sounds like Oracle's
> old pricing models. :(
>
> I wouldn't be surprised if you /did/ upgrade to latest version of the
> the Pro Edition if your url-patterns didn't fail there, too. The spec
> has been tightened around v2.5 (that would be Tomcat 5.5/6) which was
> quite a long time ago, now.
>
> > the idea was floated to fork Tomcat to insert our own parsing rule on the
> > servlet-mapping, and I may also investigate that; my worry is creating a
> > maintenance nightmare where upgrades become risky, however it may turn
> out
> > that the other containers also do servlet-mapping in this way and we'd be
> > forced to use a modified TC.
>
> I don't think you need a full fork just to add this capability, though
> it might not be as simple as extending a class or two and setting a
> configuration option. In Tomcat 7.0.x, everything starts in
> org.apache.tomcat.http.mapper.Mapper.internalMapWrapper.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0I87gACgkQ9CaO5/Lv0PBEDwCdHBzHmylva5pF42psAuNFU8CH
> Fu0An3K60U3zQWYrtzVxiZa0GSTSbPOk
> =Ilnl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/15/2010 11:40 AM, Gary Lawrence Murphy wrote:
> Resin will only work on single CPU although it will use all the cores of
> that CPU; to work with multiple CPU we could license the pro version, but
> the cost for us is prohibitive.
That's interesting that Resin constrains you to a single CPU (but up to
4 cores). I didn't know that Java code could impose that requirement.
Perhaps they play some games at the native level. Sounds like Oracle's
old pricing models. :(
I wouldn't be surprised if you /did/ upgrade to latest version of the
the Pro Edition if your url-patterns didn't fail there, too. The spec
has been tightened around v2.5 (that would be Tomcat 5.5/6) which was
quite a long time ago, now.
> the idea was floated to fork Tomcat to insert our own parsing rule on the
> servlet-mapping, and I may also investigate that; my worry is creating a
> maintenance nightmare where upgrades become risky, however it may turn out
> that the other containers also do servlet-mapping in this way and we'd be
> forced to use a modified TC.
I don't think you need a full fork just to add this capability, though
it might not be as simple as extending a class or two and setting a
configuration option. In Tomcat 7.0.x, everything starts in
org.apache.tomcat.http.mapper.Mapper.internalMapWrapper.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0I87gACgkQ9CaO5/Lv0PBEDwCdHBzHmylva5pF42psAuNFU8CH
Fu0An3K60U3zQWYrtzVxiZa0GSTSbPOk
=Ilnl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
On Wed, Dec 15, 2010 at 11:29 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
>
> A high-volume real-time environment where on-the-fly JSP compilation is
> allowed and ad-hoc insertion of new dynamic content is allowed? Sounds
> like madness.
>
yes it is. such is the real world. we deal in sports news, about 20-40 xml
documents per second inbound to an xsl process that requires various utility
services such as timezone conversions, with two orders of magnitude outbound
publishings of the results which require various authentication rules.
Being live human-generated data, we are required to be fleet of foot, and
if it goes down, or even slows down, the fantasy sports people start to lose
big money.
it is improvisational, absolutely.
> May I ask what the problem is with sticking with Resin and/or Jetty? As
> much as I like Tomcat myself... why are you considering switching?
Resin will only work on single CPU although it will use all the cores of
that CPU; to work with multiple CPU we could license the pro version, but
the cost for us is prohibitive. Everything was fine working on quad-core
servers, however we now have a good case to move to amazon cloud-hosted
services for scaling reasons, however AWS servers appear as 1-core multi-CPU
machines, at best dual core, which makes a highly multithreaded java app
pretty much useless.
the sysstat clearly shows that Caucho is enforcing that single-CPU rule, it
is not inherent in java, and mpstat proves that other servlet containers
will use all available cores. So the hunt was on for an affordable
alternative. We had begun with Jetty but had to abandon it years ago as it
was expensive to maintain and did not perform well under extreme loads
typical of certain sports events (playoffs, olympics etc) although I may
revisit it if tomcat does not work out.
the idea was floated to fork Tomcat to insert our own parsing rule on the
servlet-mapping, and I may also investigate that; my worry is creating a
maintenance nightmare where upgrades become risky, however it may turn out
that the other containers also do servlet-mapping in this way and we'd be
forced to use a modified TC.
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/14/2010 10:08 PM, Gary Lawrence Murphy wrote:
> I am in a high-volume real-time environment where editing
> the web.xml to insert a new service is simply not an option, the recognition
> of .jsp scripts with pathinfo appended needs to be fluid and generic to
> allow ad-hoc insertions.
A high-volume real-time environment where on-the-fly JSP compilation is
allowed and ad-hoc insertion of new dynamic content is allowed? Sounds
like madness.
> Oh well. Thanks for your help in all this and for the ideas and
> explanations; looks like I'm stuck with resin and jetty; there's far too
> many scripts and other systems dependent on these URL patterns to rewrite it
> all now (the eternal curse of the legacy software)
You are certainly welcome to patch Tomcat yourself: the Mapper uses the
simple url-pattern mapping rules specified by the servlet spec... you
could simply add your own that used "true" globbing or even regular
expressions if you are into that kind of thing.
May I ask what the problem is with sticking with Resin and/or Jetty? As
much as I like Tomcat myself... why are you considering switching?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0I7PcACgkQ9CaO5/Lv0PCqmACgjxkHkiJOZUMn5AsbCgP9Pj2D
3AAAn3WZU7izdwRydPJOTogi8z1pd2jN
=qRkk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
Thanks for the tip; I can't confirm it right now but it seems to me I tried
to do just such a mapping and it also violated the parsing rules and was
rejected by the webapp loader.
regardless though, I am in a high-volume real-time environment where editing
the web.xml to insert a new service is simply not an option, the recognition
of .jsp scripts with pathinfo appended needs to be fluid and generic to
allow ad-hoc insertions. Even with an auto-recognition of the update to the
web.xml, it would take down all the jsp-generated servlets every time a
change is made and that would upset a lot of client business.
Oh well. Thanks for your help in all this and for the ideas and
explanations; looks like I'm stuck with resin and jetty; there's far too
many scripts and other systems dependent on these URL patterns to rewrite it
all now (the eternal curse of the legacy software)
On Tue, Dec 14, 2010 at 7:30 PM, Mark Thomas <ma...@apache.org> wrote:
> On 15/12/2010 00:00, Mark Thomas wrote:
>
>> On 14/12/2010 22:54, Gary Lawrence Murphy wrote:
>>
>>> On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz<
>>> chris@christopherschultz.net> wrote:
>>>
>>>
>>>> however when called with http://localhost:8080/test.jsp/this it
>>>>> fails as
>>>>>
>>>> a
>>>>
>>>>> 404 not found
>>>>>
>>>>
>>>> Actually, this makes sense to me: the default mapping for the JSP
>>>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
>>>> not match the url-pattern.
>>>>
>>>> this is the crux of the problem, and the showstopper preventing us from
>>>>
>>> deploying under Tomcat -- all our applications use this convention
>>> and, as I
>>> said, it works in other servlet containers.
>>>
>>> I tried using *.jsp/* and this threw a parsing error,
>>>
>> Hmm. Odd. I'll look into that. It won't work they way you want but I'd
>> like to get to the bottom of the parsing error.
>>
>> the webapp refused to run load. *.jsp* ignored all jsp files.
>>>
>> The * characters are probably being treated literally.
>>
>> I think other servlet containers
>>> are using a globbing that is assumed to be the complete expression,
>>> which in
>>> regex would be .*\.jsp, whereas it appears that tomcat is taking it in
>>> what
>>> a regex would phrase as .*\.jsp$, ie it is enforcing the end of the
>>> string
>>> as the end of the candidate string. If this behaviour cannot be
>>> changed, I
>>> have to change servlet containers, so I'm eager to find out one way or
>>> the
>>> other if tomcat can accommodate this.
>>>
>>
>> Tomcat is following the mapping rules in the Servlet spec. It looks like
>> Resin has some proprietary extensions to the mapping rules. I'd be
>> surprised if you found other containers supporting them.
>>
>
> I can get Tomcat to behave the way you want but configuring web.xml isn't
> going to be pretty. I'd strongly recommend moving to an approach more in
> line with the Servlet spec rather than the current container-specific
> mapping approach.
>
> If you have a JSP in the root of your webapp called snoop.jsp (I took this
> from the examples web app) then you'll need to add the following:
> <servlet>
> <servlet-name>snoop</servlet-name>
> <jsp-file>/snoop.jsp</jsp-file>
> </servlet>
> <servlet-mapping>
> <servlet-name>snoop</servlet-name>
> <url-pattern>/snoop.jsp/*</url-pattern>
> </servlet-mapping>
>
> As I said, adding that for every single JSP isn't going to be pretty but it
> does give you a way to make this work on Tomcat (or any other container).
>
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
RE: troubleshooting getPathInfo in jsp files
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark Thomas [mailto:markt@apache.org]
> Subject: Re: troubleshooting getPathInfo in jsp files
> I can get Tomcat to behave the way you want but configuring web.xml
> isn't going to be pretty. I'd strongly recommend moving to an approach
> more in line with the Servlet spec rather than the current
> container-specific mapping approach.
> If you have a JSP in the root of your webapp called snoop.jsp (I took
> this from the examples web app) then you'll need to add the following:
> <servlet>
> <servlet-name>snoop</servlet-name>
> <jsp-file>/snoop.jsp</jsp-file>
> </servlet>
> <servlet-mapping>
> <servlet-name>snoop</servlet-name>
> <url-pattern>/snoop.jsp/*</url-pattern>
> </servlet-mapping>
> As I said, adding that for every single JSP isn't going to be pretty but
> it does give you a way to make this work on Tomcat (or any other container).
Perhaps tweaking the ant JSP pre-compilation script to generate the mappings would help ease the pain.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 15/12/2010 00:00, Mark Thomas wrote:
> On 14/12/2010 22:54, Gary Lawrence Murphy wrote:
>> On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz<
>> chris@christopherschultz.net> wrote:
>>
>>>
>>>> however when called with http://localhost:8080/test.jsp/this it
>>>> fails as
>>> a
>>>> 404 not found
>>>
>>> Actually, this makes sense to me: the default mapping for the JSP
>>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
>>> not match the url-pattern.
>>>
>>> this is the crux of the problem, and the showstopper preventing us from
>> deploying under Tomcat -- all our applications use this convention
>> and, as I
>> said, it works in other servlet containers.
>>
>> I tried using *.jsp/* and this threw a parsing error,
> Hmm. Odd. I'll look into that. It won't work they way you want but I'd
> like to get to the bottom of the parsing error.
>
>> the webapp refused to run load. *.jsp* ignored all jsp files.
> The * characters are probably being treated literally.
>
>> I think other servlet containers
>> are using a globbing that is assumed to be the complete expression,
>> which in
>> regex would be .*\.jsp, whereas it appears that tomcat is taking it in
>> what
>> a regex would phrase as .*\.jsp$, ie it is enforcing the end of the
>> string
>> as the end of the candidate string. If this behaviour cannot be
>> changed, I
>> have to change servlet containers, so I'm eager to find out one way or
>> the
>> other if tomcat can accommodate this.
>
> Tomcat is following the mapping rules in the Servlet spec. It looks like
> Resin has some proprietary extensions to the mapping rules. I'd be
> surprised if you found other containers supporting them.
I can get Tomcat to behave the way you want but configuring web.xml
isn't going to be pretty. I'd strongly recommend moving to an approach
more in line with the Servlet spec rather than the current
container-specific mapping approach.
If you have a JSP in the root of your webapp called snoop.jsp (I took
this from the examples web app) then you'll need to add the following:
<servlet>
<servlet-name>snoop</servlet-name>
<jsp-file>/snoop.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>snoop</servlet-name>
<url-pattern>/snoop.jsp/*</url-pattern>
</servlet-mapping>
As I said, adding that for every single JSP isn't going to be pretty but
it does give you a way to make this work on Tomcat (or any other container).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
Yeah, that's what I thought as well, moments after asking ;)
On Wed, Dec 15, 2010 at 12:03 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> most user agents aren't going to send the anchor to the server because
> it's not relevant.
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/15/2010 11:54 AM, Gary Lawrence Murphy wrote:
> as a total aside that may work for me, in the URL spec cited above, they
> used the notation of #extra-material -- what is the java method that returns
> that extra material?
There is none: the anchor is a client-specific thing that the server
rarely sees. You can try it using something like curl or wget just to
see what the server reports for all those methods you're testing. But
most user agents aren't going to send the anchor to the server because
it's not relevant.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0I9PsACgkQ9CaO5/Lv0PD+1gCeM5EwjQrMNDSuePJSYAQUFmEe
Y74An2eE4AQzjpOrztC2iAcAZg63Oyln
=JGcf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
well, first I'll have to completely digest the spec before I could answer
this and ok, I guess we can throw MacOS in on the blame ;)
as a total aside that may work for me, in the URL spec cited above, they
used the notation of #extra-material -- what is the java method that returns
that extra material?
On Wed, Dec 15, 2010 at 11:48 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
>
> Can you show us a url-pattern that meets the spec that gives you what
> you want? Note that "extensions" are not limited to 3 characters...
> there's no reason to blame MS-DOS for anything (at least not here).
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/15/2010 11:24 AM, Gary Lawrence Murphy wrote:
> http://host:8080/clock/thetimeis.now/utc
>
> what I am hearing in the thread here is that I have introduced a
> CPM/MSDOS convention from the middle 70's that now changes the URI
> from a valid expression into an invalid one.
Then you aren't listening. The presence of a dot is not relevant: it's
just another character. The servlet specification lays out 4 kinds of
pattern matches. You're right, though, that they only allow globbing for
"extension mapping" which might cramp your style.
There is also this note in the 3.0 spec:
"
Versions of this specification prior to 2.5 made use of these mapping
techniques as a suggestion rather than a requirement, allowing servlet
containers to each have their different schemes for mapping client
requests to servlets.
"
So, not only have the authors restricted mapping to a certain set of
patterns, they have made it mandatory how they are processed. If you
read the spec (hint, hint), you'll see that any other behavior is
actually prohibited by the specification. Complaints can be sent to
those responsible.
> That is the issue I struggle to understand and I will re-read that
> spec a few times, but on the first two readings I do not find any
> rule that demands that the active server trigger term of the URI must
> needs be the terminal token *iff* that token contains a
> servlet-mapped CPM/MSDOS extension suffix routing to a script
> interpreter.
Can you show us a url-pattern that meets the spec that gives you what
you want? Note that "extensions" are not limited to 3 characters...
there's no reason to blame MS-DOS for anything (at least not here).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0I8VAACgkQ9CaO5/Lv0PDqGACgw3R4V1q5z7zflUPJ+HfqPZm1
As0An0Z4udYNxKOZeIWbdWD4nsp3QKPM
=M9f2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 15/12/2010 16:24, Gary Lawrence Murphy wrote:
> I mean, clearly I'm wrong, I'm just trying to see *why* I am wrong. To my
> mind, a URI should be completely implementation independent and all valid
> URI token characters should be valid regardless of the underlying
> technology.
Again, go and read the Servlet specification. This is nothing to do with
the validity of the URI and everything to do with the rules that the
Servlet specification defines for mapping URIs to servlets.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
Thanks so much for that snippet; I notice in there no mention of filename
extensions but instead they talk of parsing the string form and give no
special meaning to the dot.
It is a difficult question hard to answer in an email without a great deal
of study, but to be naive and bold about it, what I believe what I am seeing
are the opposite, I am seeing Hierarchical URI which are Relative URI but
are not acceptable to the TC implementation. I found just now they are not
acceptable to winstone either.
Here is an example:
http://host:8080/clock/thetimeisnow/utc
is perfectly valid and semantic in the sense that in the collection of clock
resources there exists "thetimeisnow" resource wherein we can request the
time now in UTC. That seems natural and reasonable. Where it gets fuzzy
given the current implementation is if I introduce a dot character, which in
the article you quote is nowhere said to be anything more than just another
char
http://host:8080/clock/thetimeis.now/utc
the semantic meaning of my dot is maybe dubious ;) but nonetheless, what I
am hearing in the thread here is that I have introduced a CPM/MSDOS
convention from the middle 70's that now changes the URI from a valid
expression into an invalid one. From a strictly information-retrieval point
of view this makes little sense. But it still may have a valid generic
pattern-recognition rule that would let the server-side realize that we are
calling the servlet generated from thetimeis.now.java, which I am nearly
certain would pass the javac and would load and obtain PathInfo as expected.
So now ...
http://host:8080/clock/thetimeis.jsp/utc
becomes 404 not found; it is still a string, still semantically partitioning
the namespace of the clock tools, only, for the server-side
techno-convenience, I wish to employ a pattern recognition of the
(.*\.jsp)(.*) to return the script name in $1 and the PathInfo in $2; to the
Java code within the main body of the JSP, the use of getPathInfo() does as
expected, to the servlet container the pattern extracts the script for
Jasper processing, adding the remaining path as the PathInfo.
but this is considered invalid and undesirable behaviour. That is the issue
I struggle to understand and I will re-read that spec a few times, but on
the first two readings I do not find any rule that demands that the active
server trigger term of the URI must needs be the terminal token *iff* that
token contains a servlet-mapped CPM/MSDOS extension suffix routing to a
script interpreter.
I mean, clearly I'm wrong, I'm just trying to see *why* I am wrong. To my
mind, a URI should be completely implementation independent and all valid
URI token characters should be valid regardless of the underlying
technology.
On Wed, Dec 15, 2010 at 10:23 AM, Martin Gainty <mg...@hotmail.com> wrote:
>
>
> my question is:
> are you seeing implementations (in TC) of a Hierarchical URI which is NOT
> Absolute URI
> or Relative URI
>
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
RE: troubleshooting getPathInfo in jsp files
Posted by Martin Gainty <mg...@hotmail.com>.
Hi Gary
this copied text comes straight from the Doc:
"Java Platform Standard Ed. 7 DRAFT ea-b121
java.net.Class URI
java.lang.Object extended by java.net.URI
All Implemented Interfaces:
Serializable, Comparable<URI>
public final class URI extends Object implements Comparable<URI>, Serializable
Represents a Uniform Resource Identifier (URI) reference.
Aside from some minor deviations noted below, an instance of this class represents a URI reference as defined by
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, amended by
RFC 2732: Format for Literal IPv6 Addresses in URLs. The Literal IPv6 address format also supports scope_ids. The syntax and usage of scope_ids is described here. This class provides constructors for creating URI instances from their components or by parsing their string forms, methods for accessing the various components of an instance, and methods for normalizing, resolving, and relativizing URI instances. Instances of this class are immutable.
URI syntax and components
At the highest level a URI reference (hereinafter simply "URI") in string form has the syntax
[scheme:]scheme-specific-part[#fragment]
where square brackets [...] delineate optional components and the characters : and # stand for themselves.
An absolute URI specifies a scheme;
a URI that is NOT absolute is said to be relative.
URIs are also classified according to whether they are OPAQUE or HIERARCHICAL
An OPAQUE URI is an absolute URI whose scheme-specific part does NOT begin with a slash character ('/').
Opaque URIs are not subject to further parsing. Some examples of opaque URIs are:
mailto:java-net@java.sun.com
news:comp.lang.java
urn:isbn:096139210x
A HIERARCHICAL URI is either an
ABSOLUTE URI (whose scheme-specific part begins with a slash character),
or a RELATIVE URI, that is, a URI that does not specify a scheme.
Some examples of hierarchical URIs are:
http://java.sun.com/j2se/1.3/
docs/guide/collections/designfaq.html#28
../../../demo/jfc/SwingSet2/src/SwingSet2.java
file:///~/calendar
A hierarchical URI is subject to further parsing according to the syntax
[scheme:][//authority][path][?query][#fragment]
here the characters :, /, ?, and # stand for themselves. The scheme-specific part of a hierarchical URI consists of the characters between the scheme and fragment components."
<snip>
"See Also:
RFC 2279: UTF-8, a transformation format of ISO 10646,
RFC 2373: IPv6 Addressing Architecture,
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax,
RFC 2732: Format for Literal IPv6 Addresses in URLs,
URISyntaxException, Serialized Form"
<snip>
"Copyright © 1993, 2010, Oracle Corporation. All rights reserved.
DRAFT ea-b121 "
my question is:
are you seeing implementations (in TC) of a Hierarchical URI which is NOT
Absolute URI
or Relative URI
?
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Wed, 15 Dec 2010 09:48:18 -0500
> Subject: Re: troubleshooting getPathInfo in jsp files
> From: garym@teledyn.com
> To: users@tomcat.apache.org
>
> thanks. I just might :) I can probably find it on Google, but would you
> happen to have the url for the jsr-315 spec? I still find it incredible
> that a 15 year mature unix-originating project in 2010 would still be
> demanding CPM/MSDOS filename extensions and not simply using the standard
> regex library, or that java servers should be constrained not allow a
> hierarchical address space to a universal resource simply because the active
> agent in the URI happened to be a script - the supplier of a resource in a
> REST environment should be invisible to the resource requester imho, however
> it is built under the surface of the request, I think it should just be
> /a/path/on/the/web and not a?subject=path&relation=on&article=the&object=web
> :)
>
> but yeah, I should take that up with them.
>
> On Wed, Dec 15, 2010 at 9:33 AM, Mark Thomas <ma...@apache.org> wrote:
>
> > On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
> > > On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <ma...@apache.org> wrote:
> > >
> > >> Go read the spec. The JSP Servlet is mapped *based on file extension*
> > not
> > >> path.
> > >
> > >
> > > heh, how very quaint. Where did they get this idea? from MSDOS? Oh
> > never
> > > mind. I don't think I want to know, and I suppose I just should be happy
> > > the names aren't constrained to 8 ascii chars.
> >
> > If you want to lobby the Servlet Expert group to modify the mapping
> > rules to support more flexible mapping then the place to send your
> > comments is jsr-315-comments@jcp.org
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
> --
> *Have Blog, Will Travel: blog.teledyn.com*
> *A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 15/12/2010 14:48, Gary Lawrence Murphy wrote:
> thanks. I just might :) I can probably find it on Google, but would you
> happen to have the url for the jsr-315 spec?
You can grab it from http://jcp.org/en/jsr/detail?id=315
Mark
> I still find it incredible
> that a 15 year mature unix-originating project in 2010 would still be
> demanding CPM/MSDOS filename extensions and not simply using the standard
> regex library, or that java servers should be constrained not allow a
> hierarchical address space to a universal resource simply because the active
> agent in the URI happened to be a script - the supplier of a resource in a
> REST environment should be invisible to the resource requester imho, however
> it is built under the surface of the request, I think it should just be
> /a/path/on/the/web and not a?subject=path&relation=on&article=the&object=web
> :)
>
> but yeah, I should take that up with them.
>
> On Wed, Dec 15, 2010 at 9:33 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
>>> On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> Go read the spec. The JSP Servlet is mapped *based on file extension*
>> not
>>>> path.
>>>
>>>
>>> heh, how very quaint. Where did they get this idea? from MSDOS? Oh
>> never
>>> mind. I don't think I want to know, and I suppose I just should be happy
>>> the names aren't constrained to 8 ascii chars.
>>
>> If you want to lobby the Servlet Expert group to modify the mapping
>> rules to support more flexible mapping then the place to send your
>> comments is jsr-315-comments@jcp.org
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
thanks. I just might :) I can probably find it on Google, but would you
happen to have the url for the jsr-315 spec? I still find it incredible
that a 15 year mature unix-originating project in 2010 would still be
demanding CPM/MSDOS filename extensions and not simply using the standard
regex library, or that java servers should be constrained not allow a
hierarchical address space to a universal resource simply because the active
agent in the URI happened to be a script - the supplier of a resource in a
REST environment should be invisible to the resource requester imho, however
it is built under the surface of the request, I think it should just be
/a/path/on/the/web and not a?subject=path&relation=on&article=the&object=web
:)
but yeah, I should take that up with them.
On Wed, Dec 15, 2010 at 9:33 AM, Mark Thomas <ma...@apache.org> wrote:
> On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
> > On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> Go read the spec. The JSP Servlet is mapped *based on file extension*
> not
> >> path.
> >
> >
> > heh, how very quaint. Where did they get this idea? from MSDOS? Oh
> never
> > mind. I don't think I want to know, and I suppose I just should be happy
> > the names aren't constrained to 8 ascii chars.
>
> If you want to lobby the Servlet Expert group to modify the mapping
> rules to support more flexible mapping then the place to send your
> comments is jsr-315-comments@jcp.org
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
> On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> Go read the spec. The JSP Servlet is mapped *based on file extension* not
>> path.
>
>
> heh, how very quaint. Where did they get this idea? from MSDOS? Oh never
> mind. I don't think I want to know, and I suppose I just should be happy
> the names aren't constrained to 8 ascii chars.
If you want to lobby the Servlet Expert group to modify the mapping
rules to support more flexible mapping then the place to send your
comments is jsr-315-comments@jcp.org
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <ma...@apache.org> wrote:
> Go read the spec. The JSP Servlet is mapped *based on file extension* not
> path.
heh, how very quaint. Where did they get this idea? from MSDOS? Oh never
mind. I don't think I want to know, and I suppose I just should be happy
the names aren't constrained to 8 ascii chars.
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 15/12/2010 03:03, Gary Lawrence Murphy wrote:
> On Tue, Dec 14, 2010 at 7:00 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>
>>>> Actually, this makes sense to me: the default mapping for the JSP
>>>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
>>>> not match the url-pattern.
>>>>
>>>> this is the crux of the problem, and the showstopper preventing us from
>>>>
>>> deploying under Tomcat -- all our applications use this convention and, as
>>> I
>>> said, it works in other servlet containers.
>>>
>>> I tried using *.jsp/* and this threw a parsing error,
>>>
>> Hmm. Odd. I'll look into that. It won't work they way you want but I'd like
>> to get to the bottom of the parsing error.
>
>
> Thanks. It's beginning to sound like Tomcat won't be suitable for this app,
> and I can respect the servlet spec, but it does seem odd to me that a JSP is
> not just another servlet that happens to have a funny infix-dot name.
Go read the spec. The JSP Servlet is mapped based on file extension not
path. There is *no* facility within the Servlet spec to map any Servlet
to /**/*.jsp/*
> It should obey the same rules of conduct as any servlet,
It does.
> and if not, then the
> class should prevent the use of functions like getPathInfo() or the
> documents warn against the use of these as the presence of them is giving a
> false impression of jsp/servlet equivalence.
They are entirely equivalent. getPathInfo() is always going to return
null for any servlet (JSP or any other) using extension mapping.
The issue is containers providing Servlet mappings that are not
compliant with the Servlet specification and not warning their users
that is what they are doing. That makes portability pretty much impossible.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
On Tue, Dec 14, 2010 at 7:00 PM, Mark Thomas <ma...@apache.org> wrote:
>
>
>>> Actually, this makes sense to me: the default mapping for the JSP
>>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
>>> not match the url-pattern.
>>>
>>> this is the crux of the problem, and the showstopper preventing us from
>>>
>> deploying under Tomcat -- all our applications use this convention and, as
>> I
>> said, it works in other servlet containers.
>>
>> I tried using *.jsp/* and this threw a parsing error,
>>
> Hmm. Odd. I'll look into that. It won't work they way you want but I'd like
> to get to the bottom of the parsing error.
Thanks. It's beginning to sound like Tomcat won't be suitable for this app,
and I can respect the servlet spec, but it does seem odd to me that a JSP is
not just another servlet that happens to have a funny infix-dot name. It
should obey the same rules of conduct as any servlet, and if not, then the
class should prevent the use of functions like getPathInfo() or the
documents warn against the use of these as the presence of them is giving a
false impression of jsp/servlet equivalence.
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2010 22:54, Gary Lawrence Murphy wrote:
> On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz<
> chris@christopherschultz.net> wrote:
>
>>
>>> however when called with http://localhost:8080/test.jsp/this it fails as
>> a
>>> 404 not found
>>
>> Actually, this makes sense to me: the default mapping for the JSP
>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
>> not match the url-pattern.
>>
>> this is the crux of the problem, and the showstopper preventing us from
> deploying under Tomcat -- all our applications use this convention and, as I
> said, it works in other servlet containers.
>
> I tried using *.jsp/* and this threw a parsing error,
Hmm. Odd. I'll look into that. It won't work they way you want but I'd
like to get to the bottom of the parsing error.
> the webapp refused to run load. *.jsp* ignored all jsp files.
The * characters are probably being treated literally.
> I think other servlet containers
> are using a globbing that is assumed to be the complete expression, which in
> regex would be .*\.jsp, whereas it appears that tomcat is taking it in what
> a regex would phrase as .*\.jsp$, ie it is enforcing the end of the string
> as the end of the candidate string. If this behaviour cannot be changed, I
> have to change servlet containers, so I'm eager to find out one way or the
> other if tomcat can accommodate this.
Tomcat is following the mapping rules in the Servlet spec. It looks like
Resin has some proprietary extensions to the mapping rules. I'd be
surprised if you found other containers supporting them.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: troubleshooting getPathInfo in jsp files
Posted by Gary Lawrence Murphy <ga...@teledyn.com>.
On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
>
> > however when called with http://localhost:8080/test.jsp/this it fails as
> a
> > 404 not found
>
> Actually, this makes sense to me: the default mapping for the JSP
> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
> not match the url-pattern.
>
> this is the crux of the problem, and the showstopper preventing us from
deploying under Tomcat -- all our applications use this convention and, as I
said, it works in other servlet containers.
I tried using *.jsp/* and this threw a parsing error, the webapp refused to
run load. *.jsp* ignored all jsp files. I think other servlet containers
are using a globbing that is assumed to be the complete expression, which in
regex would be .*\.jsp, whereas it appears that tomcat is taking it in what
a regex would phrase as .*\.jsp$, ie it is enforcing the end of the string
as the end of the candidate string. If this behaviour cannot be changed, I
have to change servlet containers, so I'm eager to find out one way or the
other if tomcat can accommodate this.
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
Re: troubleshooting getPathInfo in jsp files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary,
On 12/14/2010 3:49 PM, Gary Lawrence Murphy wrote:
> <path-info><%= request.getPathInfo() %></path-info>
> <path-translated><%= request.getPathTranslated() %></path-translated>
> <query-string><%= request.getQueryString() %></query-string>
Ok.
> when called with http://localhost:8080/test.jsp it reports three nulls
That seems appropriate to me.
> when called with http://localhost:8080/test.jsp?query it reports the
> query-string
With or without the '?'?
> however when called with http://localhost:8080/test.jsp/this it fails as a
> 404 not found
Actually, this makes sense to me: the default mapping for the JSP
servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does
not match the url-pattern.
> by comparison, on a resin-4 server running the same jsp code, same os and
> java version
> when called with http://localhost:8080/test.jsp it reports
>
> <path-info>/test</path-info>
That's strange: pathinfo should be everything /after/ the URL of the
resource that handled the request. I would have expected "" (or null)
for path-info.
> <path-translated>/opt/resin-4/webapps/ROOT/test</path-translated>
path-translated will only return a value if path-info has a value. It's
interesting what Resul has chosen to return for the path-translated
value: the "base name" of the .jsp file on the filesystem.
> and when called with http://localhost:8080/test.jsp/this?query it gives the
> expected
>
> <path-info>/test</path-info>
> <path-translated>/opt/resin-4/webapps/ROOT/test</path-translated>
> <query-string>query</query-string>
This URL actually does have a path-info string (relative to "/test.jsp").
I'm not sure how Tomcat is supposed to divine that /test.jsp/test is, in
fact, a request to /test.jsp in disguise.
> what could I have messed up in the installation? could tomcat6 be
> encountering a conflicting jar file before its expected version? do I need
> to enable some feature to get pathinfo parsing on jsp files?
I think you need to add a url-mapping for the JSP servlet. Maybe
something like '/test.jsp/*'?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0H4yIACgkQ9CaO5/Lv0PCI8ACcCQAkN/2cePUg4hVTclrDY4TS
ydcAoIn/XrIX1egB4ALEM4pgIoVSdNvB
=J69B
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org