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
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
-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:
-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
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 mate
-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 va
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, Christophe
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.
-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 webap
-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 f
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
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
t 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: ga...@teledyn.com
> To: users@tomc
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-orig
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 li
On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
> On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas 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
On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas 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
On 15/12/2010 03:03, Gary Lawrence Murphy wrote:
> On Tue, Dec 14, 2010 at 7:00 PM, Mark Thomas 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.
t
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 si
On Tue, Dec 14, 2010 at 7:00 PM, Mark Thomas 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 preven
> 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
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 make
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 t
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 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 doe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary,
On 12/14/2010 3:49 PM, Gary Lawrence Murphy wrote:
> <%= request.getPathInfo() %>
> <%= request.getPathTranslated() %>
> <%= request.getQueryString() %>
Ok.
> when called with http://localhost:8080/test.jsp it reports three nulls
That seems a
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 langua
27 matches
Mail list logo
