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
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
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
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
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
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: ga...@teledyn.com
To: users@tomcat.apache.org
thanks. I just might :) I can probably find it on Google, but would you
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,
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
-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
-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
On Wed, Dec 15, 2010 at 11:29 AM, Christopher Schultz
ch...@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
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,
-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
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
-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
-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:
Yeah, that's what I thought as well, moments after asking ;)
On Wed, Dec 15, 2010 at 12:03 PM, Christopher Schultz
ch...@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
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
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
-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
On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz
ch...@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
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.
On 14/12/2010 22:54, Gary Lawrence Murphy wrote:
On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz
ch...@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
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
ch...@christopherschultz.net wrote:
however when called with http://localhost:8080/test.jsp/this it
fails as
a
404 not found
Actually, this makes
From: Mark Thomas [mailto:ma...@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
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
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
27 matches
Mail list logo
