Re: form parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 3/16/2009 8:30 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> André,
>>
>> (Man, I need to get a keyboard mapping for "é". This copy-and-paste
>> thing is such a drag...)
>
> Well, you can use Andre, I don't mind and I'm used to all kinds of
> spellings. Or you can use André , the special form for people who
> haven't dominated their MIME charsets yet ;-)
Or for those whose charsets are mismatched (ha!).
> Well yes [size does matter], in a number of situations. Think for example
> about
> webserver logs, where these things then appear as a very very long
> string, percent-escaped to boot.
Eh, so you'd get your data enlarged to some extent. Again, the exact
Content-Type is not really relevant, since the problem is the same in
either case. The only difference is whether the servlet spec says it'll
expose that data to you through getParameter and friends.
> There is no "Content-Type of the request". Try it : make a GET request
> (or a POST with application/x-www-form-urlencoded), and look for a
> request Content-Type with a charset.
> For a GET there is no content-type (because there is no request body).
> For a POST there is a content-type, but without charset.
That's the browser's fault, not the spec's. A request /does/ have a
Content-Type, whether implied or explicit. The problem is when the
client encodes the POST body with a content type other than the default,
and refuses to advertise it (which is the root of the problem).
> The gist of it is : for an "enctype=application/x-www-form-urlencoded"
> (whether explicit or by default), the URL is encoded in whatever charset
> the browser feels like encoding it. Which MAY depend on what the browser
> thinks the charset of the page is, which contains the ; or the
> "accept-charset" attribute of the form tag, or the user's preferences.
> But whatever the browser is in the end sending you, it does not say.
Agreed. My interpretation of the spec is that most clients are
non-compliant. When I use the filter attached to one of my other posts,
I most certainly *do* get POST content in UTF-8 encoding, yet the
browser fails to inform me with a Content-Type header.
If I POST "gregör", the POST body (again, without charset indicated in
the content-type) is this:
query=greg%C3%B6r
Note that if ISO-8859-1 had been used, the string should have been:
query=greg%F6r
So, the browser is patently violating the spec: it is using UTF-8 to
encode the request body yet not advertising it (RFC 2616 section 3.7.1).
Technically speaking, there is /no/ default charset unless the primary
media type is "text". My interpretation of the HTTP spec is that both
multipart/form-data /and/ application/x-www-urlencoded /require/ a
charset to be declared, even if the charset is "raw" or something like
that (for binary files, for instance).
> But $filename is also ("magically") a /filehandle/, as
> soon as you treat it like one and read from it. That filehandle is
> connected to a temporary file in which the module has already read and
> saved the file part as uploaded by the browser.
Yeah, this is commons-upload for Java peeps:
http://commons.apache.org/fileupload/
> So, no, it is not a 10 MB string in memory.
> If the programmer closes that filehandle, the file is automatically
> deleted from whatever temporary space it occupied.
> Keep reading, and don't miss the
> $type = uploadInfo($filename)->{'Content-Type'};
Note that the encoding for a file upload should always be
application/octet-stream. Otherwise, you'll get things like newline
conversions such that md5(source) != md5(target). The Content-Type
should be the mime-type for the file.
> In our applications, we are the ones sending the forms to the client,
> and we know the type of encoding to expect from them.
If that's the case, why not simply force Java to always use a certain
encoding? That's essentially what you're doing in Perl, whether you know
it or not.
> Just to keep people honest, we also always include a hidden parameter
> containing a UTF-8 string with non-US-ASCII characters, and check the
> returned length (in bytes and in characters) when the form is submitted.
> If there is a discrepancy between them, we know that the form
> parameter's encoding is not what it should be, and reject the post.
That can easily be done in Java, too.
> It doesn't [currently fail] because so far I am not processing form posts in
> Java servlets.
> This discussion started because I need to do it now, in relation with
> the same external application for which I posted some questions about
> BufferedInputStreamReader's and such a while ago.
Yup, I remember.
> Now I have the problem in reverse : the application gets input from an
> iso-8859-2 form, in iso-8859-2, but is interpreting it as iso-8859-1.
> I was just wondering if by changing the form to use the
> multipart/form-data encoding type, the se
Re: form parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 3/16/2009 6:59 PM, André Warnier wrote: > The real fix would be HTTP 1.2, specifying once and for all that the > default encoding for query parameters is Unicode/UTF-8 Yes. Given that HTTP/1.1 clients should include Content-Type yet don't, how long do you think adoption of HTTP/1.2 will take? ;) > I fail to understand why the powers-that-be did not reach that > conclusion several years ago already. Because it was the swingin' '90s, baby! Honestly, I'm very surprised that CERN, being located in a country with so many languages, was content to stick with ISO-8859-1. > This being an English-speaking list, I also assume that whatever time is > seen here being spent discussing it, is only a biased view of the > overall situation. Yup. I can tell you that in the US, non-ASCII characters are usually an afterthought. I've seen many sites that don't accept (or don't properly handle) anything but [a-zA-Z0-9]. :( > Since the Apache CON Europe is upcoming, and since I'm planning to > attend, I wonder if a bit of stirring up matters there would help. Go to MozillaCON or OperaCON or something. Drop a huge metal W3C on Microsoft's front lawn (http://home.snafu.de/tilman/mozilla/stomps.html). /That's/ where you need to complain; it's the browsers that are very conservative, which makes sense given that it will take a while for everyone on the planet to upgrade to HTTP/1.2-compatible server software. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm++X8ACgkQ9CaO5/Lv0PC3hACeNdLiXAdi9hQQ/ZNtToispZ9T G8AAn1E2trLhbvIS+g1ULmlDcmoNNa4B =UuI/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
(Man, I need to get a keyboard mapping for "é". This copy-and-paste
thing is such a drag...)
Well, you can use Andre, I don't mind and I'm used to all kinds of
spellings. Or you can use André , the special form for people who
haven't dominated their MIME charsets yet ;-)
Plus, the fact that the same applications often do offer the possibility
to submit very large non-USASCII text fields.
The size of the fields shouldn't be an issue, unless you want to stream
the data yourself.
Well yes it does, in a number of situations. Think for example about
webserver logs, where these things then appear as a very very long
string, percent-escaped to boot.
[...]
I took an early aversion to application/x-www-form-urlencoded,
...
No, it will work and its better that GET because it's encoded using the
Content-Type of the request, rather than God-knows-what given the
browser settings.
There is no "Content-Type of the request". Try it : make a GET request
(or a POST with application/x-www-form-urlencoded), and look for a
request Content-Type with a charset.
For a GET there is no content-type (because there is no request body).
For a POST there is a content-type, but without charset.
The gist of it is : for an "enctype=application/x-www-form-urlencoded"
(whether explicit or by default), the URL is encoded in whatever charset
the browser feels like encoding it. Which MAY depend on what the browser
thinks the charset of the page is, which contains the ; or the
"accept-charset" attribute of the form tag, or the user's preferences.
But whatever the browser is in the end sending you, it does not say.
The only differences I see between multipart/form-data and
application/x-www-urlencoded encoding types are the W3C's choice for the
default and the servlet spec's requirement (both x-www) and the W3C's
statement about .
http://www.w3.org/TR/html401/interact/forms.html#adef-enctype
says, quote :
The value "multipart/form-data" should be used in combination with the
INPUT element, type="file".
unquote
Note that it does /not/ say that it should /not/ be used with something
else. What it says is that if you upload a file, you SHOULD use the
multipart/form-data content encoding, because of course it does not make
any sense to send the whole file as a "&file=...(10MB)"
application/x-www-urlencoded encoded string, percent-escaped to boot.
It is also a big disappointment to see (you are right, I checked) that
the Servlet Spec does not foresee a simple method to get the parameter
values if they are posted via the multipart/form-data encoding method.
This is because the implication of using multipart/form-data is that the
app code will read its own stream. If you upload a 100MB file, do you
want that whole thing in memory as a (useless) String value?
Let me introduce you to the hidden beauties of Perl, and of the CGI.pm
module. Read this :
http://cpan.uwinnipeg.ca/htdocs/CGI.pm/CGI.html#CREATING_A_FILE_UPLOAD_FIELD
You can skip the first part, which is about creating a file upload field
when composing a form. The second part, starting at this shaded box :
$filename = param('uploaded_file');
explains what happens at the server side when reading such a request
parameter. Essentially you do :
$filename = param('name'); (Java : f = req.getParameter("name");)
In Perl, $filename is now a string containing the uploaded /filename/,
as explained. But $filename is also ("magically") a /filehandle/, as
soon as you treat it like one and read from it. That filehandle is
connected to a temporary file in which the module has already read and
saved the file part as uploaded by the browser.
So, no, it is not a 10 MB string in memory.
If the programmer closes that filehandle, the file is automatically
deleted from whatever temporary space it occupied.
Keep reading, and don't miss the
$type = uploadInfo($filename)->{'Content-Type'};
So what is Perl's default charset? I find it hard to believe that Perl
just magically works with the same missing charset information.
"magically" is a word full of connotations, in perl.
(Like "any sufficiently advanced technology..")
But you are right, even perl cannot magically determine the charset if
the browser does not supply it.
In our applications, we are the ones sending the forms to the client,
and we know the type of encoding to expect from them.
Just to keep people honest, we also always include a hidden parameter
containing a UTF-8 string with non-US-ASCII characters, and check the
returned length (in bytes and in characters) when the form is submitted.
If there is a discrepancy between them, we know that the form
parameter's encoding is not what it should be, and reject the post.
Read the body myself and parsing it ? in 2009 ?
Yes, read it yourself. You told the servlet container that you wanted to
do it. I'm actually surprised that getParamete
Re: mysql/J connector + tomcat and it configuration
Hello Tomas, Start with http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html What Tomcat/Java versions are you using? If you are just starting, you should use Tomcat 6.0.18 and Java 1.5+ --Ken On Mar 16, 2009, at 8:15 PM, Tomas Rodriguez wrote: Hi everybody. I'm new in this list and new work with tomcat, by this reason I have a doubt with mysql/j connector and Tomcat. my doubt is. what should I do for configurate mysql/j and tomcat work together? somebody can help me with this big problem for me?. Thanks so much. have a good day - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mysql/J connector + tomcat and it configuration
Hi everybody. I'm new in this list and new work with tomcat, by this reason I have a doubt with mysql/j connector and Tomcat. my doubt is. what should I do for configurate mysql/j and tomcat work together? somebody can help me with this big problem for me?. Thanks so much. have a good day - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 3/16/2009 11:53 AM, André Warnier wrote: As far as I understand the HTTP specs, something like request.setCharacterEncoding() should only be used (with a charset different from iso-8859-1) when a request comes in without a charset specification (which also indicates a broken client). This is my interpretation of the spec. This is my implementation of a fix: [...] Thanks. I already found that one, and it is a fix. But it's a miserable one in the wider context of a multilingual WWW. The real fix would be HTTP 1.2, specifying once and for all that the default encoding for query parameters is Unicode/UTF-8 + percent-encoding when needed (as far as I can think, only when appended to the URL). Since Unicode/UTF-8 can represent all characters known to man and more, I fail to understand why the powers-that-be did not reach that conclusion several years ago already. As you yourself mention in another post, these issues occupy a significant portion of the bandwidth of anything to do with the WWW, and probably cause the annual loss of thousands of work hours. This being an English-speaking list, I also assume that whatever time is seen here being spent discussing it, is only a biased view of the overall situation. Since the Apache CON Europe is upcoming, and since I'm planning to attend, I wonder if a bit of stirring up matters there would help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, (Man, I need to get a keyboard mapping for "é". This copy-and-paste thing is such a drag...) On 3/16/2009 6:09 PM, André Warnier wrote: > Christopher Schultz wrote: >> >> Quick question: multipart/form-data is typically used for file upload... >> why not use application/x-www-form-urlencoded instead? I realize the >> problem is that certain browsers do not send the proper charset in the >> Content-Type, but I'd like to understand your affinity for >> multipart/form-data. >> > This : > http://www.w3.org/TR/html401/interact/forms.html#h-17.13 > See the note in green at the end of 17.13.1 Form submission method. The W3C docs for 'enctype' mentions that multipart/form-data should be used with http://www.w3.org/TR/html401/interact/forms.html#adef-enctype > Plus, the fact that our applications (area : document management) very > often do offer the possibility to upload a file from within forms. Gotcha. > Plus, the fact that the same applications often do offer the possibility > to submit very large non-USASCII text fields. The size of the fields shouldn't be an issue, unless you want to stream the data yourself. But you mentioned using getParameter, so you're /not/ streaming the data yourself. > Plus, the fact that most of my activity relates to users who are not > mainly English-speaking and do not use a US keyboard to fill-in web forms. > Plus, the fact that having seen HTTP/HTML being born, I remember the > time when URL's were typically limited in size, in a manner inconsistent > between platforms. That might still be the case. It is :) > Somewhat abusively I admit, I took an early aversion to > application/x-www-form-urlencoded, as synonymous to GET, to non-capable > of anything but US-ASCII (ok, iso-8859-1 at a stretch, but see the above > green note) and to "nobody agrees as to the proper percent encoding and > at what moment it should take place or not". No, it will work and its better that GET because it's encoded using the Content-Type of the request, rather than God-knows-what given the browser settings. > The multipart/form-data encoding does not have all of these > connotations, and should be a foolproof way for a browser to send data > to a server without any size limit or charset ambiguity. The only differences I see between multipart/form-data and application/x-www-urlencoded encoding types are the W3C's choice for the default and the servlet spec's requirement (both x-www) and the W3C's statement about . > It is also a big disappointment to see (you are right, I checked) that > the Servlet Spec does not foresee a simple method to get the parameter > values if they are posted via the multipart/form-data encoding method. This is because the implication of using multipart/form-data is that the app code will read its own stream. If you upload a 100MB file, do you want that whole thing in memory as a (useless) String value? > That is probably because for 10 years or so, I have been using this > under Apache and perl without any problems at all : I just use the > equivalent of GetParameter() there, without having to worry a jot about > the request encoding; and why should I have to ? So what is Perl's default charset? I find it hard to believe that Perl just magically works with the same missing charset information. > Read the body myself and parsing it ? in 2009 ? Yes, read it yourself. You told the servlet container that you wanted to do it. I'm actually surprised that getParameter() gets you any of your POST form data when using multipart/form-data. You never did say how it failed: do you get a bad String (misinterpreted) or do you get null because getParameter didn't parse the request? > Now come on, I am sure that there must exist some standard Java library > usable in a servlet context, and which does that, no ? You can use commons-upload, which was intended to be used with file uploads, and will probably read "simple" multipart/form-data fields as well. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+2qcACgkQ9CaO5/Lv0PASywCcDJ1ZonoXKXuHp7SyUa3M6qeD /ogAnii33RObyJ6HJvLkLEyBf+F8jQKZ =3ArQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Coding your JDBC to avoid connection leaks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, We've had enough people ask about JDBC connection leaks over the years that I thought I'd write a blog entry about how to properly write JDBC code. While it's not Tomcat-specific, I figured I'd post it here in case anyone wants to refer to it in the future. Comments are certainly welcome. http://blog.christopherschultz.net/?p=68 Thanks, and enjoy. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+10kACgkQ9CaO5/Lv0PCxIQCgkTe89UdLucwH/hMnV2E16CP6 s2wAnAg8a5lAd91x6BnwUDqLE18W1wlc =Bnft -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MemoryLeak Problem with ThreadWithAttributes
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: MemoryLeak Problem with ThreadWithAttributes > > Back in 2003, Remy makes a claim that almost sounds like thData is > deprecated and unused. I'm interested in what you find. It does appear to be dead code in 6.0.18. Even though it's in the same modules in 6.0.18 as in 5.5.15, the ThreadWithAttributes class itself doesn't seem to be used anymore with either the standard or the NIO connector. It is used with the AJP one, but it looks like the HTTP connectors have been updated to take advantage of mechanisms available in java.util.concurrent instead. - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 on Windows 2003 - 64 bit
Tuan Quan wrote: Hi all, I've installed Java JDK 1.6.0_04 - 64 Bit version. Then install Tomcat 6.0.16, but when starting Tomcat I got the error below in Tomcat's log file. The JRE 1.6.0_04 is there and installed. [2009-03-16 16:00:07] [986 prunsrv.c] [error] Failed creating java C:\Program Files\Java\jre6\bin\server\jvm.dll [2009-03-16 16:00:07] [1260 prunsrv.c] [error] ServiceStart returned 1 May that be (again) because the prunsrv (aka tomcat6.exe) that is standard with the msi installer version of Tomcat is the 32-bit one ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6 on Windows 2003 - 64 bit
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] > Subject: RE: Tomcat 6 on Windows 2003 - 64 bit > > Those are available for download here: > http://svn.apache.org/repos/asf/tomcat/connectors/trunk/procrun/bin/amd64/ > > Rename them, replacing the '5' with a '6', then try starting > the service again. Or use the Tomcat 6 versions; no renaming needed (otherwise identical to what's in 5.5). http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/res/procrun/amd64/ - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Christopher Schultz wrote: Quick question: multipart/form-data is typically used for file upload... why not use application/x-www-form-urlencoded instead? I realize the problem is that certain browsers do not send the proper charset in the Content-Type, but I'd like to understand your affinity for multipart/form-data. This : http://www.w3.org/TR/html401/interact/forms.html#h-17.13 See the note in green at the end of 17.13.1 Form submission method. Plus, the fact that our applications (area : document management) very often do offer the possibility to upload a file from within forms. Plus, the fact that the same applications often do offer the possibility to submit very large non-USASCII text fields. Plus, the fact that most of my activity relates to users who are not mainly English-speaking and do not use a US keyboard to fill-in web forms. Plus, the fact that having seen HTTP/HTML being born, I remember the time when URL's were typically limited in size, in a manner inconsistent between platforms. That might still be the case. Somewhat abusively I admit, I took an early aversion to application/x-www-form-urlencoded, as synonymous to GET, to non-capable of anything but US-ASCII (ok, iso-8859-1 at a stretch, but see the above green note) and to "nobody agrees as to the proper percent encoding and at what moment it should take place or not". The multipart/form-data encoding does not have all of these connotations, and should be a foolproof way for a browser to send data to a server without any size limit or charset ambiguity. It is therefore a big surprise and big disappointment to see that browser developers do not take advantage of this, for some reason I have trouble to fathom (because it's there, it is well-defined, it is easy to do, and it would save a lot of problems). It is also a big disappointment to see (you are right, I checked) that the Servlet Spec does not foresee a simple method to get the parameter values if they are posted via the multipart/form-data encoding method. That is probably because for 10 years or so, I have been using this under Apache and perl without any problems at all : I just use the equivalent of GetParameter() there, without having to worry a jot about the request encoding; and why should I have to ? Read the body myself and parsing it ? in 2009 ? Now come on, I am sure that there must exist some standard Java library usable in a servlet context, and which does that, no ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6 on Windows 2003 - 64 bit
> From: Tuan Quan [mailto:tuan_q...@yahoo.com] > Subject: Tomcat 6 on Windows 2003 - 64 bit > > I've installed Java JDK 1.6.0_04 - 64 Bit version. > Then install Tomcat 6.0.16, You need to replace the tomcat6.exe and tomcat6w.exe programs in Tomcat's bin directory with the 64-bit versions. Those are available for download here: http://svn.apache.org/repos/asf/tomcat/connectors/trunk/procrun/bin/amd64/ Rename them, replacing the '5' with a '6', then try starting the service again. - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 on Windows 2003 - 64 bit
Hi all, I've installed Java JDK 1.6.0_04 - 64 Bit version. Then install Tomcat 6.0.16, but when starting Tomcat I got the error below in Tomcat's log file. The JRE 1.6.0_04 is there and installed. [2009-03-16 16:00:07] [986 prunsrv.c] [error] Failed creating java C:\Program Files\Java\jre6\bin\server\jvm.dll [2009-03-16 16:00:07] [1260 prunsrv.c] [error] ServiceStart returned 1 thank Tuan
Re: MemoryLeak Problem with ThreadWithAttributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 3/16/2009 4:51 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: MemoryLeak Problem with ThreadWithAttributes >> >> The current version of ThreadWithAttributes doesn't have any >> methods with locals of type Object[] > > These aren't local variables, these are references local to the > object. There are at least two such Object arrays in TWA: notes, and > thData. The notes array is fixed at 16 entries, so it must be > thData. Aah... I was having trouble interpreting the screenshot. Some of the objects had "names" so I assumed "local" meant that it was a local (to the method) whose name was lost at compile time. > The thData array is set by a call to setThreadData(), and can only > be cleared by said call with a null parameter. But there are no such calls, > so once it's set, the array is kept. > > (All of the above is true from 5.5.15 through 6.0.18.) > > I'm still chasing what the array is used for. An interesting and short read: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=80777 Back in 2003, Remy makes a claim that almost sounds like thData is deprecated and unused. I'm interested in what you find. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+yigACgkQ9CaO5/Lv0PDpOgCeM9mLWNL0HCDWBFqOlHDk6yUz AD8AnRzEAbHONWOD5rfUnsNHOXDTshGd =Kyf9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Garbage collection problem and Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian, On 3/12/2009 2:03 PM, Ian Long wrote: > I'm using hibernate wrapped via the spring framework, so all connections > *should* be returned to the pool under all conditions. Do you ever obtain a java.sql.Connection object in your own code? If so, could you post a sample so we can see how you handle it? IF you never do this, I would complain to the spring and/or hibernate folks. > I don't use > tomcat(6.0.16) connection pools, I have hibernate (via spring) to use > the connection pool directly. So Tomcat is not involved at all. You should post to their list instead of here, since Tomcat is really just a bystander. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+yU0ACgkQ9CaO5/Lv0PD8zQCdFRtEbBsHRk5RDK6tDGZWKvWt fRUAoJ7LJiWo7LizqzNdVGHGXN/SF0Uc =sho1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan, On 3/16/2009 4:09 PM, Alan Chaney wrote: > I spent some time looking to see whether these were configurable, but I > found nothing, apart from a rather snotty message on the vmware bulletin > boards stating that they didn't think that you should run a server on > the same platform as a vmware setup Wait, what? They said "don't run Tomcat on a VMWare instance?" or "don't run Tomcat on the VMWare manager instance?". (I'm no VMWare Server expert, but many virtualization products have a special virtualized instance that "controls" the underlying OS that manages all the instances). Can you clarify this a bit? > it stops working unless you can edit the 'other end' as it were and that > doesn't appear possible. I hunted through all the available > configuration files but the values must be hard-coded. That's obnoxious. :( A good question to the VMWare team would be "hey, why did you use heavy-ass Java for web interface when you're using virtualized hardware? ever heard of lighttpd/php or whatever everybody embeds in their routers?". Sheesh... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+x8MACgkQ9CaO5/Lv0PCLjACgkI9fZt0iGm6ZtfYuWXMF9gFG 2qwAoLw5HQG5Jy2iBgup7QSARzBLXrCy =9IOi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stack overflow when creating a session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, On 3/16/2009 12:48 PM, Michael Moynihan wrote: > Does anyone know why a Struts app would go into a recursive loop trying to > create a session? I see the following when the app is requested. > > java.lang.StackOverflowError > at org.apache.catalina.connector.Request.doGetSession(Request.java:2270) > at org.apache.catalina.connector.Request.getSession(Request.java:2075) > at > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) > at > javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) > at > org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) > at > javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) > at > org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) > at > javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) > at > org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) > at > javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) > This might be due to many wrappers around the request object. Each of those HttpServletRequestWrapper objects above might actually be distinct. Is there more of the stack trace? What filters do you have installed? It's interesting that the top of the stack is the "real" getSession method. Are there really hundreds of elements in the stack trace? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+xm0ACgkQ9CaO5/Lv0PB3+gCeOQFrCHX5oSO9l20JLrkjcSgA p6UAn2V2wBwP0lyHj9icR+D7BmIa1mGp =EdD7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 3/16/2009 11:53 AM, André Warnier wrote:
> As far as I understand the HTTP specs, something like
> request.setCharacterEncoding() should only be used (with a charset
> different from iso-8859-1) when a request comes in without a charset
> specification (which also indicates a broken client).
This is my interpretation of the spec.
This is my implementation of a fix:
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterConfig;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
/**
* A filter to ensure that a valid character encoding is available to the
* request.
*
* @author Chris Schultz
* @version $Revision: 1.2 $ $Date: 2006-07-14 14:23:43 $
*/
public class EncodingFilter
implements Filter
{
public static final String DEFAULT_ENCODING = "UTF-8";
private String _encoding;
/**
* Called by the servlet container to indicate to a filter that it is
* being put into service.
*
* @param config The Filter configuration.
*/
public void init(FilterConfig config)
{
_encoding = config.getInitParameter("encoding");
if(null == _encoding)
_encoding = DEFAULT_ENCODING;
}
protected String getDefaultEncoding()
{
return _encoding;
}
/**
* Performs the filtering operation provided by this filter.
*
* This filter performs the following:
*
* Sets the character encoding on the request to that specified in the
* init parameters, but only if the request does not already have
* a specified encoding.
*
* @param request The request being made to the server.
* @param response The response object prepared for the client.
* @param chain The chain of filters providing request services.
*/
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException
{
if(null == request.getCharacterEncoding())
request.setCharacterEncoding(this.getDefaultEncoding());
chain.doFilter(request, response);
}
/**
* Called by the servlet container to indicate that a filter is being
* taken out of service.
*/
public void destroy()
{
}
}
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm+xZkACgkQ9CaO5/Lv0PCTvwCeL5ppLbBLpFyF+FZKYtEumfhE
t1wAn2V0bm8OCkQo6EyHJ9WQXhgvCoWf
=XR+P
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
FYI After logging, this seems to be one of the most-discussed topics on
the list.
On 3/16/2009 9:54 AM, André Warnier wrote:
> I am about 99% sure of the following, but I would like to be 100% sure.
To sum up:
1. Using to set the Content-Type of the page to
charset ISO-8859-2
2. Submitting a POST form with higher ASCII characters (those that
will only work properly when respecting ISO-8859-2)
and enctype="multipart/form-data"
3. Trying to use HttpServletRequest.getParameter()
> then, if this form is submitted, within my servlet the line
>
> String p1 = request.getParameter("param1");
>
> would always return into p1, the proper internal Java Unicode string
> value of the input element "param1" of the form, properly decoded from
> it's original iso-8859-2 encoding.
> Yes ?
No. The servlet spec (SRV 3.1.1) states that POST data will only be read
from the request when the following conditions are true (note #3):
"
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter
family of methods on the request object.
"
Since you are using multipart/form-data, Tomcat isn't supposed to read
the POST parameters. You will have to do this yourself. If your client
is not sending a Content-Type including a character encoding, then you
have a client who isn't playing nicely. :( Most people give up and just
set everything to UTF-8 and be done with it.
Mikolaj's experience suggests that his client doesn't send the right
Content-Type (charset, really) and so Tomcat defaults to ISO-8859-1.
Most people use a filter that checks to see what the character encoding
is and, if there is none, sets the default to whatever pages advertise
themselves as (often UTF-8, in your case ISO-8859-2). This fixes 90% of
the POST encoding problems.
GET is another issue. :(
You asked how the server asks the client to encode a request. There's
really no provision for that in the HTTP spec. Anecdotal evidence
suggests that request (N + 1) is sent using the encoding of response N,
meaning that the client tends to use the encoding of the server's last
response.
Your statement about GET requests being (not) covered under a
shortcoming of the HTTP and URL specs is spot on: you basically can't
count on correct non-ISO-8859-1 characters in a URL. The solution? Use POST.
Quick question: multipart/form-data is typically used for file upload...
why not use application/x-www-form-urlencoded instead? I realize the
problem is that certain browsers do not send the proper charset in the
Content-Type, but I'd like to understand your affinity for
multipart/form-data.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm+w9kACgkQ9CaO5/Lv0PCXDgCdHi/cBwJgafNE5yR636FaXyHi
w24An0AMx7XXG8PRpjszGFmWM6KNWlnc
=Mtww
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MemoryLeak Problem with ThreadWithAttributes
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] > Subject: RE: MemoryLeak Problem with ThreadWithAttributes > > I'm still chasing what the array is used for. This is getting weird. The only usage of the thData array in 5.5.15 is only two slots long. Something has gone seriously wrong inside the OP's Tomcat (or perhaps JVM). I would strongly urge upgrading both Tomcat (to 5.5.27) and the JVM (to 1.5.0_17, preferably). - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MemoryLeak Problem with ThreadWithAttributes
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: MemoryLeak Problem with ThreadWithAttributes > > The current version of ThreadWithAttributes doesn't have any > methods with locals of type Object[] These aren't local variables, these are references local to the object. There are at least two such Object arrays in TWA: notes, and thData. The notes array is fixed at 16 entries, so it must be thData. The thData array is set by a call to setThreadData(), and can only be cleared by said call with a null parameter. But there are no such calls, so once it's set, the array is kept. (All of the above is true from 5.5.15 through 6.0.18.) I'm still chasing what the array is used for. > I wouldn't guess that java.lang.Thread would have > anything like this. It doesn't (at least in the OP's JVM version). - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cofiguring tomcat for trial certificate by trusted authorities like verisign not working.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bhuvanesh, On 3/16/2009 8:40 AM, Bhuvanesh Pattanashetti wrote: > Hi ,I had tried that was y also.. now i m able to get the SSL working with > the thawte trial SSL certificate. > but not with the Verisign yet. i dono why. If you are using an EV cert, there are /two /intermediate certs that you need to install. Have you installed both of their intermediate certs? I know they offer a single file that contains both, so that may be an option as well (or you may have imported both of them without realizing it). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+u90ACgkQ9CaO5/Lv0PAtegCeJ3creKsQOF0SsQ1784C7jf6b STQAnA4hpSRDeLVn0YsYo5UxbWKmE+IW =BQ1+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: Can't lookup new HighLowSequence for field id using sequence name SEQ_t_xx_xxx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ChupaMe, On 3/12/2009 7:40 AM, ChupaMe wrote: > we have a Problem with Tomcat/MySQL which causes our webapplication to stop > working. > After a restart of Tomcat and MySQL it works again. But we have to do this a > few times a day. [snip] > Often the follow error occurs the application is blocked: > > Mar 12, 2009 9:25:19 AM org.apache.ojb.broker.util.logging.CommonsLoggerImpl > error > SEVERE: Can't lookup new HighLowSequence for field id using sequence name > SEQ_t_xx_xxx > org.apache.ojb.broker.TransactionInProgressException: Connection is already > in transaction I think you might want to contact the Apache OJB folks about this one: http://db.apache.org/ojb/mail-lists.html Tomcat does not provide any database services other than to set up JNDI DataSources for you. It appears that the data source is working in your case and so the problem most likely lies with the OJB implementation. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+uXkACgkQ9CaO5/Lv0PDbswCgrQURWeQcY5a7xNtl7TPdWeaO U6QAnjJJszoisjWxRQ5Jm8hkW7Pd7arX =fXnB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MemoryLeak Problem with ThreadWithAttributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 3/16/2009 2:00 PM, Caldarale, Charles R wrote: > You need to look > inside the java.lang.Object array that this particular thread is > holding and see what the type of object in the array is. That should > help to narrow down where they're coming from. Your second screen > shot shows you starting to do this, but you didn't wait long enough > for it to display the array contents. Note that the array has room for 25764983 elements which is a /huge/ array. The array itself takes up 103059932 which is about 100MiB just for the array (on a 32-bit system... if it's a 64-bit system, you're talking about 200MiB), then any non-null elements of that array will need space on the heap, too. Sounds like something is being cached or not otherwise cleared-out. The current version of ThreadWithAttributes doesn't have any methods with locals of type Object[] (I couldn't find the source of TWA in the SVN repo) so I wonder where the "local Object[]" is coming from. I wouldn't guess that java.lang.Thread would have anything like this. Please give us more details about the contents of that array. I'm sure it will be enlightening. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+twcACgkQ9CaO5/Lv0PDtmQCdEt/5As0jrBNBMv1PkjgYN5vZ 7BUAoL23LSHgrX77r9a8fUpzFooAsD6U =WUGX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 warning
> From: ndolan [mailto:thallur...@yahoo.com]
> Subject: Tomcat 6.0.18 warning
>
> The server comes back with a 'requested resource()
> not found error.
Comes back from what URL? Check all the logs, not just the console.
> Mar 15, 2009 7:03:00 PM
> org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING:
> [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting
> property 'source' to 'org.eclipse.jst.jee.server:JSFTutorial'
> did not find a matching property.
Some IDEs insist on throwing invalid junk into the element. (Yet
another reason I have not to trust them blindly.) If you look at the doc for
, you'll see there is no source attribute:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
This has nothing to do with the resource not found error.
- 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
I've just wasted about a couple of hours sorting out an issue with Vmware server 2 and tomcat and I thought I'd pass it along, hoping to save someone else a small piece of frustration. I've been setting up a new development workstation (CentOS 5.2) and switched to using vmware server 2 (because version 1 is now moribund). Version 2 uses a web interface which is apparently 'served' from a local tomcat instance. Yay tomcat! However, in their infinite wisdom vmware have changed the default http and https ports from 8080 and 8443, but left the startup port at 8005 and the mod-jk port at 8009, and, what's more, not provided any way to change it. I spent some time looking to see whether these were configurable, but I found nothing, apart from a rather snotty message on the vmware bulletin boards stating that they didn't think that you should run a server on the same platform as a vmware setup which is odd, because A. I do in production all the time and it works fine and B. haven't they heard of development environments? I don't know about other people but I have all sorts of servers running on my workstation when I'm testing and debugging things. I found the vmware 'local' tomcat installation (6.0.16) and obviously you can edit the startup and mod-jk ports there, but then also obviously it stops working unless you can edit the 'other end' as it were and that doesn't appear possible. I hunted through all the available configuration files but the values must be hard-coded. So it seems that you must reconfigure any other local tomcat(s) on the same machine to use (a) different startup port(s). Hope that someone, someday, finds this helpful. I'd be interested if someone else finds out more about this. Alan Chaney - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Gregor Schneider wrote: > If found this one: > > http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset > > Actually, to me it's not clear why Tomcat should believe the input > being encoded in ISO8859-1, when one can give a detailled information > how the form-data is encoded. > > If I understand it correctly, one can even *force* any client (as long > as the client is following the specs) to encode the form-data using > the "accepeted-charset"-attribute of the -element. > > IOW: > > Setting "accepted-charset="UTF8"" should solve the problems. > > Comments, anyone? Yes it should work but it won't. Tomcat will honour it if sent but the browsers don't send it. See http://markmail.org/message/zozxd3iqp47ciisw Mark > > Rgds > > Gregor - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Gregor Schneider wrote: If found this one: http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset Actually, to me it's not clear why Tomcat should believe the input being encoded in ISO8859-1, when one can give a detailled information how the form-data is encoded. If I understand it correctly, one can even *force* any client (as long as the client is following the specs) to encode the form-data using the "accepeted-charset"-attribute of the -element. IOW: Setting "accepted-charset="UTF8"" should solve the problems. Comments, anyone? Yes. But no, it does not seem to work. I was under the same impression as you indicate above, and I already knew about the But I just tested this in Firefox 2 and in IE 6, and it does not work as expected. This is my test : 1) I created a html page as follows : -- begin -- http://mira.wissensbank.com/pcgi/printenv.pl"; method="POST" enctype="multipart/form-data" accept-charset="UTF-8"> First param: Second param: -- end -- The above file is created with a UTF-8 aware editor, and the characters in it (in "andré" and "gregör")(the umlaut is mine, as a test), are encoded as UTF-8. I saved the file as UTF-8 without BOM. As you can see, the document contains a tag indicating the page encoding, and the form contains an "accept-charset" attribute of the same color. 2) I opened this file in Firefox 2.0 and clicked the GO button. Since I open this as a local file, there is no "Content-Type" header coming from the server to confuse things. In Firefox, I have the LiveHttpHeaders plugin installed, which allows me to see the request as sent to the server, and save a copy of it, which I did. This is the result : -- begin -- POST /pcgi/printenv.pl HTTP/1.1 Host: mira.wissensbank.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.15) Gecko/20080623 Firefox/2.0.0.15 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-gb,en;q=0.7,de-de;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Content-Type: multipart/form-data; boundary=---218302158314236 Content-Length: 350 -218302158314236 Content-Disposition: form-data; name="param1" andré -218302158314236 Content-Disposition: form-data; name="param2" gregör -218302158314236 Content-Disposition: form-data; name="go" GO -218302158314236-- -- end -- 3) I did the same in Internet Explorer 6.0, which has another plugin of similar functionality (Fiddler), with which I can capture the whole request. Here it is : -- begin -- POST /pcgi/printenv.pl HTTP/1.1 Accept: */* Accept-Language: de Content-Type: multipart/form-data; boundary=---7d98c5bb072c Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Host: mira.wissensbank.com Content-Length: 338 Connection: Keep-Alive Pragma: no-cache -7d98c5bb072c Content-Disposition: form-data; name="param1" andré -7d98c5bb072c Content-Disposition: form-data; name="param2" gregör -7d98c5bb072c Content-Disposition: form-data; name="go" GO -7d98c5bb072c-- -- end -- So, as anyone can see, neither one of these browsers is adding any charset information to the POST. Which I personally find very strange, and rather on the bad side of the HTTP specs. Which tends to confirm the note in SRV 4.9 of the Servlet Specs 2.4/2.5 : "Currently, many browsers do not send a char encoding qualifier with the Content-Type header, leaving open the determination of the character encoding for reading HTTP requests." Which also seems to contradict the HTML specs which you mention : http://www.w3.org/TR/html401/interact/forms.html#h-17.13 and following paragraphs. (Note by the way the "Note" at the end of 17.13.1) In particular, this one from section "17.13.4 Form content types" : As with all multipart MIME types, each part has an optional "Content-Type" header that defaults to "text/plain". User agents should supply the "Content-Type" header, accompanied by a "charset" parameter. Well, Firefox 2.0 and IE 6.0 don't supply a "Content-Type" and even less a charset. In the case of IE 6.0, I am not really surprised, but in the case of Firefox, who would have thunk ? Anyway, it kind of puts a spin on what I posted here before, in the sense that the servlet engine thus, even in the case of a html form which should have everything in it to leave no choice to the browser, still does not get any information about the real character set of the data sent by the browser. Which personally, in our day and age, I find abso
Tomcat 6.0.18 warning
Hi,
I am trying to run a sample JSF tutorial on eclipse 3.2 on mac osx 10.5. The
server comes back with a 'requested resource() not found error. From the
server log in console, I found a warning as seen below:
Mar 15, 2009 7:03:00 PM org.apache.tomcat.util.digester.SetPropertiesRule
begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting
property 'source' to 'org.eclipse.jst.jee.server:JSFTutorial' did not find a
matching property.
Mar 15, 2009 7:03:00 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
Mar 15, 2009 7:03:00 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Mar 15, 2009 7:03:00 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2031 ms
Mar 15, 2009 7:03:01 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Mar 15, 2009 7:03:01 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
Mar 15, 2009 7:03:02 PM com.sun.faces.config.ConfigureListener
contextInitialized
INFO: Initializing Mojarra (1.2_09-b02-FCS) for context '/JSFTutorial'
Mar 15, 2009 7:03:05 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Mar 15, 2009 7:03:05 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Mar 15, 2009 7:03:05 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/90 config=null
Mar 15, 2009 7:03:05 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 4916 ms
Anyone know what this means?
Thanks.
--
View this message in context:
http://www.nabble.com/Tomcat-6.0.18-warning-tp22541483p22541483.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MemoryLeak Problem with ThreadWithAttributes
> From: Hennig, Patrick [mailto:phen...@l1id.com] > Subject: RE: MemoryLeak Problem with ThreadWithAttributes > The Tomcat Level is 5.5.15. That's over three years old. The first thing I'd do is move up to the current 5.5.27. > In one of the HeapDumps i see 25 ThreadWithAttributes Objects. That's not an unusual number. Tomcat uses ThreadWithAttributes objects to handle incoming requests; this is controlled by the various thread-related attributes of each element. > i see that this Object hast round 515mb of kind "Object" stored. No, the 515mb is the aggregate for all of the request-handling threads. The thread in question has a bit over 100 MB (which is still a lot). > And nealy all the time all the MemoryAnalyser`s say, that > ThreadWithAttribute is the Reason for OOM. It's not the ThreadWithAttributes objects themselves, it's what some of them are hanging onto that causes the OOME. You need to look inside the java.lang.Object array that this particular thread is holding and see what the type of object in the array is. That should help to narrow down where they're coming from. Your second screen shot shows you starting to do this, but you didn't wait long enough for it to display the array contents. - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stack overflow when creating a session
So how should we help you then without knowing your application? Remeber: This is a Tomcat-mailinglist. However, since some guys here do have quite some Struts-know, maybe you're lucky if providing sufficiant information... Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stack overflow when creating a session
Yes, I would agree with you. Struts 1.3.8 on tomcat 6. - Original Message From: Gregor Schneider To: Tomcat Users List Sent: Monday, March 16, 2009 1:29:48 PM Subject: Re: Stack overflow when creating a session Since Struts is very well tested on Tomcat (btw: which versions are you running?), I wouldn't believe this being a Tomcat / Struts-problem but a problem of your app. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stack overflow when creating a session
Since Struts is very well tested on Tomcat (btw: which versions are you running?), I wouldn't believe this being a Tomcat / Struts-problem but a problem of your app. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
If found this one: http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset Actually, to me it's not clear why Tomcat should believe the input being encoded in ISO8859-1, when one can give a detailled information how the form-data is encoded. If I understand it correctly, one can even *force* any client (as long as the client is following the specs) to encode the form-data using the "accepeted-charset"-attribute of the -element. IOW: Setting "accepted-charset="UTF8"" should solve the problems. Comments, anyone? Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Stack overflow when creating a session
Hi, Does anyone know why a Struts app would go into a recursive loop trying to create a session? I see the following when the app is requested. java.lang.StackOverflowError at org.apache.catalina.connector.Request.doGetSession(Request.java:2270) at org.apache.catalina.connector.Request.getSession(Request.java:2075) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: MemoryLeak Problem with ThreadWithAttributes
Hi Chuck, sorry for late answer. The Tomcat Level is 5.5.15. >How many ThreadWithAttributes objects are you seeing? In one of the HeapDumps i see 25 ThreadWithAttributes Objects. ( http://img518.imageshack.us/img518/4395/incomingreferences.png ~110kb ) Only 1 Object becomes that large. If i analyse the Object by outgoing Refrerences, i see that this Object hast round 515mb of kind "Object" stored. ( http://img10.imageshack.us/img10/4555/outgoingrefrences.png ~100kb) Dont know where these 515MB "Object" Objects are coming from...the reason why iam writing here is, to know why they are there. I dont guess, that this are Object which are not collected my GC, because of a still remaining reference. If it would be something like this, it would be possible to calculate, when memory runs out: The Testfile is round 3MB, doing some operations on it, the memory amount growth to X MB. MaxMemory / X MB = Rounds of Testing till out of Memory. But sometimes it crashes after 20 Testcases(5-6 Hours), then it works for days(without allocating virtual Memory), doing the same Test over and over again. This is why iam interested, in how ThreadWithAttributes is created and handled. Maybe iam totally wrong, searching for the Error on ThreadWithAttribute but dont know where to search.. And nealy all the time all the MemoryAnalyser`s say, that ThreadWithAttribute is the Reason for OOM. And doing a long-term Profining i can not say something like "after every testcase there is a 2% memory increasment". Can not see something like that. But when it runs out of Memory, it doesnt take more then 2-5 mins..then you see the memory increasment in the curve chart(jconsole). Patrick -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, March 10, 2009 8:55 PM To: Tomcat Users List Subject: RE: MemoryLeak Problem with ThreadWithAttributes > From: Hennig, Patrick [mailto:phen...@l1id.com] > Subject: RE: MemoryLeak Problem with ThreadWithAttributes > > (Dont`t know exactly, what you mean by "Tomcat Level") 5.5.?? Fill in the question marks. > redirectPort="8443" protocol="AJP/1.3"> port="8081" maxHttpHeaderSize="8192" > maxThreads="150" minSpareThreads="25" maxSpareThreads="75" > enableLookups="false" redirectPort="8443" acceptCount="100" > connectionTimeout="2" disableUploadTimeout="true"> If I understand the code correctly, this will limit the number of threads Tomcat uses to 350 (the default 200 for AJP plus 150 for HTTP). Consequently, you should see no more than that number of ThreadWithAttributes objects. > Iam focused on ThreadWithAttributes, because i see it everytime i > review a ErrorHeapDump. How many ThreadWithAttributes objects are you seeing? - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Joseph Millet wrote: Thing is you've got an HTML form that you tell browsers it is ISO-8859-2, so when they post it to form target URL - it gets send encoded as ISO-8859-2, it is then your responsibility to parse incoming queries Sorry, but I think this is incorrect. According to the HTTP specs, the client should specify a character encoding, and the server should respect the specified character encoding indicated by the client, and not guess. ... > in the encoding you asked it to be encoded. How does the server ask the client to encode his request ? Depending upon your requirements, UTF-8 will fit most of any languages needs True, but irrelevant here until the HTTP specs are revised. There is one confusing case : a GET request, with the parameters encoded in the URL, because in that case the client has no defined way to specify the real character encoding of the request parameters. That is a shortcoming of the HTTP and URL specs. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Gregor Schneider wrote: On Mon, Mar 16, 2009 at 3:10 PM, Mikolaj Rydzewski wrote: It doesn't work for me. By default Tomcat uses ISO-8859-1 encoding. And it will try this encoding to parse input parameters. That's true, I'm doing the same here for German Umlaute, however: One link in the Wiki is pointing to HTTP specification section 3.4.1, however, there's something that I do not understand: The specs say in 3.4.1: HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1. So, for me as a non-native English speaker, I understand it in such a way that your conent-encoding must be obliged - or do I get it wrong here? So, if in the content-encoding UTF-8 is specified, why isn't it accepted then? +1. In other words, according to the HTTP specs (and the Servlet Specs SRV 4.9), if the client sends a form content using the "multipart/form-data" encoding, and specifies a charset for one of the parts, then the servlet engine should decode it that way. And if the client sends a form content using the "multipart/form-data" encoding but does not specify a charset for any given part, then the servlet engine should consider that it is iso-8859-1, this being the default HTTP encoding. As far as I understand the HTTP specs, something like request.setCharacterEncoding() should only be used (with a charset different from iso-8859-1) when a request comes in without a charset specification (which also indicates a broken client). Comments anyone ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
Thing is you've got an HTML form that you tell browsers it is
ISO-8859-2, so when they post it to form target URL - it gets send
encoded as ISO-8859-2, it is then your responsibility to parse
incoming queries in the encoding you asked it to be encoded.
Depending upon your requirements, UTF-8 will fit most of any languages
needs but there are cases where you want to store some languages in
specific charsets as converting from specific charsets towards unicode
is reasonably reliable whereas converting from unicode towards
specific charsets can be tricky in some cases.
However, in your case your data is posted in ISO-8859-2 you'll need to
convert it in case you want to manipulate it as unicode using
something similar as this :
String value = request.getParameter("mytext");
try{
value = new String(value.getBytes(), request.getCharacterEncoding());
}catch(java.io.UnsupportedEncodingException ex){
System.err.println(ex);
}
But there might be some easier method and I'm not a JSP Guru ...
- Joseph
On Mon, Mar 16, 2009 at 3:40 PM, Gregor Schneider wrote:
> On Mon, Mar 16, 2009 at 3:10 PM, Mikolaj Rydzewski wrote:
>>
>> It doesn't work for me. By default Tomcat uses ISO-8859-1 encoding. And it
>> will try this encoding to parse input parameters.
>>
>
> That's true, I'm doing the same here for German Umlaute, however:
>
> One link in the Wiki is pointing to HTTP specification section 3.4.1,
> however, there's something that I do not understand:
>
> The specs say in 3.4.1:
>
>
> HTTP/1.1 recipients MUST respect the
> charset label provided by the sender; and those user agents that have
> a provision to "guess" a charset MUST use the charset from the
> content-type field if they support that charset, rather than the
> recipient's preference, when initially displaying a document. See
> section 3.7.1.
>
>
> So, for me as a non-native English speaker, I understand it in such a
> way that your conent-encoding must be obliged - or do I get it wrong
> here? So, if in the content-encoding UTF-8 is specified, why isn't it
> accepted then?
>
> Rgds
>
> Gregor
> --
> just because your paranoid, doesn't mean they're not after you...
> gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
> gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6 multiple hosts howto
> From: Jeroen Kransen [mailto:jer...@kransen.nl] > Subject: Tomcat 6 multiple hosts howto > > I used Tomcat 5.5 with multiple elements in the > server.xml Now I read that this has to be done differently > in Tomcat 6, but I am not sure how. Tomcat 6 is a bit stricter; you may not have been doing things completely properly in 5.5. The doc is here: http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html > I added a conf/Catalina/examplecom/context.xml You must have misinterpreted what you read; the above would only be appropriate for a web site with the name "examplecom" (not "example.com") with a webapp named "context". Unlikely to be what you want. > Also, is there a way to specify individual classpaths that > have a Host as scope? No. > That way I can deploy the same webapp for different hosts > using different settings in the .properies files. Bad idea. Just deploy the .war (or directory) as many times as you need. It costs some disk space, but that's exceedingly cheap. Separate properties can be specified in each webapp's element, placed in the conf/Catalina/[host]/[appName].xml files. - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: form parameters
On Mon, Mar 16, 2009 at 3:10 PM, Mikolaj Rydzewski wrote: > > It doesn't work for me. By default Tomcat uses ISO-8859-1 encoding. And it > will try this encoding to parse input parameters. > That's true, I'm doing the same here for German Umlaute, however: One link in the Wiki is pointing to HTTP specification section 3.4.1, however, there's something that I do not understand: The specs say in 3.4.1: HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1. So, for me as a non-native English speaker, I understand it in such a way that your conent-encoding must be obliged - or do I get it wrong here? So, if in the content-encoding UTF-8 is specified, why isn't it accepted then? Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6 multiple hosts howto
>>I used Tomcat 5.5 with multiple elements in the server.xml Now I read that this has to be done differently in Tomcat No, it is not. You should have one element for every virtual host you need. http://tomcat.apache.org/tomcat-6.0-doc/config/host.html -Original Message- From: Jeroen Kransen [mailto:jer...@kransen.nl] Sent: Monday, March 16, 2009 5:29 PM To: users@tomcat.apache.org Subject: Tomcat 6 multiple hosts howto Hello all, I am sure this is a FAQ, but I can't find any info about it. I used Tomcat 5.5 with multiple elements in the server.xml Now I read that this has to be done differently in Tomcat 6, but I am not sure how. I added a conf/Catalina/examplecom/context.xml, but I don't know what to put there, and how to link it to the host example.com.. Also, is there a way to specify individual classpaths that have a Host as scope? That way I can deploy the same webapp for different hosts using different settings in the .properies files. Thanks in advance! Jeroen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 multiple hosts howto
Hello all, I am sure this is a FAQ, but I can't find any info about it. I used Tomcat 5.5 with multiple elements in the server.xml Now I read that this has to be done differently in Tomcat 6, but I am not sure how. I added a conf/Catalina/examplecom/context.xml, but I don't know what to put there, and how to link it to the host example.com.. Also, is there a way to specify individual classpaths that have a Host as scope? That way I can deploy the same webapp for different hosts using different settings in the .properies files. Thanks in advance! Jeroen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Howdy ! A little help ?
nup all good now worked it out :) Thankyou so much to thoes who helped me :) Stu
Re: form parameters
André Warnier wrote: If, inside a html page containing a tag such as [...] would always return into p1, the proper internal Java Unicode string value of the input element "param1" of the form, properly decoded from it's original iso-8859-2 encoding. Yes ? Hi, It doesn't work for me. By default Tomcat uses ISO-8859-1 encoding. And it will try this encoding to parse input parameters. You have to call request.setCharacterEncoding(...) before reading parameter values from request. Best solution is to have servlet filter that sets request encoding to some value. I use always UTF-8 and it works with no problems. http://wiki.apache.org/tomcat/Tomcat/UTF-8 -- Mikolaj Rydzewski smime.p7s Description: S/MIME Cryptographic Signature
form parameters
Hi.
I am about 99% sure of the following, but I would like to be 100% sure.
Referring to
HttpServletRequest.getParameter()
HttpServletRequest.getParameterValues()
If, inside a html page containing a tag such as
there is a form section defined as follows :
action="(url of my webapp/servlet)">
...
then, if this form is submitted, within my servlet the line
String p1 = request.getParameter("param1");
would always return into p1, the proper internal Java Unicode string
value of the input element "param1" of the form, properly decoded from
it's original iso-8859-2 encoding.
Yes ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: XSD mime type
Markus Schönhaber wrote: > Pid: > >> What, if any, is the correct MIME type for the XSD file type? > > When you say "the XSD file type", you're talking about files containing > XML Schemas? Yes. Typically I see schema files defined in schema_name.xsd. > IIRC there's no special media type for schemas. But since they are > themselves XML files, this... > >> I'm guessing it's text/xml or application/xml > ...would be what I, too, would use. Thanks, I just wanted to be sure I wasn't missing something obvious. p > Regards > mks > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Hi Andre, I meant to stop writing, not closing the socket. Poor choice of words, apologies. André Warnier wrote: Taylan Develioglu wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taylan, No, you'd need to modify the source. It's not particularly useful in most scenarios to intentionally stall an HTTP conversation, so it's not a built-in feature :) No, I'm saying that you should send exactly the right amount of data, but you should stall in the middle. For instance, set the Content-Length to 10 bytes, then send 5 bytes, then wait 10 or 20 seconds, and send the rest. Ah ofcourse, I understand what you're saying now. We basically wait for the timeout to occur before we send the post parameters. Could be done by *socket.setTcpNoDelay*() then writing to the socket and closing ,then waiting and writing the other half I think. No, I don't think you want to close. Send the first 5 bytes, then wait, then send the rest. Then maybe close (but only the sending side of the socket). If you close the connection totally (including the receiving side), you will provoke an error at the server side. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cofiguring tomcat for trial certificate by trusted authorities like verisign not working.
Hi ,I had tried that was y also.. now i m able to get the SSL working with the thawte trial SSL certificate. but not with the Verisign yet. i dono why. Even after this importing the CA Certificate. i m getting the alert for non-Secure items. So is that the reason that i dont have the paid SSL certificate. or even the trail cert from thawte would behave as same as the paid one. Thanks, Bhuvan P On Sun, Mar 15, 2009 at 4:24 AM, Bill Barker wrote: > > "Bhuvanesh Pattanashetti" wrote in message > news:bce69da80903122202i384a040cj66e5089fc14f6...@mail.gmail.com... > > HI All,thanks all for your suggestions. :-) > > > > Here are following some more details. > > > > I m using > > > > - tomcat 6.0, > > - JDK 1.6, > > - no i m not using keystore. > > - I m running on Xp with Spring-DM framework. > > connector is as follows. > > > > > port="8443" minSpareThreads="5" maxSpareThreads="75" > > enableLookups="true" disableUploadTimeout="true" > > acceptCount="100" maxThreads="200" > > scheme="https" secure="true" SSLEnabled="true" > > keyAlias="aliasName" > > keystoreFile="KEeySrotePath" keystorePass="password" > > clientAuth="false" sslProtocol="TLS"/> > > >^ > If you remove the keyAlias from | it will probably just work. > > > I have generated the keystore using keytool. > > Please suggest me further. > > > > > > > > > > > > On Fri, Mar 13, 2009 at 7:51 AM, Bill Barker > wrote: > > > >> Willing to try and play psychic ;). > >> > >> Procedure 1 is what you want. But the keystore must be the same one > that > >> you used to create the CSR you sent to Verisign. This is by far the > >> second > >> most common mistake that people make when setting up Tomcat to use SSL. > >> As > >> Chuck suggested, check if you are using APR (the SSL configuration > >> options > >> are different, and APR can't use a JKS keystore). This is the most > >> common > >> mistake. Verisign has an intermediate cert as well. You'll likely need > >> to > >> import that as well. And of course, import the Verisign root cert. > >> > >> > >> "Bhuvanesh Pattanashetti" wrote in message > >> news:bce69da80903120948v7c2f1693md9db7e74e6e3f...@mail.gmail.com... > >> > Hi all, > >> > I m trying to set up the SSL for tomcat server. I wanted to know what > >> > exactly is the procedure. > >> > here is what i have followed. > >> > > >> > Procedure 1. > >> > > >> > 1. Created my own keystore. > >> > 2. Imported the trial certificate (provided by Verisign ) into the > >> > keystore. > >> > 3. Added a ssl connector component in to the conf/server.xml into > >> tomcat > >> > configuration file. > >> > 4. Started the Server, When tried accessing connector port from > >> browser, > >> > I got cannot display the webpage. > >> > 5. > >> > > >> > procedure 2 : > >> > > >> > 1. Created my own keystore. > >> > 2. Imported the trial certificate (provided by Verisign ) into the > >> > keystore. > >> > 3. Imported the trial certificate (provided by Verisign ) into the > >> > cacerts from jre/lib/security/cacerts. > >> > 4. Added a ssl connector component in to the conf/server.xml into > >> tomcat > >> > configuration file mentioning keyAlias pointing to imported > >> > certificate > >> > alias. > >> > 5. Started the Server, at start up i got the folliwing exception > >> > > >> > java.io.IOException: Alias name mykeyalias does not identify a key > >> entry > >> > > >> > I had importing the root certificate or intrmediate certificate first > >> > before > >> > importing trial verisign certificate suggested by tomcat. > >> > But none of the things are working :-( please suggest me. > >> > thanks in advance. > >> > Bhuvan P > >> > > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat w/apr data lost in http post request?
Taylan Develioglu wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taylan, No, you'd need to modify the source. It's not particularly useful in most scenarios to intentionally stall an HTTP conversation, so it's not a built-in feature :) No, I'm saying that you should send exactly the right amount of data, but you should stall in the middle. For instance, set the Content-Length to 10 bytes, then send 5 bytes, then wait 10 or 20 seconds, and send the rest. Ah ofcourse, I understand what you're saying now. We basically wait for the timeout to occur before we send the post parameters. Could be done by *socket.setTcpNoDelay*() then writing to the socket and closing ,then waiting and writing the other half I think. No, I don't think you want to close. Send the first 5 bytes, then wait, then send the rest. Then maybe close (but only the sending side of the socket). If you close the connection totally (including the receiving side), you will provoke an error at the server side. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taylan, No, you'd need to modify the source. It's not particularly useful in most scenarios to intentionally stall an HTTP conversation, so it's not a built-in feature :) No, I'm saying that you should send exactly the right amount of data, but you should stall in the middle. For instance, set the Content-Length to 10 bytes, then send 5 bytes, then wait 10 or 20 seconds, and send the rest. Ah ofcourse, I understand what you're saying now. We basically wait for the timeout to occur before we send the post parameters. Could be done by *socket.setTcpNoDelay*() then writing to the socket and closing ,then waiting and writing the other half I think. Wow, I didn't realize that browsers would keep an HTTP connection open to a web server for 10 idle seconds. That seems like a really long time. Actually, the default for IE is even 60 seconds (idle) on a keepalive connection. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: XSD mime type
Pid: > What, if any, is the correct MIME type for the XSD file type? When you say "the XSD file type", you're talking about files containing XML Schemas? IIRC there's no special media type for schemas. But since they are themselves XML files, this... > I'm guessing it's text/xml or application/xml ...would be what I, too, would use. Regards mks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Hi Chris, Raising the keepalive-timeout value on the connector definitely improves the situation. From what I've gathered from what people posted here (thanks guys) and dumping packets I believe the situation to be somewhat as follows: With nagle's off, IE sends out the http request in two separate packets. Somewhere between Tomcats receipt of packet 1 (header) and packet 2 (body/parameters) timeout occurs leading to the contents of the second packet to be ignored. Raising keepalive-timeout alleviates the problem by decreasing the chance of a timeout to occur. Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taylan, On 3/6/2009 4:05 AM, Taylan Develioglu wrote: James, thank you very much. I suspected IE to be guilty because it was happening only with IE clients. Chris, I guess we don't need to try and reproduce this anymore now we know the cause? Well, you might want to figure out how to handle this situation. You can't simply ignore 80% of the potential clients out there :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm1mosACgkQ9CaO5/Lv0PBDRgCfQXPTf2uwKVgIeNHiuVbcyYT6 ZuEAnjNY9yEDmIFrc0q4TwNuvPkBuI3U =NGPN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Possibly IE writes to the socket buffer in seperate steps for header info and post parameters. This would cause the data to be sent out in seperate packets if nagle's alg. is off. Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: tomcat w/apr data lost in http post request? Can MSIE even control which data goes in which packet? TCP/IP APIs on most platforms allow the Nagle algorithm to be disabled, which will cause data to be sent out on each call. Most TCP/IP stacks also set the push flag on the last packet of a sequence to force the peer stack to deliver the data to the receiver without delay. Tthat's probably all that IE is doing (but I don't know the MS APIs). - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
XSD mime type
Hi, What, if any, is the correct MIME type for the XSD file type? I'm guessing it's text/xml or application/xml - but it's not defined in either Apache HTTPDs mime types or Tomcats web.xml. (TC6 or HTTPD 2.2.11) Am I missing something obvious? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Path problem
Hi,
ln my case i the config file is not in any of the jars, also i cant set it
to the classpath for some reason. (This product runs in different machines
connecting through RMI). My config file just resides inside WEB-INF. so if i
want to set it as a system property what can i do?
The java classes i run are inside a jar which is in WEB-INF/lib directory.
David Smith-2 wrote:
>
> To demystify things:
>
> 1. ServletContext.getResourceAsStream("/path/inside/webapp.blah")
> returns an object that supports the java.io.InputStream stream
> interface. After you get the stream, you can treat it like any other
> input stream in the java world.
>
> 2. The path is rooted in the *webapp*, not the file system. Given a
> file in a webapp like
> $CATALINA_HOME/webapps/mywebapp/WEB-INF/myconfigs/myconfig.properties,
> the path you'd use with ServletContext.getResourceAsStream() would be
> "/WEB-INF/myconfigs/myconfig.properties".
>
> 3. Logs would be a different story. You are best off configuring your
> log tool according to it's documentation and let it handle the logging.
>
> --David
>
> David.Meldrum wrote:
>> OK, I agree about writing, but what about reading? I guess I didn't
>> realize there was a method called getResourcesStream(), on
>> ServletContext, so that clears up some confusion. Yet when I read the
>> javadoc on ServletContext.getRessourceAsStream()
>> see:
>> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContext.html#getResourceAsStream(java.lang.String)
>>
>>
>> It still isn't clear how to properly use this. For example, how do I
>> get a reference to the "/webapps/MyWebApp/WEB-INF/foo.properties" file?
>> Like this?
>> ServletContext.getRessourceAsStream("/webapps/MyWebApp/WEB-INF/foo.properties");?
>>
>> The javadoc says the argument is a path, but I don't know the full
>> path, only relative to Tomcat, and I don't really know where Tomcat is.
>> Also how do I create a file under "/logs"?
>> Is there some way to determine the path to the /logs directory in a
>> format that I can create a file under the logs
>> directory, without assuming where Tomcat is deployed?
>>
>> -d
>>
>> Caldarale, Charles R wrote:
From: David.Meldrum [mailto:david.meld...@verizon.net] Subject: Re:
Path problem
actually in my case I am trying to read/write from a ContextListenr
>>>
>>> It's generally a bad idea to ever *write* into the webapp deployment
>>> space. You have no guarantee that the space is writable, nor that
>>> the container will provide any write access. You're much better off
>>> writing to files outside of Tomcat's directory structure, where the
>>> path can be provided by system property, environment variable,
>>> , or whatever.
>>>
>>>
As recommended below, you could use Class.getResourcesStream(), but
as I understand it,
that will give the location of this class under WEB-INF.
>>>
>>> Or anywhere else in the webapp's structure; it's not confined to
>>> WEB-INF.
>>>
>>>
public void contextInitialized(ServletContextEvent event) {
ServletContext sctx = event.getServletContext();
String propPath = sctx.getRealPath(
"/WEB-INF/resource.properties");
FileInputStream inStrm = new FileInputStream(propPath);
.
}
>>>
>>> Using ServletContext.getRealPath() is risky; the container is under
>>> no obligation to provide access to the underlying file system (think
>>> deployment via .war file). Much safer and better to use
>>> getResourceAsStream().
>>>
>>> - Chuck
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Path-problem-tp22490662p22535464.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to install tomcat container into jboss 4.0.4
Hi This is what u get on default server request [ http://localhost:8080/] Tomcat status (full) (XML) JMX Console JBoss Web Console With regards Karthik -Original Message- From: Prashant Kadam [mailto:prashant_ka...@persistent.co.in] Sent: Monday, March 16, 2009 2:35 PM To: 'Tomcat Users List' Subject: RE: How to install tomcat container into jboss 4.0.4 WebService (caGrid service) which I want to deploy only supports to jboss 4.0.4 .. cant 4.0.4 come with inbuilt tomcat ? how to verify that ? Thanks Prashant -Original Message- From: Karthik Nanjangude [mailto:karthik.nanjang...@xius-bcgi.com] Sent: Monday, March 16, 2009 2:27 PM To: Tomcat Users List Subject: RE: How to install tomcat container into jboss 4.0.4 Hi >> tomcat container into jboss 4.0.4 Any specific reason for JBOSS 4.0.4 being installed... Latest stable release is 4.2.3 with built in TOMCAT 5 With regards Karthik -Original Message- From: Prashant Kadam [mailto:prashant_ka...@persistent.co.in] Sent: Monday, March 16, 2009 12:52 PM To: users@tomcat.apache.org Subject: How to install tomcat container into jboss 4.0.4 Hi, I am working on some webservice deployment part where I want to deploy service to jboss and as per tutorial provided, it mentions to make sure tomcat container is installed into jboss 4.0.4. What is exactly means ? and how to install or how to verify whether it is already installed ? Thanks Prashant DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shutting down Tomcat 5.5.27 on Windows Vista takes forever
Hi! All the logs of a startup and shutdown can be found on: http://dl.getdropbox.com/u/404360/logs.zip Best regards, Nuno Guerreiro On Sun, Mar 15, 2009 at 2:36 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Nuno Guerreiro [mailto:nmd.guerre...@gmail.com] > > Subject: Shutting down Tomcat 5.5.27 on Windows Vista takes forever > > > > I am attaching the full catalina.log file. > > Most attachments, including this one, are stripped by the mail list server. > > If you can put all the non-empty Tomcat log files (not just catalina.log) > on a publically accessible server somewhere, that would work. Otherwise > just include them as text in the mail message. > > - 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: How to install tomcat container into jboss 4.0.4
WebService (caGrid service) which I want to deploy only supports to jboss 4.0.4 .. cant 4.0.4 come with inbuilt tomcat ? how to verify that ? Thanks Prashant -Original Message- From: Karthik Nanjangude [mailto:karthik.nanjang...@xius-bcgi.com] Sent: Monday, March 16, 2009 2:27 PM To: Tomcat Users List Subject: RE: How to install tomcat container into jboss 4.0.4 Hi >> tomcat container into jboss 4.0.4 Any specific reason for JBOSS 4.0.4 being installed... Latest stable release is 4.2.3 with built in TOMCAT 5 With regards Karthik -Original Message- From: Prashant Kadam [mailto:prashant_ka...@persistent.co.in] Sent: Monday, March 16, 2009 12:52 PM To: users@tomcat.apache.org Subject: How to install tomcat container into jboss 4.0.4 Hi, I am working on some webservice deployment part where I want to deploy service to jboss and as per tutorial provided, it mentions to make sure tomcat container is installed into jboss 4.0.4. What is exactly means ? and how to install or how to verify whether it is already installed ? Thanks Prashant DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to install tomcat container into jboss 4.0.4
Hi >> tomcat container into jboss 4.0.4 Any specific reason for JBOSS 4.0.4 being installed... Latest stable release is 4.2.3 with built in TOMCAT 5 With regards Karthik -Original Message- From: Prashant Kadam [mailto:prashant_ka...@persistent.co.in] Sent: Monday, March 16, 2009 12:52 PM To: users@tomcat.apache.org Subject: How to install tomcat container into jboss 4.0.4 Hi, I am working on some webservice deployment part where I want to deploy service to jboss and as per tutorial provided, it mentions to make sure tomcat container is installed into jboss 4.0.4. What is exactly means ? and how to install or how to verify whether it is already installed ? Thanks Prashant DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to install tomcat container into jboss 4.0.4
Hi, I am working on some webservice deployment part where I want to deploy service to jboss and as per tutorial provided, it mentions to make sure tomcat container is installed into jboss 4.0.4. What is exactly means ? and how to install or how to verify whether it is already installed ? Thanks Prashant DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
