DO NOT REPLY [Bug 10407] - Tomcat Memory Management
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=10407. 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=10407 Tomcat Memory Management --- Additional Comments From [EMAIL PROTECTED] 2003-01-29 08:03 --- Hi, We tried calling System.gc() explicitly and it seems to work, at least in windows. Hope this works for others too. regards, Srikanth. S - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16531] New: - Updating already deployed .war files in a single step
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=16531. 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=16531 Updating already deployed .war files in a single step Summary: Updating already deployed .war files in a single step Product: Tomcat 4 Version: 4.1.20 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After a WAR file is deployed and unpacked by Tomcat, irrespective of the value of the unpackWARs attribute in server.xml, replacing the WAR file with a newer version (an upgrade) does nothing, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpacked files are deleted). If the WAR file is updated, it's *probably* safe to assume that this was done voluntarily, and so any previous unpacked version should be removed then replaced. This was discussed on the tomcat-dev mailing list on 22nd January 2002. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16532] New: - TagLibraryInfoImpl produces NullPointerException
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=16532.
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=16532
TagLibraryInfoImpl produces NullPointerException
Summary: TagLibraryInfoImpl produces NullPointerException
Product: Tomcat 4
Version: 4.1.12
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I ran JspC via the ant-task proposed by the JavaDocs (taskdef
classname=org.apache.jasper.JspC name=jasper2/) on a I think quite normal webapp
like
so:
jasper2 verbose=0
uriroot=${webapp.dir}
outputDir=${jsp.output.dir}
classDebugInfo=true
compile=true/
(running directly from jspc.sh made no
difference to the problem.)
But this failed at the first file with a NullPointerException in
TagLibraryInfoImpl around line 212, which is a catch clause stating
Constants.message(
jsp.error.taglib.jarFileException,
new Object[] {url.toString(),
ex.getMessage()},
Logger.ERROR);
But url is null in my situation.
I investigated
the cause and found it to be around line 192 which says
if(ctxt.getClassLoader() != null
URLClassLoader.class.equals(ctxt.getClassLoader().getClass())
path.startsWith(/))
path = path.substring(1,path.length());
In my situation this
resulted in the paths to JARs of taglibs I use to be truncated from
/WEB-INF/lib/thejar.jar to
WEB-INF/lib/thejar.jar, which in turn of course causes a MalformedURLException at
the next
line,
url = ctxt.getResource(path);
which is caught at the well-known catch-clause - but url is
null!
Frankly, I don't understand the URLClassLoader thing at all, but what I do understand
is that the catch-clause, which would have reported the malformed URL or some other
useful
Exception containing information about the problem at hand, instead produces a
genuinely
unhelpful NullPointerException.
What confuses me most, though, is this: after I removed
the URLClassloader-statements, JspC compiled my webapp just fine...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16331] - don't override the default port for the channelSocket
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=16331. 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=16331 don't override the default port for the channelSocket [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor Priority|Other |Low Version|4.1.19 |4.1.18 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
? to find servlets and their cpu usage at runtime
I want to find the names of servlets running on the tomcat 4.0 server at a particular time with their corresponding CPU usage. Please send me either some tool available or some way of doing this - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-jk-ant
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-01-29/jakarta-tomcat-jk-ant.html Buildfile: build.xml does not exist! Build failed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ap..cache
Hi all, recently I've been thinking about a way to implement a cache mechanism in Apache-Tomcat interaction (e.g. ajp13). I'd be really grateful if you gave me some suggestions or advice on the matter. Below I shortly describe what I've built as a kind of prototype. To sum up, I've modified mod_jk (win2000) in some points in order to make it cache-aware. I've introduced in httpd.conf the following directives: # # normal jk directives # JkMount /*.jsp ajp13 #Cache extensions JkCache on JkCacheDirectory C:\cache This is, basically, the collaboration diagram I've implemented: · mod_jk intercepts request for /pippo/cachetest.jsp; · mod_jk asks Tomcat, at the moment actually a WebApp controller, for a list of dirty items in cache folder; · then, mod_jk deletes dirty-bit pages in the cache; · now mod_jk manages current request. If it finds the page in the cache it returns static file to Apache. · Otherwise it requires the resource back to the WebApp controller. The latter knows if the page is to be cached and puts a special tag on the byte stream in response, after having dynamically built it; · mod_jk receives the response and if it does contain the above mentioned tag, mod_jk writes it in the cache folder before sending it to Apache. If there's a query string, it'll include it in the static resource name. The second and third steps are an overload respect to normal interaction, but that permits to save a lot of elaborating time and network roundtrips when you ask for a very heavy resource (e.g a jsp which loads many non-volatile and quite stable data from a db). All that seems to work fine...According to your opinion is a worth-to-develop idea? Thanks in advance for your advise! Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ? to find servlets and their cpu usage at runtime
Here is what my mail server said about you ;). -Original Message- From: gautamjha [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 10:57 AM To: [EMAIL PROTECTED] Subject: *SPAM* ? to find servlets and their cpu usage at runtime SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (7.20 hits, 5 required) SPAM: RCVD_IN_ORBS (2.2 points) RBL: Received via a relay in orbs.dorkslayers.com SPAM:[RBL check: found 97.102.86.203.orbs.dorkslayers.com.] SPAM: RCVD_IN_OSIRUSOFT_COM (0.4 points) RBL: Received via a relay in relays.osirusoft.com SPAM:[RBL check: found 97.102.86.203.relays.osirusoft.com., type: 127.0.0.4] SPAM: X_OSIRU_SPAM_SRC (2.7 points) RBL: DNSBL: sender is Confirmed Spam Source I want to find the names of servlets running on the tomcat 4.0 server at a particular time with their corresponding CPU usage. Please send me either some tool available or some way of doing this MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?
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=9931. 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=9931 Base64 decoder chokes on a whitespace: FASTER? --- Additional Comments From [EMAIL PROTECTED] 2003-01-29 12:30 --- I've just been bitten by this bug. Nice to see the patch is available, but I would like to call your attention to RFC2045: The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. So, it seems discardWhitespace() should either discard all non-base64 characters or throw an exception. As the patch stands, other invalid characters will still silently corrupt the data. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina Wrapper.java
remm2003/01/29 04:41:47 Modified:catalina/src/share/org/apache/catalina Wrapper.java Log: - Add a way to get the mappings associated with a wrapper (there was none which of course is a problem unless the mapper is the context itself). Revision ChangesPath 1.2 +26 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Wrapper.java Index: Wrapper.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Wrapper.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Wrapper.java 18 Jul 2002 16:47:38 - 1.1 +++ Wrapper.java 29 Jan 2003 12:41:47 - 1.2 @@ -205,6 +205,14 @@ /** + * Add a mapping associated with the Wrapper. + * + * @param pattern The new wrapper mapping + */ +public void addMapping(String mapping); + + +/** * Add a new security role reference record to the set of records for * this servlet. * @@ -260,6 +268,12 @@ /** + * Return the mappings associated with this wrapper. + */ +public String[] findMappings(); + + +/** * Return the security role link for the specified security role * reference name, if any; otherwise return codenull/code. * @@ -302,6 +316,14 @@ * @param listener The listener to remove */ public void removeInstanceListener(InstanceListener listener); + + +/** + * Remove a mapping associated with the wrapper. + * + * @param mapping The pattern to remove + */ +public void removeMapping(String mapping); /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
remm2003/01/29 04:42:21
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Add a way to get the mappings associated with a wrapper (there was none
which of course is a problem unless the mapper is the context itself).
Revision ChangesPath
1.14 +53 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StandardWrapper.java 27 Jan 2003 23:33:10 - 1.13
+++ StandardWrapper.java 29 Jan 2003 12:42:20 - 1.14
@@ -66,6 +66,7 @@
import java.io.PrintStream;
+import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Stack;
@@ -187,6 +188,12 @@
/**
+ * Mappings associated with the wrapper.
+ */
+private ArrayList mappings = new ArrayList();
+
+
+/**
* The initialization parameters for this servlet, keyed by
* parameter name.
*/
@@ -620,6 +627,21 @@
/**
+ * Add a mapping associated with the Wrapper.
+ *
+ * @param pattern The new wrapper mapping
+ */
+public void addMapping(String mapping) {
+
+synchronized (mappings) {
+mappings.add(mapping);
+}
+fireContainerEvent(addMapping, mapping);
+
+}
+
+
+/**
* Add a new security role reference record to the set of records for
* this servlet.
*
@@ -776,6 +798,18 @@
/**
+ * Return the mappings associated with this wrapper.
+ */
+public String[] findMappings() {
+
+synchronized (mappings) {
+return (String[]) mappings.toArray(new String[mappings.size()]);
+}
+
+}
+
+
+/**
* Return the security role link for the specified security role
* reference name, if any; otherwise return codenull/code.
*
@@ -1041,6 +1075,21 @@
public void removeInstanceListener(InstanceListener listener) {
instanceSupport.removeInstanceListener(listener);
+
+}
+
+
+/**
+ * Remove a mapping associated with the wrapper.
+ *
+ * @param mapping The pattern to remove
+ */
+public void removeMapping(String mapping) {
+
+synchronized (mappings) {
+mappings.remove(mapping);
+}
+fireContainerEvent(removeMapping, mapping);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2003/01/29 04:43:26
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- Don't generate useless garbage in the critical path (if the value is used later,
toString can be called on the object).
Revision ChangesPath
1.58 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- Http11Processor.java 20 Jan 2003 23:47:05 - 1.57
+++ Http11Processor.java 29 Jan 2003 12:43:26 - 1.58
@@ -582,7 +582,7 @@
socket.setSoTimeout(soTimeout);
}
inputBuffer.parseRequestLine();
-thrA.setParam( threadPool, request.requestURI().toString());
+thrA.setParam( threadPool, request.requestURI() );
keptAlive = true;
if (!disableUploadTimeout) {
socket.setSoTimeout(timeout);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
remm2003/01/29 04:45:33
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
- Allow URI to grow.
Revision ChangesPath
1.2 +2 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Mapper.java 28 Jan 2003 18:14:51 - 1.1
+++ Mapper.java 29 Jan 2003 12:45:33 - 1.2
@@ -370,6 +370,8 @@
MappingData mappingData)
throws Exception {
+uri.setLimit(-1);
+
Context[] contexts = null;
Context context = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina HttpRequest.java
remm2003/01/29 04:49:32 Modified:catalina/src/share/org/apache/catalina HttpRequest.java Log: - Add access to memory efficient buffers, as was mentioned over the past months. This allows manipulating the various paths available in the request. - Similar accessors will be added for headers, etc. Revision ChangesPath 1.2 +38 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/HttpRequest.java Index: HttpRequest.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/HttpRequest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- HttpRequest.java 18 Jul 2002 16:47:37 - 1.1 +++ HttpRequest.java 29 Jan 2003 12:49:32 - 1.2 @@ -67,8 +67,10 @@ import java.security.Principal; import java.util.Locale; + import javax.servlet.http.Cookie; +import org.apache.tomcat.util.buf.MessageBytes; /** * An bHttpRequest/b is the Catalina internal facade for an @@ -157,6 +159,14 @@ /** + * Get the context path. + * + * @return the context path + */ +public MessageBytes getContextPathMB(); + + +/** * Set the context path for this Request. This will normally be called * when the associated Context is mapping the Request to a particular * Wrapper. @@ -184,6 +194,14 @@ /** + * Get the path info. + * + * @return the path info + */ +public MessageBytes getPathInfoMB(); + + +/** * Set the path information for this Request. This will normally be called * when the associated Context is mapping the Request to a particular * Wrapper. @@ -245,6 +263,22 @@ * @return the URL decoded request URI */ public String getDecodedRequestURI(); + + +/** + * Get the decoded request URI. + * + * @return the URL decoded request URI + */ +public MessageBytes getDecodedRequestURIMB(); + + +/** + * Get the servlet path. + * + * @return the servlet path + */ +public MessageBytes getServletPathMB(); /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core DummyRequest.java
remm2003/01/29 04:49:41
Modified:catalina/src/share/org/apache/catalina/core
DummyRequest.java
Log:
- Add access to memory efficient buffers, as was mentioned over the
past months. This allows manipulating the various paths available in the request.
- Similar accessors will be added for headers, etc.
Revision ChangesPath
1.4 +22 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
Index: DummyRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DummyRequest.java 28 Jan 2003 19:07:30 - 1.3
+++ DummyRequest.java 29 Jan 2003 12:49:41 - 1.4
@@ -102,6 +102,8 @@
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
+
+import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.naming.resources.Resource;
import org.apache.naming.resources.DirContextURLStreamHandler;
import org.apache.naming.resources.DirContextURLConnection;
@@ -158,6 +160,10 @@
return (contextPath);
}
+public MessageBytes getContextPathMB() {
+return null;
+}
+
public ServletRequest getRequest() {
return (this);
}
@@ -166,6 +172,10 @@
return decodedURI;
}
+public MessageBytes getDecodedRequestURIMB() {
+return null;
+}
+
public FilterChain getFilterChain() {
return (this.filterChain);
}
@@ -190,12 +200,20 @@
pathInfo = path;
}
+public MessageBytes getPathInfoMB() {
+return null;
+}
+
public String getServletPath() {
return servletPath;
}
public void setServletPath(String path) {
servletPath = path;
+}
+
+public MessageBytes getServletPathMB() {
+return null;
}
public ValveContext getValveContext() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2003/01/29 04:49:59
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Update wrapper mappings.
Revision ChangesPath
1.16 +10 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- StandardContext.java 28 Jan 2003 18:18:39 - 1.15
+++ StandardContext.java 29 Jan 2003 12:49:58 - 1.16
@@ -1814,6 +1814,8 @@
synchronized (servletMappings) {
servletMappings.put(pattern, name);
}
+Wrapper wrapper = (Wrapper) findChild(name);
+wrapper.addMapping(pattern);
fireContainerEvent(addServletMapping, pattern);
}
@@ -3233,9 +3235,12 @@
*/
public void removeServletMapping(String pattern) {
+String name = null;
synchronized (servletMappings) {
-servletMappings.remove(pattern);
+name = (String) servletMappings.remove(pattern);
}
+Wrapper wrapper = (Wrapper) findChild(name);
+wrapper.removeMapping(pattern);
fireContainerEvent(removeServletMapping, pattern);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContextValve.java
remm2003/01/29 04:50:53
Modified:catalina/src/share/org/apache/catalina/core
StandardContextValve.java
Log:
- Optimize checks for /WEB-INF and /META-INF.
Revision ChangesPath
1.4 +36 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
Index: StandardContextValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardContextValve.java 12 Sep 2002 20:40:37 - 1.3
+++ StandardContextValve.java 29 Jan 2003 12:50:52 - 1.4
@@ -67,10 +67,15 @@
import java.io.IOException;
import java.io.PrintWriter;
+
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.naming.NamingException;
+
+import org.apache.tomcat.util.buf.CharChunk;
+import org.apache.tomcat.util.buf.MessageBytes;
+
import org.apache.naming.ContextBindings;
import org.apache.naming.resources.DirContextURLStreamHandler;
import org.apache.catalina.Container;
@@ -156,15 +161,31 @@
}
// Disallow any direct access to resources under WEB-INF or META-INF
-HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
-String contextPath = hreq.getContextPath();
-String requestURI = ((HttpRequest) request).getDecodedRequestURI();
-String relativeURI =
-requestURI.substring(contextPath.length()).toUpperCase();
-if (relativeURI.equals(/META-INF) ||
-relativeURI.equals(/WEB-INF) ||
-relativeURI.startsWith(/META-INF/) ||
-relativeURI.startsWith(/WEB-INF/)) {
+HttpRequest hreq = (HttpRequest) request;
+MessageBytes contextPathMB = hreq.getContextPathMB();
+int length = contextPathMB.getLength();
+MessageBytes decodedURIMB = hreq.getDecodedRequestURIMB();
+decodedURIMB.toChars();
+CharChunk decodedURIBC = decodedURIMB.getCharChunk();
+int bcLength = decodedURIBC.getLength();
+boolean notFound = false;
+if (decodedURIBC.startsWithIgnoreCase(/META-INF, length)) {
+if ((decodedURIBC.getLength() == (/META-INF.length() + length))
+|| (decodedURIBC.getBuffer()[/META-INF.length() + length]
+== '/')) {
+notFound = true;
+}
+}
+if (decodedURIBC.startsWithIgnoreCase(/WEB-INF, length)) {
+if ((decodedURIBC.getLength() == (/WEB-INF.length() + length))
+|| (decodedURIBC.getBuffer()[/WEB-INF.length() + length]
+== '/')) {
+System.out.println(Not found);
+notFound = true;
+}
+}
+if (notFound) {
+String requestURI = hreq.getDecodedRequestURI();
notFound(requestURI, (HttpServletResponse) response.getResponse());
return;
}
@@ -176,11 +197,13 @@
try {
wrapper = (Wrapper) context.map(request, true);
} catch (IllegalArgumentException e) {
+String requestURI = hreq.getDecodedRequestURI();
badRequest(requestURI,
(HttpServletResponse) response.getResponse());
return;
}
if (wrapper == null) {
+String requestURI = hreq.getDecodedRequestURI();
notFound(requestURI, (HttpServletResponse) response.getResponse());
return;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java CoyoteConnector.java CoyoteRequest.java
remm2003/01/29 04:54:59
Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
Added: coyote/src/java/org/apache/coyote/tomcat5
MapperListener.java
Log:
- Use the new mapper.
- This will very likely cause problems (although for now the old mapper still tries
to
map requests whcih have not been fully mapped). If it does, the mapper
can be uncommented easily in CoyoteAdapter.postParseRequest.
- Currently, the new mapper intgroduces a quite nasty B2C conversion on the
URI, which will be addressed.
Revision ChangesPath
1.11 +10 -2
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CoyoteConnector.java 28 Jan 2003 18:19:38 - 1.10
+++ CoyoteConnector.java 29 Jan 2003 12:54:59 - 1.11
@@ -70,8 +70,8 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-import org.apache.tomcat.util.http.mapper.Mapper;
import org.apache.tomcat.util.IntrospectionUtils;
+import org.apache.tomcat.util.http.mapper.Mapper;
import org.apache.coyote.Adapter;
import org.apache.coyote.ProtocolHandler;
@@ -329,6 +329,12 @@
private Mapper mapper = new Mapper();
+ /**
+ * Mapper listener.
+ */
+ private MapperListener mapperListener = new MapperListener(mapper);
+
+
// - Properties
@@ -1113,6 +1119,8 @@
(sm.getString
(coyoteConnector.protocolHandlerStartFailed, e));
}
+
+mapperListener.init();
}
1.16 +57 -37
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CoyoteRequest.java28 Jan 2003 18:19:38 - 1.15
+++ CoyoteRequest.java29 Jan 2003 12:54:59 - 1.16
@@ -100,8 +100,11 @@
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
+import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.http.FastHttpDateFormat;
import org.apache.tomcat.util.http.Parameters;
+import org.apache.tomcat.util.http.mapper.MappingData;
+import org.apache.tomcat.util.net.SSLSupport;
import org.apache.coyote.ActionCode;
import org.apache.coyote.Request;
@@ -124,9 +127,6 @@
import org.apache.catalina.util.StringManager;
import org.apache.catalina.util.StringParser;
-import org.apache.tomcat.util.http.mapper.MappingData;
-import org.apache.tomcat.util.net.SSLSupport;
-
/**
* Wrapper object for the Coyote request.
*
@@ -272,24 +272,6 @@
/**
- * Context path.
- */
-protected String contextPath = ;
-
-
-/**
- * Path info.
- */
-protected String pathInfo = null;
-
-
-/**
- * Servlet path.
- */
-protected String servletPath = null;
-
-
-/**
* User principal.
*/
protected Principal userPrincipal = null;
@@ -396,9 +378,6 @@
inputBuffer.recycle();
usingInputStream = false;
usingReader = false;
-contextPath = ;
-pathInfo = null;
-servletPath = null;
userPrincipal = null;
sessionParsed = false;
requestParametersParsed = false;
@@ -1475,9 +1454,9 @@
public void setContextPath(String path) {
if (path == null) {
-this.contextPath = ;
+mappingData.contextPath.setString();
} else {
-this.contextPath = path;
+mappingData.contextPath.setString(path);
}
}
@@ -1512,7 +1491,7 @@
* @param path The path information
*/
public void setPathInfo(String path) {
-this.pathInfo = path;
+mappingData.pathInfo.setString(path);
}
@@ -1589,6 +1568,16 @@
/**
+ * Get the decoded request URI.
+ *
+ * @return the URL decoded request URI
+ */
+public MessageBytes getDecodedRequestURIMB() {
+return (coyoteRequest.decodedURI());
+}
+
+
+/**
* Set the servlet path for this Request.
DO NOT REPLY [Bug 16540] New: - tomcat shut's down after an unknown time
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=16540. 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=16540 tomcat shut's down after an unknown time Summary: tomcat shut's down after an unknown time Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The tomcatserver shut's down after a unknown period of little activity( this can be within an hour or after 2 days). In the log's I can't find anything wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16541] New: - jndi realm role search cannot handle \ in user dn correctly
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=16541. 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=16541 jndi realm role search cannot handle \ in user dn correctly Summary: jndi realm role search cannot handle \ in user dn correctly Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] User DN contains \ e.g CN=Haaf\, Armin,CN=Users,DC=mercatis,DC=de role search did not return any roles, because it interprets the \, as an escaped , Solution replace all \ in user dn with \\ in the getRoles method of the JNDIRealm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ap..cache
Fabio, We're achieving a good cache result by using mod_proxy and its built in proxy cache. We have: Front servers that do caching and backservers that runs the tomcat. The fron servers runs apache and mod_proxy. Any request coming in to example www.foo.com/index.jsp is proxied through to the back hosts where another apache is listening on port 80. The apache on the back host uses mod_jk to connect to Tomcat which serves the page. mod_proxy on the fron hosts has a proxy cache which can be used to cache our jsp pages. There are some simple rules to follow when you want a jsp to be cached in a generic web cache (see HTTP protocol for details on web caches). We got it sorted so that a request that comes into the front hosts, will only result in a revalidation (If-Modified-Since) to the back hosts. The jsp page can be coded to deal with this type of request and can then tell the front hosts to serve the cached page or return a new one. Martin -Original Message- From: Fabio Salvi [mailto:[EMAIL PROTECTED]] Sent: 29 January 2003 10:43 To: [EMAIL PROTECTED] Subject: Ap..cache Hi all, recently I've been thinking about a way to implement a cache mechanism in Apache-Tomcat interaction (e.g. ajp13). I'd be really grateful if you gave me some suggestions or advice on the matter. Below I shortly describe what I've built as a kind of prototype. To sum up, I've modified mod_jk (win2000) in some points in order to make it cache-aware. I've introduced in httpd.conf the following directives: # # normal jk directives # JkMount /*.jsp ajp13 #Cache extensions JkCache on JkCacheDirectory C:\cache This is, basically, the collaboration diagram I've implemented: . mod_jk intercepts request for /pippo/cachetest.jsp; . mod_jk asks Tomcat, at the moment actually a WebApp controller, for a list of dirty items in cache folder; . then, mod_jk deletes dirty-bit pages in the cache; . now mod_jk manages current request. If it finds the page in the cache it returns static file to Apache. . Otherwise it requires the resource back to the WebApp controller. The latter knows if the page is to be cached and puts a special tag on the byte stream in response, after having dynamically built it; . mod_jk receives the response and if it does contain the above mentioned tag, mod_jk writes it in the cache folder before sending it to Apache. If there's a query string, it'll include it in the static resource name. The second and third steps are an overload respect to normal interaction, but that permits to save a lot of elaborating time and network roundtrips when you ask for a very heavy resource (e.g a jsp which loads many non-volatile and quite stable data from a db). All that seems to work fine...According to your opinion is a worth-to-develop idea? Thanks in advance for your advise! Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16160] - Upload problem: Stream ended unexpectedly
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=16160. 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=16160 Upload problem: Stream ended unexpectedly --- Additional Comments From [EMAIL PROTECTED] 2003-01-29 14:56 --- Also fails under RedHat 7.3 and Tomcat 4.1.17-LE-jdk14 using Apache/2.0.43 (Unix) mod_jk2/2.0.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf MessageBytes.java
remm2003/01/29 07:20:25
Modified:util/java/org/apache/tomcat/util/buf MessageBytes.java
Log:
- Byte based setInt.
Revision ChangesPath
1.8 +33 -6
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java
Index: MessageBytes.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MessageBytes.java 12 Jul 2002 18:00:14 - 1.7
+++ MessageBytes.java 29 Jan 2003 15:20:25 - 1.8
@@ -583,13 +583,40 @@
* be done in headers
*/
public void setInt(int i) {
- // XXX replace it with a byte[] tool
recycle();
- strValue=String.valueOf( i );
- intValue=i;
- hasIntValue=true;
- hasStrValue=true;
- type=T_STR;
+byteC.allocate(16, 32);
+int current = i;
+byte[] buf = byteC.getBuffer();
+int start = 0;
+int end = 0;
+if (i == 0) {
+buf[end++] = (byte) '0';
+}
+if (i 0) {
+current = -i;
+buf[end++] = (byte) '-';
+}
+while (current 0) {
+int digit = current % 10;
+current = current / 10;
+buf[end++] = HexUtils.HEX[digit];
+}
+byteC.setEnd(end);
+// Inverting buffer
+end--;
+if (i 0) {
+start++;
+}
+while (end start) {
+byte temp = buf[start];
+buf[start] = buf[end];
+buf[end] = temp;
+start++;
+end--;
+}
+intValue=i;
+hasIntValue=true;
+type=T_BYTES;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 InputBuffer.java OutputBuffer.java
remm2003/01/29 07:35:22 Modified:coyote/src/java/org/apache/coyote/tomcat5 InputBuffer.java OutputBuffer.java Log: - The request is a thread safe component - use non synced collections. Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/InputBuffer.java Index: InputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/InputBuffer.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- InputBuffer.java 5 Jan 2003 17:20:41 - 1.3 +++ InputBuffer.java 29 Jan 2003 15:35:22 - 1.4 @@ -63,7 +63,7 @@ import java.io.IOException; import java.io.Reader; import java.io.UnsupportedEncodingException; -import java.util.Hashtable; +import java.util.HashMap; import org.apache.tomcat.util.buf.B2CConverter; import org.apache.tomcat.util.buf.ByteChunk; @@ -161,7 +161,7 @@ /** * List of encoders. */ -protected Hashtable encoders = new Hashtable(); +protected HashMap encoders = new HashMap(); /** 1.6 +2 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java Index: OutputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- OutputBuffer.java 9 Jan 2003 18:15:05 - 1.5 +++ OutputBuffer.java 29 Jan 2003 15:35:22 - 1.6 @@ -63,7 +63,7 @@ import java.io.OutputStream; import java.io.UnsupportedEncodingException; import java.io.Writer; -import java.util.Hashtable; +import java.util.HashMap; import org.apache.tomcat.util.buf.ByteChunk; import org.apache.tomcat.util.buf.C2BConverter; @@ -167,7 +167,7 @@ /** * List of encoders. */ -protected Hashtable encoders = new Hashtable(); +protected HashMap encoders = new HashMap(); /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Splitting authentication and authorization.
Costin Manolache wrote:
What about this:
instead of 3 methods, have a single method:
interface Authorization {
boolean hasPermission( HttpServletRequest, Permission perm )
}
115, not 155 :-)
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will return false. Then we will need to set the
proper error message on the HttpServletResponse:
((HttpServletResponse) response.getResponse()).sendError( )
If the method only return false, then we will not be able to properly
set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
I would prefer having:
interface Authorization {
boolean hasPermission( HttpServletResponse, Permission p )
}
since p should contains all the information required to grant/denied the request.
or
interface Authorization {
boolean hasPermission( HttpServletRequest, HttpServletResponse, String role )
}
if we don't want a Permission object.
Based on the permission type, we will be able to discover if it's a
Resource/UserData/Role call.
I'm still trying to figure out the hack in JSR155 ( with the
permission per request ) - but if you understand
I hope I understand a little...I did participate in the
definition/implementation of the specs :-)
it we can even
use
boolean implies( Permission currentRequestPermission,
Permission targetPermission )
Here I assume targetPermission is a permission that we have created when
reading the web.xml (right?). We will have a collection of
targetPermission. To make it work, we will have to do:
for (int i; i targetPermissionCollection; i++){
...implies(currentRequestPermission, targetPermissionCollection(i));
}
I would prefer having:
Provider
--
boolean implies( ProtectionDomain currentRequestPermission,
Permission currentRequestPermission )
Here is how I see the process (simplified):
(1) when Tomcat starts, create the Policy (Provider is we standardize on 115)
(2) when deploying web.xml, created the appropriate Permission object (proprietary or 115) and store them inside a PolicyConfiguration object.
(3) each PolicyConfiguration will be stored in the Policy
(4) during a request, AuthenticatorBase will
4.1 create a Permission object
4.2 invoke Authorization.hasPermission()
4.3 invoke the Policy.implies()
4.4 Based on the ProtectionDomain, the Policy will locate the proper PolicyConfiguration, get the permission collection and do a PermissionCollection.implies(currentRequestPermission).
This way the Autorization implementation doesn't have to know anything about web.xml permission.
The bigest problem is when we create the permission (at deployment time). We have to use the url pattern matching rule to creates all the possible permissions. Performance staregy will be required here (I will buy Remy's book :-) )
Where currentRequestPermission will hold info about the request.
When we decide to support JSR155 - we can either make our Permission
implement the JSR155 classes, or change the code to support both
kinds of Permissions.
Even if we support 155 - we'll still need our own implementation -
for optimizations, recycle, etc.
It seems Authorization interface is needed - at least from reading
155. BTW, in the draft I'm reading there is also the option of using
Policy ( which would not require the security manager ).
My understanding was that the security manager and permissions are one.
I like the idea of using the Policy without the Security Manager. I will
read a little on the subject
-- Jeanfrancois
Costin
Costin Manolache wrote:
It seems I missread your post, I tought you would add another
authentication interface too ...
But I still don't like the interface :-)
I need to think about it.
I'm pretty sure we can use Policy, Permission, etc without a security
manager, and it would be better to go directly to use those.
One problem is in parameter passing ( since HttpServletRequest and
all other info must be available when making the policy decission ).
The authentication layer should be able to return a Principal
that is associated with the request. And the authorization layer shouldn't
care about the request - only about the Principal and the required
permission.
In other words - all security constraints can be converted to Permissions
( no need for 3 methods in the interface - just one method that checks
a particular Permission ).
The problem mentioned about JBoss is due to the fact that the
authorization layer calls the authentication ( this seems to be the case
in your proposal as well ). A request that doesn't have a security
constraint will not try to set the Principal.
Costin
since the last time I've proposed to split
Authentication/Authorization, we have moved to JMX Listerner as hooks
and standardize on JMX, I would like to
error compiling mod_jk
Hi list! My platform is HPUX 11.0, Tomcat 3.3.1, Apache 1.3.19 The command I'm using to compile is: apxs -I$JAVA_HOME/include -I$JAVA_HOME/include/hpux -I../jk -o mod_jk.so -c *.c ../common/*.c The error msg I've got is: gcc -DHPUX11 -DMOD_SSL=208103 -I/usr/local/php-4.0.6 -I/usr/local/php-4.0.6/main -I/usr/local/php-4.0.6/main -I/usr/local/php-4.0.6/Zend -I/usr/local/php-4.0.6/ Zend -I/usr/local/php-4.0.6/TSRM -I/usr/local/php-4.0.6/TSRM -I/usr/local/php-4. 0.6 -DEAPI -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -DKRB5 -I/usr/local/a pache/include -I/opt/java1.3/include -I/opt/java1.3/include/hpux -I../jk -c ../ common/jk_worker.c In file included from ../common/jk_global.h:69, from ../common/jk_logger.h:65, from ../common/jk_ajp12_worker.h:65, from ../common/jk_worker_list.h:80, from ../common/jk_worker.c:63: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdlib.h:28: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t his is the location of the previous definition -o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_sockbuf.o jk_pool.o jk_nwmain.o jk_msg_buff.o jk_map.o jk_lb_worker.o jk_jni_worker.o jk_connect.o j k_ajp13_worker.o jk_ajp13.o jk_ajp12_worker.o mod_jk.o apxs:Break: Command failed with rc=16777215 Thanks for your help !! Gustavo A. Edelstein
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteConnector.java CoyoteRequest.java
remm2003/01/29 08:39:11
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
CoyoteConnector.java CoyoteRequest.java
Log:
- Allow configuring the URI B2C decoding.
- Fast conversion for ASCII.
Revision ChangesPath
1.9 +59 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CoyoteAdapter.java28 Jan 2003 18:19:38 - 1.8
+++ CoyoteAdapter.java29 Jan 2003 16:39:11 - 1.9
@@ -67,7 +67,9 @@
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
+import org.apache.tomcat.util.buf.B2CConverter;
import org.apache.tomcat.util.buf.ByteChunk;
+import org.apache.tomcat.util.buf.CharChunk;
import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.http.Cookies;
import org.apache.tomcat.util.http.ServerCookie;
@@ -237,7 +239,6 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
req.getURLDecoder().convert(req.decodedURI(), false);
-req.decodedURI().setEncoding(UTF-8);
// Normalize decoded URI
if (!normalize(req.decodedURI())) {
@@ -268,6 +269,9 @@
request.setUserPrincipal(new CoyotePrincipal(principal));
}
+// URI character decoding
+convertURI(req.decodedURI(), request);
+
// Request mapping
connector.getMapper().map(req.serverName(), req.decodedURI(),
request.getMappingData());
@@ -359,6 +363,56 @@
}
request.setCookies(cookies);
+
+}
+
+
+/**
+ * Character conversion of the URI.
+ */
+protected void convertURI(MessageBytes uri, CoyoteRequest request)
+throws Exception {
+
+ByteChunk bc = uri.getByteChunk();
+CharChunk cc = uri.getCharChunk();
+cc.allocate(bc.getLength(), -1);
+
+String enc = connector.getURIEncoding();
+if (enc != null) {
+B2CConverter conv = request.getURIConverter();
+try {
+if (conv == null) {
+conv = new B2CConverter(enc);
+request.setURIConverter(conv);
+} else {
+conv.recycle();
+}
+} catch (IOException e) {
+// Ignore
+log(Invalid URI encoding; using HTTP default);
+connector.setURIEncoding(null);
+}
+if (conv != null) {
+try {
+conv.convert(bc, cc);
+uri.setChars(cc.getBuffer(), cc.getStart(),
+ cc.getLength());
+return;
+} catch (IOException e) {
+log(Invalid URI character encoding; trying ascii);
+cc.recycle();
+}
+}
+}
+
+// Default encoding: fast conversion
+byte[] bbuf = bc.getBuffer();
+char[] cbuf = cc.getBuffer();
+int start = bc.getStart();
+for (int i = 0; i bc.getLength(); i++) {
+cbuf[i] = (char) (bbuf[i + start] 0xff);
+}
+uri.setChars(cbuf, 0, bc.getLength());
}
1.12 +29 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CoyoteConnector.java 29 Jan 2003 12:54:59 - 1.11
+++ CoyoteConnector.java 29 Jan 2003 16:39:11 - 1.12
@@ -335,6 +335,12 @@
private MapperListener mapperListener = new MapperListener(mapper);
+ /**
+ * URI encoding.
+ */
+ private String URIEncoding = null;
+
+
// - Properties
@@ -878,6 +884,28 @@
this.tcpNoDelay = tcpNoDelay;
}
+
+
+ /**
+ * Return the character encoding to be used for the URI.
+ */
+ public String getURIEncoding() {
+
+ return (this.URIEncoding);
+
+ }
+
+
+ /**
+ * Set the URI encoding to be used for the URI.
+ *
+ * @param URIEncoding The new
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
jfarcand2003/01/29 09:04:22
Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
FIX a NPE exception when the enumeration is null.
Revision ChangesPath
1.20 +11 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- JspServlet.java 28 Jan 2003 18:15:49 - 1.19
+++ JspServlet.java 29 Jan 2003 17:04:21 - 1.20
@@ -230,11 +230,14 @@
log.debug(\t QueryString: + request.getQueryString());
log.debug(\t Request Params: );
Enumeration e = request.getParameterNames();
- while (e.hasMoreElements()) {
- String name = (String) e.nextElement();
- log.debug(\t\t + name + = +
- request.getParameter(name));
- }
+
+if (e != null) {
+while (e.hasMoreElements()) {
+String name = (String) e.nextElement();
+log.info(\t\t + name + = +
+ request.getParameter(name));
+}
+}
}
serviceJspFile(request, response, jspUri, null, precompile);
} catch (RuntimeException e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16550] New: - Parse error for Context/docBase
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=16550. 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=16550 Parse error for Context/docBase Summary: Parse error for Context/docBase Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a docBase Context doc-base folder ends with '.xml' extension (attribute docBase of Context element in server.xml), Tomcat writes a number of exceptions to logs. Same thing (with different exception) happens if the doc- base folder is a symbolic link with '.xml' at the end. Still it seems that Tomcat handles requests for this context with no problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
jfarcand2003/01/29 10:20:08
Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
Add a small comment to remind that the case occurs only when DummyRequest is used.
Thsi method should never return a null enumration.
Revision ChangesPath
1.21 +5 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspServlet.java 29 Jan 2003 17:04:21 - 1.20
+++ JspServlet.java 29 Jan 2003 18:20:08 - 1.21
@@ -231,6 +231,8 @@
log.debug(\t Request Params: );
Enumeration e = request.getParameterNames();
+// Occurs only when DummyRequest is used (this method never
+// when used in the normal case return null
if (e != null) {
while (e.hasMoreElements()) {
String name = (String) e.nextElement();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Splitting authentication and authorization.
Jeanfrancois Arcand wrote:
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will return false. Then we will need to set the
proper error message on the HttpServletResponse:
If we look at JSR115, it sugests creating several (3?) permission objects -
each will be associated with the request.
The creation of those objects will be part of the container ( probably in
a valve or other module ).
The point is that all _authorization_ decisions will be deletated to
a plugin - tomcat will just make the calls. It will be tomcat's
job to provide the arguments and deal with the response.
((HttpServletResponse) response.getResponse()).sendError( )
I don't think mixing HTTP request processing in the authorizer is a good
idea, and it seems JSR115 ( at least the published draft ) is on the same
side.
Let the authorizer deal with authorization - if the permissions
( to a URI, method, transport ) are valid.
If the method only return false, then we will not be able to properly
set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
Another reason to let the authorizer deal with authorization and nothing
else. A false will mean FORBIDDEN. ( we can still know what was forbidden
- we'll have to check 3 different permissions )
I would prefer having:
interface Authorization {
boolean hasPermission( HttpServletResponse, Permission p )
}
You can get the Response from the Request - passing one or both is the same.
Again - that would mean the authorizer will deal with HTTP processing, that
will keep code complex.
The JSR115 aproach is IMO much better - all the information that must be
checked ( URI, method, etc ) is passed as part of the requested permission.
since p should contains all the information required to grant/denied the
request.
Exactly - there is no need to pass the response/request. If you really want
- you can cast the permission to TomcatRequestPermission and get the source
request and response.
or
interface Authorization {
boolean hasPermission( HttpServletRequest, HttpServletResponse, String
role )
}
if we don't want a Permission object.
I don't see why not. ( and it's not one, but few ). This is far more
flexible.
Based on the permission type, we will be able to discover if it's a
Resource/UserData/Role call.
+1
I'm still trying to figure out the hack in JSR155 ( with the
permission per request ) - but if you understand
I hope I understand a little...I did participate in the
definition/implementation of the specs :-)
Good to know :-)
it we can even
use
boolean implies( Permission currentRequestPermission,
Permission targetPermission )
Here I assume targetPermission is a permission that we have created when
reading the web.xml (right?). We will have a collection of
targetPermission. To make it work, we will have to do:
Sorry - I meant PermissionCollection for the second argument, and yes - it
includes all the permissions from the web.xml ( and maybe the permissions
from the policy - if in sandbox mode ).
for (int i; i targetPermissionCollection; i++){
...implies(currentRequestPermission, targetPermissionCollection(i));
}
I would prefer having:
Provider
--
boolean implies( ProtectionDomain currentRequestPermission,
Permission currentRequestPermission )
Yes, that's what I had in mind too - except PermissionCollection instead
of ProtectionDomain.
Actually - I have a better idea ( IMHO :-):
Request {
...
Permissions requestPermissions[]; - we add this to coyote request ( with
getter/setter )
}
Context {
PermissionCollection authorizer;
}
The Authorizer will just be an implementation of PermissionCollection.
It seems JSR115 is a bit confused about this - in 4.7 it lists 6
alternatives for checking. I don't see why anything more than providing a
PermissionCollection and using impies() would be needed.
But I'm fine with ProtectionDomain - it adds the CodeSource of the
context ( which is good ). Not sure what the principals would be.
Here is how I see the process (simplified):
(1) when Tomcat starts, create the Policy (Provider is we standardize on
115)
There is no requirement on that - we can create a ProtectionDomain or
Policy without 115. ( well, we already do - AFAIK - for the class loader ).
(2) when deploying web.xml, created the appropriate Permission object
(proprietary or 115) and store them inside a PolicyConfiguration object.
That's my biggest problem with 115 :-)
All J2EE is moving toward JMX - and they define yet another config API.
Sorry - I will vote for proprietary here ( actually - JMX ). The Policy
will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean
server is
Error when compiling JSP page with taglib using JspC
I ran into an Error when compile JSP page with taglib using JspC. This happens with the Jasper in Tomcat 4.1.12. The root of the exception is thrown by ServletContext.getResource, the exception is MalformedURLException. After some digging, the following code (in TagLibraryInfoImpl.java) looks dubious, because it intentionally strips out the / at the beginning of the path, however the Serlvet spec requires the path to be start with /. See http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContext.html#getResource(java.lang.String) if(ctxt.getClassLoader() != null URLClassLoader.class.equals(ctxt.getClassLoader().getClass()) path.startsWith(/)) path = path.substring(1,path.length()) ; So I suggest to change the above lines to the following to guarantee that path is started with /: if(ctxt.getClassLoader() != null URLClassLoader.class.equals(ctxt.getClassLoader().getClass()) !path.startsWith(/)) path = / +path ; One thing that I haven't spent much time on is that why JSP pages with Taglib compiled OK in Tomcat, I just assume that it might be executing the different code path. If a regular Jasper developer could examine if the above change makes sense, I would like submit the change to the code base. Since I am not a regular developer, I am just posting to the list for now. -- Kelly Chen Tumbleweed Communication Corp. T:650-216-2043 700 Saginaw Drive F:650-216-2565 Redwood City, CA 94063 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServlet.java
[EMAIL PROTECTED] wrote: jfarcand2003/01/29 10:20:08 Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java Log: Add a small comment to remind that the case occurs only when DummyRequest is used. Thsi method should never return a null enumration. The thing is that the DummyRequest had as few things as possible being implemented, and it is used for request dispatcher mapping as well as . You can add whatever is needed ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServlet.java
OK Then I will remove that and create a dummy enumeration instead :-) -- Jeanfrancois Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/01/29 10:20:08 Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java Log: Add a small comment to remind that the case occurs only when DummyRequest is used. Thsi method should never return a null enumration. The thing is that the DummyRequest had as few things as possible being implemented, and it is used for request dispatcher mapping as well as . You can add whatever is needed ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] New mapper
Remy Maucherat wrote: The mapper has a currently unused dependency on JNDI, and I plan to put it in the org.apache.tomcat.util.http.mapper package. JNDI deps are fine - dependencies on org.apache.naming are not very good ( since tomcat can be used in an app that uses a different naming impl ). How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite obvious, but I think I missed it in 1.1. The static queries are of course similar. It's the same - register a listener on the MBeanServerDelegate. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
remm2003/01/29 12:03:21
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
MappingData.java
Log:
- Also compute a request path field.
Revision ChangesPath
1.3 +9 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Mapper.java 29 Jan 2003 12:45:33 - 1.2
+++ Mapper.java 29 Jan 2003 20:03:21 - 1.3
@@ -494,6 +494,8 @@
(path.equals(extensionWrappers[pos].name))) {
mappingData.wrapperPath.setChars
(buf, servletPath, pathEnd - servletPath);
+mappingData.requestPath.setChars
+(buf, servletPath, pathEnd - servletPath);
mappingData.wrapper = extensionWrappers[pos].object;
}
path.setOffset(servletPath);
@@ -538,6 +540,8 @@
if (mappingData.wrapper == null) {
if (context.defaultWrapper != null) {
mappingData.wrapper = context.defaultWrapper.object;
+mappingData.requestPath.setChars
+(path.getBuffer(), path.getStart(), path.getLength());
mappingData.wrapperPath.setChars
(path.getBuffer(), path.getStart(), path.getLength());
}
@@ -556,6 +560,7 @@
(Wrapper[] wrappers, CharChunk path, MappingData mappingData) {
int pos = find(wrappers, path);
if ((pos != -1) (path.equals(wrappers[pos].name))) {
+mappingData.requestPath.setString(wrappers[pos].name);
mappingData.wrapperPath.setString(wrappers[pos].name);
mappingData.wrapper = wrappers[pos].object;
}
@@ -590,6 +595,8 @@
path.getOffset() + length,
path.getLength() - length);
}
+mappingData.requestPath.setChars
+(path.getBuffer(), path.getOffset(), path.getLength());
mappingData.wrapper = wrappers[pos].object;
}
}
@@ -865,7 +872,7 @@
MessageBytes host = MessageBytes.newInstance();
host.setString(iowejoiejfoiew);
MessageBytes uri = MessageBytes.newInstance();
-uri.setString(/foo/bar/blah/);
+uri.setString(/foo/bar/blah/bobou/foo);
uri.toChars();
uri.getCharChunk().setLimit(-1);
@@ -908,6 +915,7 @@
System.out.println(contextPath: + mappingData.contextPath);
System.out.println(wrapperPath: + mappingData.wrapperPath);
+System.out.println(requestPath: + mappingData.requestPath);
System.out.println(pathInfo: + mappingData.pathInfo);
System.out.println(redirectPath: + mappingData.redirectPath);
1.2 +2 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/MappingData.java
Index: MappingData.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/MappingData.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MappingData.java 28 Jan 2003 18:14:51 - 1.1
+++ MappingData.java 29 Jan 2003 20:03:21 - 1.2
@@ -73,6 +73,7 @@
public Object wrapper = null;
public MessageBytes contextPath = MessageBytes.newInstance();
+public MessageBytes requestPath = MessageBytes.newInstance();
public MessageBytes wrapperPath = MessageBytes.newInstance();
public MessageBytes pathInfo = MessageBytes.newInstance();
@@ -83,6 +84,7 @@
context = null;
wrapper = null;
pathInfo.recycle();
+requestPath.recycle();
wrapperPath.recycle();
contextPath.recycle();
redirectPath.recycle();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] New mapper
Remy Maucherat wrote: Speaking of which, I'm missing a registration for the hosts (I don't know if it's defined in JSR 77). Could we add some custom attributes on the object name for wrapper (giving the mapping), as well as the host registration, and still comply with the spec (I'd say yes, but ...) ? Sure. JSR77 is very thin - way too thin. It doesn't forbid container-specific objects - but leves the naming open. The only issue - we need to get rid of the Listeners and move the JMX registration in the core objects. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] New mapper
Costin Manolache wrote: Remy Maucherat wrote: The mapper has a currently unused dependency on JNDI, and I plan to put it in the org.apache.tomcat.util.http.mapper package. JNDI deps are fine - dependencies on org.apache.naming are not very good ( since tomcat can be used in an app that uses a different naming impl ). Well, I'm still unsure about physical welcome files. On the plus side, it would be considerably faster to do that in the mapper. How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite obvious, but I think I missed it in 1.1. The static queries are of course similar. It's the same - register a listener on the MBeanServerDelegate. I tried that, and get a lot of nice notifications about registration, but how do I get the ObjectName of the MBean which caused the notification (the source of the Notification is the server delegate, which doesn't help). ? Help :-P Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina HttpRequest.java
remm2003/01/29 12:20:46 Modified:catalina/src/share/org/apache/catalina HttpRequest.java Log: - Add request path field (basically, it's servletPath + pathInfo, which is very convinient to have rather than compute it over and over). Revision ChangesPath 1.3 +12 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/HttpRequest.java Index: HttpRequest.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/HttpRequest.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- HttpRequest.java 29 Jan 2003 12:49:32 - 1.2 +++ HttpRequest.java 29 Jan 2003 20:20:46 - 1.3 @@ -212,6 +212,14 @@ /** + * Get the request path. + * + * @return the request path + */ +public MessageBytes getRequestPathMB(); + + +/** * Set a flag indicating whether or not the requested session ID for this * request came in through a cookie. This is normally called by the * HTTP Connector, when it parses the request headers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
remm2003/01/29 12:54:55
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
- Fix find method bug (in case the elements are equal).
Revision ChangesPath
1.4 +2 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Mapper.java 29 Jan 2003 20:03:21 - 1.3
+++ Mapper.java 29 Jan 2003 20:54:55 - 1.4
@@ -648,7 +648,7 @@
}
if ((b - a) == 1) {
int result2 = compare(name, start, end, map[b].name);
-if (result2 1) {
+if (result2 0) {
return a;
} else {
return b;
@@ -693,7 +693,7 @@
}
if ((b - a) == 1) {
int result2 = name.compareTo(map[b].name);
-if (result2 1) {
+if (result2 0) {
return a;
} else {
return b;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core DummyRequest.java
remm2003/01/29 12:57:16
Modified:catalina/src/share/org/apache/catalina/core
DummyRequest.java
Log:
- Add request path field (basically, it's servletPath + pathInfo, which is very
convinient to have rather than compute it over and over).
Revision ChangesPath
1.5 +8 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
Index: DummyRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DummyRequest.java 29 Jan 2003 12:49:41 - 1.4
+++ DummyRequest.java 29 Jan 2003 20:57:16 - 1.5
@@ -204,6 +204,10 @@
return null;
}
+public MessageBytes getRequestPathMB() {
+return null;
+}
+
public String getServletPath() {
return servletPath;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteRequest.java
remm2003/01/29 12:57:28
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteRequest.java
Log:
- Add request path field (basically, it's servletPath + pathInfo, which is very
convinient to have rather than compute it over and over).
Revision ChangesPath
1.18 +14 -4
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- CoyoteRequest.java29 Jan 2003 16:39:11 - 1.17
+++ CoyoteRequest.java29 Jan 2003 20:57:28 - 1.18
@@ -1824,6 +1824,16 @@
/**
+ * Get the request path.
+ *
+ * @return the request path
+ */
+public MessageBytes getRequestPathMB() {
+return (mappingData.requestPath);
+}
+
+
+/**
* Return the session identifier included in this request, if any.
*/
public String getRequestedSessionId() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5: javadoc enhancements
Javadoc enhancements for JSP 2.0 API.
New Files (attached separately):
- jsr152/src/share/javax/servlet/jsp/package.html
- jsr152/src/share/javax/servlet/jsp/el/package.html
- jsr152/src/share/javax/servlet/jsp/tagext/package.html
jsr152/src/share/javax/servlet/jsp/JspContext.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/JspFactory.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/PageContext.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java
- Added description for doInitBody() @throws JspException
jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java
- Added description for doAfterBody() @throws JspException
jsr152/src/share/javax/servlet/jsp/tagext/PageData.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/SimpleTagSupport.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TagExtraInfo.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TryCatchFinally.java
- Added @throws Throwable tag for doCatch()
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Index: jsr152/src/share/javax/servlet/jsp/JspContext.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java,v
retrieving revision 1.6
diff -u -r1.6 JspContext.java
--- jsr152/src/share/javax/servlet/jsp/JspContext.java 18 Dec 2002 18:35:37 -
1.6
+++ jsr152/src/share/javax/servlet/jsp/JspContext.java 29 Jan 2003 21:01:27 -
@@ -109,6 +109,13 @@
public abstract class JspContext {
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspContext() {
+}
+
/**
* Register the name and value specified with page scope semantics.
* If the value passed in is codenull/code, this has the same
Index: jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspEngineInfo.java
--- jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java 13 Aug 2002 16:20:54
- 1.1.1.1
+++ jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java 29 Jan 2003 21:01:27
+-
@@ -61,6 +61,13 @@
*/
public abstract class JspEngineInfo {
+
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspEngineInfo() {
+}
/**
* Return the version number of the JSP specification that is supported by
Index: jsr152/src/share/javax/servlet/jsp/JspFactory.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspFactory.java,v
retrieving revision 1.2
diff -u -r1.2 JspFactory.java
--- jsr152/src/share/javax/servlet/jsp/JspFactory.java 19 Aug 2002 16:29:49 -
1.2
+++ jsr152/src/share/javax/servlet/jsp/JspFactory.java 29 Jan 2003 21:01:27 -
@@ -82,6 +82,13 @@
public abstract class JspFactory {
private static JspFactory deflt = null;
+
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspFactory() {
+}
/**
* p
Index: jsr152/src/share/javax/servlet/jsp/PageContext.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/PageContext.java,v
retrieving revision 1.6
diff -u -r1.6 PageContext.java
--- jsr152/src/share/javax/servlet/jsp/PageContext.java 18 Dec 2002 18:35:37 -
1.6
+++ jsr152/src/share/javax/servlet/jsp/PageContext.java 29 Jan 2003 21:01:28 -
@@ -132,7 +132,14 @@
abstract public class PageContext
extends JspContext
{
-
+
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public PageContext() {
+}
+
/**
* Page scope: (this is the default) the named reference remains available
* in this PageContext until the return from the current Servlet.service()
Index: jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java
===
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java StandardContextValve.java StandardWrapperValve.java
remm2003/01/29 13:23:29
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
StandardContextValve.java StandardWrapperValve.java
Log:
- Code simplifications using the request path.
Revision ChangesPath
1.6 +10 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
Index: ApplicationFilterFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApplicationFilterFactory.java 27 Nov 2002 20:34:20 - 1.5
+++ ApplicationFilterFactory.java 29 Jan 2003 21:23:29 - 1.6
@@ -91,10 +91,14 @@
public final class ApplicationFilterFactory {
public static final int ERROR = 1;
-public static final int FORWARD =2;
-public static final int INCLUDE =4;
+public static final Integer ERROR_INTEGER = new Integer(ERROR);
+public static final int FORWARD = 2;
+public static final Integer FORWARD_INTEGER = new Integer(FORWARD);
+public static final int INCLUDE = 4;
+public static final Integer INCLUDE_INTEGER = new Integer(INCLUDE);
public static final int REQUEST = 8;
-
+public static final Integer REQUEST_INTEGER = new Integer(REQUEST);
+
public static final String
DISPATCHER_TYPE_ATTR=org.apache.catalina.core.DISPATCHER_TYPE;
public static final String
DISPATCHER_REQUEST_PATH_ATTR=org.apache.catalina.core.DISPATCHER_REQUEST_PATH;
1.5 +9 -27
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
Index: StandardContextValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- StandardContextValve.java 29 Jan 2003 12:50:52 - 1.4
+++ StandardContextValve.java 29 Jan 2003 21:23:29 - 1.5
@@ -162,29 +162,11 @@
// Disallow any direct access to resources under WEB-INF or META-INF
HttpRequest hreq = (HttpRequest) request;
-MessageBytes contextPathMB = hreq.getContextPathMB();
-int length = contextPathMB.getLength();
-MessageBytes decodedURIMB = hreq.getDecodedRequestURIMB();
-decodedURIMB.toChars();
-CharChunk decodedURIBC = decodedURIMB.getCharChunk();
-int bcLength = decodedURIBC.getLength();
-boolean notFound = false;
-if (decodedURIBC.startsWithIgnoreCase(/META-INF, length)) {
-if ((decodedURIBC.getLength() == (/META-INF.length() + length))
-|| (decodedURIBC.getBuffer()[/META-INF.length() + length]
-== '/')) {
-notFound = true;
-}
-}
-if (decodedURIBC.startsWithIgnoreCase(/WEB-INF, length)) {
-if ((decodedURIBC.getLength() == (/WEB-INF.length() + length))
-|| (decodedURIBC.getBuffer()[/WEB-INF.length() + length]
-== '/')) {
-System.out.println(Not found);
-notFound = true;
-}
-}
-if (notFound) {
+MessageBytes requestPathMB = hreq.getRequestPathMB();
+if ((requestPathMB.startsWithIgnoreCase(/META-INF/, 0))
+|| (requestPathMB.equalsIgnoreCase(/META-INF))
+|| (requestPathMB.startsWithIgnoreCase(/WEB-INF/, 0))
+|| (requestPathMB.equalsIgnoreCase(/WEB-INF))) {
String requestURI = hreq.getDecodedRequestURI();
notFound(requestURI, (HttpServletResponse) response.getResponse());
return;
1.10 +14 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
Index: StandardWrapperValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- StandardWrapperValve.java 24 Jan 2003 23:47:46 - 1.9
+++ StandardWrapperValve.java 29 Jan 2003 21:23:29 - 1.10
@@ -79,6 +79,9 @@
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+
+import org.apache.tomcat.util.buf.MessageBytes;
+
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.Globals;
@@ -185,6
Re: [5.0] New mapper
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: The mapper has a currently unused dependency on JNDI, and I plan to put it in the org.apache.tomcat.util.http.mapper package. JNDI deps are fine - dependencies on org.apache.naming are not very good ( since tomcat can be used in an app that uses a different naming impl ). Well, I'm still unsure about physical welcome files. On the plus side, it would be considerably faster to do that in the mapper. How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite obvious, but I think I missed it in 1.1. The static queries are of course similar. It's the same - register a listener on the MBeanServerDelegate. I tried that, and get a lot of nice notifications about registration, but how do I get the ObjectName of the MBean which caused the notification (the source of the Notification is the server delegate, which doesn't help). ? Cast the notification to MBeanServerNotification :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Splitting authentication and authorization.
Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will return false. Then we will need to set the
proper error message on the HttpServletResponse:
If we look at JSR115, it sugests creating several (3?) permission objects -
each will be associated with the request.
The creation of those objects will be part of the container ( probably in
a valve or other module ).
The point is that all _authorization_ decisions will be deletated to
a plugin - tomcat will just make the calls. It will be tomcat's
job to provide the arguments and deal with the response.
OK. But I would prefer nmot having that code in the current
AuthenticatorBase. We will need something inbetween AuthenticatorBase
and AuthorizationBase (WebPermissionUtil)
((HttpServletResponse) response.getResponse()).sendError( )
I don't think mixing HTTP request processing in the authorizer is a good
idea, and it seems JSR115 ( at least the published draft ) is on the same
side.
Well, I agree...if we have something in between Authentication and
Authorization :-)
Let the authorizer deal with authorization - if the permissions
( to a URI, method, transport ) are valid.
If the method only return false, then we will not be able to properly
set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
Another reason to let the authorizer deal with authorization and nothing
else. A false will mean FORBIDDEN. ( we can still know what was forbidden
- we'll have to check 3 different permissions )\
True. Using the permission type we can find the which error type to return.
I would prefer having:
interface Authorization {
boolean hasPermission( HttpServletResponse, Permission p )
}
You can get the Response from the Request - passing one or both is the same.
True. My mistake.
Again - that would mean the authorizer will deal with HTTP processing, that
will keep code complex.
The JSR115 aproach is IMO much better - all the information that must be
checked ( URI, method, etc ) is passed as part of the requested permission.
since p should contains all the information required to grant/denied the
request.
Exactly - there is no need to pass the response/request. If you really want
- you can cast the permission to TomcatRequestPermission and get the source
request and response.
+1
or
interface Authorization {
boolean hasPermission( HttpServletRequest, HttpServletResponse, String
role )
}
if we don't want a Permission object.
I don't see why not. ( and it's not one, but few ). This is far more
flexible.
Based on the permission type, we will be able to discover if it's a
Resource/UserData/Role call.
+1
I'm still trying to figure out the hack in JSR155 ( with the
permission per request ) - but if you understand
I hope I understand a little...I did participate in the
definition/implementation of the specs :-)
Good to know :-)
it we can even
use
boolean implies( Permission currentRequestPermission,
Permission targetPermission )
Here I assume targetPermission is a permission that we have created when
reading the web.xml (right?). We will have a collection of
targetPermission. To make it work, we will have to do:
Sorry - I meant PermissionCollection for the second argument, and yes - it
includes all the permissions from the web.xml ( and maybe the permissions
from the policy - if in sandbox mode ).
for (int i; i targetPermissionCollection; i++){
...implies(currentRequestPermission, targetPermissionCollection(i));
}
I would prefer having:
Provider
--
boolean implies( ProtectionDomain currentRequestPermission,
Permission currentRequestPermission )
Yes, that's what I had in mind too - except PermissionCollection instead
of ProtectionDomain.
Actually - I have a better idea ( IMHO :-):
Request {
...
Permissions requestPermissions[]; - we add this to coyote request ( with
getter/setter )
}
Context {
PermissionCollection authorizer;
}
The Authorizer will just be an implementation of PermissionCollection.
It seems JSR115 is a bit confused about this - in 4.7 it lists 6
alternatives for checking. I don't see why anything more than providing a
PermissionCollection and using impies() would be needed.
But I'm fine with ProtectionDomain - it adds the CodeSource of the
context ( which is good ). Not sure what the principals would be.
The small problem I see is if we go with a PermissionCollection, people
interested in extending the model will be limited by the
PermissionCollection design. I would prefer having an implementation of
a Policy object instead.
Here is how I see
cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext BodyTag.java IterationTag.java PageData.java SimpleTagSupport.java TagExtraInfo.java TagLibraryValidator.java TryCatchFinally.java
kinman 2003/01/29 13:42:13
Modified:jsr152/src/share/javax/servlet/jsp JspContext.java
JspEngineInfo.java JspFactory.java PageContext.java
jsr152/src/share/javax/servlet/jsp/tagext BodyTag.java
IterationTag.java PageData.java
SimpleTagSupport.java TagExtraInfo.java
TagLibraryValidator.java TryCatchFinally.java
Log:
- Patch by Mark Roth:
Javadoc enhancements for JSP 2.0 API.
New Files (attached separately):
- jsr152/src/share/javax/servlet/jsp/package.html
- jsr152/src/share/javax/servlet/jsp/el/package.html
- jsr152/src/share/javax/servlet/jsp/tagext/package.html
jsr152/src/share/javax/servlet/jsp/JspContext.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/JspFactory.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/PageContext.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java
- Added description for doInitBody() @throws JspException
jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java
- Added description for doAfterBody() @throws JspException
jsr152/src/share/javax/servlet/jsp/tagext/PageData.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/SimpleTagSupport.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TagExtraInfo.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java
- Added javadoc comment for public no-args constructor
jsr152/src/share/javax/servlet/jsp/tagext/TryCatchFinally.java
- Added @throws Throwable tag for doCatch()
Revision ChangesPath
1.7 +7 -0
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java
Index: JspContext.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JspContext.java 18 Dec 2002 18:35:37 - 1.6
+++ JspContext.java 29 Jan 2003 21:42:13 - 1.7
@@ -109,6 +109,13 @@
public abstract class JspContext {
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspContext() {
+}
+
/**
* Register the name and value specified with page scope semantics.
* If the value passed in is codenull/code, this has the same
1.2 +7 -0
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java
Index: JspEngineInfo.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspEngineInfo.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JspEngineInfo.java13 Aug 2002 16:20:54 - 1.1
+++ JspEngineInfo.java29 Jan 2003 21:42:13 - 1.2
@@ -61,6 +61,13 @@
*/
public abstract class JspEngineInfo {
+
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspEngineInfo() {
+}
/**
* Return the version number of the JSP specification that is supported by
1.3 +7 -0
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspFactory.java
Index: JspFactory.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JspFactory.java 19 Aug 2002 16:29:49 - 1.2
+++ JspFactory.java 29 Jan 2003 21:42:13 - 1.3
@@ -82,6 +82,13 @@
public abstract class JspFactory {
private static JspFactory deflt = null;
+
+/**
+ * Sole constructor. (For invocation by subclass constructors,
+ * typically implicit.)
+ */
+public JspFactory() {
+}
/**
* p
1.7 +8 -1
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/PageContext.java
Index: PageContext.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/PageContext.java,v
retrieving revision 1.6
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
jfarcand2003/01/29 14:09:32
Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
Remove the condition. DummyRequest will be modified.
Revision ChangesPath
1.22 +7 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- JspServlet.java 29 Jan 2003 18:20:08 - 1.21
+++ JspServlet.java 29 Jan 2003 22:09:32 - 1.22
@@ -231,14 +231,10 @@
log.debug(\t Request Params: );
Enumeration e = request.getParameterNames();
-// Occurs only when DummyRequest is used (this method never
-// when used in the normal case return null
-if (e != null) {
-while (e.hasMoreElements()) {
-String name = (String) e.nextElement();
-log.info(\t\t + name + = +
- request.getParameter(name));
-}
+ while (e.hasMoreElements()) {
+String name = (String) e.nextElement();
+log.info(\t\t + name + = +
+ request.getParameter(name));
}
}
serviceJspFile(request, response, jspUri, null, precompile);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext package.html
kinman 2003/01/29 14:26:18 Added: jsr152/src/share/javax/servlet/jsp package.html jsr152/src/share/javax/servlet/jsp/el package.html jsr152/src/share/javax/servlet/jsp/tagext package.html Log: - Add new files Revision ChangesPath 1.1 jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/package.html Index: package.html === !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN html head !-- - The Apache Software License, Version 1.1 - - Copyright (c) 1999 The Apache Software Foundation. All rights - reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - 1. Redistributions of source code must retain the above copyright -notice, this list of conditions and the following disclaimer. - - 2. Redistributions in binary form must reproduce the above copyright -notice, this list of conditions and the following disclaimer in -the documentation and/or other materials provided with the -distribution. - - 3. The end-user documentation included with the redistribution, if -any, must include the following acknowlegement: - This product includes software developed by the -Apache Software Foundation (http://www.apache.org/). -Alternately, this acknowlegement may appear in the software itself, -if and wherever such third-party acknowlegements normally appear. - - 4. The names The Jakarta Project, Tomcat, and Apache Software -Foundation must not be used to endorse or promote products derived -from this software without prior written permission. For written -permission, please contact [EMAIL PROTECTED] - - 5. Products derived from this software may not be called Apache -nor may Apache appear in their names without prior written -permission of the Apache Group. - - THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED - WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR - ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, - OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT - OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - SUCH DAMAGE. - - - This software consists of voluntary contributions made by many - individuals on behalf of the Apache Software Foundation. For more - information on the Apache Software Foundation, please see - http://www.apache.org/. - -- /head body bgcolor=white Classes and interfaces for the Core JSP 2.0 API. p The javax.servlet.jsp package contains a number of classes and interfaces that describe and define the contracts between a JSP page implementation class and the runtime environment provided for an instance of such a class by a conforming JSP container. /body /html 1.1 jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/el/package.html Index: package.html === !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN html head !-- - The Apache Software License, Version 1.1 - - Copyright (c) 1999 The Apache Software Foundation. All rights - reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - 1. Redistributions of source code must retain the above copyright -notice, this list of conditions and the following disclaimer. - - 2. Redistributions in binary form must reproduce the above copyright -notice, this list of conditions and the following disclaimer in -the documentation and/or other materials provided with the -distribution. - - 3. The end-user documentation included with the redistribution, if -any, must include the following acknowlegement: - This product includes software developed by the -Apache Software Foundation (http://www.apache.org/). -Alternately, this acknowlegement may appear in the software itself, -if and wherever such third-party acknowlegements
Re: [5.0] Splitting authentication and authorization.
Jeanfrancois Arcand wrote: If we look at JSR115, it sugests creating several (3?) permission objects - each will be associated with the request. The creation of those objects will be part of the container ( probably in a valve or other module ). The point is that all _authorization_ decisions will be deletated to a plugin - tomcat will just make the calls. It will be tomcat's job to provide the arguments and deal with the response. OK. But I would prefer nmot having that code in the current AuthenticatorBase. We will need something inbetween AuthenticatorBase and AuthorizationBase (WebPermissionUtil) As long as authorization (and authentication) does not deal directly with http requests ( i.e. plain JSR115/Java security + JAAS ) - I'm fine. Separating the authorization and authentication abstractions is one thing - implementing the request processing is another. WebPermissionUtil needs to know how to do the calls to authorization/authentication and how to provide the right permissions. I don't see too much value in having AuthenticatorBase and AuthorizatiorBase - if the authorizer is a ProtectionDomain or Policy, all we need is an implementation of that, called from the a valve. I don't think mixing HTTP request processing in the authorizer is a good idea, and it seems JSR115 ( at least the published draft ) is on the same side. Well, I agree...if we have something in between Authentication and Authorization :-) That's the current valve - with the authorization code moved in a TomcatProtectionDomain class ( that extends ProtectionDomain, is pluggable, etc ) I would make the JAAS valve the default - and hope that Nacho and the other people will be able to refactor the LDAP/JDBC valves to JAAS plugin modules ( bonus: they'll become reusable in other servers that use JAAS ). Another reason to let the authorizer deal with authorization and nothing else. A false will mean FORBIDDEN. ( we can still know what was forbidden - we'll have to check 3 different permissions )\ True. Using the permission type we can find the which error type to return. Or what action to perform - redirect to the login page, etc. It seems JSR115 is a bit confused about this - in 4.7 it lists 6 alternatives for checking. I don't see why anything more than providing a PermissionCollection and using impies() would be needed. But I'm fine with ProtectionDomain - it adds the CodeSource of the context ( which is good ). Not sure what the principals would be. The small problem I see is if we go with a PermissionCollection, people interested in extending the model will be limited by the PermissionCollection design. I would prefer having an implementation of a Policy object instead. The problem with Policy: There is only one Policy object in effect at any given time ( in javadoc). That limits a lot our flexibility. Having a PermissionCollection per server or per Context still permits people to have them in the global Policy. Each Context will be associated with a CodeSource ( it is already AFAIK ), and the Policy is just a container for CodeSource-PermissionCollection. If we use PermissionCollection in our code, it is very easy to extract it from a Policy ( if one is present ), but we can have more flexibility. It would be possible to plug in a PermissionCollection in a context - without having it in the Policy, and we can use tomcat with a foreign policy, installed by a different application ( which may not support 115 ) Here is how I see the process (simplified): (1) when Tomcat starts, create the Policy (Provider is we standardize on 115) There is no requirement on that - we can create a ProtectionDomain or Policy without 115. ( well, we already do - AFAIK - for the class loader ). Here I mean the Policy implementation. See my previous comment. I'm ok with having a Policy created - but as an optional step, our code should use PermCollection. If a Policy already exists - and it can be used ( i.e. 115 compatible ) - we should use it, but it shouldn't be required. ( by JSR115 compatible I mean it support the interfaces that allow us to modify it ) (2) when deploying web.xml, created the appropriate Permission object (proprietary or 115) and store them inside a PolicyConfiguration object. That's my biggest problem with 115 :-) All J2EE is moving toward JMX - and they define yet another config API. Sorry - I will vote for proprietary here ( actually - JMX ). The Policy will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean server is protected ). There is nothing that prevent us implementing a PolicyConfiguration using JMX and still be 115 compliant. Doing that will allow changing the permission without stopping the container. That's a very nice feature. I know - my point was that JSR115 should specify the JMX attributes and mechanism - instead of defining the interfaces. Look at JSR77 for example ( which is far from perfect, but IMO goes in a very good
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java
luehe 2003/01/29 14:32:09 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: Provide valid default for connector class Revision ChangesPath 1.13 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java Index: Catalina.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- Catalina.java 10 Jan 2003 18:48:49 - 1.12 +++ Catalina.java 29 Jan 2003 22:32:09 - 1.13 @@ -330,7 +330,7 @@ org.apache.catalina.LifecycleListener); digester.addObjectCreate(Server/Service/Connector, - org.apache.catalina.connector.http.HttpConnector, + org.apache.coyote.tomcat5.CoyoteConnector, className); digester.addSetProperties(Server/Service/Connector); digester.addSetNext(Server/Service/Connector, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core DummyRequest.java
jfarcand2003/01/29 14:40:19
Modified:catalina/src/share/org/apache/catalina/core
DummyRequest.java
Log:
Return an empty enumeration instead of a null to be spec compliant (and to avoid
JspServlet to throw NPE)
Revision ChangesPath
1.6 +14 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
Index: DummyRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DummyRequest.java 29 Jan 2003 20:57:16 - 1.5
+++ DummyRequest.java 29 Jan 2003 22:40:19 - 1.6
@@ -155,6 +155,15 @@
protected FilterChain filterChain = null;
protected ValveContext valveContext = null;
+
+protected Enumeration dummyEnum = new Enumeration(){
+public boolean hasMoreElements(){
+return false;
+}
+public Object nextElement(){
+return null;
+}
+};
public String getContextPath() {
return (contextPath);
@@ -310,7 +319,7 @@
public void setUserPrincipal(Principal principal) {}
public String getParameter(String name) { return null; }
public Map getParameterMap() { return null; }
-public Enumeration getParameterNames() { return null; }
+public Enumeration getParameterNames() { return dummyEnum; }
public String[] getParameterValues(String name) { return null; }
public RequestDispatcher getRequestDispatcher(String path) {
return null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java
amyroh 2003/01/29 15:02:38
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
Log:
Fix bugzilla 7564 - Avoid hardcoding the default deployment descriptor location.
Revision ChangesPath
1.18 +35 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ContextConfig.java16 Jan 2003 21:44:17 - 1.17
+++ ContextConfig.java29 Jan 2003 23:02:38 - 1.18
@@ -165,7 +165,13 @@
*/
private int debug = 0;
-
+
+/**
+ * The default web application's deployment descriptor location.
+ */
+private String defaultWebXml = Constants.DefaultWebXml;
+
+
/**
* Track any fatal errors during startup configuration processing.
*/
@@ -202,7 +208,7 @@
*/
private static boolean xmlNamespaceAware = false;
-
+
// - Properties
@@ -226,6 +232,28 @@
this.debug = debug;
}
+
+
+/**
+ * Return the location of the default deployment descriptor
+ */
+public String getDefaultWebXml() {
+
+return (this.defaultWebXml);
+
+}
+
+
+/**
+ * Set the location of the default deployment descriptor
+ *
+ * @param path Absolute/relative path to the default web.xml
+ */
+public void setDefaultWebXml(String path) {
+
+this.defaultWebXml = path;
+
+}
// - Public Methods
@@ -603,10 +631,11 @@
long t1=System.currentTimeMillis();
// Open the default web.xml file, if it exists
-File file = new File(Constants.DefaultWebXml);
-if (!file.isAbsolute())
+File file = new File(this.defaultWebXml);
+if (!file.isAbsolute()) {
file = new File(System.getProperty(catalina.base),
-Constants.DefaultWebXml);
+this.defaultWebXml);
+}
FileInputStream stream = null;
try {
stream = new FileInputStream(file.getCanonicalPath());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7564] - Avoid hardcoding the default deployment descriptor location
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=7564. 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=7564 Avoid hardcoding the default deployment descriptor location [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-29 23:08 --- Fixed. Should be available in the next release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16572] New: - Compile error when invoking tag file that uses JSTL
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=16572.
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=16572
Compile error when invoking tag file that uses JSTL
Summary: Compile error when invoking tag file that uses JSTL
Product: Tomcat 5
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Blocker
Priority: Other
Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A simple JSP page:
%@ taglib prefix=my tagdir=/WEB-INF/tags/mytags %
my:test/
invoking a simple tag file:
%@ taglib prefix=c uri=http://java.sun.com/jstl/core_rt; %
jsp:useBean id=now class=java.util.Date /
c:out value=${now} /
Results in:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:120)
at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:307)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:405)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:429)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:572)
at
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:215)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:446)
at
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:84)
at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:488)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1033)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1700)
[...]
If I change the tag file to not use c:out, everything works fine:
jsp:useBean id=now class=java.util.Date /
${now}
Since I've seen the same error with other JSTL (1.0.1) actions, I assume there's
a problem with JSTL (or custom actions in general) in tag files.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core DummyRequest.java
jfarcand2003/01/29 16:04:29
Modified:catalina/src/share/org/apache/catalina/core
DummyRequest.java
Log:
Make the dummy enumeration static and private. This way we will create only 1 object.
Thanks to Jan.
Revision ChangesPath
1.7 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java
Index: DummyRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyRequest.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DummyRequest.java 29 Jan 2003 22:40:19 - 1.6
+++ DummyRequest.java 30 Jan 2003 00:04:28 - 1.7
@@ -156,7 +156,7 @@
protected FilterChain filterChain = null;
protected ValveContext valveContext = null;
-protected Enumeration dummyEnum = new Enumeration(){
+private static Enumeration dummyEnum = new Enumeration(){
public boolean hasMoreElements(){
return false;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JSP javadocs not available
Hi, I noticed the link on the following page states Servlet/JSP Javadocs but only the Servlet javadocs are available. http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html - Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Remove redundant constructor from StandardSessionFacade
* catalina/src/share/org/apache/catalina/session/StandardSessionFacade.java
StandardSessionFacade(StandardSession): Removed redundant constructor. As
StandardSession implements HttpSession, the
StandardSessionFacade(HttpSession) constructor already does the job
admirably.
---
/tmp/jakarta-tomcat-4.1.18-src/catalina/src/share/org/apache/catalina/session/StandardSessionFacade.java
Wed Jan 29 15:56:00 2003
+++ /tmp/StandardSessionFacade.java Wed Jan 29 15:56:00 2003
@@ -104,15 +104,6 @@
/**
* Construct a new session facade.
*/
-public StandardSessionFacade(StandardSession session) {
-super();
-this.session = (HttpSession) session;
-}
-
-
-/**
- * Construct a new session facade.
- */
public StandardSessionFacade(HttpSession session) {
super();
this.session = session;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16574] New: - java.lang.NullPointerException in classes that implement HttpSessionBindingListener
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=16574.
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=16574
java.lang.NullPointerException in classes that implement HttpSessionBindingListener
Summary: java.lang.NullPointerException in classes that implement
HttpSessionBindingListener
Product: Tomcat 4
Version: 4.1.18
Platform: Other
OS/Version: Windows NT/2K
Status: UNCONFIRMED
Severity: Normal
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The problem is, that when replace a session attribute that implements
HttpSessionBindingListener, in the valueUnbound method I get
java.lang.NullPointerException.
example:
public void valueUnbound(HttpSessionBindingEvent be) {
User u = (User)be.getValue();
System.out.println(The user + u.getName() + was unbounded);
}
I believe that the error is that in line 1250 of StandardSession
(new HttpSessionBindingEvent((HttpSession) this, name));
you have put (new HttpSessionBindingEvent((HttpSession) this, name, unbound));
In the specification of Servlet 2.3, the method getValue() of
HttpSessionBindingEvent class say:
If the attribute was replaced, this is the old value of the attribute.
Thank for your attention and sorry for my english. I you don't understand me,
please let me know.
Jorge L. Middleton
Bs. As. Argentina
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16572] - Compile error when invoking tag file that uses JSTL
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=16572. 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=16572 Compile error when invoking tag file that uses JSTL --- Additional Comments From [EMAIL PROTECTED] 2003-01-30 00:32 --- The bug was due to a recent change in tag pooling, and the changes introduced a bug when tag pooling is enabled in a tag file. The method org.apache.jasper.runtime.TagHandlerPool.getTagHandlerPool has been modified to take a jspServlet, which a tag file is not. Hence the bug. A workaround is to turn off tag pooling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16576] New: - JSP 1.2 spec section 10.2.2 - BodyTag
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=16576. 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=16576 JSP 1.2 spec section 10.2.2 - BodyTag Summary: JSP 1.2 spec section 10.2.2 - BodyTag Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Catalina servlet container does not call the doAfterBody() method of a BodyTag handler if the BodyTag's corresponding XML tag in the JSP is empty. While this may seem sensible, it is required by the JSP spec that setBodyContent(), initBody() and doAfterBody() are called if the return value from doStartTag() is EVAL_BODY_BUFFERED. In such a case the container should push an empty BodyContent object onto the pageContext BodyContent stack. This may break (has broken) web apps implementing custom tag handlers that conform to the standard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16576] - JSP 1.2 spec section 10.2.2 - BodyTag
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=16576. 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=16576 JSP 1.2 spec section 10.2.2 - BodyTag --- Additional Comments From [EMAIL PROTECTED] 2003-01-30 02:07 --- Correction to the above: setBodyContent() should not be called for empty tags - however the description of doAfterBody() implies that this method should be called - the spec doc also seems to contradict itself here when comparing the text to the state transition diagram of the same section which would seem to suggest that setBodyContent() is a prerequisite of doInitBody() and doAfterBody () - some clarification of the spec perhaps? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
luehe 2003/01/29 19:22:01
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
Capture javac error messages
Revision ChangesPath
1.48 +1 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- Compiler.java 26 Jan 2003 19:00:58 - 1.47
+++ Compiler.java 30 Jan 2003 03:22:01 - 1.48
@@ -153,10 +153,7 @@
logger = new JasperAntLogger();
logger.setOutputPrintStream(System.out);
logger.setErrorPrintStream(System.err);
-
-if( log.isTraceEnabled() ) {
-logger.setMessageOutputLevel( Project.MSG_VERBOSE );
-}
+ logger.setMessageOutputLevel(Project.MSG_INFO);
project.addBuildListener( logger);
if( options.getCompiler() != null ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16579] New: - documentation page layout/style breaks wrapping to fit browser window
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=16579. 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=16579 documentation page layout/style breaks wrapping to fit browser window Summary: documentation page layout/style breaks wrapping to fit browser window Product: Tomcat 4 Version: 4.0 Final Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi- resources-howto.html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Could the page layout for Tomcat documentation please be reconsidered? It stops _all_ regular text from wrapping to fit the window when _any_ line of fixed-width text is wider than the window. Specifically, using an HTML table to put navigation links to the left of the main page text forces the browser to ignore the width of the browser window and wrap wrappable text to match the width of the longest fixed-width line. Then, when the user uses a window that is not as wide as the longest line, the user must scroll horizontally to read _every_ line. (If the browser weren't constrained by the table, it could wrap all the wrappable text to fit the window, and only the long, fixed-width lines would require horizontal scrolling to see.) I realize that avoiding putting the body text inside a table may prevent having a list of navigation links on the left. However, PLEASE re-consider the layout. One option is to put navigation elements at the top of the page. (You don't need a table to do that, so the body text doesn't need to be in a table, so wrappable text can still wrap to fit the browser window.) Another thing to consider is whether every detail page really needs a list of links to every sibling page. (Books don't have a copy of the table of contents at the start of each chapter.) Each detail page needs only an up link to one common index page that lists the various detail pages. (Of course, you'd probably have more links that just that absolute minimum.)) Consider some precedents: Sun's JavaDoc layout for a class: - Class description text and member description text wraps to fit even very narrow windows, even if summary tables don't fit within the window. (Also, notice that each summary table is independent. If one is too wide and requires horizontal scrolling, the others can still fit.) - The page for one class is not cluttered with links to a bunch of sibling classes. - The page has an up link to the page for the containing package, which does list the sibling classes of the given class. - The navigation is on the top, not the left. (That allows most of the text to wrap to fit within the window width.) Linux HOW-TO documents in HTML generated from DocBook: - Wrappable text wraps to fit the browser window, even if some fixed-width text or images are wider. - There are some basic Next/Previous/section number links at the top. - The pages are not cluttered with multiple links to sibling documents, just a simple up link or two. Relatedly, when thinking about page widths, please don't assume that all readers use full-screen browser windows. Especially for technical documentation, readers are likely to be reading documentation in one window and using it (e.g., editing code, running some tool) in another window. Also note how wide pages such as http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html are. On my system, that page requires a 1086-pixel-wide browser window to display the entire width! Display just the body does fit in 800 pixels, but you'd need 1600 pixels across to see the text without scrolling on one side of your screen and edit something in a same-sized window on the other side. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16577] - WebappClassLoader delegates to parent loader
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=16577. 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=16577 WebappClassLoader delegates to parent loader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-01-30 07:04 --- The behavior mentioned in the specification is only a recommendation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
