DO NOT REPLY [Bug 14188] New: - directive import in the included page causes encoding(charset) modification for this page

2002-11-02 Thread bugzilla
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=14188.
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=14188

directive import in the included page causes encoding(charset) modification for this 
page

   Summary: directive import in the included page causes
encoding(charset) modification for this page
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


directive import in the included page causes encoding(charset) modification 
for this page

EXAMLE1 - FILES

page1.jsp
%@ page contentType=text/html; charset=windows-1251 %
%@ include file=include1.jsp %
PRE
PAGE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ PAGE 1  RUSSIAN TEXT IN Win1251
PAGE 1 TEXT
/PRE
page1.jsp

include1.jsp
html
head
titleCHarset TEST/title
meta http-equiv=Content-Type content=text/html; charset=windows-1251
/head

body bgcolor=#FF text=#00 leftmargin=0 topmargin=0 
marginwidth=0 marginheight=0

PRE
INCLUDE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ INCLUDE 1
INCLUDE 1 TEXT
/PRE
include1.jsp

EXAMLE1 - RESULT

INCLUDE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ INCLUDE 1
INCLUDE 1 TEXT

PAGE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ PAGE 1  RUSSIAN TEXT IN Win1251
PAGE 1 TEXT



EXAMLE2 - FILES

page1.jsp
%@ page contentType=text/html; charset=windows-1251 %
%@ include file=include1.jsp %
PRE
PAGE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ PAGE 1  RUSSIAN TEXT IN Win1251
PAGE 1 TEXT
/PRE
page1.jsp

include1.jsp
%@ page import=java.lang.String%
html
head
titleCHarset TEST/title
meta http-equiv=Content-Type content=text/html; charset=windows-1251
/head

body bgcolor=#FF text=#00 leftmargin=0 topmargin=0 
marginwidth=0 marginheight=0

PRE
INCLUDE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ INCLUDE 1
INCLUDE 1 TEXT
/PRE
include1.jsp

EXAMLE2 - RESULT

INCLUDE 1 TEXT
? ??  INCLUDE 1  RUSSIAN TEXT IN Win1251
INCLUDE 1 TEXT

PAGE 1 TEXT
ÒÅÊÑÒ ÑÎ ÑÒÐÀÍÈÖÛ PAGE 1
PAGE 1 TEXT



jasper 1 not have this problem

???

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14191] New: - Cannot acquire MBeanServer reference

2002-11-02 Thread bugzilla
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=14191.
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=14191

Cannot acquire MBeanServer reference

   Summary: Cannot acquire MBeanServer reference
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


ERROR: Cannot acquire MBeanServer reference occurs after first install and 
first attempt at startup of catalina.bat

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14192] New: - setclasspath.bat does not set classpath correctly

2002-11-02 Thread bugzilla
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=14192.
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=14192

setclasspath.bat does not set classpath correctly

   Summary: setclasspath.bat does not set classpath correctly
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


setclasspath.bat does not set classpath correctly

The only claspath that is set is 
set CLASSPATH=%JAVA_HOME%\lib\tools.jar

When you try to launch Tomcat you get a classnotfound exception.

If you move all the jars into the ext directory, it works fine.

I installed Tomcat on my g: drive under windows 2000.  My CATALINA_HOME is 
set correctly because I do not get any errors relating to CATALINA_HOME not 
found.

I don't think you get this bug if you install to the c: drive.

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




Catalina Ant tasks

2002-11-02 Thread Ryan Hoegg
Hi,

Am I missing something or do we not have Ant tasks for the functionality 
available through the /admin application?  I have an itch, so if not I 
will be willing to contribute some code.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org



DO NOT REPLY [Bug 14193] New: - Tomcat doesn't restart if defined a new DefaultContext with a different Check Intervale time

2002-11-02 Thread bugzilla
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=14193.
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=14193

Tomcat doesn't restart if defined a new DefaultContext with a different Check 
Intervale time

   Summary: Tomcat doesn't restart if defined a new DefaultContext
