/show_bug.cgi?id=31567
--- Additional Comments From [EMAIL PROTECTED] 2004-12-22 22:35 ---
One additional comment it almost seems that Tomcat is not honoring the
Content-Length header. If I read this correctly, you use the first line of the
body original request as the first line of the second
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=21146.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
--- Additional Comments From [EMAIL PROTECTED] 2004-12-22 23:12 ---
(In reply to comment #8)
Can you please be more specific? What is wrong with the requests from the
client? I can't tell if you have issue with data on the original or second
request.
The orignal request. See RFC 2616
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=32708
Summary: NullPointer for every request
Product: Tomcat 5
Version: 5.5.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: blocker
Priority: P1
Component: Unknown
AssignedTo
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=32708.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi,
Can someone with access please run the Servlet and JSP TCKs against
Tomcat 5.5.5? I'd like to have a stability vote starting Thursday.
Thanks,
Yoav Shapira http://www.yoavshapira.com
This e-mail, including any attachments, is a confidential business
communication, and may contain
Shapira, Yoav wrote:
Hi,
Can someone with access please run the Servlet and JSP TCKs against
Tomcat 5.5.5? I'd like to have a stability vote starting Thursday.
I think you're going to hate me, but *32505* is a serious issue (which I
misundurstood at first), so it needs at least one hotfix :(
Hi,
Can someone with access please run the Servlet and JSP TCKs against
Tomcat 5.5.5? I'd like to have a stability vote starting Thursday.
I think you're going to hate me, but *32505* is a serious issue (which
I
misundurstood at first), so it needs at least one hotfix :(
I don't hate you or
Shapira, Yoav wrote:
I don't hate you or anyone else ;) I agree it's a fairly serious issue,
and it probably means 5.5.5 stays beta. But that's not that big a
deal...
It copies the contents of the drive where Tomcat is installed to a
folder named conf/Catalina/localhost/context_path_here. It's
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=31567.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=32275
Summary: Problem with compilation and jsp:useBean id=toto
scope=request class=java.lang.Integer/
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
:
jsp:useBean id=toto scope=request class=java.lang.Integer/jsp:useBean
html
body
OK
/body
/html
Please test it !
(In reply to comment #1)
I think you need a space before the /, or a separate /jsp:useBean closing
element. This is a difference between JSP Spec 1.1 and 2.0 (which Tomcat 5
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=32275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi,
If using AJP connector to redirect requests from frontend webserver
to the backend tomcat engines, is it possible to share the same Http
servlet request object? I am setting some attributes in the request in
frontend webserver, but those attributes are not available in tomcat.
I am using
First part of the secure mail is available.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/show_bug.cgi?id=31741
servlet request forward to jsp with jsp:include tag can cause extra request to be
submitted
--- Additional Comments From [EMAIL PROTECTED] 2004-10-19 04:13 ---
This does not seem to be an issue in Tomcat 5.0.28. The output I got is below
and seems to be correct
/show_bug.cgi?id=31741
servlet request forward to jsp with jsp:include tag can cause extra request to be
submitted
Summary: servlet request forward to jsp with jsp:include tag
can cause extra request to be submitted
Product: Tomcat 4
Version: 4.1.30
/show_bug.cgi?id=31643
form type not int request parameters
Summary: form type not int request parameters
Product: Tomcat 5
Version: 5.0.28
Platform: All
OS/Version: All
Status: NEW
Severity: Critical
Priority: Other
/show_bug.cgi?id=31643
form type not int request parameters
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/show_bug.cgi?id=31643
form type not int request parameters
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
/show_bug.cgi?id=31643
form type not int request parameters
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
/show_bug.cgi?id=31655
org.apache.catalina.cluster.session.DeltaManager requestCompleted, SEVERE: Unable to
serialize delta request, java.io.NotSerializableException:
Summary: org.apache.catalina.cluster.session.DeltaManager
requestCompleted, SEVERE: Unable to serialize
/show_bug.cgi?id=31655
org.apache.catalina.cluster.session.DeltaManager requestCompleted, SEVERE: Unable to
serialize delta request, java.io.NotSerializableException:
[EMAIL PROTECTED] changed:
What|Removed |Added
/show_bug.cgi?id=31655
org.apache.catalina.cluster.session.DeltaManager requestCompleted, SEVERE: Unable to
serialize delta request, java.io.NotSerializableException:
[EMAIL PROTECTED] changed:
What|Removed |Added
The original user was having trouble figuring out which class(es) in
their application were causing NotSerializableExceptions.
And, in fact, I was starting to think about the Serializable issue for
a client...
And then Tim wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-10-11
Don't bother. Here is it for the archives.
package x;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import javax.servlet.http.HttpSessionBindingEvent;
import javax.servlet.http.HttpSessionAttributeListener;
import
/show_bug.cgi?id=31567
505 request error from .NET client
--- Additional Comments From [EMAIL PROTECTED] 2004-10-07 10:18 ---
I found out that the problem is with first request from .NET soap client.
After this first request following ones are okay because they don't contain
first part which
The Message has been received, you should get a response shortly
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/show_bug.cgi?id=31567
505 request error from .NET client
Summary: 505 request error from .NET client
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Blocker
Priority: Other
/show_bug.cgi?id=31567
505 request error from .NET client
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
Summary: Request parameters are not always passed to
HttpServlet.service
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: All
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 10:04 ---
I am very sure the request parameters are sent correctly, because the issue
occurs with several different browsers, including IE
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 10:20 ---
Exactly the same sequence of events can lead to either the parameters being
present, or not.
Can you describe the sequence and provide
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 10:21 ---
Also describe the connector configuration you are using
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 10:47 ---
Unfortunately I cannot give a test WAR, because that would include business
information. We are using Cocoon Forms to display a simple
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 11:04 ---
What you mention would hint at a race condition, but the threading (or lack of)
of the parameter parsing code is really obvious. Note
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 11:24 ---
As I said before, I read all request parameters at the entry of the service
method. This is before any cocoon code is run. The incomming
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 11:36 ---
Yes, of course, all the container objects provided by Tomcat are recycled. The
exception is, of course, when using a security manager
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 14:39 ---
Hmm,
I have spend a small time to simulate missing post parameter situation,
but I can't find an error. I test with JMeter and a small
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 14:40 ---
Created an attachment (id=12931)
PostParam App
-
To unsubscribe, e
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 14:41 ---
Created an attachment (id=12932)
Simple Catalina Base Config
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 15:24 ---
Thanks a lot Peter. That's a good test to work on to see if this issue is real
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 15:56 ---
I've tried running Tomcat with the security manager enabled (with a grant all
in the policy file). This brought up some worrying facts. I
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 16:43 ---
If your second thread is probably synced, then it's supposed to work. It's still
not allowed in the servlet specification (it mandates one
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 16:44 ---
The first sentence should read: If your second thread is properly synced, then
it's supposed to work. probably doesn't do it in this case
/show_bug.cgi?id=31523
Request parameters are not always passed to HttpServlet.service
--- Additional Comments From [EMAIL PROTECTED] 2004-10-04 17:18 ---
I'm confident that the thread is properly synced, however I'm afraid Cocoon
uses the current thread as a way to determine the context
/show_bug.cgi?id=30949
After Failed Include, Request and Response not Unwrapped
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=21146
Request variables from Apache are not available in Tomcat
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED
/show_bug.cgi?id=30949
After Failed Include, Request and Response not Unwrapped
--- Additional Comments From [EMAIL PROTECTED] 2004-09-08 05:26 ---
That seems like a reasonable solution.
-
To unsubscribe, e-mail: [EMAIL
/show_bug.cgi?id=30949
After Failed Include, Request and Response not Unwrapped
Summary: After Failed Include, Request and Response not Unwrapped
Product: Tomcat 5
Version: 5.0.27
Platform: All
OS/Version: All
Status: NEW
Severity
/show_bug.cgi?id=30949
After Failed Include, Request and Response not Unwrapped
--- Additional Comments From [EMAIL PROTECTED] 2004-08-31 00:29 ---
Ok. Since I don't want to use a finally for that (as the exception is rethrown
in invoke), I think moving the unwrapping in the invoke method
/show_bug.cgi?id=30859
index.jsp request not loading
Summary: index.jsp request not loading
Product: Tomcat 4
Version: 4.1.27
Platform: Sun
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component
/show_bug.cgi?id=30859
index.jsp request not loading
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Hi all,
Can it really be, that the newer TC 5.0.25 and 5.0.27 breaks the formula
-
requestURI = contextPath + servletPath + pathInfo
(Servlet 2.4 specification, page 38)
?
My TC sets some really weird request-info like .e.g on a request upon
the URL http://localhost:8080/Oginok_Prime
: Mismatch request-URI vs. servlet-path in TC 5.0.XX
Hi all,
Can it really be, that the newer TC 5.0.25 and 5.0.27 breaks the formula
-
requestURI = contextPath + servletPath + pathInfo
(Servlet 2.4 specification, page 38)
?
My TC sets some really weird request-info like .e.g on a request
Hi Webmasters of that site,
Some errors re: Setup on Windows/IIS/JK2 (2.0.4) took me a week to find out.
Please correct!
See resolved Bug [Bug 30383]
Problem was that the Website was outdated. The info on
http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk2/
a filter and a request
wrapper. The filter is mapped to the protected directory, and any
request that passes through gets checked for a token. If the token is
not found, it dumps the contents of the request into a session object,
and forwards to the login servlet. After the login is approved
was sent in the request
body, such as occurs with an HTTP POST request,
then reading the body directly via getInputStream()
or getReader() can interfere with the execution
of this method.
[...]
And the Servlet 2.3 Spec. SRV 4.1.1 also fails to nail it down.
However, the current
:
[...]
If the parameter data was sent in the requestbody, such as
occurs with an HTTP POST request,then reading the body directly
via getInputStream()or getReader() can interfere with the
executionof this method. [...]
And the Servlet 2.3 Spec. SRV 4.1.1 also fails to nail it down
Remy Maucherat wrote:
This bug report was submitted many times, and resolved as INVALID.
Then I'm sorry I didn't find it before posting. I did not mean to spam the dev.
list.
Maybe you could use a valve or a filter, it would have been faster than
writing this email ;)
No Sorry. Writing the email
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
It hurts my eyes to see the Socket in the o.a.c.connector.Request :). Now
that Remy has gotten rid of the o.a.catalina.Request, there isn't any reason
for it to be there. However, I thought I should give people a chance to
veto removing it before I put the work in (I'm lazy that way :).
This
that way :).
It's really not used anymore ? I didn't know (my Eclipse seems to hint
that nothing uses it indeed). It would be great to get rid of it.
I have a few uncommitted updates (I had to get the current code to build
on my new JDK), so I just committed my modified Request class.
Rémy
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
--- Additional Comments From [EMAIL PROTECTED] 2004-07-23 08:55 ---
*** Bug 30287 has been marked as a duplicate of this bug
Bill Barker wrote:
It hurts my eyes to see the Socket in the o.a.c.connector.Request :). Now
that Remy has gotten rid of the o.a.catalina.Request, there isn't any reason
for it to be there. However, I thought I should give people a chance to
veto removing it before I put the work in (I'm lazy
the Request
Bill Barker wrote:
It hurts my eyes to see the Socket in the o.a.c.connector.Request :).
Now
that Remy has gotten rid of the o.a.catalina.Request, there isn't any
reason
for it to be there. However, I thought I should give people a chance
to
veto removing it before I put the work in (I'm
/show_bug.cgi?id=28944
Request with HTTP 1.0 then display it's source code
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=23231
Bad Request, page failed to be served, due to jave length overflow
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
--- Additional Comments From [EMAIL PROTECTED] 2004-07-23 05:35 ---
You need to look at the toAbsolute method of the
org.apache.coyote.tomcat5.CoyoteResponse class. That is where you would
normalize the URL
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
Summary: Unexpected bug when use phone browser request redirect
page
Product: Tomcat 5
Version: 5.0.25
Platform: Other
OS/Version: Other
/show_bug.cgi?id=30206
Unexpected bug when use phone browser request redirect page
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=27315
Coyote java.util.ConcurrentModificationException removing request processor
[EMAIL PROTECTED] changed:
What|Removed |Added
CC
/show_bug.cgi?id=28366
The example for request filters is wrong
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Hi Peter,
I suppose there is some confusion.
I believe you got it right, that the Media Server is the one which
will interpret the VXML pages and not the Application server.
But these VXML pages wont have any SPEECH in it. Instead they have
specific TAGS related to speech
for e.g a snipplet from
I think I get a better picture. I was guessing it might be a Text To
Speech application. I use to work on a wireless platform and one of
the features we explored was converting emails to .wav files and send
them to the user.
in my experience, the wav file would have been sent to a WAP phone
with
by the way, there is a standard Text To Speech API and reference
implementing for Java. I know Leap Wireless uses that with an EJB
container for some internal applications. I can't go into details, but
I do know of cases where it scales just fine.
peter
On Fri, 9 Jul 2004 11:19:23 -0700,
We implement a Messaging PLatform for Voice Applications.
Our current platform has 2 Major Components as shown below:-
Media Server --- MML/TCP-IP --- Application Server.
We want to move to a new architecture for our Application Server where
the interaction between App Server and Media Server is
from where I am sitting, sounds like the project doesn't have enough
information to make a good decision. Why move from MML/TCP to
VXML/HTTP?
if you read my performance article on the resources page, XML is very
CPU and memory intensive. Even with XStream java-xml binding library,
handling
201 - 300 of 887 matches
Mail list logo
