BugRat Report #560 has been filed.
Bug report #560 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/560 REPORT #560 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Windows 2000 OS Release: 5.0 sp1 Platform: Windows, Sybase Synopsis: Authentication failes using the JDBCRealm with Sybase ASE 11.9.2 for Linux Description: Using the JDBCRealm for authentication with Sybase ASE 11.9.2 gives an authentication failed, dispite the fact that username and password are correct. This is due to the fact that the retrieved password from the database may contain trailing spaces if the datatype char is used instead of varchar. Title: BugRat Report # 560 BugRat Report # 560 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Allan Schweitz ([EMAIL PROTECTED]) Date Submitted: Dec 9 2000, 03:11:08 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Authentication failes using the JDBCRealm with Sybase ASE 11.9.2 for Linux Environment: (jvm, os, osrel, platform) 1.3, Windows 2000, 5.0 sp1, Windows, Sybase Additional Environment Description: Tomcat 3.2 running on JDK 1.3 on Windows 2000 connecting to Sybase ASE 11.9.2 running on Linux. Report Description: Using the JDBCRealm for authentication with Sybase ASE 11.9.2 gives an authentication failed, dispite the fact that username and password are correct. This is due to the fact that the retrieved password from the database may contain trailing spaces if the datatype char is used instead of varchar. How To Reproduce: null Workaround: null View this report online...
pre compile
Hi all Does anybody know how do i compile all jsps at once from command line or whatever. I do not want to go to each page to have them compiled. Thanks = Cengiz Kayay WebObjects/JAVA Consultant __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
RE: Handler/ServletWrapper/Error handling
Hi Larry, Suggestion 1) In Handler and ServletWrapper some calls are made to contextM.handleStatus() and contextM.handleError(). I think it would be an improvement to add handlerStatus() and handleError() to Handler, which would make the call to contextM.handleXXX. This would allow, ServletWrapper could hook these if needed. For example, a ServletWrapper.handleError() could check for UnavailableExceptions and take some action if desired. Easy to do, seems a good idea. What about adding handleInitException() and handleServiceException() - since a ClassNotFound will have different effects ( 404 if in init, normal error if in service - the first means the servlet wasn't found, the second may happen if the servlet does a Class.forName with a class that is not found ). There is another hook I want to add, preInit() - that can be called before preServletInit / init / postServletInit. It'll be used to prepare the handler for preServletInit ( i.e. loadServlet, check if still unavailable). That would make a very clean implementation of unavailable, and avoid calling pre/post too often. ( the rule should be that preInit / init / postInit are called at least once before service() - some people expect init() to be called only once, but that's not true since UnavailableException may determine a another attempt. ) Suggesion 2) Since "inclusion", as far as I can tell, is only implemented in RequestDispatcherImpl it could be considered a Servlet 2.2 thing. With Suggestion 1 above, tests for res.isIncluded() could move to ServletWrapper. I'm not sure if Handler needs to be "inclusion" aware. That would be good for better separating the layers. Great ! Question) Mainly to provide better default output for UnavailableExceptions, I was looking to implement an interceptor in facade22, say Servlet22ErrorHandler, that could provide additional error handling support. Preferrably it could override some of ErrorHandler's behavior, as opposed to replacing ErrorHandler completely. There is a general problem with this with regard to the order the contextInit() and handleError() methods would be called. Servlet22ErrorHandler would want its contextInit() called after ErrorHandler's, but would want its handleError() called before ErrorHandler's!? Maybe handleError() methods could be called in reverse order of appearance in server.xml? Or is ErrorHandler only replacable? Ideas? ErrorHandler is the result of refactoring the error processing code and an attempt to make it more modular. It's the first round - I expect / hope it'll be replaced with a better version based on what we learn. Regarding ordering/chaining of hooks, there are few options: 1. We can move ErrorHandler after Servlet22EH ( or just replace it ). 2. We can enhance the code to do what Apache2.0 does - accept a FIRST, BEGGINING, END, LAST options for the hooks. That's the best solution, but it's a bit complex ( and I would leave it at the end, after we finish everything else in core / bug fixes / etc.). I think it's more important to finish the core objects and freeze the core API - and then work on individual modules and replace them if needed - that can continue after 3.3 is released, since modules can be added/replaced without need for a tomcat release. If the suggestions make sense in your patches go ahead and include them. +1 BTW, what about a more radical aproach - just remove init/destroy from handler, leave only service() ( eventually renamed to "invoke" :-) ? The whole init/destroy machine is servlet-specific - none of the internal handlers are using it and the modules have access to all the Interceptor notifications anyway. The only reason for keeping the init/destroy is to enforce the pre/postInit calling - but we can move this responsibility to the ServletInterceptor. That would make Handler really easy, clean up and simplify ServletWrapper. Costin
Re: how to maintain session between HTTP and HTTPS?
In a load balanced environment, this is tricky with people behind a IP randomizing proxy (like AOL). If you use all SSL, the load balancer can track the SSL session ID across different IPs. If you use all non-SSL, you can track with a cookie. You can use IP based sticky if the IP stays the same. Its tricky if you have to mix more than one of those. What we're doing is using IP sticky with our load balancers, with mod_jk sending all new sessions to the local server, and redistributing them to the proper server if they aren't local. I might write up a document describing how we run Tomcat in this environment if anybody is interested. Paul
[PROPOSAL] JSSI for Tomcat
After seeing a number of users on the TC user list asking about support for servlet tags and NCSA SSI directives, I decided to port Apache JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is what to do with it ;-) If anyone is interested in this, I propose the following: 1) Make this a new Jakarta subproject, named jakarta-jssi. The reason for this is that it's an optional module and it can live its own life outside the container development. Note! This requires approval by the PMC, but I want to see what this group thinks about it before I make a proposal to the PMC. 2) Support only for TC 3.2 initially Since JSSI is dependent on the TC internals, it needs to be adapted for each architecture. For instance, in TC 3.2 there's a package named org.apache.tomcat.facade that is used by JSSI, but in TC 3.3 the package is named org.apache.tomcat.facade2.2, and in TC 4.0 facades are not used at all so a different integration is needed. The current port works with TC 3.2. When the others get released, the integration code can be factored out into a very small, pluggable class. 3) Package structure (for TC 3.2 version) In order to integrate with Tomcat's Context and ServletWrapper classes (for servlet loading and execution), the JSSI classes should be in org.apache.tomcat.* packages, and at least one of them must be in the org.apache.tomcat.facade package specifically. Keeping basically the original internal package structure but adjusted to Tomcat, I suggest the following packages: org.apache.tomcat.facade One class (ServletTagHandler) org.apache.tomcat.ssi Main classes org.apache.tomcat.ssi.util SGMLTag org.apache.tomcat.ssi.io PositionReader If you're positive to this proposal, I'll approach PMC about the new subproject and try to get it set up ASAP. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 1:48 PM, "Hans Bergsten" [EMAIL PROTECTED] wrote: After seeing a number of users on the TC user list asking about support for servlet tags and NCSA SSI directives, I decided to port Apache JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is what to do with it ;-) If anyone is interested in this, I propose the following: 1) Make this a new Jakarta subproject, named jakarta-jssi. The reason for this is that it's an optional module and it can live its own life outside the container development. Note! This requires approval by the PMC, but I want to see what this group thinks about it before I make a proposal to the PMC. No approval by the PMC is necessary. This has already been voted on and approved. It is part of the migration of Java Apache projects over to Jakarta. 2) Support only for TC 3.2 initially Since JSSI is dependent on the TC internals, it needs to be adapted for each architecture. For instance, in TC 3.2 there's a package named org.apache.tomcat.facade that is used by JSSI, but in TC 3.3 the package is named org.apache.tomcat.facade2.2, and in TC 4.0 facades are not used at all so a different integration is needed. The current port works with TC 3.2. When the others get released, the integration code can be factored out into a very small, pluggable class. Having it be integrated in is fine. 3) Package structure (for TC 3.2 version) In order to integrate with Tomcat's Context and ServletWrapper classes (for servlet loading and execution), the JSSI classes should be in org.apache.tomcat.* packages, and at least one of them must be in the org.apache.tomcat.facade package specifically. Keeping basically the original internal package structure but adjusted to Tomcat, I suggest the following packages: org.apache.tomcat.facade One class (ServletTagHandler) org.apache.tomcat.ssi Main classes org.apache.tomcat.ssi.util SGMLTag org.apache.tomcat.ssi.io PositionReader If you're positive to this proposal, I'll approach PMC about the new subproject and try to get it set up ASAP. +1 Again, you don't need PMC approval because you already have it. -jon -- Honk if you love peace and quiet.
Re: [PROPOSAL] JSSI for Tomcat
Jon Stevens wrote: [...] 1) Make this a new Jakarta subproject, named jakarta-jssi. The reason for this is that it's an optional module and it can live its own life outside the container development. Note! This requires approval by the PMC, but I want to see what this group thinks about it before I make a proposal to the PMC. No approval by the PMC is necessary. This has already been voted on and approved. It is part of the migration of Java Apache projects over to Jakarta. I know the migration of Java Apache projects has been discussed, but I have not seen a formal decision being made by PMC. So I like to run it by the PMC anyway, but based on what you say it sounds like it will not be any problem then. Another thing. If the migrated JSSI is supposed to continue to support JServ (sounds reasonable), maybe this should be called TSSI instead to avoid confusion (since it relies on TC internals and use TC package names). An alternative would be to keep the JSSI name but use TC package names and make it work with JServ as well as TC 3.2 in the initial version. Comments? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
RE: Handler/ServletWrapper/Error handling
Easy to do, seems a good idea. What about adding handleInitException()
and
handleServiceException() - since a ClassNotFound will have different
effects ( 404 if in init, normal error if in service - the first means
the
servlet wasn't found, the second may happen if the servlet does a
Class.forName with a class that is not found ).
+1
There is another hook I want to add, preInit() - that can be called
before
preServletInit / init / postServletInit. It'll be used to prepare the
handler for preServletInit ( i.e. loadServlet, check if still
unavailable). That would make a very clean implementation of
unavailable,
and avoid calling pre/post too often.
+1
1. We can move ErrorHandler after Servlet22EH ( or just replace it ).
Since default error output now only occurs at the top level request, my desire was to
have a "notFoundHandler" that could show the "included"
request URI if that was where the "not found" occurred. (Handy during development.)
With EH after Servlet22EH, EH is going to call ctx.addErrorPage("404",...)
after Servlet22EH, replacing the enhanced handler with the default one.
If we put EH before ServletEH, then EH's handleError() gets called
first. Though it will find Servlet22EH's handler for "404", other things
may not work right. :-(
2. We can enhance the code to do what Apache2.0 does - accept a FIRST,
BEGGINING, END, LAST options for the hooks. That's the best solution,
but
it's a bit complex ( and I would leave it at the end, after we finish
everything else in core / bug fixes / etc.).
I still think there might be a case for saying that the nature of a
interceptor method implies whether a new instance is appended or
inserted at the beginning. I haven't spent much time looking at the
issue, but at this moment, contextInit() looks to me like an "append"
(interceptors added later are called later) and handleError() looks like
an "insert at beginning" (interceptors added later are called earlier).
With this, the placing the "overrider" after the "overridee" will work and you can
override error handlers all you want. With just FIRST,
BEGINNING, END, LAST, once an interceptor uses one, you limit what
another "overriding" interceptor can use and still work.
BTW, what about a more radical aproach - just remove init/destroy from
handler, leave only service() ( eventually renamed to "invoke" :-) ?
The whole init/destroy machine is servlet-specific - none of the
internal
handlers are using it and the modules have access to all the Interceptor
notifications anyway.
This appeals to me too. +1
Lary
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 3:55 PM, "Hans Bergsten" [EMAIL PROTECTED] wrote: I know the migration of Java Apache projects has been discussed, but I have not seen a formal decision being made by PMC. So I like to run it by the PMC anyway, but based on what you say it sounds like it will not be any problem then. This has already been formalized and even advertised as happening. Look at the Jakarta and Java Apache homepages as it clearly discusses this. In essence, I'm just trying to save everyone time here. Another thing. If the migrated JSSI is supposed to continue to support JServ (sounds reasonable) No need to do that. , maybe this should be called TSSI instead to avoid confusion (since it relies on TC internals and use TC package names). An alternative would be to keep the JSSI name but use TC package names and make it work with JServ as well as TC 3.2 in the initial version. Comments? +1 for TSSI. -jon
Re: [PROPOSAL] JSSI for Tomcat
Jon Stevens wrote: on 12/9/2000 3:55 PM, "Hans Bergsten" [EMAIL PROTECTED] wrote: I know the migration of Java Apache projects has been discussed, but I have not seen a formal decision being made by PMC. So I like to run it by the PMC anyway, but based on what you say it sounds like it will not be any problem then. This has already been formalized and even advertised as happening. Look at the Jakarta and Java Apache homepages as it clearly discusses this. In essence, I'm just trying to save everyone time here. Another thing. If the migrated JSSI is supposed to continue to support JServ (sounds reasonable) No need to do that. , maybe this should be called TSSI instead to avoid confusion (since it relies on TC internals and use TC package names). An alternative would be to keep the JSSI name but use TC package names and make it work with JServ as well as TC 3.2 in the initial version. Comments? +1 for TSSI. If it is Tomcat-specific, is there any reason it really needs to be a separate Jakarta project at all? Why not just absorb it into Tomcat? In terms of CVS repositories, if the amount of version-dependent code is large it would be easier just to put it in the existing version repositories as an optional feature. If it's mostly independent with just a few links, a separate CVS repository, under the auspices of the Tomcat project, seems to be much more straightforward. -jon Craig
Re: [PROPOSAL] JSSI for Tomcat
"Craig R. McClanahan" wrote: [...] If it is Tomcat-specific, is there any reason it really needs to be a separate Jakarta project at all? Why not just absorb it into Tomcat? In terms of CVS repositories, if the amount of version-dependent code is large it would be easier just to put it in the existing version repositories as an optional feature. If it's mostly independent with just a few links, a separate CVS repository, under the auspices of the Tomcat project, seems to be much more straightforward. There are a few reasons I suggested a separate Jakarta project: 1) Since it's optional, not part of the Servlet spec, and most likely of interest to less than the majority, keeping it in the main TC project just adds overhead (larger downloads, more to build, etc.) 2) Initially, it only supports TC 3.2. But 3.2 is in bugfix mode, so adding this as a new module (feature) in 3.2.1 doesn't seem right. 3) Except for a small amount of code that's needed to tie into the servlet container, it's independent from the various containers. I have not made any attempts to refactor the code yet, but the container interface could be a very simple class. It would then be easy to add interfaces to non-Tomcat containers as well. Keeping it as a separate project means that all improvements automatically applies to all supported containers. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/examples ShowSource.java
craigmcc00/12/09 19:12:19
Modified:webapps/examples/WEB-INF/classes/examples ShowSource.java
Log:
Fix a security vulnerability. The "ShowSource" custom tag, in conjunction with
the "/examples/jsp/source.jsp" page, could be used to expose sensitive data in
the WEB-INF and META-INF directories of a web application.
Revision ChangesPath
1.2 +3 -1
jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/examples/ShowSource.java
Index: ShowSource.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/examples/ShowSource.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ShowSource.java 2000/08/17 00:57:58 1.1
+++ ShowSource.java 2000/12/10 03:12:19 1.2
@@ -20,7 +20,9 @@
}
public int doEndTag() throws JspException {
- if (jspFile.indexOf( ".." ) = 0)
+ if ((jspFile.indexOf( ".." ) = 0) ||
+(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
+(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
throw new JspTagException("Invalid JSP file " + jspFile);
InputStream in
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 6:21 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: If it is Tomcat-specific, is there any reason it really needs to be a separate Jakarta project at all? Why not just absorb it into Tomcat? Problem with that in my eyes is that Tomcat is supposed to be the reference implementation of the Servlet and JSP spec's, not of SSI. -jon -- Honk if you love peace and quiet.
Re: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java
on 12/9/2000 7:07 PM, "[EMAIL PROTECTED]"
[EMAIL PROTECTED] wrote:
+(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
+(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
Seems like it would be better to define this as a constant somewhere...
public static final String WEB_INF = "/WEB-INF";
Also, I think you should remove the trailing / because the extra character
comparison isn't needed and could cause issues if it isn't there (although
it probably wouldn't be...). :-)
-jon
--
Honk if you love peace and quiet.
Re: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java
Jon Stevens wrote:
on 12/9/2000 7:07 PM, "[EMAIL PROTECTED]"
[EMAIL PROTECTED] wrote:
+(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
+(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
Seems like it would be better to define this as a constant somewhere...
public static final String WEB_INF = "/WEB-INF";
I suppose, although there's only one place within the core servlet container
that these directories are significant (in the module that handles static
resources), so a constant would only be used once.
In the case at hand, this is an *application* level component (the ShowSource
custom tag used on the "source.jsp" page, inherited back from JSDK 2.1 days)
that is deliberately ignoring the restrictions of the servlet spec, and you
would not want to make compiling it dependent on the servlet container core
classes anyway ...
Also, I think you should remove the trailing / because the extra character
comparison isn't needed and could cause issues if it isn't there (although
it probably wouldn't be...). :-)
Your suggestion would mean I could not have a directory "WEB-INF-stuff" or
"META-INF-data" in my webapp treated like any other directory. That's going
beyond protecting people and into the realm of infringing their freedom :-).
-jon
--
Honk if you love peace and quiet.
Craig
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
pierred 00/12/09 21:56:44
Modified:jasper/src/share/org/apache/jasper Constants.java
jasper/src/share/org/apache/jasper/compiler
BeanGenerator.java JspParseEventListener.java
ParserXJspSaxHandler.java
Log:
Take 2 on the default list of imports for JSP generated classes.
Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception.
All that's left is org.apache.jasper.runtime.*.
That will be in take 3 (eventually :-))
[Thanks to Craig for "waking me up" on this...]
Revision ChangesPath
1.6 +0 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Constants.java2000/12/09 05:45:47 1.5
+++ Constants.java2000/12/10 05:56:43 1.6
@@ -95,10 +95,7 @@
"javax.servlet.http.*",
"javax.servlet.jsp.*",
"javax.servlet.jsp.tagext.*",
- "java.io.IOException",
- "java.beans.Beans",
"org.apache.jasper.runtime.*",
- "org.apache.jasper.JasperException"
};
/**
1.4 +5 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanGenerator.java
Index: BeanGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanGenerator.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BeanGenerator.java2000/11/30 21:47:47 1.3
+++ BeanGenerator.java2000/12/10 05:56:43 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanGenerator.java,v
1.3 2000/11/30 21:47:47 pierred Exp $
- * $Revision: 1.3 $
- * $Date: 2000/11/30 21:47:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanGenerator.java,v
1.4 2000/12/10 05:56:43 pierred Exp $
+ * $Revision: 1.4 $
+ * $Date: 2000/12/10 05:56:43 $
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
@@ -350,11 +350,11 @@
writer.pushIndent ();
if (beanRT == false)
writer.println(varname+" = ("+ convert +
-") Beans.instantiate(this.getClass().getClassLoader(), "+
+")
java.beans.Beans.instantiate(this.getClass().getClassLoader(), "+
writer.quoteString(clsname) +");");
else
writer.println(varname+" = ("+ convert +
-") Beans.instantiate(this.getClass().getClassLoader(), "+
+")
java.beans.Beans.instantiate(this.getClass().getClassLoader(), "+
clsname +");");
writer.popIndent ();
writer.println ("} catch (Exception exc) {");
1.18 +5 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JspParseEventListener.java2000/12/09 00:36:10 1.17
+++ JspParseEventListener.java2000/12/10 05:56:43 1.18
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.17 2000/12/09 00:36:10 pierred Exp $
- * $Revision: 1.17 $
- * $Date: 2000/12/09 00:36:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.18 2000/12/10 05:56:43 pierred Exp $
+ * $Revision: 1.18 $
+ * $Date: 2000/12/10 05:56:43 $
*
*
*
@@ -297,7 +297,7 @@
writer.println("private static boolean _jspx_inited = false;");
writer.println();
-writer.println("public final void _jspx_init() throws JasperException {");
+writer.println("public final void _jspx_init() throws
org.apache.jasper.JasperException {");
writer.pushIndent();
generateAll(InitMethodPhase.class);
writer.popIndent();
@@ -309,7 +309,7 @@
"HttpServletRequest request, "+
"HttpServletResponse response)");
- writer.println("throws IOException, ServletException {");
+ writer.println("throws java.io.IOException,
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
[EMAIL PROTECTED] wrote: pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the default list of imports for JSP generated classes. Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception. All that's left is org.apache.jasper.runtime.*. That will be in take 3 (eventually :-)) [Thanks to Craig for "waking me up" on this...] Sorry, but I don't see what difference this change make. You're not removing dependencies, just removing imports and replacing them with FQCNs in the code. Why? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
Hans Bergsten wrote: [EMAIL PROTECTED] wrote: pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the default list of imports for JSP generated classes. Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception. All that's left is org.apache.jasper.runtime.*. That will be in take 3 (eventually :-)) [Thanks to Craig for "waking me up" on this...] Sorry, but I don't see what difference this change make. You're not removing dependencies, just removing imports and replacing them with FQCNs in the code. Why? Agree. Does not make a difference besides having a shorter import list. [Craig had made a comment about "java.Beans.*", but in fact I was only importing java.beans.Beans.] Might be better to leave those in the import list to make the dependency clear. What do you think? -- Pierre Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
Hans Bergsten wrote: Pierre Delisle wrote: Hans Bergsten wrote: [EMAIL PROTECTED] wrote: pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the default list of imports for JSP generated classes. Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception. All that's left is org.apache.jasper.runtime.*. That will be in take 3 (eventually :-)) [Thanks to Craig for "waking me up" on this...] Sorry, but I don't see what difference this change make. You're not removing dependencies, just removing imports and replacing them with FQCNs in the code. Why? Agree. Does not make a difference besides having a shorter import list. [Craig had made a comment about "java.Beans.*", but in fact I was only importing java.beans.Beans.] Might be better to leave those in the import list to make the dependency clear. What do you think? In general, I prefer imports for the reason you mention; it makes it easier to see all dependencies. In generated JSP compilation classes, the important thing is not to have other complete package imports than the ones in the spec, but FQCN imports can't hurt anything. So, yeah, I think it's better to keep imports like java.beans.Beans and org.apache.jasper.Exception. Actually, it could make a difference. Assuming tomcat puts the import 'java.beans.Beans' in all generated JSP servlet classes, then a developer using Tomcat can use 'Beans' in a scriptlet without having to worry about the import. However, when porting the JSP page to another engine, the compile could fail if the target JSP container uses a FQCN in the generated code rather than an import statement as tomcat does. Given this, it then makes sense to limit the import list to the 'default' one mentioned in the spec. Container specific FQCN imports are also OK, but anything else should not be part of the import list. Does that make sense? -- Pierre
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
Pierre Delisle wrote: Hans Bergsten wrote: [...] In general, I prefer imports for the reason you mention; it makes it easier to see all dependencies. In generated JSP compilation classes, the important thing is not to have other complete package imports than the ones in the spec, but FQCN imports can't hurt anything. So, yeah, I think it's better to keep imports like java.beans.Beans and org.apache.jasper.Exception. Actually, it could make a difference. Assuming tomcat puts the import 'java.beans.Beans' in all generated JSP servlet classes, then a developer using Tomcat can use 'Beans' in a scriptlet without having to worry about the import. However, when porting the JSP page to another engine, the compile could fail if the target JSP container uses a FQCN in the generated code rather than an import statement as tomcat does. Given this, it then makes sense to limit the import list to the 'default' one mentioned in the spec. Container specific FQCN imports are also OK, but anything else should not be part of the import list. Does that make sense? Yes, you're right, of course :-) Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
