DO NOT REPLY [Bug 24385] - text conversion fails with jsp:forward/param on linux server
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24385 text conversion fails with jsp:forward/param on linux server --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 09:15 --- Thank you for your answer. I've tried the first proposion: % request.setCharacterEncoding(ISO-8859-1); % gives strange results, but % request.setCharacterEncoding(UTF-8); % works (on the other hand the workaround fails). Result - Template Text: Test Umlaut Ä-Ö-Ü-ä-ö-ü Text from Parameter: Test Umlaut Ä-Ö-Ü-ä-ö-ü Text from Parameter (Workaround): Test Umlaut ?-?-?-?-? - Without setCharacterEncoding the system browser/tomcat seems to do the conversion ISO-8859-1 to UTF-8 twice in one direction, but only once in the other. For me the workaround does the job at the moment - so I wait for Tomcat 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24488] New: - ignoring compiler setting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24488. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24488 ignoring compiler setting Summary: ignoring compiler setting Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the Environment set up jdk1.3.1_09 Apache Tomcat 4.1.24 I kept my bean class file under webapps\ROOT\WEB-INF\classes.No package I'm getting the following error when i request a jsp file. Please help to solve this issue. HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Since fork is true, ignoring compiler setting. [javac] Compiling 1 source file [javac] Since fork is true, ignoring compiler setting. [javac] C:\Program Files\Apache Group\Tomcat 4.1 \work\Standalone\localhost\_\jsp\ConnectionPooling_jsp.java:44: cannot resolve symbol [javac] symbol : class PCSTDatabaseConnectionPoolingBean [javac] location: class org.apache.jsp.ConnectionPooling_jsp [javac] PCSTDatabaseConnectionPoolingBean connectionpool = null; [javac] ^ [javac] C:\Program Files\Apache Group\Tomcat 4.1 \work\Standalone\localhost\_\jsp\ConnectionPooling_jsp.java:46: cannot resolve symbol [javac] symbol : class PCSTDatabaseConnectionPoolingBean [javac] location: class org.apache.jsp.ConnectionPooling_jsp [javac] connectionpool = (PCSTDatabaseConnectionPoolingBean) pageContext.getAttribute(connectionpool, PageContext.SESSION_SCOPE); [javac] ^ [javac] C:\Program Files\Apache Group\Tomcat 4.1 \work\Standalone\localhost\_\jsp\ConnectionPooling_jsp.java:49: cannot resolve symbol [javac] symbol : class PCSTDatabaseConnectionPoolingBean [javac] location: class org.apache.jsp.ConnectionPooling_jsp [javac] connectionpool = (PCSTDatabaseConnectionPoolingBean) java.beans.Beans.instantiate(this.getClass().getClassLoader (), PCSTDatabaseConnectionPoolingBean); [javac] ^ [javac] 3 errors at org.apache.jasper.compiler.DefaultErrorHandler.javacError (DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError (ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370) at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:473) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:190) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at
[Fatal Error] :-1:-1: Premature end of file.
Hi I am using Tomcat to handle servlets which makes JDBC calls to Oracle database. I have got the same application running at various places and for a long time but for the first time I am getting the following error message at our 2 installations: [Fatal Error] :-1:-1: Premature end of file. I have no idea as on what action wihtin the application this is coming up. Plus this message is not even visible in Tomcat error logs. Do you have any idea as to why would such messages appear. Atif DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. Copyright Valid Information Systems Limited. http://www.valinf.com Address Morline House, 160 London Road, Barking, Essex, IG11 8BB. Tel: 020 8215 1414 Fax: 020 8215 2040.
Saving user information when serializing HttpSession
Hi! Could anyone, please, explain why Tomcat's session serialization is implemented the way it is? As far as I can see in StandardSession.java the user's principal is deliberately skipped when serializing/deserializing a session. Why? In my opinion this can cause undesired behavior. Imagine the following situation. A web application is protected using form-based authentication. For every logged in user (i.e. for every session, which is valid and not new) there is a session attribute, which contains some user-specific data (e.g. user preferences like background color etc.). That data is initialized from an external source (e.g. database) when the user logs in. Now imagine that the session gets serialized and deserialized. (In real life this can be triggered by restarting the web application). After that the session is still valid (although represented by a different object instance) and it contains the same (deserialized) user-specific data. So everything looks good. But the session does not have a user principal any more, so the next request from the user is redirected to the login page. And here it comes. There is nothing that prevents the user from typing different login/password and if those are valid then it means the existing session will have a new user associated with it, while it still has all its attributes from the old user. As a result this is likely to cause not only user's confusion, but also saving the user-specific data in the wrong place in the database (when session is invalidated). Not to mention potential security problems that can raise from the ability of the user to access another user's information stored in the session object attributes. Moreover, in my opinion this breaks the very concept of a session as something bound to a particular user. In practice it is not very hard to work around this problem, for example by creating a filter, which will check user name for every request, but that would usually have negative impact on the application's performance. And still, the user is usually not aware of any possible session serializations/deserializations and I believe he should not be asked to re-login unexpectedly (from his point of view). I suppose there must have been certain reasons why user principal is not serialized. I wonder what those might be. And don't you think the problem I have described is worth fixing? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24496] New: - could not retrive httpsession
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496
could not retrive httpsession
Summary: could not retrive httpsession
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: Critical
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I've a sample application based on MVC-model. A servlet that make a session an
manager a database connection. I've developped with Jdeveloper, everything
works fine. Now I've deployed to tomcat4.1.24, when i go to oher jsp page the
session is null. Your help we'll be very useful
.
Rony Auguste
TurboSystem
Analyst-programmer.
---
here's the servlet source :
---
package pop;
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.PrintWriter;
import java.io.IOException;
import java.io.*;
import java.util.Properties;
import java.sql.*;
public class login extends HttpServlet implements java.io.Serializable
{
private final String CONTENT_TYPE = text/html; charset=windows-1252;
public Connection con;
public void init(ServletConfig config) throws ServletException
{
super.init(config);
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletExce$
{
Properties conValues = Utilities.loadParams(/confile.properties );
String host = (String)conValues.get( HOST );
String sid= (String)conValues.get( SID );
String port = (String)conValues.get( PORT );
//set the database url
String dburl = jdbc:oracle:thin:@+host+:+port+:+sid;
String user = request.getParameter(username) ;
String pass = request.getParameter(password) ;
//declaration des variables de connection
ResultSet rs = null;
Statement stmt =null;
try
{
String driverName = oracle.jdbc.driver.OracleDriver ;
Class.forName(driverName);
}
catch (ClassNotFoundException e)
{
System.out.println(Unable to load driver
class : );
System.out.println(e.getMessage());
}
// connecting to the database
try {
con = DriverManager.getConnection(dburl,user,pass);
stmt= con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_REA$
String querry=select a.AGENT_ID from TRSF.AGENT a,
TRSF.USER_AGENT u +
where a.AGENT_ID = u.AGENT_IDand u.USER_ID
= user;
rs=stmt.executeQuery(querry) ;
if (rs.next()) {
HttpSession session = request.getSession(true);
synchronized(session) {
session.setAttribute(uname,user);
session.setAttribute(agence,rs.getString(1));
session.setAttribute(con,con);
}
request.setAttribute(db,sid);
ServletContext context = getServletContext();
RequestDispatcher dispatcher=
context.getRequestDispatcher(/jsp/main.jsp);
dispatcher.forward(request,response);
}
} //end try connecting to the database
catch(SQLException ex){
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
out.println(Message :+ex.getMessage());
out.println(Etat :+ex.getSQLState());
out.println(Code erreur:+ex.getErrorCode()+\n);
/*get catch
fin get catch*/
}
} //end dopost
}
} // end class
I could retrieve the session on the main.jsp forward by the servlet, but for
the other jsp nothing
---
ex:
%@ page errorPage=error.jsp %
%@ page session=true %
%@ page import=java.sql.* %
%@ page import = java.io.* %
%
HttpSession popsession = request.getSession(true);
Connection con= null ;
con = (Connection)popsession.getAttribute(con);
if(con!=null){
Statement stmt = null;
Statement stmt_date = null;
ResultSet rset = null;
ResultSet rset_date = null;
try {
stmt = con.createStatement ();
stmt_date = con.createStatement ();
rset_date =
DO NOT REPLY [Bug 24496] - could not retrive httpsession
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496 could not retrive httpsession --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 14:45 --- Created an attachment (id=8976) servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24496] - could not retrive httpsession
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24496 could not retrive httpsession [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 14:49 --- Please use tomcat-user list to debug. Bugzilla is not for general support. It is for filing bugs in tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24347] - Try to log on with a user without any roles. Then enter /admin, the /admin does not work.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24347. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24347 Try to log on with a user without any roles. Then enter /admin, the /admin does not work. --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 14:50 --- Refreshing the page usually does not help. What really helps is making a custom error page for the status code 403 and placing there a logout link to some url, which invalidates the session. Then you can login as any other user (e.g. admin). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vegas Anyone? :-)
ApacheCon 2003 will be held in Las Vegas this November 16-19. Who is going to be there from Tomcat Dev? Maybe we can coordinate Tomcat get together... :-) Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24506] New: - New line elimination at end of directives
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24506. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24506 New line elimination at end of directives Summary: New line elimination at end of directives Product: Tomcat 4 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] JSP pages are a templating system which is using a meta language (the JSP directives, declarations, scriplets and expressions) and literals from the output language (HTML, XML or other text based fragments). The JSP specification does not deal the new lines (or white space in general) introduced by the meta language. These new lines are used for readability reasons. In most cases the output language being HTML or XML extra empty lines (or white space in general) does not have any semantical impact, so probably this is the main reason why this issue was neglected. In HTML/XML empty lines can be a problem in the following cases: - JSP pages in general have may directives at the top of the page, this leads to may empty lines at the top of the generated page, problems with this: - Internet Explorer may not properly detect the page type for XHTML pages since it is doing a limited look ahead (http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/overview/appendix_a.asp) - viewing the source of these pages shows a blank screen first (trivial, but how many developers over the years are dealing with this annoying fact?) - the content of pre or textarea blocks in HTML - the content of CDATA blocks in XML In the case of other formats than HTML/XML (like plain text) the extra empty lines can be a real problem. Other templating languages are dealing with this very same issue: http://freemarker.sourceforge.net/docs/dgui_misc_whitespace.html#dgui_misc_whitespace_stripping While the proper solution would be in the specification, changing that is a lengthy process (not to mention that it is almos impossible for an individual). Since the spec is not saying anything about this issue and there is an obvious problem I think that it would be proper to provide a limited fix in Tomcat. The limited fix I am suggesting is as follows: - for directives and declarations for which the end tag is followed only by white space consider that white space and the new line as part of the directive and don't output it - for scriplets and expressions don't apply this A switch or setting could be provided to enable this behaviour. Cheers, Marius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24009] - Jasper option for whitespace-optimized HTML output
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24009. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24009 Jasper option for whitespace-optimized HTML output --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 17:50 --- I created a new issue, 24506, for the new lines at the end of directives. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 18:41 --- Can you patch to check the return values of the fflush and fclose calls? They should be 0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24508] New: - Webapp class loader issue
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508 Webapp class loader issue Summary: Webapp class loader issue Product: Tomcat 4 Version: 4.1.27 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The webapp class loading mechanism had been changed from 4.0.x to 4.1.x. In 4.1.x all xerces and xalan classes will be skipped from the webapps directory (See WebappClassLoader.java). The problem is that tomcat now forcing every webapps in the same tomcat to use the same version of xerces and xalan without any choice. The engineer from Sun pointed out that servlet container should follows the recommendation defined in the 2.3 specification, and the endorsed mechansim used in JDK 1.4 has nothing to force the webapps to use the endorsed directory. However, after a long discussion in the tomcat developer forum still getting inconclusive. Seems to me that a simple configuration property will solve all the issues. Tomcat/webapps should able to be configured to either use the endorsed files, or use the ones from its own webapps? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24508] - Webapp class loader issue
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508 Webapp class loader issue [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 19:19 --- a) The Sun engineer is wrong b) This has been discussed at length, and the current behavior will not be changed, as it is the one which gives the best behavior c) Please do not reopen the report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24510] New: - Odd back button behavior in a multi-frame environment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510 Odd back button behavior in a multi-frame environment Summary: Odd back button behavior in a multi-frame environment Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm testing using the Tomcat servlet container with IPlanet 6 and have found a strange error when I try to use the BACK button in IE to return to a previous frameset. Here's the scenario: The first page of my web application displays a frameset which contains 2 frames (docA and docB). I click on one of the links in the right frame and it changes the right frame to a menu for selecting parameters (using a simple HREF with no target). So the frameset now contains the same document in the left frame but a different document in the right frame (docC). I select parameters and SUBMIT. The submission has a target=_parent which causes the resulting report to be displayed in the complete browser window. Then, when I press the BACK button the frameset refreshes not to the last configuration (containing docA and docC) but to its original configuration (containing docA and docB). It's as if I had pressed the BACK button twice. All of these documents are dynamically-generated by either servlets or JSPs. If I run the identical code using a straight IPlanet setup the BACK button works as expected. I only see this problem using IE (version 6.0.2800). In addition, if I save all of the pages as HTML files and run through the same sequence the BACK button works as expected. Right now, I can't provide a URL since this is on my test environment behind a firewall. I could set one up if needed (it would just take a little time). I'm not clear on how the servlet container has anything to do with how a browser BACK button works but I'd appreciate any tips you could give me on this subject. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24508] - Webapp class loader issue
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24508 Webapp class loader issue --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 19:20 --- a) The Sun engineer is wrong b) This has been discussed at length, and the current behavior will not be changed, as it is the one which gives the best behavior c) Please do not reopen the report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24510] - Odd back button behavior in a multi-frame environment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510 Odd back button behavior in a multi-frame environment --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 19:31 --- This is more a browser quirk than a Tomcat issue, but is Tomcat-involved. Probably due to the headers being set on your frameset page, IE will reload it when loaded from a server, but not from disk. When the frameset page is reloaded, it contains the pointers to your original docA and docB, so they'll be loaded. IE errs on the side of reload in many cases, esp. if there are Cookie, Pragma, or CacheControl headers. This isn't a Tomcat problem. You may investigate setting headers (like Expires) to trick IE into not reloading the frameset page, but I'd recommend writing your site to encourage people not to use Back. Provide good navigation within your pages. I'm not closing this, because I'm really not a Tomcat developer. But I'm trying to be helpful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vegas Anyone? :-)
On Fri, Nov 07, 2003 at 09:44:04AM -0800, Amy Roh wrote: ApacheCon 2003 will be held in Las Vegas this November 16-19. Who is going to be there from Tomcat Dev? Maybe we can coordinate Tomcat get together... :-) I'll be there, including Sat Sun for the Hack-A-Thon. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 01:36 --- I added a few syslog calls to record the fflush() and fclose() return values. Both calls return 0 consistently. I also tried replace fclose(p-logfile) with close(fileno(p-logfile)). Likewise, close() returned 0 consistenly. Unfortunately, in both situations above, none of the file descriptors where close()/fclose() succeeded were actually closed. Both lsof and /proc/PID/fd still show them as being used by the parent httpd process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk2/apache13 patch
Attached is a patch to jk2 for the remaining changes that are needed for
using HEAD with apache13. In addition to this patch I needed to delete
common/jk_channel_socket.c and common/jk_pool.c from my tree (perhaps these
should be moved to the attic).
This patch does the following things:
1) adds --with-apr-util to jk_apr.m4 and configure.in and will be a required
configure argument for apache13.
2) fixes some small problems in jk_apr.m4 and jk_exec.m4.
3) removes the remaining ifdefs HAS_APR from server/apache13/mod_jk2.c
and -DHAS_APR from jk_apr.m4 (I couldn't find any remaining code that needs
it now).
4) reverts server/apache13/Makefile.in to create mod_jk.so without creating
mod_jk.la (this may of interest to jean-frederic clere). I wasn't able to
figure out how to get apr-0 and apr-util-0 statically linked in to mod_jk.so
the way it was changed. To be honest libtool is not my strong point, help
with this would be appreciated. I also removed -lcrypt too.
I think that covers it. Please review and comment.
-Kurt
Index: native2/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- native2/Makefile.in 4 Nov 2003 12:48:05 - 1.3
+++ native2/Makefile.in 7 Nov 2003 23:50:15 -
@@ -41,10 +41,10 @@
done;
apr-build:
- ( cd @APR_DIR@ make )
+ ( cd @APR_DIR@ make cd @APR_UTIL_DIR@ make )
apr-clean:
- ( cd @APR_DIR@ make clean )
+ ( cd @APR_DIR@ make clean cd @APR_UTIL_DIR@ make clean )
apidocs: common/*.h
mkdir -p ./docs/api
Index: native2/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native2/configure.in,v
retrieving revision 1.13
diff -u -r1.13 configure.in
--- native2/configure.in5 Nov 2003 09:15:19 - 1.13
+++ native2/configure.in7 Nov 2003 23:50:15 -
@@ -175,15 +175,10 @@
JK_APR_THREADS()
JK_APR([include/apr.h.in])
+JK_APR_UTIL([include/apu.h.in])
JK_APR_INCDIR([apr.h])
JK_APR_LIBDIR()
-dnl Set these to empty until we know what to do with them
-
-AC_SUBST(APR_UTIL_INCL)
-AC_SUBST(APR_UTIL_LIB)
-
-
dnl Java settings
JK_JNI()
@@ -205,11 +200,16 @@
AC_SUBST(WEBSERVERS)
+dnl if --with-apr is specified, --with-apr-util must be too
+if ${TEST} ! -z $APR_BUILD -a -z $APR_UTIL_DIR; then
+ AC_MSG_ERROR([--with-apr and --with-apr-util must be used together])
+fi
+
dnl apache 1.3 consistancy checks
if ! ${TEST} -z $APACHE_HOME ; then
dnl check if apache 1.3 was selected without apr sources
if ${TEST} -z $APR_BUILD; then
-AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr])
+AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use
--with-apr and --with-apr-util])
fi
dnl make sure compiler matchs apxs
if ${TEST} $APACHE_CC != $CC; then
@@ -222,9 +222,9 @@
fi
dnl apache 2 consistancy checks
-if ! ${TEST} -z $APACHE2_HOME ; then
+if ${TEST} ! -z $APACHE2_HOME ; then
dnl check if apache 2 was selected with apr sources
-if ${TEST} -z $APR_BUILD; then
+if ${TEST} ! -z $APR_BUILD; then
AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
fi
dnl make sure compiler matchs apxs
@@ -245,9 +245,12 @@
AC_SUBST(APR_CFLAGS)
AC_SUBST(APR_CLEAN)
AC_SUBST(APR_DIR)
+AC_SUBST(APR_UTIL_DIR)
AC_SUBST(APR_HOME)
AC_SUBST(APR_INCDIR)
+AC_SUBST(APR_UTIL_INCDIR)
AC_SUBST(APR_LIBDIR)
+AC_SUBST(APR_UTIL_LIBDIR)
AC_SUBST(APR_CONFIGURE_ARGS)
AC_SUBST(APR_LDFLAGS)
AC_SUBST(COMMON_APR_OBJECTS)
Index: native2/server/apache13/Makefile.in
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.7
diff -u -r1.7 Makefile.in
--- native2/server/apache13/Makefile.in 28 Nov 2002 15:54:51 - 1.7
+++ native2/server/apache13/Makefile.in 7 Nov 2003 23:50:15 -
@@ -23,7 +23,7 @@
${APACHE_INCL}
JK_CFLAGS=-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 @APR_CFLAGS@ -DHAVE_MMAP ${JAVA_INCL}
-JK_LDFLAGS=-L${APACHE_HOME}/lib -lcrypt @APR_LDFLAGS@ ${JAVA_LIB}
+JK_LDFLAGS=-L${APACHE_HOME}/lib ${JAVA_LIB}
## Based on rules.mk ##
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
@@ -36,7 +36,7 @@
COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) $(JK_CFLAGS)
-MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -rpath
$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
+MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -shared -rpath
$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
MOD_INSTALL = $(LIBTOOL) --mode=install $(CP)
Re: Vegas Anyone? :-)
Amy Roh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ApacheCon 2003 will be held in Las Vegas this November 16-19. Who is going to be there from Tomcat Dev? Maybe we can coordinate Tomcat get together... :-) I have way too much work to stay for the conference :(. But I could drive over if something was planned for the weekend. Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