with a different Check Intervale time
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Trying to create a new DefaultContext to set Tomcat to be Reloadable with 
a Check interval different of the default 15s, using http://localhost/admin.

The Web application works right, and after saving and commiting the changes, 
the server.xml is updated with the following lines:

DefaultContext className=org.apache.catalina.core.StandardDefaultContext 
cookies=true crossContext=true name=defaultContext reloadable=true 
swallowOutput=false useNaming=true 
wrapperClass=org.apache.catalina.core.StandardWrapper
Loader className=org.apache.catalina.loader.WebappLoader 
checkInterval=10 debug=0 delegate=false 
loaderClass=org.apache.catalina.loader.WebappClassLoader reloadable=true/
/DefaultContext

After that, Tomcat works well, but if you try to restart it, it crashes. At the 
end you can find the error message.

Also note that if you create a new DefaultContext and set Reloadable to 
true, but without altering the default Check interval, Tomcat restarts 
without problems. However, in this case, if you enter again in the 
http://localhost/admin web application, and click the new icon DefaultContext 
in the left panel, you will receive the message HTTP Status 500 - Error 
retrieving attribute debug.

Here is the error exception:

...
02/11/2002 14:55:55 org.apache.commons.digester.Digester startElement
SEVERE: Begin event threw exception
java.lang.ClassCastException
at org.apache.catalina.startup.CreateLoaderRule.begin(ContextRuleSe
a:306)
at org.apache.commons.digester.Digester.startElement(Digester.java:

at org.apache.xerces.parsers.AbstractSAXParser.startElement(Abstrac
arser.java:454)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement
ractXMLDocumentParser.java:217)
at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(XMLNamesp
nder.java:594)
at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDVa
or.java:777)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartE
t(XMLDocumentFragmentScannerImpl.java:748)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentCo
Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1453)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocume
LDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguratio
a:524)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguratio
a:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXPar
ava:1169)
at org.apache.commons.digester.Digester.parse(Digester.java:1495)
at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Catalina.start: java.lang.ClassCastException
java.lang.ClassCastException
at org.apache.commons.digester.Digester.createSAXException(Digester
:2312)
at org.apache.commons.digester.Digester.createSAXException(Digester
:2332)
at org.apache.commons.digester.Digester.startElement(Digester.java:

at org.apache.xerces.parsers.AbstractSAXParser.startElement(Abstrac
arser.java:454)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement
ractXMLDocumentParser.java:217)
at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(XMLNamesp
nder.java:594)
at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDVa
or.java:777)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartE
t(XMLDocumentFragmentScannerImpl.java:748)
at 

Setting Content Type in Servlet Filter fails

2002-11-02 Thread Scott Farquhar
Guys,

Currently, when a JSP is compiled to java code, it includes a line such as:

  response.setContentType(text/html;charset=ISO-8859-1);

However, this seems to preclude setting the content type in a servlet 
filter, as anything that is set in the filter is over-ridden by the JSP. 
 Eg, with our product JIRA - we must cater for many different character 
sets, and so we can't hard-code the characterset in the header of the 
JSP, and must set it at runtime.

To do so, we use a filter that does this:

  servletRequest.setCharacterEncoding(UTF-8);
  servletResponse.setContentType(text/html;charset=UTF-8);

Which works fine on Orion and Resin.  But fails on Tomcat and Jetty 
(presumably because they share the same JSP compilation engine).

You can't set it after the JSP has been called, because by then the 
response has been committed, and you can't set headers after that time.

There is already a bug raised in bugzilla for this:
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5715

Any ideas on how to fix it?  Could you make setContentType immutable? 
So only allow it to be set once?  Else change the JSP compiler so that 
it checks if contentType has already been set before setting it?

This prevents JIRA running on Tomcat with configurable charactersets, 
and presumably other applications are in the same position.

Thanks for your time.

Scott

--

ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support
---
Need a simple, powerful way to track and manage issues?
Try JIRA - http://www.atlassian.com/software/jira


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org



DO NOT REPLY [Bug 5715] - response.setContentType() in Filter.doFilter not changed content type

