WebDAV characters bug?
I am using Tomcat 5.5.9 (on Windows XP) and WebDAV to upload files to my server. However it seems to be a bug or limitation in the Tomcat WebDAV that limits the use of some characters I frequently use. Unsupported characters are : ; (semicolon) + (plus) # (pound) I know these are reserved characters, so I have tried to URL encode them, but Tomcat ignores the URL encoding and writes the URL encoded filenames to disk. Eg. myfile;01.txt is saved like myfile%B301.txt on the server. Tomcat is configured to do URL Encoding. If I don't do URL Encoding it simply cuts the end of the filename from semicolon like myfile. This is my Connector configuration in server.xml: Connector port=80 maxHttpHeaderSize=8192 useBodyEncodingForURI=true URIEncoding=UTF-8 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / I also tested this in Tomcat 5.5.12 with same problems. I have tested several clients. IE 6.0, DavExplorer and own code. The reason I think this is a bug is because these characters are supported by Apache/mod_dav. Anyone know of a fix to this problem, or if it is a known bug? Regards Roland Rabben Technical Director Scala Nordic AS [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDAV characters bug?
Looks like a bug to me. Create a bugzilla entry for it and I'll try and take a look before the next release. Mark Roland Rabben wrote: I am using Tomcat 5.5.9 (on Windows XP) and WebDAV to upload files to my server. However it seems to be a bug or limitation in the Tomcat WebDAV that limits the use of some characters I frequently use. Unsupported characters are : ; (semicolon) + (plus) # (pound) I know these are reserved characters, so I have tried to URL encode them, but Tomcat ignores the URL encoding and writes the URL encoded filenames to disk. Eg. myfile;01.txt is saved like myfile%B301.txt on the server. Tomcat is configured to do URL Encoding. If I don't do URL Encoding it simply cuts the end of the filename from semicolon like myfile. This is my Connector configuration in server.xml: Connector port=80 maxHttpHeaderSize=8192 useBodyEncodingForURI=true URIEncoding=UTF-8 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / I also tested this in Tomcat 5.5.12 with same problems. I have tested several clients. IE 6.0, DavExplorer and own code. The reason I think this is a bug is because these characters are supported by Apache/mod_dav. Anyone know of a fix to this problem, or if it is a known bug? Regards Roland Rabben Technical Director Scala Nordic AS [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible Security Bug
I have a _possible_ bug involving security in Tomcat 5.0.28. I dont see it in the bug database, although it may be described in a way that I didnt search for. I would prefer to send it privately in case its real. If thats not feasible, I will post it here. Or is there a way to put it in the database but mark it private? Can anyone advise? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible Security Bug
John Caron wrote: I have a _possible_ bug involving security in Tomcat 5.0.28. I dont see it in the bug database, although it may be described in a way that I didnt search for. I would prefer to send it privately in case its real. If thats not feasible, I will post it here. Or is there a way to put it in the database but mark it private? Can anyone advise? Security bugs should be sent to [EMAIL PROTECTED] (who will send it on to the tomcat team). If you send it to me directly I'll take a look now. One other point, when sending a message on a new topic to the list, please don't reply to an old message and change the subject line. Thread aware mail clients still recognise your new message as part of the old thread. The correct process is to create a new message. Mark [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug votes needed..you really should read this..Tomcat/JVM hangs in session.getAttribute / HashMap.get()
This bug doesn't only affect code where you access the session using session.getAttribute() or session.setAttribute(,), but also affects jsp tags such as jsp:useBean with scope=session. I'm guessing that pages using EL and accessing the session are going to be broken as well I didn't look that far, but if you are using the jsp page context and using the methods JspContext.get/setAttribute and using SESSION_SCOPE you will be affected by the bug. The big picture here is that we can't control the users, and if they make multiple threads access the session they can and more than likely crash your server. Remember if you access the session from your application they can hit reload a few times and cause this or if you use frames. They could even have more than one browser instance opened. One the CPU will start to get used up, and two your Tomcat threads will run out. Affected versions: Tomcat 5.0.x Tomcat 5.5.x If you don't have a bugzilla account maybe you can set one up and vote for the bug. It helps all of us to vote for bugs. So, read up on it, and make a decision. Don't read only a few comments about the bug as the entire picture isn't discussed. Read them all and know what the issue is. Here is the bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 Again, setup a bugzilla account and vote for this bug. If an application doesn't use the session at all it won't be affected, but remember if you use sessions and notice your Tomcat crashing or hanging then this is probably your issue. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug votes needed..you really should read this..Tomcat/JVM hangs in session.getAttribute / HashMap.get()
I've send a similar mail to the struts-users mailing list. Maybe other affected jakarta projects should be notified too. Leon -Ursprüngliche Nachricht- Von: Wade Chandler [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 7. September 2005 23:05 An: Tomcat Users List Betreff: Re: Bug votes needed..you really should read this..Tomcat/JVM hangs in session.getAttribute / HashMap.get() This bug doesn't only affect code where you access the session using session.getAttribute() or session.setAttribute(,), but also affects jsp tags such as jsp:useBean with scope=session. I'm guessing that pages using EL and accessing the session are going to be broken as well I didn't look that far, but if you are using the jsp page context and using the methods JspContext.get/setAttribute and using SESSION_SCOPE you will be affected by the bug. The big picture here is that we can't control the users, and if they make multiple threads access the session they can and more than likely crash your server. Remember if you access the session from your application they can hit reload a few times and cause this or if you use frames. They could even have more than one browser instance opened. One the CPU will start to get used up, and two your Tomcat threads will run out. Affected versions: Tomcat 5.0.x Tomcat 5.5.x If you don't have a bugzilla account maybe you can set one up and vote for the bug. It helps all of us to vote for bugs. So, read up on it, and make a decision. Don't read only a few comments about the bug as the entire picture isn't discussed. Read them all and know what the issue is. Here is the bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 Again, setup a bugzilla account and vote for this bug. If an application doesn't use the session at all it won't be affected, but remember if you use sessions and notice your Tomcat crashing or hanging then this is probably your issue. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
request.getServletPath() changes during request lifecycle, BUG or Specified behaviour ?
At the start of my HttpServlet class code: request.getServletPath() = /myServlet But then my HttpServlet code runs a MVC pattern and decides to forward off to a JSP page /someDir/myPage.jsp so inside any tag's inside that JSP page now get: request.getServletPath() = /someDir/myPage.jsp Which is just plain wrong. Can anyone confirm if this correct behaviour ? It seems pretty ludicrious that the request object is meant to be associated with the original request, so I would expect it to remain constant (unless my app overides it), like how we got here is pretty important stuff throughout the whole lifetime of a request. The forwarding methodology JSP uses seems to be more related to the response part, as-in the path /someDir/myPage.jsp is a forwarding action that is being carried out in the response part. To work around this sillyness: I have added code into my HttpServlet like 'request.setAttribute(getHttpRequestPath, request.getServletPath())' so that the original HttpRequest information can be preserved throughout the whole request lifecycle. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.getServletPath() changes during request lifecycle, BUG or Specified behaviour ?
Darryl L. Miles wrote: At the start of my HttpServlet class code: request.getServletPath() = /myServlet But then my HttpServlet code runs a MVC pattern and decides to forward off to a JSP page /someDir/myPage.jsp so inside any tag's inside that JSP page now get: request.getServletPath() = /someDir/myPage.jsp Which is just plain wrong. Can anyone confirm if this correct behaviour ? To work around this sillyness: Alternatively, per the 2.4 Servlet spec: SRV.8.4.2 Forwarded Request Parameters Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the forward method of RequestDispatcher has access to the path of the original request. The following request attributes must be set: javax.servlet.forward.request_uri javax.servlet.forward.context_path javax.servlet.forward.servlet_path javax.servlet.forward.path_info javax.servlet.forward.query_string ... etc. HTH! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Content-type, bug 24970
I am using Tomcat 5.0.28 and need to have a pdf document open as a plug-in in Internet Explorer. I tried using the response.class file (for an earlier version of Tomcat) recommended in the bug documentation, but it did not make a difference. Is there any additional information/solutions that are available for this issue? Regards, Chris Ferraro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Markup Character Entities attr=lt;amp;quot;gt; BUG ?
The following example JSP page seems to be interpreted incorrectly. %@ page language=java contentType=text/html; charset=UTF-8 pageEncoding=UTF-8% !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN %@ taglib prefix=g uri=http://domain.com/taglibs/generic-0.1; % html head titleTAG GENERIC PAGE/title /head body g:generic attrOne=1 attrTwo=2 attrThree=lt;amp;quot;gt; attrFour=quot;/lt; lt;Tag Herebr/ /body /html logged calls to setDymanicAttribute() showing the 3 arguments passed. DEBUG 10:22:40,279 (GenericTag.java:setDynamicAttribute:47) -null attrOne 1 DEBUG 10:22:40,285 (GenericTag.java:setDynamicAttribute:47) -null attrTwo 2 DEBUG 10:22:40,287 (GenericTag.java:setDynamicAttribute:47) -null attrThree lt;amp;gt; DEBUG 10:22:40,298 (GenericTag.java:setDynamicAttribute:47) -null attrFour It seems the quot; is correctly converted into but other character entities are not. It is my understanding that all markup file parsing should follow through the order of: * characterize file from its encoding type (UTF-8, etc...) * tokenize character stream looking for character entities and substitute what they represent (no matter where they are in the file), any substituted character may not be used as tokens that delimit markup elements in the next step * now parse the markup in the resulting file For performance reasons it probably doesn't happen exactly like that. I am expecting output like: null attrThree null attrFour I also notice that it seems common place to use JSP tags like this: img height=10 src=foo:tag name=value/ width=10/ Is the above recursivly reliable like this: x:outer attr=x:middle attr=x:inner attr=foo/// merge:img merge:attr height=10/ merge:attr-body name=srcfoo:tag name=value//merge:attr-body merge:attr width=10/ /merge:img I appreciate the former maybe done as lazy short hand, but it appears to break something else which is a stronger binding standard. There must be many possible alternative approaches in JSP to this problem that won't conflict with other elements of all the standards that come info play. Is it possible to force a purist approach to this problem and switch off this mode to get back a reliable behaviour (even if it does seem like I have to take the long way around) call this idealized behaviour if you will. Ultimatly our JSP authoring tools will be powerful enough to automatically hide complex tag constructs like this and allow us to see at a glance the representation we most like to see but really whats saved in the raw file maybe the unrolled purist version. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.9 with Struts 1.2.7 - ClassCastException - looks like a Tomcat bug
Thank you Christian - you are correct. A colleague also referred me to: http://www.systemmobile.com/wp/?p=152 I had a copy of jsp-api.jar in my app (/WEB-INF/lib/jsp-api.jar) And Tomcat (both 5.0.28 and 5.5.9) has a copy under $CATALINA_HOME/common/lib/jsp-api.jar This makes the copy in my app redundant and it can safely be removed. By removing it, it resolves the ClassCastException with org.apache.struts.taglib.html.MessagesTei But why should this double presence of jsp-api.jar be a problem for Tomcat 5.5.9 but not for 5.0.28? Thank you, Stewart -Original Message- From: Christian Dionne [mailto:[EMAIL PROTECTED] Sent: 17 August 2005 14:14 To: 'Struts Users Mailing List' Subject: RE: Tomcat 5.5.9 with Struts 1.2.7 - ClassCastException - looks like a Tomcat bug Hi Stewart, I had the same problem and I received a great answer on this mailing list a few days ago. The problem is caused by either one of these libraries that are conflicting with Struts: - jsp-api.jar - jsp-2.0-api.jar On my side, removing these libraries from my project (they were not used) solved the problem. Thanks, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: August 17, 2005 6:24 AM To: [EMAIL PROTECTED]; user@struts.apache.org Subject: Tomcat 5.5.9 with Struts 1.2.7 - ClassCastException - looks like a Tomcat bug Using Struts 1.2.7 with the latest Tomcat 5.5.9 I get the following in localhost.date.log when I first try to access my web application: 17-Aug-2005 11:02:02 org.apache.catalina.core.Stand-ardHostValve custom SEVERE: Exception Processing ErrorPage[exceptionType=java.l-ang.Exception, location=/error.jsp] org.apache.jasper.JasperExcept-ion: Failed to load or instantiate TagExtraInfo class: org.apache.struts.taglib.html.-MessagesTei And in stdout_date.log I get: ERROR:org.apache.catalina.core-.ApplicationDispatcher.invoke(-Applicatio nDispatcher.java:704-) Servlet.service() for servlet jsp threw exception java.lang.ClassCastException: org.apache.struts.taglib.html.-MessagesTei Through trial and error I have found that this does not happen with Tomcat 5.0.28, with all other factors (struts, my application, etc) kept the same. Thought you all might like to know. Stewart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in allowlinking on AIX?
I am definitely having an issue getting allowlinking=true to work in a Tomcat 5.0.28, JDK 1.4 on AIX 5.2 install. I have tried multiple scenarios using the following Host tag: Host name=host debug=0 appBase=/sys_apps_01/tomcat/test unpackWARs=true autoDeploy=true allowlinking=true deployXML=true / I can bring up the app but a request to /help, which is a symlink in the war to a directory outside of the tomcat applications directory, throws 404s. I also tried this: Context allowLinking=true path=infoview docbase=/sys_apps_01/tomcat/test/infoview override=true debug=9 / I changed to Host appbase to go to a webapps which is empty so I knew the context was definitely loading the unpacked war which includes the symlink. I still get a 404. The ChangeNotes for the 5.0.28 version states explicitely: --- Symlinking static resources: --- By default, Unix symlinks will not work when used in a web application to link resources located outside the web application root directory. This behavior is optional, and the allowLinking flag may be used to disable the check. Does anyone have symlinks working on 5.0.28? -- Ben Ricker He's just this guy, you know? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC5.5.9 Linux - shutdown port 8005 not bound BUG?
FYI - From TC bugzilla. So I added -pidfile jsvc.pid to my execution and am not killing the jsvc process not the JVM itself. --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 03:51 --- This is by design. With jsvc, you are supposed to shutdown Tomcat by: kill -TERM `cat $PIDFILE` As a result, jsvc doesn't tell Tomcat to listen on port 8005. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC5.5.9 Linux - shutdown port 8005 not bound BUG?
I've never had TC bind itself to 127.0.0.1:8005 to allow correct shutdown to occur. I've always had to kill the TC JVM. I use JSVC to be able to get a non-root userid. Does this affect how the shutdown port works ? My startup command line: ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -classpath :/opt/jakarta-tomcat-5.5.9/bin/bootstrap.jar:/opt/jakarta-tomcat-5.5.9/bin/commons-logging-api.jar -Dcatalina.base=/opt/jakarta-tomcat-5.5.9 -Dcatalina.home=/opt/jakarta-tomcat-5.5.9 -Djava.io.tmpdir=/opt/jakarta-tomcat-5.5.9/temp -outfile ./logs/catalina.out -errfile ./logs/catalina.err -user jakarta -Xmx2048M -Xms512M -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start $ netstat -tanp | grep 80 tcp0 0 :::127.0.0.1:8009 :::*LISTEN 4621/jsvc.exec tcp0 0 :::127.0.0.1:8080 :::*LISTEN 4621/jsvc.exec Should I file this as a bug ? -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC5.5.9 Linux - shutdown port 8005 not bound BUG?
From: Darryl L. Miles [mailto:[EMAIL PROTECTED] Subject: TC5.5.9 Linux - shutdown port 8005 not bound BUG? I've never had TC bind itself to 127.0.0.1:8005 to allow correct shutdown to occur. [...] $ netstat -tanp | grep 80 tcp0 0 :::127.0.0.1:8009 :::*LISTEN 4621/jsvc.exec There it is, on 8009 not 8005. Should I file this as a bug ? Depends - have you changed your server.xml at all? - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC5.5.9 Linux - shutdown port 8005 not bound BUG?
Peter Crowther wrote: From: Darryl L. Miles [mailto:[EMAIL PROTECTED] Subject: TC5.5.9 Linux - shutdown port 8005 not bound BUG? I've never had TC bind itself to 127.0.0.1:8005 to allow correct shutdown to occur. [...] $ netstat -tanp | grep 80 tcp0 0 :::127.0.0.1:8009 :::*LISTEN 4621/jsvc.exec There it is, on 8009 not 8005. Should I file this as a bug ? Depends - have you changed your server.xml at all? Sorry yes... 8009 is the apj13 port (was figuring you'd guess). My apache is using it locally I have added address=127.0.0.1 for ajp13 so its not exposed externally. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC5.5.9 Linux - shutdown port 8005 not bound BUG?
From: Darryl L. Miles [mailto:[EMAIL PROTECTED] Sorry yes... 8009 is the apj13 port (was figuring you'd guess). Doh. My bad - I use Tomcat directly, not via a front-end, so missed that one. Sorry Darryl (and anyone reading this thread in the archives). My apache is using it locally I have added address=127.0.0.1 for ajp13 so its not exposed externally. Makes sense. I'll crawl back into my hole now. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a bug? - Tomcat 5.5 HTTP post buffer contains trailing zeros
I'm a first time user of this forum. If I'm posting a question incorrectly, please advise (and accept my apologies). - Switched to Tomcat 5 from version 4. I'm using HTTPS to post a URL-encoded buffer which often exceeds 4K in length. On the Tomcat side, the received buffer has the correct size but all the bytes past 4096 are zero (the front 4K bytes are correct). Problem does not exist in Tomcat 4. I cannot find any configuration parameter that might address this issue other than 'maxPostSize'. The connector we use does not specify the maxPostSize (so it should default to 2MB according to documentation). Any suggestions? workaround? Is this a Tomcat bug? -Thanks in advance David
Jk's shared memory file - fixed? bug?
Ok, here's what happened. I'm running Apace 2.0 on Fedora Core 4, connecting
to Tomcat 5.0.28 with Jk 1.2.10. In my /etc/httpd/conf/httpd.conf, I had:
#Jk stuff
LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkLogStampFormat [%a %b %d %H:%M:%S %Y]
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkMount /jsp-examples/* ajp13w
JkMount /JSPWiki/* ajp13w
JkShmFile /etc/httpd/logs/jk-runtime-status
In /etc/httpd/conf/workers.properties, I had:
worker.list=wlb,jkstatus,ajp13w
worker.ajp13w.type=ajp13
worker.ajp13w.host=localhost
worker.ajp13w.port=8009
worker.wlb.type=lb
worker.wlb.balance_workers=ajp13w
worker.jkstatus.type=status
In /usr/share/tomcat5/conf/server.xml, I had
Listener
className=org.apache.jk.config.ApacheConfig
configHome=/usr/share/tomcat5
modJk=/usr/lib/httpd/modules/mod_jk.so
jkWorker=ajp13w
forwardAll=False
jkLog=/etc/httpd/logs/mod_jk.log
jkDebug=debug
noRoot=False
workersConfig=/etc/httpd/conf/workers.properties/
Connector port=8009
enableLookups=false redirectPort=8443 debug=0
protocol=AJP/1.3 /
Everything was working fine until the file /etc/httpd/logs/jk-runtime-status
reached the default JkShmSize limit of 64k. Once that happened, everything
died. I started getting errors in mod_jk.log like:
[error] init_jk::mod_jk.c (2347): Initializing
shm:/etc/httpd/logs/jk-runtime-status errno=13
errno=13 is typically a permission denied error, but my permissions were set
appropriately. I tried deleting the contents of
/etc/httpd/logs/jk-runtime-status to get below the size limit, but that
didn't help anything. I tried creating a new file /etc/httpd/logs/jk.shm
and pointing my config file there, but no success. I didn't get things
working again until I recompiled my mod_jk.so and reinstalled it. I checked
out the code in jk_shm.c that was giving me an error:
jk_shmem.hdr = (jk_shm_header_t *)calloc(1, jk_shmem.size);
if (!jk_shmem.hdr) {
JK_TRACE_EXIT(l);
return -1;
}
So, devs, why was this breaking? I've now set JkShmSize to 10M. But will it
break again once jk.shm reaches 10M?
Anybody out there?
-Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Caching static content - Bug in Filter implementation?
Hello I do some further analysis in this problem and got following result: Precondition: The filter manipulates the HTTP header when returning a static resource (e.g. image). HTTP 200 In case of a HTTP 200 (OK) result the header is not added when the doFilter method is like following: filterChain.doFilter(request, response); response.setHeader(name, value); In contrast to it works when the code is like following: response.setHeader(name, value); filterChain.doFilter(request, response); In other words: When returning a HTTP 200 (OK) I must set the header before forwarding the request to the next filter. HTTP 304 In this case it doesn't mention whether setting the header is before or after forwarding the request. Any comments? Jürgen Dufner - Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching static content - Bug in Filter implementation?
I think that's expected behaviour: You can't set headers after the response has been committed (more body data has been written to the outputstream than the buffer size). In the case of the 200 response code the call to filterChain.doFilter(...) actually serves the content. Setting of the header after this is too late. Jon [EMAIL PROTECTED] wrote: Hello I do some further analysis in this problem and got following result: Precondition: The filter manipulates the HTTP header when returning a static resource (e.g. image). HTTP 200 In case of a HTTP 200 (OK) result the header is not added when the doFilter method is like following: filterChain.doFilter(request, response); response.setHeader(name, value); In contrast to it works when the code is like following: response.setHeader(name, value); filterChain.doFilter(request, response); In other words: When returning a HTTP 200 (OK) I must set the header before forwarding the request to the next filter. HTTP 304 In this case it doesn't mention whether setting the header is before or after forwarding the request. Any comments? Jürgen Dufner - Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
I agree; it does the job :) There is an equivalent for IE: http://www.blunck.info/iehttpheaders.html Enjoy, Jon Woodchuck wrote: GB Developer, thanks so much for your suggestion, Live HTTP Headers is awesome! and my hunch was correct. the problem is Tomcat 5.5 does not produce any Content-Type information at all when serving back the .txt file. here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT as it clearly shows, the header info produced by Tomcat 5.5 does not have any Content-Type or even Content-Length. is this a bug that i should enter into BugZilla? or is this something that can be fixed via Tomcat configuration? thanks in advance, woodchuck --- GB Developer [EMAIL PROTECTED] wrote: (i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck I like using FireFox for debugging this type of thing, and the liveheaders plugin http://livehttpheaders.mozdev.org/ VERY handy. There is probably an IE equivalent of some sort, but haven't heard of a really good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
hi Chuck, thanks for the heads up. my Tomcat 4.1 and Tomcat 5.5 instances are separate and each are sitting on a different machine. as well, the actual URLs to these text files are different on each instance (so they are not requesting the same exact URL and should not be using cache for the second txt file request). anyhow i want to make sure of this, and i will retest again and clearing all cache each time before requesting the txt files. thanks, woodchuck --- Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Woodchuck [mailto:[EMAIL PROTECTED] Subject: RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?] here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT You've got apples and oranges here. The 1st response actually includes the text, whereas the 2nd just tells the browser to use what it has already cached. You need to try it again with the cache cleared prior to each request. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
awesome! thanks, Jon! woodchuck --- Jon Wingfield [EMAIL PROTECTED] wrote: I agree; it does the job :) There is an equivalent for IE: http://www.blunck.info/iehttpheaders.html Enjoy, Jon Woodchuck wrote: GB Developer, thanks so much for your suggestion, Live HTTP Headers is awesome! and my hunch was correct. the problem is Tomcat 5.5 does not produce any Content-Type information at all when serving back the .txt file. here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT as it clearly shows, the header info produced by Tomcat 5.5 does not have any Content-Type or even Content-Length. is this a bug that i should enter into BugZilla? or is this something that can be fixed via Tomcat configuration? thanks in advance, woodchuck --- GB Developer [EMAIL PROTECTED] wrote: (i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck I like using FireFox for debugging this type of thing, and the liveheaders plugin http://livehttpheaders.mozdev.org/ VERY handy. There is probably an IE equivalent of some sort, but haven't heard of a really good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
Indeed, thanks Jon. -Original Message- From: Woodchuck [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 10:15 AM To: Tomcat Users List Subject: Re: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?] awesome! thanks, Jon! woodchuck --- Jon Wingfield [EMAIL PROTECTED] wrote: I agree; it does the job :) There is an equivalent for IE: http://www.blunck.info/iehttpheaders.html Enjoy, Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla confirmed]
--- Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Woodchuck [mailto:[EMAIL PROTECTED] Subject: RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?] here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT You've got apples and oranges here. The 1st response actually includes the text, whereas the 2nd just tells the browser to use what it has already cached. You need to try it again with the cache cleared prior to each request. - Chuck alrighty, i've retested again. same results. each time prior to requesting the .txt file i cleared the cache of the browser just to be sure. header chunk generated by Tomcat 4.1 for a .txt file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 header chunk generated by Tomcat 5.5 for a .txt file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Content-Length: 1706 Date: Wed, 06 Jul 2005 16:20:26 GMT as the above shows, Tomcat 5.5 did not product the Content-Type: text/plain when it served back the .txt file to the browser. i also checked the Tomcat 5.5's conf/web.xml file and the mime mapping for txt files is there. mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping i will enter this to Bugzilla then. i'm guessing this is not likely to be a Tomcat 5.5 configuration issue although i'm not 100% sure. thanks to everyone who helped on this! woodchuck Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla confirmed]
woohoo! my first Bugzilla!! http://issues.apache.org/bugzilla/show_bug.cgi?id=35632 :D woodchuck --- Woodchuck [EMAIL PROTECTED] wrote: --- Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Woodchuck [mailto:[EMAIL PROTECTED] Subject: RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?] here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT You've got apples and oranges here. The 1st response actually includes the text, whereas the 2nd just tells the browser to use what it has already cached. You need to try it again with the cache cleared prior to each request. - Chuck alrighty, i've retested again. same results. each time prior to requesting the .txt file i cleared the cache of the browser just to be sure. header chunk generated by Tomcat 4.1 for a .txt file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 header chunk generated by Tomcat 5.5 for a .txt file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Content-Length: 1706 Date: Wed, 06 Jul 2005 16:20:26 GMT as the above shows, Tomcat 5.5 did not product the Content-Type: text/plain when it served back the .txt file to the browser. i also checked the Tomcat 5.5's conf/web.xml file and the mime mapping for txt files is there. mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping i will enter this to Bugzilla then. i'm guessing this is not likely to be a Tomcat 5.5 configuration issue although i'm not 100% sure. thanks to everyone who helped on this! woodchuck Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla confirmed]
Why does 4.x have: HTTP/1.1 200 Server: Microsoft-IIS/5.0 and 5.x have: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Are you fronting 4.x with IIS, and not 5.x? That is one config difference that you'll need to dispense with, in order to be fairly comparing the two. Mike Curwen header chunk generated by Tomcat 4.1 for a .txt file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain header chunk generated by Tomcat 5.5 for a .txt file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Date: Wed, 06 Jul 2005 16:20:26 GMT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla confirmed]
ack! you are right! thanks for noticing this. actually, they are both setup with JK connector redirecting from IIS to Tomcat (let me know if you want to know why one is different from the other.. it's a longer story) at any rate, let me test again by accessing both directly without using IIS (ie. port 8080). woodchuck --- GB Developer [EMAIL PROTECTED] wrote: Why does 4.x have: HTTP/1.1 200 Server: Microsoft-IIS/5.0 and 5.x have: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Are you fronting 4.x with IIS, and not 5.x? That is one config difference that you'll need to dispense with, in order to be fairly comparing the two. Mike Curwen header chunk generated by Tomcat 4.1 for a .txt file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain header chunk generated by Tomcat 5.5 for a .txt file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Date: Wed, 06 Jul 2005 16:20:26 GMT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla confirmed]
phew! (relief) the results are the same... both Tomcat version instances accessed directly via port 8080 (not through IIS). cleared cache each time prior to requesting TXT file. header chunk from Tomcat 4.1 when serving a TXT file: HTTP/1.1 200 OK ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Wed, 06 Jul 2005 18:54:08 GMT Server: Apache Coyote/1.0 header chunk from Tomcat 5.5 when serving a TXT file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Content-Length: 1706 Date: Wed, 06 Jul 2005 18:57:00 GMT thanks again, Mike, for noticing the IIS difference. i would hate to have filed my first Bugzilla falsely... -_- woodchuck --- Woodchuck [EMAIL PROTECTED] wrote: ack! you are right! thanks for noticing this. actually, they are both setup with JK connector redirecting from IIS to Tomcat (let me know if you want to know why one is different from the other.. it's a longer story) at any rate, let me test again by accessing both directly without using IIS (ie. port 8080). woodchuck --- GB Developer [EMAIL PROTECTED] wrote: Why does 4.x have: HTTP/1.1 200 Server: Microsoft-IIS/5.0 and 5.x have: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Are you fronting 4.x with IIS, and not 5.x? That is one config difference that you'll need to dispense with, in order to be fairly comparing the two. Mike Curwen header chunk generated by Tomcat 4.1 for a .txt file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain header chunk generated by Tomcat 5.5 for a .txt file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Date: Wed, 06 Jul 2005 16:20:26 GMT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESOLVED] RE: obscure tomcat 5.5 text file display bug? [NOT a Bugzilla]
sorry all, i did more testing and found the cause to be because the text files i was requesting had uppercase extensions... ie. TXT rather than txt. and as expected a work-around was to add the following mime-mapping in conf/web.xml: mime-mapping extensionTXT/extension mime-typetext/plain/mime-type /mime-mapping so sorry for the false alarm. :( sincerely, woodchuck -- needs to improve on testing Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
obscure tomcat 5.5 text file display bug?
hihi all, i'm having an obscure problem relating to the display of regular plain .txt files hosted withing Tomcat. on Tomcat 4.1 links to .txt files would diplay within the browser and the text files would preserve the text formatting (ie. spaces) *because* the text file contents would be displayed in plain text font (ie. fixed-width font) however in Tomcat 5.5 links to the same .txt files would also display within the browser, but the formatting is stripped because the text file contents are being displayed in a non-fixed width font (looks like courier true type) and all the spaces are stripped away. i'm using the same browser to test. and the only difference is the Tomcat version difference. does anyone know why this is happening? and more importantly how to fix it so that .txt files are displayed using fixed-width fonts in Tomcat 5.5? (i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug?
(i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck I like using FireFox for debugging this type of thing, and the liveheaders plugin http://livehttpheaders.mozdev.org/ VERY handy. There is probably an IE equivalent of some sort, but haven't heard of a really good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug?
thanks GB Developer! i will definitely give this a try! woodchuck --- GB Developer [EMAIL PROTECTED] wrote: (i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck I like using FireFox for debugging this type of thing, and the liveheaders plugin http://livehttpheaders.mozdev.org/ VERY handy. There is probably an IE equivalent of some sort, but haven't heard of a really good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug?
From: Woodchuck [mailto:[EMAIL PROTECTED] Subject: obscure tomcat 5.5 text file display bug? however in Tomcat 5.5 links to the same .txt files would also display within the browser, but the formatting is stripped because the text file contents are being displayed in a non-fixed width font (looks like courier true type) and all the spaces are stripped away. Can't help you with the missing spaces, but all forms of Courier are fixed-pitch fonts, by definition. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
GB Developer, thanks so much for your suggestion, Live HTTP Headers is awesome! and my hunch was correct. the problem is Tomcat 5.5 does not produce any Content-Type information at all when serving back the .txt file. here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT as it clearly shows, the header info produced by Tomcat 5.5 does not have any Content-Type or even Content-Length. is this a bug that i should enter into BugZilla? or is this something that can be fixed via Tomcat configuration? thanks in advance, woodchuck --- GB Developer [EMAIL PROTECTED] wrote: (i suspect it's the way Tomcat is telling the browser what type of file it's sending back... some kind of header info.. but i'm not sure how to go about debugging this) thx in advance, woodchuck I like using FireFox for debugging this type of thing, and the liveheaders plugin http://livehttpheaders.mozdev.org/ VERY handy. There is probably an IE equivalent of some sort, but haven't heard of a really good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?]
From: Woodchuck [mailto:[EMAIL PROTECTED] Subject: RE: obscure tomcat 5.5 text file display bug? [Bugzilla candidate?] here is the relevant header info from Tomcat 4.1: HTTP/1.x 200 OK Etag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 Date: Tue, 05 Jul 2005 20:59:46 GMT Server: Apache Coyote/1.0 Proxy-Connection: Keep-Alive and here is the relevant header info from Tomcat 5.5: If-Modified-Since: Sun, 03 Jul 2005 18:42:58 GMT If-None-Match: W/1706-1120416178619 HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Tue, 05 Jul 2005 19:57:35 GMT You've got apples and oranges here. The 1st response actually includes the text, whereas the 2nd just tells the browser to use what it has already cached. You need to try it again with the cache cleared prior to each request. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat JDK 1.5 and osx bug
Does anyone know how to get around this bug, I have the same problem, but I do not really want to remove the files in the extensions dir, too many files I use are affected from that one: http://lists.apple.com/archives/Java-dev/2005/May/msg00760.html Basically the bug is, that jasper assumes everything in the OSX jdk extensions dir is a zip and thus starts to choke on binaries. Does anyone know the fix for this one. I basically have the problem with the latest Tomcat as well. Werner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat JDK 1.5 and osx bug
Rebuild the files as zip? --- Werner Punz [EMAIL PROTECTED] wrote: Does anyone know how to get around this bug, I have the same problem, but I do not really want to remove the files in the extensions dir, too many files I use are affected from that one: http://lists.apple.com/archives/Java-dev/2005/May/msg00760.html Basically the bug is, that jasper assumes everything in the OSX jdk extensions dir is a zip and thus starts to choke on binaries. Does anyone know the fix for this one. I basically have the problem with the latest Tomcat as well. Werner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat JDK 1.5 and osx bug
not possible, since those are binaries and prebuilt by osx... Werner Mark Winslow wrote: Rebuild the files as zip? --- Werner Punz [EMAIL PROTECTED] wrote: Does anyone know how to get around this bug, I have the same problem, but I do not really want to remove the files in the extensions dir, too many files I use are affected from that one: http://lists.apple.com/archives/Java-dev/2005/May/msg00760.html Basically the bug is, that jasper assumes everything in the OSX jdk extensions dir is a zip and thus starts to choke on binaries. Does anyone know the fix for this one. I basically have the problem with the latest Tomcat as well. Werner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error count for http connector and localhost/ default context seem to increment for no reason: mbean bug?
whenever i access any web application deployed on tomcat, i notice that error count for localhost/ default[/] increments (request count also increments, not sure either if request count is suppose to increment..). http connector error count also increments. i'm checking these counter values via the tomcat manager web application as well as through my own servlet which accesses tomcat mbeans. even without deploying any of my own web applications (ie just after fresh install of tomcat and w/o changing any default configuration), if i go to the tomcat manager web application and continuously refresh it, it'll increment error count for localhost/ default[/] and for http8080 each time i do the refresh. there doesn't seem to be any error, so not sure why these counters are incrementing.. i've checked the logs in $CATALINA_HOME/logs, but don't see anything suspicious. here are the specific counters from http://myserver:8080/manager/jmxproxy (indicated by ): Name: Catalina:type=GlobalRequestProcessor,name=http8080 modelerType: org.apache.coyote.RequestGroupInfo requestCount: 44 maxTime: 616 bytesSent: 1595769 bytesReceived: 0 processingTime: 2609 errorCount: 20 Name: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none modelerType: org.apache.catalina.core.StandardWrapper engineName: Catalina eventProvider: false objectName: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none stateManageable: false statisticsProvider: false processingTime: 17 maxTime: 16 minTime: 0 requestCount: 19 errorCount: 19 loadTime: 0 classLoadTime: 0 any ideas? thanks. -annie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error count for http connector and localhost/ default context seem to increment for no reason: mbean bug?
The errors are almost certainly 404s in response to the browser's request for favicon.ico every time you request a page. The Tomcat distro does not include a favicon.ico hence the 404 response. Mark Annie Wang wrote: whenever i access any web application deployed on tomcat, i notice that error count for localhost/ default[/] increments (request count also increments, not sure either if request count is suppose to increment..). http connector error count also increments. i'm checking these counter values via the tomcat manager web application as well as through my own servlet which accesses tomcat mbeans. even without deploying any of my own web applications (ie just after fresh install of tomcat and w/o changing any default configuration), if i go to the tomcat manager web application and continuously refresh it, it'll increment error count for localhost/ default[/] and for http8080 each time i do the refresh. there doesn't seem to be any error, so not sure why these counters are incrementing.. i've checked the logs in $CATALINA_HOME/logs, but don't see anything suspicious. here are the specific counters from http://myserver:8080/manager/jmxproxy (indicated by ): Name: Catalina:type=GlobalRequestProcessor,name=http8080 modelerType: org.apache.coyote.RequestGroupInfo requestCount: 44 maxTime: 616 bytesSent: 1595769 bytesReceived: 0 processingTime: 2609 errorCount: 20 Name: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none modelerType: org.apache.catalina.core.StandardWrapper engineName: Catalina eventProvider: false objectName: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none stateManageable: false statisticsProvider: false processingTime: 17 maxTime: 16 minTime: 0 requestCount: 19 errorCount: 19 loadTime: 0 classLoadTime: 0 any ideas? thanks. -annie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error count for http connector and localhost/ default context seem to increment for no reason: mbean bug?
thanks mark! it's working okay now w/the favicon.ico. -annie On 7/1/05, Mark Thomas [EMAIL PROTECTED] wrote: The errors are almost certainly 404s in response to the browser's request for favicon.ico every time you request a page. The Tomcat distro does not include a favicon.ico hence the 404 response. Mark Annie Wang wrote: whenever i access any web application deployed on tomcat, i notice that error count for localhost/ default[/] increments (request count also increments, not sure either if request count is suppose to increment..). http connector error count also increments. i'm checking these counter values via the tomcat manager web application as well as through my own servlet which accesses tomcat mbeans. even without deploying any of my own web applications (ie just after fresh install of tomcat and w/o changing any default configuration), if i go to the tomcat manager web application and continuously refresh it, it'll increment error count for localhost/ default[/] and for http8080 each time i do the refresh. there doesn't seem to be any error, so not sure why these counters are incrementing.. i've checked the logs in $CATALINA_HOME/logs, but don't see anything suspicious. here are the specific counters from http://myserver:8080/manager/jmxproxy (indicated by ): Name: Catalina:type=GlobalRequestProcessor,name=http8080 modelerType: org.apache.coyote.RequestGroupInfo requestCount: 44 maxTime: 616 bytesSent: 1595769 bytesReceived: 0 processingTime: 2609 errorCount: 20 Name: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none modelerType: org.apache.catalina.core.StandardWrapper engineName: Catalina eventProvider: false objectName: Catalina:j2eeType=Servlet,name=default,WebModule=//localhost/,J2EEApplication=none,J2EEServer=none stateManageable: false statisticsProvider: false processingTime: 17 maxTime: 16 minTime: 0 requestCount: 19 errorCount: 19 loadTime: 0 classLoadTime: 0 any ideas? thanks. -annie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk / Apache bug - max transfer of 496kbytes
- When serving files larger than 496kbytes, the download always stops at 496k, and I get a child segfault in apache error_log. No usefull info in mod_jk.log - Using the tomcat-http connector works no problem. - Going through Apache+ mod_jk works no problem for normal web pages (small elements). - It doesn't seem related to mod_ssl because the bug is here in http and https. Could that come from a configuration issue or is it a bug? It seems to be a too obvious bug, although it's impossible to find it anywhere on google or what... I hope someone already had the problem! Thanks. This is a RHEL 4 with these: Apache/2.0.54 (Unix) DAV/2 mod_ssl/2.0.49 OpenSSL/0.9.7a mod_jk/1.2.13 Tomcat 5.5.9 We have the exact same problem with RHEL3 JBoss 3.2.5 Apache/2.0.52 (Unix) PHP/5.0.2 DAV/2 mod_ssl/2.0.49 OpenSSL/0.9.7a mod_jk2/2.0.4 In both cases Apache is prefork with mod_jk.so dynamically linked. I tried compiling mod_jk with --enable-prefork but it doesn't change anything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk / Apache bug - max transfer of 496kbytes
Oups sorry for that, it was due to a bug in mod_bandwidth, so not really anything to do with you guys. For some reason the rule to limit bandwidth on files larger than 500k produced a segfault. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug in request parameter decoding
In Tomcat 5.5.9, class org.apache.catalina.connector.Request, lines 2307-2312, the charset used to decode request parameters is identified as org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING, i.e. ISO-8859-1. According to http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars request parameters are encoded in UTF-8. A simple form test suffices to confirm that my user-agents (Camino and Safari) correctly encode both POST and GET request parameters in UTF-8. It seems this may be a long-standing bug in Tomcat, preventing the posting of non-ASCII text from standards-compliant user-agents. I can't find anything matching in Bugzilla though. Is there a good reason for using Latin-1 here? -- Chris Burdess - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in request parameter decoding
The HTTP spec is vague. It has many references to ISO8859-1. IIRC, there is a connector option to decode parameters as UTF-8. -Tim Chris Burdess wrote: In Tomcat 5.5.9, class org.apache.catalina.connector.Request, lines 2307-2312, the charset used to decode request parameters is identified as org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING, i.e. ISO-8859-1. According to http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars request parameters are encoded in UTF-8. A simple form test suffices to confirm that my user-agents (Camino and Safari) correctly encode both POST and GET request parameters in UTF-8. It seems this may be a long-standing bug in Tomcat, preventing the posting of non-ASCII text from standards-compliant user-agents. I can't find anything matching in Bugzilla though. Is there a good reason for using Latin-1 here? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible bug in request parameter decoding
From: Chris Burdess [mailto:[EMAIL PROTECTED] Subject: Possible bug in request parameter decoding According to http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars request parameters are encoded in UTF-8. Well, that's not quite how I read it. By definition (RFC 2396), URIs are not supposed to contain non-ASCII values. The HTML 4.0 appendix referred to above makes the somewhat contradictory suggestion to use UTF-8 to handle non-ASCII, ignoring the fact that UTF-8 encoding produces byte values outside of the ASCII range. Since the discussion in this area of the appendix is related to browser, not server, behavior, it's not really relevant to what Tomcat should do when it encounters illegal (non-ASCII) values in a URI supplied on a browser request. In any event, as Tim noted, you can configure how the connector should interpret non-ASCII bytes by specifying a value for URIEncoding in your server.xml file. I suspect that the default value of ISO-8859-1 is there largely for historical reasons, since it was the predominant encoding before UTF-8 became popular. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.13 logging - bug in mod_jk?
Hi. After upgrading mod_jk to 1.2.13 I'm observing a strange change in my mo_jk.log. I'm almost sure, that not all entries appear in my log, there is an extra empty line between every log line and dates displayed in log entries are not ordered, as they were before upgrade, e.g.: [Wed Jun 15 20:15:53 2005] inst1 0.023552 3526 my.host.pl 443 /servlet/document_view_autor_statement.xml [Wed Jun 15 20:15:55 2005] inst1 0.011634 3690 my.host.pl 443 /servlet/177214.xml [Wed Jun 15 20:16:16 2005] inst1 0.035606 4455 my.host.pl 443 /servlet/scheduler_list.xml [Wed Jun 15 20:16:42 2005] inst1 0.023546 3484 my.host.pl 443 /servlet/document_view_session_schedule.xml [Wed Jun 15 20:16:54 2005] inst1 0.081832 4137 my.host.pl 443 /servlet/message.xml [Wed Jun 15 20:21:22 2005] inst1 0.229055 7964 my.host.pl 443 /servlet/desk.xml [Wed Jun 15 20:21:47 2005] inst1 0.366541 7059 my.host.pl 443 /servlet/desk.xml [Wed Jun 15 19:59:04 2005] inst1 0.110294 3619 my.host.pl 443 /servlet/cons_top.xml [Wed Jun 15 19:59:04 2005] inst1 0.002093 2071 my.host.pl 443 /servlet/servlets.JavaScriptConfiguration [Wed Jun 15 20:00:00 2005] inst1 0.234826 12577 my.host.pl 443 /servlet/catalog_list.xml [Wed Jun 15 20:00:05 2005] inst1 0.143422 12577 my.host.pl 443 /servlet/catalog_list.xml [Wed Jun 15 20:00:15 2005] inst1 0.132816 12577 my.host.pl 443 /servlet/catalog_list.xml Is this a bug? My config is: a few virtualhosts, in main section of httpd.conf only JkWorkersFile directive, in every virtualhost section logging defined by: JkLogFile /var/log/apache/mod_jk.log JkLogLevel info JkRequestLogFormat %w %T %b %V %p %U I was using mod_jk 1.2.6 before and mod_jk.log looked fine. This strange behaviour I'm observing with 1.2.13 and 1.2.10. Version 1.2.8 generates a log with lines like [Wed Jun 15 19:52:00 2005] [info] jk_handler::mod_jk.c (1691): Service returned error=1 with status=200 for worker=inst1 instead of empty lines added by 1.2.13. Is there a known issue with this logging problem? Richard. -- First they ignore you. Then they laugh at you. Then they fight you. Then you win. - Mohandas Gandhi. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is cancelled SSL connection bug fixed in Tomcat 4.1.31?
Mike, Having I have had a look at the bug report and the message from Tomcat user and have found the cvs commit that fixes the problem. http://marc.theaimsgroup.com/?l=tomcat-devm=104142933517556w=2 This fix is included in 4.1.19 onwards and all 5.0.x and 5.5.x releases. HTH, Mark Mike Meehan wrote: Hi, Does anyone out there know if the Cancelled SSL connection cause Tomcat to stumble bug is fixed for Tomcat 4.1.31? The bug can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=17323 I can reproduce this issue with 4.1.18 but have yet to be able to reproduce it with 4.1.31. I don't want to assume that its fixed simply because I haven't been able to reproduce it. I'm comparing the two versions of Tomcat using the same: physical server, web app, connector settings, keystore. I also saw a mailing list thread (http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg79212.htm l) that suggests the problem is in PoolTcpEndPoint.java. I looked at this source and compared between the two versions. The TcpWorkerThread.runIt() method was significantly reworked since 4.1.18 so I can't tell for sure if the problem has been eliminated. (if this is in fact where the problem existed) If it has not been fixed in 4.1.31, can anyone confirm if this is fixed in 5.0? Thanks, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is cancelled SSL connection bug fixed in Tomcat 4.1.31?
Hi, Does anyone out there know if the Cancelled SSL connection cause Tomcat to stumble bug is fixed for Tomcat 4.1.31? The bug can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=17323 I can reproduce this issue with 4.1.18 but have yet to be able to reproduce it with 4.1.31. I don't want to assume that its fixed simply because I haven't been able to reproduce it. I'm comparing the two versions of Tomcat using the same: physical server, web app, connector settings, keystore. I also saw a mailing list thread (http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg79212.htm l) that suggests the problem is in PoolTcpEndPoint.java. I looked at this source and compared between the two versions. The TcpWorkerThread.runIt() method was significantly reworked since 4.1.18 so I can't tell for sure if the problem has been eliminated. (if this is in fact where the problem existed) If it has not been fixed in 4.1.31, can anyone confirm if this is fixed in 5.0? Thanks, Mike
Surprised with this behaviour. Is this a bug ?
Hello,
From a servlet deployed in tomcat I am getting the
request parameter map by calling getParameterMap()
then using reflection calling a Class say Sub that
has a method construct(HashMap requestMap). The
method is called properly but surprisingly I am
getting InvocationTargetException-ClassCastException
when I try to read the parameter from the map.
Following is the code.
Code in Class called from Servlet
// Note that the map instance is an instance of
org.apache.catalina.util.ParameterMap
Method method = cls.getMethod(constructSql, new
Class[]{request.getParameterMap().getClass().getSuperclass()});
query = (String) method.invoke(obj, new
Object[]{request.getParameterMap()});
Code from Sub
public String construct(HashMap requestMap) {
log.info(~construct());
log.info(10);
Object obj = requestMap.get(ParamKey);
log.info(obj.getClass());
log.info(10.1);
String str = (String) obj;
log.info(str);
log.info(10.2);
return ;
}
Console Output ==
INFO [http-8080-Processor25] SearchCodeQuery -
~construct()
INFO [http-8080-Processor25] SearchCodeQuery - 10
INFO [http-8080-Processor25] SearchCodeQuery -
class [Ljava.lang.String;
INFO [http-8080-Processor25] SearchCodeQuery -
10.1
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.reflect.InvocationTargetException
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.ClassCastException: [Ljava.lang.String;
Is it because that the instance is actually
org.apache.catalina.util.ParameterMap and I am trying
to call get() over that instance ? But ParameterMap
itself does not have any implementation of get() it
takes that from its superclass i.e. HashMap.
Is it not supposed to run. When you can see in the
log that the value is a String object and a similar
java application using LinkedHashMap and HashMap runs
without any hiccups ?
I am using JDK:1.5.0_03, Tomcat:5.5.9
Thanks in advance
Nitin
__
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surprised with this behaviour. Is this a bug ?
Not sure I follow all your explanation, and I think you haven't shown us
enough of your code to know what's going on, but what is the method
signature for method.invoke()? You're passing it an Object and an Object[].
The former (obj) is returned from requestMap.get(). Assuming requestMap
is a Map object, the get() method returns an object of whatever type you
pit into it, and perhaps you should downcast to this type.
The second parameter you're passing into method.invoke() is an Object
that has been upcasted from the return value of
request.getParameterMap(). That method returns an object of type
java.util.Map.
In sum, I would look at the method signature for method.invoke(), and
cast your arguments in that method call as needed.
-Mark
nitin dubey wrote:
Hello,
From a servlet deployed in tomcat I am getting the
request parameter map by calling getParameterMap()
then using reflection calling a Class say Sub that
has a method construct(HashMap requestMap). The
method is called properly but surprisingly I am
getting InvocationTargetException-ClassCastException
when I try to read the parameter from the map.
Following is the code.
Code in Class called from Servlet
// Note that the map instance is an instance of
org.apache.catalina.util.ParameterMap
Method method = cls.getMethod(constructSql, new
Class[]{request.getParameterMap().getClass().getSuperclass()});
query = (String) method.invoke(obj, new
Object[]{request.getParameterMap()});
Code from Sub
public String construct(HashMap requestMap) {
log.info(~construct());
log.info(10);
Object obj = requestMap.get(ParamKey);
log.info(obj.getClass());
log.info(10.1);
String str = (String) obj;
log.info(str);
log.info(10.2);
return ;
}
Console Output ==
INFO [http-8080-Processor25] SearchCodeQuery -
~construct()
INFO [http-8080-Processor25] SearchCodeQuery - 10
INFO [http-8080-Processor25] SearchCodeQuery -
class [Ljava.lang.String;
INFO [http-8080-Processor25] SearchCodeQuery -
10.1
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.reflect.InvocationTargetException
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.ClassCastException: [Ljava.lang.String;
Is it because that the instance is actually
org.apache.catalina.util.ParameterMap and I am trying
to call get() over that instance ? But ParameterMap
itself does not have any implementation of get() it
takes that from its superclass i.e. HashMap.
Is it not supposed to run. When you can see in the
log that the value is a String object and a similar
java application using LinkedHashMap and HashMap runs
without any hiccups ?
I am using JDK:1.5.0_03, Tomcat:5.5.9
Thanks in advance
Nitin
__
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug?: JspCompilationContext.createCompiler(JspCompilationContext.java:220)
I answered my own question. I was not including an important .jar file in
the CLASSPATH.
At 08:49 PM 5/27/2005, you wrote:
I am trying to embed tomcat in an application. I am using Sun Java 1.5
and Tomcat 5.5.9. During the tomcat startup, I receive the following error:
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:220)
I looked at the JspCompilationContext.java code and found the block where
the NullPointerException occurs:
/**
* Create a Compiler object based on some init param data. This
* is not done yet. Right now we're just hardcoding the actual
* compilers that are created.
*/
public Compiler createCompiler() throws JasperException {
if (jspCompiler != null ) {
return jspCompiler;
}
jspCompiler = null;
if (options.getCompiler() == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.JDTCompiler);
if (jspCompiler == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.AntCompiler);
}
} else {
jspCompiler =
createCompiler(org.apache.jasper.compiler.AntCompiler);
if (jspCompiler == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.JDTCompiler);
}
}
jspCompiler.init(this, jsw);
return jspCompiler;
}
private static Compiler createCompiler(String className) {
Compiler compiler = null;
try {
compiler = (Compiler) Class.forName(className).newInstance();
} catch (Throwable t) {
// Log ?
// FIXME: log
}
return compiler;
}
I was somewhat concerned by the comments within the block. I thought I
would ask if there is an open bug in this area before I continued picking
apart my own code. Is this a bug in Tomcat? If so, is there a
work-around? If not, how should I proceed?
Thank you in advance,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug?: JspCompilationContext.createCompiler(JspCompilationContext.java:220)
I am trying to embed tomcat in an application. I am using Sun Java 1.5 and
Tomcat 5.5.9. During the tomcat startup, I receive the following error:
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:220)
I looked at the JspCompilationContext.java code and found the block where
the NullPointerException occurs:
/**
* Create a Compiler object based on some init param data. This
* is not done yet. Right now we're just hardcoding the actual
* compilers that are created.
*/
public Compiler createCompiler() throws JasperException {
if (jspCompiler != null ) {
return jspCompiler;
}
jspCompiler = null;
if (options.getCompiler() == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.JDTCompiler);
if (jspCompiler == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.AntCompiler);
}
} else {
jspCompiler =
createCompiler(org.apache.jasper.compiler.AntCompiler);
if (jspCompiler == null) {
jspCompiler =
createCompiler(org.apache.jasper.compiler.JDTCompiler);
}
}
jspCompiler.init(this, jsw);
return jspCompiler;
}
private static Compiler createCompiler(String className) {
Compiler compiler = null;
try {
compiler = (Compiler) Class.forName(className).newInstance();
} catch (Throwable t) {
// Log ?
// FIXME: log
}
return compiler;
}
I was somewhat concerned by the comments within the block. I thought I
would ask if there is an open bug in this area before I continued picking
apart my own code. Is this a bug in Tomcat? If so, is there a
work-around? If not, how should I proceed?
Thank you in advance,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
logging problem (bug?)
I am running tomcat 5.5 on a java 1.5 vm. I want to turn tomcat logging (via java.util logging) up for debugging but if I set everything to FINEST there is so much logging that It takes far too much time to start up. I am trying to trim down some of the excess logging to make this more manageable. One of the packages producing excessive logs is org.apache.tomcat.util.digester. I am trying to turn this package down, but found that I cannot affect it by turning down the logger of that name with the following line in $JAVA_HOME/jre/lib/logging.properties: org.apache.tomcat.util.digester.level = INFO Rather, the only logger I have found that affects it is org.apache.commons. The problem is that this then blocks all of the commons logging which I want. Is there a way that I can just turn down the logging on the tomcat.util.digester package? Is this a bug?
Logging in servlet/jsp not working via java.uil.logging.Logger.global - BUG?
If you have a servlet/jsp which uses java.util.logging. Logger.global and use the global logger, the output seems to go nowhere. For example the following jsp page only logs printed. % java.util.logging.Logger.global.severe(not printed); java.util.logging.Logger.getLogger(foo).severe(printed); % FYI, this is with Tomcat 5.5.9 using the default settings. As you can imagine, this is a little disturbing! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 11645 reported in Tomcat 4.0
This issue applies to the deprecated http/1.1 connector which is not even shipped with 5.5x 5.5.x uses the coyote connector which does not have this issue. Mark Vineet Chopra wrote: Hi, This is regarding Bug 11645 reported in Tomcat 4.0 which I came across in http://issues.apache.org/bugzilla/show_bug.cgi?id=11645. This is the same exception which I am facing when trying to close an underlying BufferedReader created using InputStreamReader of a ServletInputStream. I would like to know whether this problem has been fixed in current Tomcat version 5.x. Please update me regarding the same. Regards, Vineet Chopra. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 11645 reported in Tomcat 4.0
Thanks Thomas for the valuable inputs. On Sun, 27 Mar 2005 10:48:08 +0100, Mark Thomas [EMAIL PROTECTED] wrote: This issue applies to the deprecated http/1.1 connector which is not even shipped with 5.5x 5.5.x uses the coyote connector which does not have this issue. Mark Vineet Chopra wrote: Hi, This is regarding Bug 11645 reported in Tomcat 4.0 which I came across in http://issues.apache.org/bugzilla/show_bug.cgi?id=11645. This is the same exception which I am facing when trying to close an underlying BufferedReader created using InputStreamReader of a ServletInputStream. I would like to know whether this problem has been fixed in current Tomcat version 5.x. Please update me regarding the same. Regards, Vineet Chopra. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug 11645 reported in Tomcat 4.0
Hi, This is regarding Bug 11645 reported in Tomcat 4.0 which I came across in http://issues.apache.org/bugzilla/show_bug.cgi?id=11645. This is the same exception which I am facing when trying to close an underlying BufferedReader created using InputStreamReader of a ServletInputStream. I would like to know whether this problem has been fixed in current Tomcat version 5.x. Please update me regarding the same. Regards, Vineet Chopra. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No bug with Delegate !
Hi, Sorry but my preceding analysis was false : I have a problem but NOT with the delegate. So, I reexplain the case : 1- I have $CATALINA_HOME/common/lib/mysql-connector-java-2.0.14-bin.jar $CATALINA_HOME/common/lib/naming-factory-dbcp.jar 2- I have a war with WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar in my test, I do : Class driver = Class.forName(org.gjt.mm.mysql.Driver); URL ressource = driver.getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); out.println( ClassForname==+ressource ); If, in my Context element, I put a Loader with delegate=false (the default), it prints : ClassForname==jar:file:/usr/local/tomcat/webapps/myContext/WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar!/org/gjt/mm/mysql/Driver.class If I put delegate=true, it prints : ClassForname==jar:file:/usr/local/tomcat/common/lib/mysql-connector-java-2.0.14-bin.jar!/org/gjt/mm/mysql/Driver.class So delegate works as it is expected. My problem is that, in my first test, I did : Context ctx = new InitialContext(); DataSource dataSource = (DataSource)ctx.lookup(java:/comp/env/jdbc/myDB); URL ressource = dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); out.println( JndiForname==+ressource ); and, in this case, I always have : ClassForname==jar:file:/usr/local/tomcat/common/lib/mysql-connector-java-2.0.14-bin.jar!/org/gjt/mm/mysql/Driver.class So, for now, I don't find the solution to use the Driver inside the war :-( But this is another problem... Sorry Remy for the bad bug report. On Wed, 23 Mar 2005 17:26:34 +0100 Lionel Farbos [EMAIL PROTECTED] wrote: Hi Simon, I wanted to use this flag because, in my $CATALINA_HOME/common/lib, I have mysql-connector-java-2.0.14-bin.jar but, in some wars, I have WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar and in other wars, I don't have any Driver Mysql So, I'd want the war_WEB-INF/lib/Mysql_jar to be taken BEFORE the common/lib/Mysql_jar one when it is possible and the common/lib/Mysql_jar to be taken in other cases. So I tried to put Loader className=org.apache.catalina.loader.WebappLoader delegate=false / or Loader className=org.apache.catalina.loader.WebappLoader delegate=true / in my Context.xml But it is always the common/lib/jar one which is taken :-(( I don't know if it is a bug or a bad config from me If a Tomcat Developer can say to me what I am wrong ... Note : To confirm the Driver version, I print : dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); Cheers On Sat, 19 Mar 2005 17:44:40 +1300 Simon Kitching [EMAIL PROTECTED] wrote: Hi, I see here that there is an option for the webapp-specific classloader to use parent-first classloading instead of the (default) child-first classloading. Can someone suggest why this might be useful? Clearly someone thought so, but I can't see any point in it. It is in catalina since version 1.1 (committer: Remy Maucherat). See delegate option in this page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html Using this option makes life exceedingly complicated for some libs like commons-beanutils and commons-logging, so I would like to know under what conditions someone might enable this feature. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No bug with Delegate !
If you want to use the .jar in WEB-INF/lib, you'll also have to implement your own DBCP pool for the app. That can be done in a ServletContextListener in servlet spec 2.4. When the container instantiates the pool, it's always going to use the jar in common/lib (or possibly shared/lib) because it's instantiated at the container level. At that level there is no awareness of you apps classloader. --David Lionel Farbos wrote: Hi, Sorry but my preceding analysis was false : I have a problem but NOT with the delegate. So, I reexplain the case : 1- I have $CATALINA_HOME/common/lib/mysql-connector-java-2.0.14-bin.jar $CATALINA_HOME/common/lib/naming-factory-dbcp.jar 2- I have a war with WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar in my test, I do : Class driver = Class.forName(org.gjt.mm.mysql.Driver); URL ressource = driver.getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); out.println( ClassForname==+ressource ); If, in my Context element, I put a Loader with delegate=false (the default), it prints : ClassForname==jar:file:/usr/local/tomcat/webapps/myContext/WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar!/org/gjt/mm/mysql/Driver.class If I put delegate=true, it prints : ClassForname==jar:file:/usr/local/tomcat/common/lib/mysql-connector-java-2.0.14-bin.jar!/org/gjt/mm/mysql/Driver.class So delegate works as it is expected. My problem is that, in my first test, I did : Context ctx = new InitialContext(); DataSource dataSource = (DataSource)ctx.lookup(java:/comp/env/jdbc/myDB); URL ressource = dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); out.println( JndiForname==+ressource ); and, in this case, I always have : ClassForname==jar:file:/usr/local/tomcat/common/lib/mysql-connector-java-2.0.14-bin.jar!/org/gjt/mm/mysql/Driver.class So, for now, I don't find the solution to use the Driver inside the war :-( But this is another problem... Sorry Remy for the bad bug report. On Wed, 23 Mar 2005 17:26:34 +0100 Lionel Farbos [EMAIL PROTECTED] wrote: Hi Simon, I wanted to use this flag because, in my $CATALINA_HOME/common/lib, I have mysql-connector-java-2.0.14-bin.jar but, in some wars, I have WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar and in other wars, I don't have any Driver Mysql So, I'd want the war_WEB-INF/lib/Mysql_jar to be taken BEFORE the common/lib/Mysql_jar one when it is possible and the common/lib/Mysql_jar to be taken in other cases. So I tried to put Loader className=org.apache.catalina.loader.WebappLoader delegate=false / or Loader className=org.apache.catalina.loader.WebappLoader delegate=true / in my Context.xml But it is always the common/lib/jar one which is taken :-(( I don't know if it is a bug or a bad config from me If a Tomcat Developer can say to me what I am wrong ... Note : To confirm the Driver version, I print : dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); Cheers On Sat, 19 Mar 2005 17:44:40 +1300 Simon Kitching [EMAIL PROTECTED] wrote: Hi, I see here that there is an option for the webapp-specific classloader to use parent-first classloading instead of the (default) child-first classloading. Can someone suggest why this might be useful? Clearly someone thought so, but I can't see any point in it. It is in catalina since version 1.1 (committer: Remy Maucherat). See delegate option in this page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html Using this option makes life exceedingly complicated for some libs like commons-beanutils and commons-logging, so I would like to know under what conditions someone might enable this feature. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug with Delegate ?
Hi Simon, I wanted to use this flag because, in my $CATALINA_HOME/common/lib, I have mysql-connector-java-2.0.14-bin.jar but, in some wars, I have WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar and in other wars, I don't have any Driver Mysql So, I'd want the war_WEB-INF/lib/Mysql_jar to be taken BEFORE the common/lib/Mysql_jar one when it is possible and the common/lib/Mysql_jar to be taken in other cases. So I tried to put Loader className=org.apache.catalina.loader.WebappLoader delegate=false / or Loader className=org.apache.catalina.loader.WebappLoader delegate=true / in my Context.xml But it is always the common/lib/jar one which is taken :-(( I don't know if it is a bug or a bad config from me If a Tomcat Developer can say to me what I am wrong ... Note : To confirm the Driver version, I print : dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); Cheers On Sat, 19 Mar 2005 17:44:40 +1300 Simon Kitching [EMAIL PROTECTED] wrote: Hi, I see here that there is an option for the webapp-specific classloader to use parent-first classloading instead of the (default) child-first classloading. Can someone suggest why this might be useful? Clearly someone thought so, but I can't see any point in it. It is in catalina since version 1.1 (committer: Remy Maucherat). See delegate option in this page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html Using this option makes life exceedingly complicated for some libs like commons-beanutils and commons-logging, so I would like to know under what conditions someone might enable this feature. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug with Delegate ?
Hi Simon, I wanted to use this flag because, in my $CATALINA_HOME/common/lib, I have mysql-connector-java-2.0.14-bin.jar but, in some wars, I have WEB-INF/lib/mysql-connector-java-3.0.15-ga-bin.jar WEB-INF/lib/naming-factory-dbcp.jar and in other wars, I don't have any Driver Mysql So, I'd want the war_WEB-INF/lib/Mysql_jar to be taken BEFORE the common/lib/Mysql_jar one when it is possible and the common/lib/Mysql_jar to be taken in other cases. So I tried to put Loader className=org.apache.catalina.loader.WebappLoader delegate=false / or Loader className=org.apache.catalina.loader.WebappLoader delegate=true / in my Context.xml But it is always the common/lib/jar one which is taken :-(( I don't know if it is a bug or a bad config from me If a Tomcat Developer can say to me what I am wrong ... Note : To confirm the Driver version, I print : dataSource.getClass().getClassLoader().getResource(org/gjt/mm/mysql/Driver.class); Cheers On Sat, 19 Mar 2005 17:44:40 +1300 Simon Kitching [EMAIL PROTECTED] wrote: Hi, I see here that there is an option for the webapp-specific classloader to use parent-first classloading instead of the (default) child-first classloading. Can someone suggest why this might be useful? Clearly someone thought so, but I can't see any point in it. It is in catalina since version 1.1 (committer: Remy Maucherat). See delegate option in this page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html Using this option makes life exceedingly complicated for some libs like commons-beanutils and commons-logging, so I would like to know under what conditions someone might enable this feature. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validator 0.5.5 doesn't have this bug anymore (Re: OT - Beware of Firefox + HTML Validator Extension)
Good point, I stumbled upon this, too. Thinking this was a Firefox bug, I even filed a bug report against it. Note: The latest version of HTML Validator (0.5.5) fixed this bug. At least no more problems in my case. greetings, Christoph Harry Mantheakis wrote: I thought I should share this with any web-app developers on this list. I recently installed the HTML Validator extension in Firefox. This caused me no-end of troubles because HTML Validator (on Windows XP) was firing off rogue secondary requests (!) whenever I was selecting any of my form submit buttons. Then I read this blog entry, and realised who the culprit was: http://ronin.keyboardsamurais.de/evil_firefox_extensions.html I uninstalled the HTML Validator extension and everything was fine again. Kudos to the LiveHTTPHeaders extension which showed the double requests being generated - though at first it made me think I had a faulty mouse! http://livehttpheaders.mozdev.org/ HTH somebody who may be pulling their hair out. Harry Mantheakis London, UK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validator 0.5.5 doesn't have this bug anymore (Re: OT - Beware of Firefox + HTML Validator Extension)
Christoph Kutzinski wrote: Good point, I stumbled upon this, too. Thinking this was a Firefox bug, I even filed a bug report against it. Note: The latest version of HTML Validator (0.5.5) fixed this bug. At least no more problems in my case. greetings, Christoph Harry Mantheakis wrote: I thought I should share this with any web-app developers on this list. I recently installed the HTML Validator extension in Firefox. This caused me no-end of troubles because HTML Validator (on Windows XP) was firing off rogue secondary requests (!) whenever I was selecting any of my form submit buttons. Then I read this blog entry, and realised who the culprit was: http://ronin.keyboardsamurais.de/evil_firefox_extensions.html I uninstalled the HTML Validator extension and everything was fine again. Kudos to the LiveHTTPHeaders extension which showed the double requests being generated - though at first it made me think I had a faulty mouse! http://livehttpheaders.mozdev.org/ HTH somebody who may be pulling their hair out. Harry Mantheakis London, UK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I couldn't even install the latest version of Firefox on RH 8.0 because it couldn't find some libraries. I googled the problem and found a post stating that some of the contributing developers weren't developing on a fresh image and were inposing specific file permissions on those who downloaded firefox. Does this make sense? I just left it at that and continued to use an older version. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RequestDispatcher.forward: a bug?
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another servlet :
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher = ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that ctx.getRequestDispatcher(...)
returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT, if it
is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
Thanks in advance.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward: a bug?
getRequestDispatcher() will always return a servlet. (The default servlet)
-Tim
Lionel Farbos wrote:
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another servlet :
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher = ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that ctx.getRequestDispatcher(...)
returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT, if it is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward: a bug?
Yes : it's my problem.
ctx.getContext(/myNewContext) always return a Context (even if myNewContext
is not deployed :-(
and
ctx.getRequestDispatcher(/myNewServlet) always return a dispatcher (even if
myNewServlet is not here :-(
So How can I avoid a 404 ?
On Wed, 02 Mar 2005 10:24:37 -0500
Tim Funk [EMAIL PROTECTED] wrote:
getRequestDispatcher() will always return a servlet. (The default servlet)
-Tim
Lionel Farbos wrote:
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another servlet
:
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher = ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that ctx.getRequestDispatcher(...)
returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT,
if it is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
?? Yet Another Tomcat Documentation Bug ??
If you go here: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html#Automatic%20Application%20Deployment The first bullet point starts out: Any XML file in the $CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed... I believe this should say, Any XML file in the $CATALINA_BASE/conf/[engine_name]/[host_name] directory is assumed... Is that right? It's another typo, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ?? Yet Another Tomcat Documentation Bug ??
From: Tony LaPaso [mailto:[EMAIL PROTECTED] Subject: ?? Yet Another Tomcat Documentation Bug ?? The first bullet point starts out: Any XML file in the $CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed... I believe this should say, Any XML file in the $CATALINA_BASE/conf/[engine_name]/[host_name] directory is assumed... Is that right? It's another typo, right? There's a fairly prominent note at the introduction to the host element: The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 5 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Yet Another Tomcat Documentation Bug ??
Yea, I know, I saw that note. It's in the Host element description but references to $CATALINA_HOME (which should be $CATALINA_BASE) are all over the place -- not just under Host documentation. What's more, a reader could easily think that the note you mentioned *only* referred to the Host element description since it says, The description below IMHO, instead of asking the reader to do a mental substitution I think the documentation should be updated s.t. it uses $CATALINA_BASE when $CATALINA_BASE is appropriate. This documentation anomaly has bothered me for a long time and I felt I needed to mention it. - Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, February 21, 2005 10:20 PM Subject: RE: ?? Yet Another Tomcat Documentation Bug ?? From: Tony LaPaso [mailto:[EMAIL PROTECTED] Subject: ?? Yet Another Tomcat Documentation Bug ?? The first bullet point starts out: Any XML file in the $CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed... I believe this should say, Any XML file in the $CATALINA_BASE/conf/[engine_name]/[host_name] directory is assumed... Is that right? It's another typo, right? There's a fairly prominent note at the introduction to the host element: The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 5 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status of Bug 24970
Hi, I'm running tomcat 5.0.28 and have been hit by bug 24970: http://issues.apache.org/bugzilla/show_bug.cgi?id=24970 I've looked at the source for Response.java and the commit comments seem to suggest this bug keeps being fixed and reintroduced. I'm a little confused about which version I can expect this bug to actually be fixed in...or if is fixed at all...or if it will be fixed... 1. Can someone confirm which version of Tomcat this bug is fixed in. If its shown in the bug page I can't see it... 2. Is there a work around other than patching a jar? Thanks Rob Tomlin _ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Bug 24970
Rob Tomlin wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=24970 I've looked at the source for Response.java and the commit comments seem to suggest this bug keeps being fixed and reintroduced. I'm a little confused about which version I can expect this bug to actually be fixed in...or if is fixed at all...or if it will be fixed... Well, the bug status is marked as RESOLVED with the resolution WONTFIX. 1. Can someone confirm which version of Tomcat this bug is fixed in. If its shown in the bug page I can't see it... 2. Is there a work around other than patching a jar? As I understand the bugzilla comments it boils down to: don't use a JSP, use a servlet, and don't use a Writer in this servlet but an OutputStream. http://issues.apache.org/bugzilla/show_bug.cgi?id=24970#c25 Regards mks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Bug 24970
Markus Schönhaber wrote: As I understand the bugzilla comments it boils down to: don't use a JSP, use a servlet, and don't use a Writer in this servlet but an OutputStream. http://issues.apache.org/bugzilla/show_bug.cgi?id=24970#c25 Well, writing a filter that removes the ;charset=... part from Content-type: application/pdf header might work as a quick hack. But I wouldn't call this a solution. Regards mks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I guess this is a BUG!!!
Can anyone please tell me if it's a BUGi think it is one. I'm using Tomcat5.5.7 and i am not able to undeploy the file,it shows that the file is undeployed and loads the new file.But it still keeps showing the old file contents.Can anyone tell me what's the fix?? Secondly,the server does not restarts until I explicitly use the kill proccess_id for the java process. Please enlighten me.
Re: I guess this is a BUG!!!
On Feb 01, 2005, at 19:36, micky none wrote: Can anyone please tell me if it's a BUGi think it is one. Then... your faith is sealed. Repent. Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I guess this is a BUG!!!
Here is a monitor request doc for both boxes. -Original Message- From: PA [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 11:37 AM To: Tomcat Users List Subject: Re: I guess this is a BUG!!! On Feb 01, 2005, at 19:36, micky none wrote: Can anyone please tell me if it's a BUGi think it is one. Then... your faith is sealed. Repent. Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SOLVED: Tomcat Bug?
Thanks Drew for your suggestion! It's ok now... =) -Original Message- From: Drew Jorgenson [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 3:29 PM To: Tomcat Users List Subject: Re: Tomcat Bug? OK, look inside TOMCAT_INSTALL_DIR/work/Catalina/localhost (or whatever other virtual host you may be running) delete the cached file in question or all of them and restart tomcat ;-) Drew. On Mon, 2005-01-24 at 20:11, Aris Javier wrote: Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug or a setup problem?
I have a very strange problem. Here is my setup: Windows Server 2003 Tomcat 5.5.4 Sun's jdk 1.5.0 build 1.5.0-b64 Whenever Tomcat serves a page from my site it gets into an infinite loop. This happens even when serving a simple html file, so I'm pretty sure that it's not related to my application. The strange thing is, even though it gets into an infinite loop (error messages don't stop on the command prompt), it serves the page without any problems. Here is my host setup in server.xml. Host name=www.XXX.com appBase=e:/fileserver/webapps unpackWARs=false autoDeploy=false xmlValidation=false xmlNamespaceAware=false AliasXXX.com/Alias Context path= docBase=websites/TR/Istanbul/RC crossContext=true caseSensitive=false / Context path=/apps docBase=apps crossContext=true caseSensitive=false / /Host Can this be something to do with my URL? I don't want to provide it for now, but it's a 4 character alphanumberic URL in the AA##.com format (A = Alpha, # = Numeric)... I'm really stuck... Any ideas? Thanks, Asim PS: Here is some of my error log... record ... loggerStandardWrapper[:jsp]/logger levelSEVERE/level classorg.apache.catalina.core.ApplicationDispatcher/class methodinvoke/method thread11/thread messageServlet.service() for servlet jsp threw exception/message exception messagejava.lang.StackOverflowError/message frame classjava.security.AccessController/class methoddoPrivileged/method /frame frame classorg.apache.catalina.connector.RequestFacade/class methodgetSession/method line520/line /frame frame classjavax.servlet.http.HttpServletRequestWrapper/class methodgetSession/method line215/line /frame frame classorg.apache.catalina.core.ApplicationHttpRequest/class methodgetSession/method line518/line /frame frame classjavax.servlet.http.HttpServletRequestWrapper/class methodgetSession/method line215/line /frame ... frame classorg.apache.catalina.security.SecurityUtil/class methodexecute/method line251/line /frame frame classorg.apache.catalina.security.SecurityUtil/class methoddoAsPrivilege/method line157/line /frame frame classorg.apache.catalina.core.ApplicationFilterChain/class methodinternalDoFilter/method line231/line /frame frame classorg.apache.catalina.core.ApplicationFilterChain/class methodaccess$000/method line50/line /frame frame classorg.apache.catalina.core.ApplicationFilterChain$1/class methodrun/method line140/line /frame frame classjava.security.AccessController/class methoddoPrivileged/method /frame frame classorg.apache.catalina.core.ApplicationFilterChain/class methoddoFilter/method line136/line /frame frame classorg.apache.catalina.core.ApplicationDispatcher/class methodinvoke/method line674/line /frame frame classorg.apache.catalina.core.ApplicationDispatcher/class methoddoInclude/method line576/line /frame ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
open Excel 2000 bug
Hi All, I have a JSP page that eventually opens Excel page. I got my content type set to be application/vnd.ms-excel I also work with FOP to serialize the Excel. I got this working for both Win 2000 and XP , and for Office XP and 2003, but for Office 2000 I got an Error generating the Ecxel. If i look at localhost access log, I see that the page is somehow been called 2 again times: GET /ExcelReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 LOCK /ExcelReportGenerationPage.jsp?reportName%3DResourceExcelRep HTTP/1.1 500 2170 GET /eBopBrowser/jsp/ReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 I know that 500 indicates an internal Error of the server, but i don't understand what is the lock doing here. I understand that it relates ot webDav - but why is it here? od i use WebDav without my knowledge? I use tomcat 5.027 How come in Excel 2000 i got this Error? I looked in Microsoft and FOP mailing lists as well with no success. Any one? Regards Sun House __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: open Excel 2000 bug
Try calling response.reset() before setting content type. ContactInfo NameDerrick Koes/Name TitleSenior Software Engineer/Title Company name=SkillSoft url=http://www.skillsoft.com/ AIMcodeauthor2001/AIM Email[EMAIL PROTECTED]/Email Phone(603) 821-3260/Phone Cell(603) 305-1753/Cell Fax/ Quote attributedTo=YodaNo, try not, do or do not, there is no try./Quote /ContactInfo -Original Message- From: Sun House [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:33 AM To: tomcat-user@jakarta.apache.org Subject: open Excel 2000 bug Hi All, I have a JSP page that eventually opens Excel page. I got my content type set to be application/vnd.ms-excel I also work with FOP to serialize the Excel. I got this working for both Win 2000 and XP , and for Office XP and 2003, but for Office 2000 I got an Error generating the Ecxel. If i look at localhost access log, I see that the page is somehow been called 2 again times: GET /ExcelReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 LOCK /ExcelReportGenerationPage.jsp?reportName%3DResourceExcelRep HTTP/1.1 500 2170 GET /eBopBrowser/jsp/ReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 I know that 500 indicates an internal Error of the server, but i don't understand what is the lock doing here. I understand that it relates ot webDav - but why is it here? od i use WebDav without my knowledge? I use tomcat 5.027 How come in Excel 2000 i got this Error? I looked in Microsoft and FOP mailing lists as well with no success. Any one? Regards Sun House __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: open Excel 2000 bug
Hi, I tried that, and it did not help it looks like maybe related to a subject of disabling WebDav from working with default servlet. though if webDav is working, it is strage because i deleted the WebDav application from tomcat Derrick Koes [EMAIL PROTECTED] wrote: Try calling response.reset() before setting content type. Derrick Koes url=http://www.skillsoft.com/ codeauthor2001 [EMAIL PROTECTED] (603) 821-3260 (603) 305-1753 No, try not, do or do not, there is no try. -Original Message- From: Sun House [mailto:[EMAIL PROTECTED] Sent: Monday, January 24, 2005 7:33 AM To: tomcat-user@jakarta.apache.org Subject: open Excel 2000 bug Hi All, I have a JSP page that eventually opens Excel page. I got my content type set to be application/vnd.ms-excel I also work with FOP to serialize the Excel. I got this working for both Win 2000 and XP , and for Office XP and 2003, but for Office 2000 I got an Error generating the Ecxel. If i look at localhost access log, I see that the page is somehow been called 2 again times: GET /ExcelReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 LOCK /ExcelReportGenerationPage.jsp?reportName%3DResourceExcelRep HTTP/1.1 500 2170 GET /eBopBrowser/jsp/ReportGenerationPage.jsp?reportName=ResourceExcelRep HTTP/1.1 200 5120 I know that 500 indicates an internal Error of the server, but i don't understand what is the lock doing here. I understand that it relates ot webDav - but why is it here? od i use WebDav without my knowledge? I use tomcat 5.027 How come in Excel 2000 i got this Error? I looked in Microsoft and FOP mailing lists as well with no success. Any one? Regards Sun House __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term'
Tomcat Bug?
Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris
Re: Tomcat Bug?
Geachte relatie, Het door u gebruikte e-mailadres is niet meer actief. U kunt uw e-mailbericht sturen naar [EMAIL PROTECTED] of dit bericht beantwoorden. Bedankt voor uw medewerking, Met vriendelijke groet, ATP Hypotheken Het Spoor 40 3994 AK Houten Tel. 030 750 25 33 Fax. 030 750 25 88 [EMAIL PROTECTED] -- DIT IS EEN AUTOMATISCH GEGENEREERD E-MAILBERICHT -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Bug?
Empty your browser cache. How are you doing the deploy? Make sure the directory is being removed before redeploy. Are other pages updating? What if you delete the page all together? Doug - Original Message - From: Aris Javier [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, January 24, 2005 11:11 PM Subject: Tomcat Bug? Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Tomcat Bug?
Geachte relatie, Het door u gebruikte e-mailadres is niet meer actief. U kunt uw e-mailbericht sturen naar [EMAIL PROTECTED] of dit bericht beantwoorden. Bedankt voor uw medewerking, Met vriendelijke groet, ATP Hypotheken Het Spoor 40 3994 AK Houten Tel. 030 750 25 33 Fax. 030 750 25 88 [EMAIL PROTECTED] -- DIT IS EEN AUTOMATISCH GEGENEREERD E-MAILBERICHT -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat Bug?
I've deleted the cookies, ie history, temp files... is this the way to empty browser cache? I've also deleted the whole webapp/elog folder before deployment. but to no avail. thanks aris -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 1:01 PM To: Tomcat Users List Subject: Re: Tomcat Bug? Empty your browser cache. How are you doing the deploy? Make sure the directory is being removed before redeploy. Are other pages updating? What if you delete the page all together? Doug - Original Message - From: Aris Javier [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, January 24, 2005 11:11 PM Subject: Tomcat Bug? Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Tomcat Bug?
Geachte relatie, Het door u gebruikte e-mailadres is niet meer actief. U kunt uw e-mailbericht sturen naar [EMAIL PROTECTED] of dit bericht beantwoorden. Bedankt voor uw medewerking, Met vriendelijke groet, ATP Hypotheken Het Spoor 40 3994 AK Houten Tel. 030 750 25 33 Fax. 030 750 25 88 [EMAIL PROTECTED] -- DIT IS EEN AUTOMATISCH GEGENEREERD E-MAILBERICHT -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Bug?
As far as I know. Under IE options for the settings in the files section you can set that to check for a new page on each visit. Pressing F5 is suppose to do a new request. Also I remember some mention about file dates. Make sure date on new file is later than on original file. There have been several threads on this but each had a slightly different twist. Check the archives. If you delete the app does the page still respond or give you an error? Doug - Original Message - From: Aris Javier [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Tuesday, January 25, 2005 12:07 AM Subject: RE: Tomcat Bug? I've deleted the cookies, ie history, temp files... is this the way to empty browser cache? I've also deleted the whole webapp/elog folder before deployment. but to no avail. thanks aris -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 1:01 PM To: Tomcat Users List Subject: Re: Tomcat Bug? Empty your browser cache. How are you doing the deploy? Make sure the directory is being removed before redeploy. Are other pages updating? What if you delete the page all together? Doug - Original Message - From: Aris Javier [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, January 24, 2005 11:11 PM Subject: Tomcat Bug? Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Bug?
OK, look inside TOMCAT_INSTALL_DIR/work/Catalina/localhost (or whatever other virtual host you may be running) delete the cached file in question or all of them and restart tomcat ;-) Drew. On Mon, 2005-01-24 at 20:11, Aris Javier wrote: Hello! Please Help! It seems Tomcat won't refresh the page... I have this logout.jsp page.. have configured it so many times... deployed it to webapps/elog/web folder but still it's initial logout.jsp appeared... restarted tomcat, restarted browser, and even restarted my pc... but to no avail. im using tomcat 5.0.25 on windows 2000... is this tomcat 5.0.25 bug? Thanks! Aris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
Mladen Turk wrote: Take a look at: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html It clearly states that (big warning in red color) The name of the worker can contain only the alphanumeric characters [a-z][A-Z][0-9] and is case insensitive. So tc1.tc1 is illegal name for the worker. thanks for that hint, but actually luckily this is working. the real problem is that the value that i specify for the jvmRoute is magically doubled and i only doubled this name in the workers.properties file as a short term workaround. i still did not find out why this jvmRoute parameter is doubled in my applications, but not in the servlets-examples/servlet/SessionExample application. -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Major bug in deployer!!
Thanks for the response Doug. Can you describe how to do this remotely? I tried renaming 'context.xml' to 'servlet#myservlet.xml' in the WAR file, but as I expected the deployer did not find the file. I'm not sure where this is described in the documentation, the only significant item I could find was... You may define as many Context elements as you wish. Each such Context MUST have a unique context path, which is defined by the path attribute. ...and... Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place Context elements directly in the server.xml file. ...but neither mention the usage of the '#' character or that the 'path' attribute is ignored and the name of the WAR file is used instead as the context path. I am pretty sure this is the case because I just changed my 'context.xml' file to... ... Context path=/something-other-than-myservlet reloadable=true ... ...and when I deployed the servlet 'myservlet.war' Tomcat simply created a 'myservlet.xml' file and used 'myservlet' as the context path. To me it seems like a problem when the documentation discourages the inclusion of a context in the 'server.xml' file and yet does not respect the 'path' attribute in the context element. So my question remains... Is there a workaround for this problem that will allow me to deploy my web application using the deployer when my web application context path needs to be '/servlet/myservlet'? Yes, the context NEEDS to be '/servlet/myservlet'! Bernard Durfee -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 6:17 PM To: Tomcat Users List Subject: Re: Major bug in deployer!! This is the default action of the 5.5 path and is noted on the context documentation. The way to fix this is to name the context.xml as servlet#myservlet.xml Doug - Original Message - From: Durfee, Bernard [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, January 20, 2005 10:48 AM Subject: Major bug in deployer!! I am trying to use the Tomcat manager to deploy a web application packed in a WAR file. In my WAR file I have a directory named 'META-INF' and in that directory I have a file named 'context.xml'. The 'context.xml' file looks like... ?xml version=1.0 encoding=UTF-8? Context path=/servlet/myservlet reloadable=true ... /Context ...so I am telling Tomcat to send all URLs ending with '/servlet/myservlet' to the web application being deployed. I do a browse, point to the WAR file and then press 'Deploy'. Tomcat then copies the WAR file to '/webapps' and copies the 'context.xml' file to 'conf/.../myservlet.xml'. So far so good. Now when I go to the manager listing the web applications I see '/myservlet' in the 'Applications' column. Uh oh! Seems that the 'path' attribute in the 'context.xml' file is being completely ignored! So right now I am forced to put the Context element in the 'server.xml' file directly, in which Tomcat respects the 'path' attribute. So my question is... Is there a workaround for this problem that will allow me to deploy my web application using the deployer when my web application context path needs to be '/servlet/myservlet'? Yes, the context NEEDS to be '/servlet/myservlet'! I have tried this in 5.5.4, 5.5.6 and 5.5.7 with the same results. The deployer would make life on our network admin MUCH easier because I would be able to deploy new versions of the web application without bugging him to install them manually. Thanks in advance!! Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Major bug in deployer!!
When I arrived at the '#' technique, it was by reading the code for org.apache.catalina.startup.HostConfig to see how it processed the context fragments ( I heart open source). Looking at the same class, it looks like it uses the name of the war file to name the context fragment if it's copying the fragment from the META-INF directory. The 'path' attribute is only used if the Context element is inline in the server.xml. You could try is deploying the Context configuration seperately in a file called servlet#myservlet.xml in the configuration base, and pointing to your war file in the Context's docBase attribute. I know this works, because it's how I manage things. If you need to bundle the context information into the war file and also specify a multiple level path, then I think the HostConfig class would have to be changed to parse the '#' in the war file's name to '/' (in HostConfig.deployWARs(File appBase, String[] files), for example). Benjamin J. Armintor Operations Systems Specialist ITS-Systems: Mainframe Group University of Texas - Austin tele: (512) 232-6562 email: [EMAIL PROTECTED] -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 9:03 AM To: Tomcat Users List Subject: RE: Major bug in deployer!! Thanks for the response Doug. Can you describe how to do this remotely? I tried renaming 'context.xml' to 'servlet#myservlet.xml' in the WAR file, but as I expected the deployer did not find the file. I'm not sure where this is described in the documentation, the only significant item I could find was... You may define as many Context elements as you wish. Each such Context MUST have a unique context path, which is defined by the path attribute. ...and... Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place Context elements directly in the server.xml file. ...but neither mention the usage of the '#' character or that the 'path' attribute is ignored and the name of the WAR file is used instead as the context path. I am pretty sure this is the case because I just changed my 'context.xml' file to... ... Context path=/something-other-than-myservlet reloadable=true ... ...and when I deployed the servlet 'myservlet.war' Tomcat simply created a 'myservlet.xml' file and used 'myservlet' as the context path. To me it seems like a problem when the documentation discourages the inclusion of a context in the 'server.xml' file and yet does not respect the 'path' attribute in the context element. So my question remains... Is there a workaround for this problem that will allow me to deploy my web application using the deployer when my web application context path needs to be '/servlet/myservlet'? Yes, the context NEEDS to be '/servlet/myservlet'! Bernard Durfee -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 6:17 PM To: Tomcat Users List Subject: Re: Major bug in deployer!! This is the default action of the 5.5 path and is noted on the context documentation. The way to fix this is to name the context.xml as servlet#myservlet.xml Doug - Original Message - From: Durfee, Bernard [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, January 20, 2005 10:48 AM Subject: Major bug in deployer!! I am trying to use the Tomcat manager to deploy a web application packed in a WAR file. In my WAR file I have a directory named 'META-INF' and in that directory I have a file named 'context.xml'. The 'context.xml' file looks like... ?xml version=1.0 encoding=UTF-8? Context path=/servlet/myservlet reloadable=true ... /Context ...so I am telling Tomcat to send all URLs ending with '/servlet/myservlet' to the web application being deployed. I do a browse, point to the WAR file and then press 'Deploy'. Tomcat then copies the WAR file to '/webapps' and copies the 'context.xml' file to 'conf/.../myservlet.xml'. So far so good. Now when I go to the manager listing the web applications I see '/myservlet' in the 'Applications' column. Uh oh! Seems that the 'path' attribute in the 'context.xml' file is being completely ignored! So right now I am forced to put the Context element in the 'server.xml' file directly, in which Tomcat respects the 'path' attribute. So my question is... Is there a workaround for this problem that will allow me to deploy my web application using the deployer when my web application context path needs to be '/servlet/myservlet'? Yes, the context NEEDS to be '/servlet/myservlet'! I have tried this in 5.5.4, 5.5.6 and 5.5.7 with the same results. The deployer would make life on our network admin MUCH easier because I would be able to deploy new versions of the web application without bugging him to install them manually. Thanks in advance!! Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Bug, context not reloading on startup.
Hello, I hope everyone is doing well. I am experiencing two problems with Tomcat and I think they both stem from the same issue. I have been deploying an application using the tomcat manager by specifying a Contact Path, XML Configuration file URL and a Directory URL. Because I am specifying the directory URL, I do not add a docBase attribute to the Context element in the configuration file. When I initially deploy the webapp, it works great. Problems arise when I restart tomcat. The first debug statement that catches my eye is: INFO: Processing Context configuration file URL file:/home/tns/bin/jakarta-tomcat-5.0.28/conf/Catalina/localhost/nmmr.xml The above is the XML Configuration file that I specified in the tomcat manager. It does not specify a docBase. The next debug statement states the the context cannot start: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base /home/tns/bin/tomcat/webapps/nmmr does not exist or is not a readable directory The document base specified in the log files is NOT the Directory URL I specified in the Tomcat Manager. If I do not specify an XML Configuration file, one is created that looks like so: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base /home/tns/bin/tomcat/webapps/nmmr does not exist or is not a readable directory All in all, it seems that tomcat should add the docBase attribute to its local copy of the Configuration file if the directory is specified external to the configuration file. -Trav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
hello, i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version 1.2.8 in a load balancing set-up with sticky sessions. when i give as jvmRoute parameter the string tc1 my sessionids look like: BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1 and i see in the mod_jk.log file that no worker with the name tc1.tc1 could be found! i've circumvented the problem currently by doubling the name in the workers.properties file as follows: -- snip start -- worker.list=load worker.load.type=lb worker.load.balance_workers=tc1.tc1,tc2.tc2 worker.load.sticky_session=True worker.tc1.tc1.port=12013 worker.tc1.tc1.host=localhost worker.tc1.tc1.type=ajp13 worker.tc2.tc2.port=12013 worker.tc2.tc2.host=remote worker.tc2.tc2.type=ajp13 -- snip end -- was this problem already noticed? did i do something wrong? or should i file a bug report? thanks, -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
On Thu, 20 Jan 2005 13:15:58 +0100, Christian Schuhegger [EMAIL PROTECTED] wrote: hello, i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version 1.2.8 in a load balancing set-up with sticky sessions. when i give as jvmRoute parameter the string tc1 my sessionids look like: BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1 and i see in the mod_jk.log file that no worker with the name tc1.tc1 could be found! i've circumvented the problem currently by doubling the name in the workers.properties file as follows: -- snip start -- worker.list=load worker.load.type=lb worker.load.balance_workers=tc1.tc1,tc2.tc2 worker.load.sticky_session=True worker.tc1.tc1.port=12013 worker.tc1.tc1.host=localhost worker.tc1.tc1.type=ajp13 worker.tc2.tc2.port=12013 worker.tc2.tc2.host=remote worker.tc2.tc2.type=ajp13 -- snip end -- was this problem already noticed? did i do something wrong? or should i file a bug report? - Added jvmRoute=tc1 on Engine - Accessed http://127.0.0.1:8080/servlets-examples/servlet/SessionExample - Session ID displayed is 8DBBCECBCAD078E18C07401A076734B0.tc1 -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
Remy Maucherat wrote: - Added jvmRoute=tc1 on Engine - Accessed http://127.0.0.1:8080/servlets-examples/servlet/SessionExample - Session ID displayed is 8DBBCECBCAD078E18C07401A076734B0.tc1 i've just tried this example myself and you're right. i see only .tc1. i have a very little webapp which does similar things to test the distributed set-up and a our main big application and both have the same problem with this double tc1.tc1. i will try to find out why i have it in the one case but not in the other? nevertheless i anybody experienced similar problems and found out where the problem comes from i would be very happy to hear about it. thanks, -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
Christian Schuhegger wrote: hello, i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version 1.2.8 in a load balancing set-up with sticky sessions. when i give as jvmRoute parameter the string tc1 my sessionids look like: BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1 and i see in the mod_jk.log file that no worker with the name tc1.tc1 could be found! Hi, Take a look at: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html It clearly states that (big warning in red color) The name of the worker can contain only the alphanumeric characters [a-z][A-Z][0-9] and is case insensitive. So tc1.tc1 is illegal name for the worker. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Major bug in deployer!!
I am trying to use the Tomcat manager to deploy a web application packed in a WAR file. In my WAR file I have a directory named 'META-INF' and in that directory I have a file named 'context.xml'. The 'context.xml' file looks like... ?xml version=1.0 encoding=UTF-8? Context path=/servlet/myservlet reloadable=true ... /Context ...so I am telling Tomcat to send all URLs ending with '/servlet/myservlet' to the web application being deployed. I do a browse, point to the WAR file and then press 'Deploy'. Tomcat then copies the WAR file to '/webapps' and copies the 'context.xml' file to 'conf/.../myservlet.xml'. So far so good. Now when I go to the manager listing the web applications I see '/myservlet' in the 'Applications' column. Uh oh! Seems that the 'path' attribute in the 'context.xml' file is being completely ignored! So right now I am forced to put the Context element in the 'server.xml' file directly, in which Tomcat respects the 'path' attribute. So my question is... Is there a workaround for this problem that will allow me to deploy my web application using the deployer when my web application context path needs to be '/servlet/myservlet'? Yes, the context NEEDS to be '/servlet/myservlet'! I have tried this in 5.5.4, 5.5.6 and 5.5.7 with the same results. The deployer would make life on our network admin MUCH easier because I would be able to deploy new versions of the web application without bugging him to install them manually. Thanks in advance!! Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