2002-11-02 Thread bugzilla
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=5715.
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=5715

response.setContentType() in Filter.doFilter not changed content type

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-02 18:24 ---
Currently, when a JSP is compiled to java code, it includes a line such as:

  response.setContentType(text/html;charset=ISO-8859-1);

However, this seems to preclude setting the content type in a servlet filter, as
anything that is set in the filter is over-ridden by the JSP.  Eg, with our
product JIRA - we must cater for many different character sets, and so we can't
hard-code the characterset in the header of the JSP, and must set it at runtime.

To do so, we use a filter that does this:

  servletRequest.setCharacterEncoding(UTF-8);
  servletResponse.setContentType(text/html;charset=UTF-8);

Which works fine on Orion and Resin.  But fails on Tomcat and Jetty (presumably
because they share the same JSP compilation engine).

You can't set it after the JSP has been called, because by then the response has
been committed, and you can't set headers after that time.

Any ideas on how to fix it?  Could you make setContentType immutable? So only
allow it to be set once?  Else change the JSP compiler so that it checks if
contentType has already been set before setting it?

This prevents JIRA running on Tomcat with configurable charactersets, and
presumably other applications are in the same position.

Scott
-- 
ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support
---
Need a simple, powerful way to track and manage issues?
Try JIRA - http://www.atlassian.com/software/jira

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 13723] - Bootstrap: Class loader creation threw exception

2002-11-02 Thread bugzilla
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=13723.
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=13723

Bootstrap: Class loader creation threw exception





--- Additional Comments From [EMAIL PROTECTED]  2002-11-02 19:25 ---
Created an attachment (id=3706)
java.lang.IllegalMonitorStateException: current thread not owner

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14195] New: - NPE from dispatch() when no errCode

2002-11-02 Thread bugzilla
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=14195.
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=14195

NPE from dispatch() when no errCode

   Summary: NPE from dispatch() when no errCode
   Product: Tomcat 4
   Version: 4.1.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The dispatch(Mark where, String errCode, Object[] args, Exception e) method in
the o.a.jasper.compiler.ErrorDispatcher throws an NPE when it's called from the
jspError(Exception e) method in the same class, since the errCode parameter is
null in this case.

A simple fix is to test for a null errCode and set a default message in this case:

// Localize
String errMsg = Unknown error message;
if (errCode != null) {
errMsg = getString(errCode, args);
}

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14195] - NPE from dispatch() when no errCode

2002-11-02 Thread bugzilla
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=14195.
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=14195

NPE from dispatch() when no errCode





--- Additional Comments From [EMAIL PROTECTED]  2002-11-02 23:23 ---
Actually, a better fix is to get the Exception message when errCode is null, to
at least give a hint about what's wrong:

  // Localize, if possible
  String errMsg = e.getMessage();
  if (errCode != null) {
  errMsg = getString(errCode, args);
  }

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14197] New: - Duplicate jspDestroy() when JSP page implements jspDestroy() and tag handler pooling enabled

2002-11-02 Thread bugzilla
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=14197.
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=14197

Duplicate jspDestroy() when JSP page implements jspDestroy() and tag handler pooling 
enabled

   Summary: Duplicate jspDestroy() when JSP page implements
jspDestroy() and tag handler pooling enabled
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Found this bug while attempting to deploy the bookstore3 example of the Java 
Web Services Tutorial (JWST).  Jasper seems to create duplicate jspDestroy() 
methods when a JSP page implements jspDestroy(), and uses custom tag 
libraries, and has Jasper's tag handler pooling enabled.

Immediate work-arounds are to turn off tag handler pooling or for a JSP author 
to not try to override jspDestroy().  However, since the ability to provide 
custom implementation of jspInit() and jspDestroy() is part of the JSP 1.2 
spec, this should be fixed.

The JWST example is as follows:

***
File:  tutorial/examples/web/bookstore3/web/bookstore.jsp

%@ taglib uri=http://jakarta.apache.org/struts/tags-bean-1.0.2; 
   prefix=bean %
%@ taglib uri=http://jakarta.apache.org/struts/tags-logic-1.0.2; 
   prefix=logic %
%@ include file=initdestroy.jsp %
%@ page import=java.util.* %
%
   ResourceBundle messages = (ResourceBundle)session.getAttribute(messages);
   if (messages == null) {
   Locale locale=null;
   String language = request.getParameter(language);

   if (language != null) { 
   if (language.equals(English)) { 
   locale=new Locale(en, ); 
   } else { 
   locale=new Locale(es, ); 
   }
   } else {
 locale = new Locale(en, );
   }
   messages = ResourceBundle.getBundle(BookStoreMessages, locale); 
   session.setAttribute(messages, messages);
  }
%
pb%=messages.getString(What)%/b/p
jsp:useBean id=bookDB class=database.BookDB scope=page 
  jsp:setProperty name=bookDB property=database value=%=bookDBAO% /
/jsp:useBean
jsp:setProperty name=bookDB property=bookId value=203 /
bean:define id=book name=bookDB property=bookDetails 
 type=database.BookDetails/
blockquotepema href=%=request.getContextPath()%/bookdetails?
bookId=203
jsp:getProperty name=book property=title//a/em, 
%=messages.getString(Talk)%/blockquote
pba href=%=request.getContextPath()%/catalog%=messages.getString
(Start)%/a/b


File: tutorial/examples/web/bookstore3/web/initdestroy.jsp

%@ page import=database.* %
%@ page errorPage=errorpage.jsp %
%!
  private BookDBAO bookDBAO;

  public void jspInit() {   

  bookDBAO = (BookDBAO)getServletContext().getAttribute(bookDB);
  if (bookDBAO == null) {
  System.out.println(Couldn't get database.);
  }
  }

  public void jspDestroy() {  
  bookDBAO = null;
  }
%
**

Jasper generated file: 
CATALINA_HOME/work/Standalone/localhost/bookstore3/bookstore_jsp.java

package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
import database.*;
import java.util.*;

public class bookstore_jsp extends HttpJspBase {

private BookDBAO bookDBAO;

public void jspInit() { 

bookDBAO = (BookDBAO)getServletContext().getAttribute(bookDB);
if (bookDBAO == null) {
System.out.println(Couldn't get database.);
}
}

public void jspDestroy() {  
bookDBAO = null;
}

private static java.util.Vector _jspx_includes;

static {
_jspx_includes = new java.util.Vector(1);
_jspx_includes.add(/initdestroy.jsp);
}

private org.apache.jasper.runtime.TagHandlerPool 
_jspx_tagPool_bean_define_type_property_name_id;

public bookstore_jsp() {
_jspx_tagPool_bean_define_type_property_name_id = new 
org.apache.jasper.runtime.TagHandlerPool();
}

public java.util.List getIncludes() {
return _jspx_includes;
}

public void jspDestroy() {
_jspx_tagPool_bean_define_type_property_name_id.release();
}

public void _jspService(HttpServletRequest request, HttpServletResponse 
response)
throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;
javax.servlet.jsp.PageContext pageContext = null;

DO NOT REPLY [Bug 14199] New: - Syntax error in jsp/xml/xml.jsp

2002-11-02 Thread bugzilla
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=14199.
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=14199

Syntax error in jsp/xml/xml.jsp

   Summary: Syntax error in jsp/xml/xml.jsp
   Product: Tomcat 4
   Version: 4.1.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jsp:root element doesn't declare the jsp namespace correctly. Instead of

jsp:root xmlns=http://java.sun.com/JSP/Page;
  version=1.2

is should be

jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  version=1.2

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14118] - JVM 1.4 dies when run as an NT service

2002-11-02 Thread bugzilla
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=14118.
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=14118

JVM 1.4 dies when run as an NT service





--- Additional Comments From [EMAIL PROTECTED]  2002-11-03 00:40 ---
I think this could be a *real* bug in the JavaService bits used
by Tomcat.  

I do not see the bug if I change the tomcat startup.bat
script to point to the server JVM.

-Eric

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14195] - NPE from dispatch() when no errCode

2002-11-02 Thread bugzilla
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=14195.
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=14195

NPE from dispatch() when no errCode





--- Additional Comments From [EMAIL PROTECTED]  2002-11-03 01:20 ---
Eh, turns out that there are case where the Exception is null as well. This
should be safe though:

  String errMsg = null;
  if (errCode != null) {
  errMsg = getString(errCode, args);
  }
  if (errMsg == null  e != null) {
  errMsg = e.getMessage();
  }

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




DO NOT REPLY [Bug 14200] New: - TLDs under WEB-INF are not scanned for URI mappings

2002-11-02 Thread bugzilla
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=14200.
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=14200

TLDs under WEB-INF are not scanned for URI mappings

   Summary: TLDs under WEB-INF are not scanned for URI mappings
   Product: Tomcat 4
   Version: 4.1.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Even though the JSP 1.2 spec is a bit vague on the subject, I'm pretty sure the
intention is that the auto-discovery of TLDs includes TLDs located directly in
the file system under WEB-INF, but the
org.apache.jasper.compiler.TldLocationsCache class only looks for TLDs in JAR
files under WEB-INF/lib. 

For consistency with which TLDs are used when scanning for listeners, I suggest
including all TLDs under WEB-INF (in addition to JAR files under WEB-INF/lib and
web.xml mappings) when the map is created.

I'll try to get this clarified in JSR-152.

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




cvs commit: jakarta-tomcat/src/doc serverxml.html

2002-11-02 Thread billbarker
billbarker2002/11/02 18:42:13

  Modified:src/doc  serverxml.html
  Log:
  Document new attribute to SessionId.
  
  Revision  ChangesPath
  1.29  +11 -3 jakarta-tomcat/src/doc/serverxml.html
  
  Index: serverxml.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- serverxml.html19 Sep 2002 11:13:18 -  1.28
  +++ serverxml.html3 Nov 2002 02:42:13 -   1.29
   -2501,13 +2501,21 
 /tr
 tr valign=top
   tdcheckSSLSessionIdbrb[Tomcat 3.3.1]/b/td
  -tdIf true, Tomcat session will be verified against SSL session to prevent
  +tdIf codetrue/code, Tomcat session will be verified against SSL session 
to prevent
 (malicious) use of other users' sessions. In order for this to work, SSL
 has to be enabled (through Apache) and SSL Session ID has to be known to
 Tomcat. More information can be found in mod_jk documentation./td
   tdfalse/td
 /tr
  -
  +  tr valign=top
  +tdsecureCookiebrb[Tomcat 3.3.2]/b/td
  +tdIf codetrue/code, then Tomcat will mark the Session ID cookie as
  +  as Secure if the session is created over a SSL connection.  A 
  +  conforming browser will only send the cookie back to a page that is using
  +  SSL.  The effect is that if a session is created from a SSL page, than 
  +  it is not available to any non-SSL pages./td
  +tdtrue/td
  +  /tr
   /table
   
   h4Example(s)/h4
  
  
  

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




cvs commit: jakarta-tomcat/src/doc serverxml.html

2002-11-02 Thread billbarker
billbarker2002/11/02 18:52:01

  Modified:src/doc  serverxml.html
  Log:
  Note to self:  check with the less-forgiving browser first.
  
  Revision  ChangesPath
  1.30  +2 -2  jakarta-tomcat/src/doc/serverxml.html
  
  Index: serverxml.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- serverxml.html3 Nov 2002 02:42:13 -   1.29
  +++ serverxml.html3 Nov 2002 02:52:01 -   1.30
   -2507,7 +2507,7 
 Tomcat. More information can be found in mod_jk documentation./td
   tdfalse/td
 /tr
  -  tr valign=top
  +  tr valign=top
   tdsecureCookiebrb[Tomcat 3.3.2]/b/td
   tdIf codetrue/code, then Tomcat will mark the Session ID cookie as
 as Secure if the session is created over a SSL connection.  A 
  
  
  

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org