BugRat Report #760 has been filed.
Bug report #760 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/760 REPORT #760 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: SuSE Linux OS Release: 6.4 Platform: Intel 2 processors, 1 GB RAM Synopsis: tomcat dying after some time Description: we are running tomcat on a middle loaded website. after some time (about 6 days) it is dying and the tomcat process is no longer present in process-list (ps -ef). tomcat must be restarted to start serving again. i made the experience, that tomcat produces more and more processes (just now i counted 77!!) in ps -ef list. what's the problem? can i configure tomcat to close no longer used processes/threads? does it help to upgrade to a newer tomcat release? Title: BugRat Report # 760 BugRat Report # 760 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Ralf Eichinger ([EMAIL PROTECTED]) Date Submitted: Jan 14 2001, 05:17:54 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: tomcat dying after some time Environment: (jvm, os, osrel, platform) 1.3, SuSE Linux, 6.4, Intel 2 processors, 1 GB RAM Additional Environment Description: Report Description: we are running tomcat on a middle loaded website. after some time (about 6 days) it is dying and the tomcat process is no longer present in process-list (ps -ef). tomcat must be restarted to start serving again. i made the experience, that tomcat produces more and more processes (just now i counted 77!!) in ps -ef list. what's the problem? can i configure tomcat to close no longer used processes/threads? does it help to upgrade to a newer tomcat release? How To Reproduce: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Updated Documentation
Craig R. McClanahan typed the following on 09:06 PM 1/13/2001 -0800 The information that is presented in the Server Configuration section is all up to date AFAIKT, but several sections are not yet written. With this, as with the rest of the docs (and the code, of course :-), feel free to suggest changes, send patches, or volunteer to do some of the writing! I can do the Manager section, since I've been mucking around with that code recently. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4 SecurityManager implementation
Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
Work on implementing this proposal is in progress. Comments please?
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
Setting policies for internal Tomcat classes
Security policies will be set using the tomcat.policy file. Security
checks will be based only on the codeSource of the class matching the
codeBase for JVM and Tomcat internal classes.
Example tomcat.policy entries affecting Tomcat internals
// javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/bin/-" {
permission java.security.AllPermission;
};
Setting policies for web application contexts
-
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
};
Security restrictions for using classes
---
StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package.
Security restrictions for defining classes
--
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"defineClassInPackage.{package name}", it will not be allowed to define
a Class in the package.
Changing security policies at runtime
-
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file.
StandardClassLoader
---
All of the code for implementing system, restricted, and allowed
checks will be removed. This will be handled by the SecurityManager.
Remove the ability to configure a contexts classloader in the
server.xml Context element.
ApplicationSecurityManager
--
This Class is a replacement for the default SecurityManager and extends
class SecurityManager.
It does a normal permission check first, if that fails it takes additional
steps if the current thread is for a web application context.
When a Context is started or stopped it will need to register with
the ApplicationSecurityManager using methods setContext() and
removeContext().
Context threads will be named threads with the name set to the
string representing the file URL of the Context. i.e.
"file:/usr/local/tomcat/webapps/examples".
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources FileDirContext.java ProxyDirContext.java
remm01/01/14 11:51:01
Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java ProxyDirContext.java
Log:
- Added some extra checks to prevent exceptions when trying to list contents
of unreadable directories.
- Fix bug with type wrapping in the proxy context when doing a lookup.
Revision ChangesPath
1.5 +8 -4
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java
Index: FileDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FileDirContext.java 2001/01/13 21:17:05 1.4
+++ FileDirContext.java 2001/01/14 19:51:00 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
1.4 2001/01/13 21:17:05 remm Exp $
- * $Revision: 1.4 $
- * $Date: 2001/01/13 21:17:05 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
1.5 2001/01/14 19:51:00 remm Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/01/14 19:51:00 $
*
*
*
@@ -98,7 +98,7 @@
* Filesystem Directory Context implementation helper class.
*
* @author Remy Maucherat
- * @version $Revision: 1.4 $ $Date: 2001/01/13 21:17:05 $
+ * @version $Revision: 1.5 $ $Date: 2001/01/14 19:51:00 $
*/
public class FileDirContext extends BaseDirContext {
@@ -884,7 +884,11 @@
protected Vector list(File file) {
Vector entries = new Vector();
+if (!file.isDirectory())
+return entries;
String[] names = file.list();
+if (names == null)
+return entries;
NamingEntry entry = null;
for (int i = 0; i names.length; i++) {
1.3 +13 -6
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java
Index: ProxyDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ProxyDirContext.java 2001/01/13 21:19:12 1.2
+++ ProxyDirContext.java 2001/01/14 19:51:00 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
1.2 2001/01/13 21:19:12 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/01/13 21:19:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
1.3 2001/01/14 19:51:00 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/01/14 19:51:00 $
*
*
*
@@ -66,6 +66,7 @@
import java.util.Hashtable;
import java.io.InputStream;
+import java.io.ByteArrayInputStream;
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.NameParser;
@@ -82,7 +83,7 @@
* Proxy Directory Context implementation.
*
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2001/01/13 21:19:12 $
+ * @version $Revision: 1.3 $ $Date: 2001/01/14 19:51:00 $
*/
public class ProxyDirContext implements DirContext {
@@ -164,10 +165,16 @@
public Object lookup(String name)
throws NamingException {
Object object = dirContext.lookup(parseName(name));
-if (object instanceof InputStream)
+if (object instanceof InputStream) {
return new Resource((InputStream) object);
-else
+} if (object instanceof DirContext) {
return object;
+} if (object instanceof Resource) {
+return object;
+} else {
+return new Resource(new ByteArrayInputStream
+(object.toString().getBytes()));
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader StandardLoader.java
remm01/01/14 11:53:47
Modified:catalina/src/share/org/apache/catalina/loader
StandardLoader.java
Log:
- Fix Jasper classpath generation.
Revision ChangesPath
1.16 +10 -7
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java
Index: StandardLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- StandardLoader.java 2001/01/13 05:27:54 1.15
+++ StandardLoader.java 2001/01/14 19:53:47 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.15 2001/01/13 05:27:54 remm Exp $
- * $Revision: 1.15 $
- * $Date: 2001/01/13 05:27:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.16 2001/01/14 19:53:47 remm Exp $
+ * $Revision: 1.16 $
+ * $Date: 2001/01/14 19:53:47 $
*
*
*
@@ -107,7 +107,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.15 $ $Date: 2001/01/13 05:27:54 $
+ * @version $Revision: 1.16 $ $Date: 2001/01/14 19:53:47 $
*/
public final class StandardLoader
@@ -806,6 +806,9 @@
repository = repository.substring(7);
else if (repository.startsWith("file:"))
repository = repository.substring(5);
+else if (repository.startsWith("jndi:"))
+repository =
+servletContext.getRealPath(repository.substring(5));
else
continue;
if (repository.endsWith("/"))
@@ -821,7 +824,7 @@
}
// Store the assembled class path as a servlet context attribute
- servletContext.setAttribute(Globals.CLASS_PATH_ATTR,
+servletContext.setAttribute(Globals.CLASS_PATH_ATTR,
classpath.toString());
}
@@ -839,7 +842,7 @@
((Context) container).getServletContext();
// Add the WEB-INF/classes subdirectory
- URL classesURL = null;
+URL classesURL = null;
try {
classesURL = servletContext.getResource("/WEB-INF/classes");
} catch (MalformedURLException e) {
@@ -869,7 +872,7 @@
}
addRepository(classesURLString + "/");
}
-
+
// Add the WEB-INF/lib/*.jar files
// FIXME - This still requires disk directory! Scan JARs if present
File libFile = new File(((Context) container).getDocBase(),
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core ApplicationContext.java StandardContext.java
remm01/01/14 11:58:30
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java StandardContext.java
Log:
- Fix the binding of the resources in the servlet context.
- Fix ServletContext.getRealPath().
- The AppContext cannot accurately generate the base path by itself
anymore, as the new resources do not expose that information. Instead, it's
passed as a parameter in the constructor.
Revision ChangesPath
1.12 +13 -6
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ApplicationContext.java 2001/01/13 05:22:40 1.11
+++ ApplicationContext.java 2001/01/14 19:58:30 1.12
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.11 2001/01/13 05:22:40 remm Exp $
- * $Revision: 1.11 $
- * $Date: 2001/01/13 05:22:40 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.12 2001/01/14 19:58:30 remm Exp $
+ * $Revision: 1.12 $
+ * $Date: 2001/01/14 19:58:30 $
*
*
*
@@ -105,7 +105,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.11 $ $Date: 2001/01/13 05:22:40 $
+ * @version $Revision: 1.12 $ $Date: 2001/01/14 19:58:30 $
*/
public final class ApplicationContext
@@ -121,10 +121,11 @@
*
* @param context The associated Context instance
*/
-public ApplicationContext(StandardContext context) {
+public ApplicationContext(String basePath, StandardContext context) {
super();
this.context = context;
+this.basePath = basePath;
}
@@ -164,6 +165,12 @@
StringManager.getManager(Constants.Package);
+/**
+ * Base path.
+ */
+private String basePath = null;
+
+
// - Public Methods
@@ -353,7 +360,7 @@
public String getRealPath(String path) {
// Here, we return a fake path
-File file = new File(context.getDocBase(), path);
+File file = new File(basePath, path);
return (file.getAbsolutePath());
}
1.36 +46 -31
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- StandardContext.java 2001/01/13 05:20:49 1.35
+++ StandardContext.java 2001/01/14 19:58:30 1.36
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.35 2001/01/13 05:20:49 remm Exp $
- * $Revision: 1.35 $
- * $Date: 2001/01/13 05:20:49 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.36 2001/01/14 19:58:30 remm Exp $
+ * $Revision: 1.36 $
+ * $Date: 2001/01/14 19:58:30 $
*
*
*
@@ -136,7 +136,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.35 $ $Date: 2001/01/13 05:20:49 $
+ * @version $Revision: 1.36 $ $Date: 2001/01/14 19:58:30 $
*/
public class StandardContext
@@ -845,7 +845,7 @@
public synchronized ServletContext getServletContext() {
if (context == null)
- context = new ApplicationContext(this);
+ context = new ApplicationContext(getBasePath(), this);
return (context);
}
@@ -912,33 +912,14 @@
public synchronized void setResources(DirContext resources) {
if (resources instanceof BaseDirContext) {
-String docBase = null;
-Container container = this;
-while (container != null) {
-if (container instanceof Host)
-break;
-container = container.getParent();
-}
-if (container == null) {
-docBase = (new File(engineBase(), getDocBase())).getPath();
-} else {
-File file = new File(getDocBase());
-if (!file.isAbsolute()) {
-
cvs commit: jakarta-tomcat/src/doc faq
larryi 01/01/14 12:18:04 Modified:src/doc Tag: tomcat_32 faq Log: Add information about "classdebuginfo" init paramter added to Jasper. Update other information as well. Revision ChangesPath No revision No revision 1.1.4.3 +38 -15jakarta-tomcat/src/doc/faq Index: faq === RCS file: /home/cvs/jakarta-tomcat/src/doc/faq,v retrieving revision 1.1.4.2 retrieving revision 1.1.4.3 diff -u -r1.1.4.2 -r1.1.4.3 --- faq 2001/01/13 14:11:09 1.1.4.2 +++ faq 2001/01/14 20:18:01 1.1.4.3 @@ -72,11 +72,11 @@ Q: Where are the classes for JSPs and Servlets? -A: webserver.jar -- class files for Servlet Engine. - lib/jspengine.jar -- class files for JSP Engine. +A: lib/webserver.jar -- class files for Servlet Engine. + lib/jasper.jar-- class files for JSP Engine. lib/servlet.jar -- Public APIs for Servlet. - lib/jsp.jar -- Public APIs for JSP. - lib/xml.jar -- classes for parsing XML document. + lib/jaxp.jar -- Public APIs for XML parser interface + lib/parser.jar-- Public XML parser reference implementation Q: Can I combine these classes with other webservers? @@ -115,13 +115,21 @@ To add "baseball" application you can make the following additions to the file (at the appropriate place): - Context path="/baseball" docBase="baseball" - defaultSessionTimeOut="30" isWARExpanded="true" - isWARValidated="false" isInvokerEnabled="true" - isWorkDirPersistent="false"/ + Context path="/baseball" docBase="baseball" + debug="0" reloadable="true"/ + Replace baseball with an absolute path to the "baseball" directory, + or a relative path that is relative to the Tomcat home directory. + Please read "server.xml" for more details. + In addition, thanks to the AutoSetup interceptor, you may create or + copy the "baseball" directory to the "webapps" directory found under + the Tomcat home directory. When placed there, it will be served + automcatically with the default settings. A Context ... / entry + in the server.xml is not required unless you want to override the + default settings. + a) To install servlets within a web-application, you can do the following: * Once a servlet has been compiled, it can be added to Tomcat by: @@ -191,30 +199,45 @@ Q: What do different init parameters for the JSP engine mean? * keepgenerated: -Whether to keep the generated java file or no. Can take a -value of true/false. If value is true then the generated files -are kept else they are deleted. +Whether to keep the generated java file or not. Can take a +value of true/false. If value is true, then the generated files +are kept, otherwise they are deleted. The default is true. * scratchdir: The work dir which will be created for storing all the generated code. This can be set to any dir. That directory will be created under the docbase. - * largeFile: + * largefile: Can take a value of true/false. If the file is really large then all the static html is stored is a separate data file if the value - of this param is set to true. + of this param is set to true. If true, this setting overrides +the mappedfile param. The default is false. + + * mappedfile: + Can take a value of true/false. If you prefer each line of static +html be output separately, set this parameter true. If largefile +is set true, this param is ignored. If neither largefile or +mappedfile is true, the static html is output in blocks up to 32K +in length. The default is false. * sendErrToClient: Can take a value of true/false. If set to true then all the compilation/parsing errors will be sent as part of the response - to the client. + to the client. The default is false. * ieClassId: This is used with the plugin. This is a particular id that is set to activate the plugin. The default value for IE 4 and 5 are - set as of now. This is for future use incase the classId for IE + set as of now. This is for future use in case the classId for IE changes in the future. + + * classdebuginfo: + Whether to include debugging information in the class file. Can take +a value of true/false. If the value is true, then class debugging +information is included in the servlet class file when it is +compiled. The default is false. + To set any of these to a value other than the default you
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java
larryi 01/01/14 12:23:08 Modified:src/share/org/apache/tomcat/core Request.java Log: Bug Report #757 User Principal incorrectly Maintained Submitted by: David Winterfeldt ([EMAIL PROTECTED]) Revision ChangesPath 1.87 +1 -0 jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java Index: Request.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v retrieving revision 1.86 retrieving revision 1.87 diff -u -r1.86 -r1.87 --- Request.java 2001/01/01 00:17:23 1.86 +++ Request.java 2001/01/14 20:23:04 1.87 @@ -816,6 +816,7 @@ charEncoding = null; authType = null; remoteUser = null; + principal = null; reqSessionId = null; serverSession = null; didParameters = false; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util PrefixMapper.java
larryi 01/01/14 12:39:12
Modified:src/share/org/apache/tomcat/util PrefixMapper.java
Log:
getLongestPrefixMatch() would enter a tight loop if the request URI didn't
map into a context. Now, if a match can't be found it returns null and
a 404 error page will be sent back to the client browser.
Revision ChangesPath
1.7 +6 -3
jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java
Index: PrefixMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PrefixMapper.java 2000/12/08 23:18:54 1.6
+++ PrefixMapper.java 2001/01/14 20:39:12 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.6
2000/12/08 23:18:54 costin Exp $
- * $Revision: 1.6 $
- * $Date: 2000/12/08 23:18:54 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.7
2001/01/14 20:39:12 larryi Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/01/14 20:39:12 $
*
*
*
@@ -227,6 +227,9 @@
container = myMap.prefixMappedServlets.get(s);
if (container == null) {
+ // if empty string didn't map, time to give up
+ if ( s.length() == 0 )
+break;
s=FileUtil.removeLast( s );
} else {
if( myMap.mapCacheEnabled ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties
larryi 01/01/14 12:45:41
Modified:src/share/org/apache/jasper EmbededServletOptions.java
JspC.java Options.java
src/share/org/apache/jasper/compiler Compiler.java
JavaCompiler.java JikesJavaCompiler.java
SunJavaCompiler.java
src/share/org/apache/jasper/resources messages.properties
messages_es.properties messages_fr.properties
Log:
Add classDebugInfo property to Options.java and related classes.
Update handling so that Jasper can compile classes with debugging
information if requested.
Revision ChangesPath
1.7 +25 -0
jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- EmbededServletOptions.java2001/01/07 19:24:12 1.6
+++ EmbededServletOptions.java2001/01/14 20:45:39 1.7
@@ -1,4 +1,8 @@
/*
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v 1.7
2001/01/14 20:45:39 larryi Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/01/14 20:45:39 $
+ *
*
*
* The Apache Software License, Version 1.1
@@ -99,6 +103,11 @@
public boolean sendErrorToClient = false;
/**
+ * Do we want to include debugging information in the class file?
+ */
+public boolean classDebugInfo = false;
+
+/**
* I want to see my generated servlets. Which directory are they
* in?
*/
@@ -166,6 +175,13 @@
}
/**
+ * Should class files be compiled with debug information?
+ */
+public boolean getClassDebugInfo() {
+return classDebugInfo;
+}
+
+/**
* Class ID for use in the plugin tag when the browser is IE.
*/
public String getIeClassId() {
@@ -252,6 +268,15 @@
else if (senderr.equalsIgnoreCase("false"))
this.sendErrorToClient = false;
else Constants.message ("jsp.warning.sendErrToClient", Logger.WARNING);
+}
+
+String debugInfo = config.getInitParameter("classdebuginfo");
+if (debugInfo != null) {
+if (debugInfo.equalsIgnoreCase("true"))
+this.classDebugInfo = true;
+else if (debugInfo.equalsIgnoreCase("false"))
+this.classDebugInfo = false;
+else Constants.message ("jsp.warning.classDebugInfo", Logger.WARNING);
}
String ieClassId = config.getInitParameter("ieClassId");
1.19 +9 -0 jakarta-tomcat/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JspC.java 2001/01/07 19:24:13 1.18
+++ JspC.java 2001/01/14 20:45:40 1.19
@@ -1,4 +1,8 @@
/*
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v 1.19
2001/01/14 20:45:40 larryi Exp $
+ * $Revision: 1.19 $
+ * $Date: 2001/01/14 20:45:40 $
+ *
*
*
* The Apache Software License, Version 1.1
@@ -169,6 +173,11 @@
return true;
}
+public boolean getClassDebugInfo() {
+// compile with debug info
+return false;
+}
+
public String getIeClassId() {
return ieClassId;
}
1.13 +9 -0 jakarta-tomcat/src/share/org/apache/jasper/Options.java
Index: Options.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Options.java 2001/01/07 19:24:13 1.12
+++ Options.java 2001/01/14 20:45:40 1.13
@@ -1,4 +1,8 @@
/*
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v
1.13 2001/01/14 20:45:40 larryi Exp $
+ * $Revision: 1.13 $
+ * $Date: 2001/01/14 20:45:40 $
+ *
*
*
* The Apache Software License, Version 1.1
@@ -90,6 +94,11 @@
*/
public boolean getSendErrorToClient();
+/**
+ * Should we include debug information in compiled class?
+ */
+public boolean getClassDebugInfo();
+
/**
* Class ID for use in the
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Glenn Nielsen wrote: Here is my proposal for implementing the Java SecurityManager in Tocmat 4. Work on implementing this proposal is in progress. Comments please? Tomcat 4 Java SecurityManager Proposal Tomcat 4 will require the Java SecurityManager, use of the SecurityManager will be optional when Tomcat is embedded in another application. [...] -0. Why not make it optional for standard use as well? If I use Tomcat for development only, I'm not concerned with security and don't want to mess with policy files. [...] Jasper JSP class loading Jasper will have the old 1.1 compatability code stripped out. +1 The work directory will be moved inside the web application context /WEB-INF/ directory. [...] -1. It should be possible to configure Tomcat so that the work directory is located under /tmp, or any other standard OS location for temporary files. Besides, creating files under /WEB-INF will not work if we one day support running applications straight from the WAR file. Jasper will be modified so that each individual jsp page will have its own URLClassLoader. When each jsp page has its own URLClassLoader we can remove the need to munge and version the jsp java and class file names. We can also create directory paths in the work dir for the context that matches the jsp page path in the context. This will make it easier to view the generated source for a jsp page. When a jsp page is recompiled, a new instance of the URLClassLoader for that page will be created. [...] +1. Great! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] Tomcat 4 SecurityManager implementation
Tomcat would be a great tool to provide catalogs and presentations on CD - with additional advantages if there are already web versions of such applications. I know of a lot of people (me included) that would like to use Tomcat this way. I already implemented a proof of concept where a Delphi application is used to configure and start a Java application using JNI and a JVM on the CD (not installed in the PC). It works very well in Windows. After this, using a small Delphi GUI to start Tomcat and run the installed Web Browser over a Tomcat's site is quite trivial. But we must be able to place work files on the temporary file directory or we can't use JSPs. I am not talking about a weird idea, it is something I am working on and with commercial interest. I even researched, found and tested (with very positive results) a java database (HypersonicSQL) to do the catalog thing. Have fun, Paulo Gaspar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Bergsten Sent: Sunday, January 14, 2001 22:05 The work directory will be moved inside the web application context /WEB-INF/ directory. [...] -1. It should be possible to configure Tomcat so that the work directory is located under /tmp, or any other standard OS location for temporary files. Besides, creating files under /WEB-INF will not work if we one day support running applications straight from the WAR file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #761 has been filed.
Bug report #761 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/761 REPORT #761 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.2.2 Operating System: windows OS Release: 2000 pro Platform: intel Synopsis: incomplete classpath when running from Description: I want to create a webapp in a folder other then the webapps folder inside my tomcat directory. When I add this line to my server.xml... Context path="/app1" docBase="/dev/app1/web"/Context ...I get a webapp and my JSPs work, but my classes in web-inf/classes are not added to the classpath. If I try to hit a servlet... /vic/servlet/fubar ...I'll get the error... Ctx( /vic ): 404 R( /vic + /servlet/fubar + null) null So far I can compile one copy of a webapp and it runs in both weblogic and tomcat (tomcat is clearly faster), but I have to keep this directory beneath tomcat/webapps. Weblogic has no problem referencing a webapp in an independent location. Title: BugRat Report # 761 BugRat Report # 761 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Victor Wynnytsky ([EMAIL PROTECTED]) Date Submitted: Jan 14 2001, 03:44:56 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: incomplete classpath when running from Environment: (jvm, os, osrel, platform) 1.2.2, windows, 2000 pro, intel Additional Environment Description: ... Report Description: I want to create a webapp in a folder other then the webapps folder inside my tomcat directory. When I add this line to my server.xml... ...I get a webapp and my JSPs work, but my classes in web-inf/classes are not added to the classpath. If I try to hit a servlet... /vic/servlet/fubar ...I'll get the error... Ctx( /vic ): 404 R( /vic + /servlet/fubar + null) null So far I can compile one copy of a webapp and it runs in both weblogic and tomcat (tomcat is clearly faster), but I have to keep this directory beneath tomcat/webapps. Weblogic has no problem referencing a webapp in an independent location. How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: [snip] Let me also state that at this point in time, I see Velocity+Turbine as being one of the best solutions out there. I agree it has benefits over JSP, but I do think it's still too hard for HTML only coders to deal with the Velocity syntax. Does an HTML person understand what $data.Parameters.getString($key) means? I think not. So, WM/Velocity is good (or at least better than JSP :-) for developing apps where the HTML is developed by people with Java experience - but thats exactly what I believe we should be heading away from. In contrast XMLC seems to be heading in the right direction because template authors need only understand (pure) HTML. Not that I'm necessarily recommending XMLC as a practical solution, I've never used that either... but I have written YATL, so I feel I have enough experience to comment. In conclusion, let me restate that I feel that Turbine+Velocity is the right way to implement Pull functionality for a simple to complex web application. Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only interested in the theoretical issues. Cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
socket.setSoTimeout(connectionTimeout)
I was pleased to see that a connection timeout has been added to Tomcat 4.0 in the HttpConnector class. A timeout was missing in Sun's JSDK through version 2.0 and in earlier versions of Tomcat. Without a timeout, the servlet runner process accumulates dead connections on the Internet and, with the JSDK, eventually stops accepting new ones since its "max handlers" limit is reached. Dead connections happen all the time out on the Internet when clients make a connection but send in only a few HTTP GET request headers, or no headers at all, and then go away (because of modem disconnects, computers crashes, or anything else silently breaking the connection between the client and the server). I suspect people didn't notice it because they tend to run servlets behind Apache, which does have a connection timeout: http://httpd.apache.org/docs/mod/core.html#timeout We run Tomcat as standalone process, though. Will that connection timeout be a permanent feature in Tomcat starting with version 4.0? Thanks, John Neffenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
"Christopher K. St. John" wrote: "Craig R. McClanahan" wrote: If your server implements session swapping or distribution (as we are currently developing in the 4.1 repository), it is pretty much guaranteed that different session object instances may be used during the lifetime of the same session. But don't you get session lifecycle events if that happens? Yes ... sessionWillPassivate() before the old session is removed, and sessionDidActivate() after the new one has been installed. My point in the remark above is that it is *not* a good assumption that a session instance will be the same physical object throughout the session's lifetime. And, on a servlet 2.2 based server, there is no mechanism to tell you when it changes, because the events are new to 2.3. -cks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: So? Is it ready yet?
Nick Bauman wrote: Have you gotten the new Bugzilla system ready? Please let me know when / if I should close down the report page for bugrat. Almost ... personally, I want to do just a bit more testing first ... Thanks -Nick (The guy running bugrat for Jakarta) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: socket.setSoTimeout(connectionTimeout)
John Neffenger wrote: I was pleased to see that a connection timeout has been added to Tomcat 4.0 in the HttpConnector class. A timeout was missing in Sun's JSDK through version 2.0 and in earlier versions of Tomcat. Without a timeout, the servlet runner process accumulates dead connections on the Internet and, with the JSDK, eventually stops accepting new ones since its "max handlers" limit is reached. Dead connections happen all the time out on the Internet when clients make a connection but send in only a few HTTP GET request headers, or no headers at all, and then go away (because of modem disconnects, computers crashes, or anything else silently breaking the connection between the client and the server). I suspect people didn't notice it because they tend to run servlets behind Apache, which does have a connection timeout: http://httpd.apache.org/docs/mod/core.html#timeout We run Tomcat as standalone process, though. Will that connection timeout be a permanent feature in Tomcat starting with version 4.0? Insofar as any of us can predict the future, I would say the answer to this is definitely yes. Among other things, the lack of a timeout creates a pretty easy DOS attack against a Tomcat server -- simply open enough socket connections to exhaust the configured pool size, and just sit there. Over time, we will probably want to tweak how long the timeouts actually are, based on the state of the interaction so far, but AFAIKT they will always be needed. Thanks, John Neffenger Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Patches and TC 4.1
Remy Maucherat wrote: I have an issue with 4.1 code (fresh from CVS) at the moment -- the JSP examples do not run correctly. That is, any JSP page that references a bean class that is loaded from WEB-INF/classes or WEB-INF/lib fails to find that class. The classpath generation for Jasper was broken. It should be fixed now. I'd like to make a few proposals : - Move the org.apache.naming package and subpackages, which is part of the Catalina subproject right now, and make it an independent Tomcat subproject. - Do the same for the org.apache.catalina.util package (and rename it org.apache.tomcat.util). By this, do you mean make them separate top-level subdirectories under jakarta-tomcat-4.1? Yes. If so, I'm +1. Ok, I'll make the changes next week. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/14/01 3:11 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: [snip] Let me also state that at this point in time, I see Velocity+Turbine as being one of the best solutions out there. I agree it has benefits over JSP, but I do think it's still too hard for HTML only coders to deal with the Velocity syntax. Does an HTML person understand what $data.Parameters.getString($key) means? I think not. So, WM/Velocity is good (or at least better than JSP :-) for developing apps where the HTML is developed by people with Java experience - but thats exactly what I believe we should be heading away from. Actually, you have missed the point entirely. I'm not expecting or even asking designers to understand what $data.Parameters.getString($key) means, however, I can expect them to be able to work around those fields in a page. There are several classifications of people who are expected to work on a web application: #1. Designers. People who know HTML. May know some javascript. Nothing more. #2. Template Engineers. People who know how to work with an API and understand the template language (ie: people who understand what $data.Parameters.getString($key) *does*, but may not understand the Java behind it). Eventually, they may become engineers. #3. Java Engineers. People who are responsible for developing the API and doing the Actions. In contrast XMLC seems to be heading in the right direction because template authors need only understand (pure) HTML. Not that I'm necessarily recommending XMLC as a practical solution, I've never used that either... but I have written YATL, so I feel I have enough experience to comment. Right, however XMLC is push based and that is bad for all the reasons documented in my Pull document. It also has the problem of tying the HTML to the Java code. For example, say you want to break elements of a form across several pages. If you can't do that without editing Java code on the back end, that is bad because then you have to pay java engineers to make the changes that template engineers should be able to do. Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only interested in the theoretical issues. It wasn't a flame war. It really saddens me to always be guilty before being proven innocent. Quit thinking that I'm always trying to start a flame war. This is a conversation and if I don't agree with something, that isn't a flame...that is me stating an opinion. I spent a bunch of time coming up with valid reasons why other technologies are sorely lacking. At least you could do the same. -jon -- Honk if you love peace and quiet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
Why not always have it optional possibly determined by a system property
value ? This way you won't have people complainig about slow down if they
don't care about security ;) It will also be easier to integrate into other
products.
Setting policies for web application contexts
-
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
};
I have actually implemented something similar this in Avalon about 7 hours
ago checking it in. Avalon has notion of .sars (Server Application
Archives) which are very similar to .wars in idea. I was having some issues
with JVM wide policy which you advocate above so I started playing around
with a per-sar policy.
To do this I had to subclass SecureClassLoader (I did this via
URLClassLoader) and overide it's method
protected PermissionCollection getPermissions( final CodeSource codeSource );
I overode this to access a per-sar Policy object. If no policy was given it
would give full access to the system. As I was embedding policy information
in another file (an XML file) it looked something like
policy
!--
keystore name="foo-keystore"
location="file:${sar.home}${/}conf${/}keystore"
type="JKS" /
grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
key-store="foo-keystore"
permission class="java.io.FilePermission" target="/tmp/*"
action="read,write" /
/grant
--
grant code-base="file:${sar.home}${/}blocks${/}*"
permission class="java.security.AllPermission" /
/grant
grant code-base="file:${sar.home}${/}lib${/}*"
permission class="java.security.AllPermission" /
/grant
To do this I implemented AbstractPolicy (for generic facilities) and
SarPolicy (for configuring it from XML file). I have attached the relevent
classes just in case you are interested.
Future enhancements
---
See if it is possible and secure to let an individual
web application set its security policies in its own
policy file located in its /WEB-INF/ directory.
This is a great facility - when implementing the equivelent for Avalon I
found it vital for a usable system ;)
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE file.
*/
package org.apache.avalon.engine;
import java.io.File;
import java.net.URL;
import java.net.MalformedURLException;
import java.security.AccessController;
import java.security.CodeSource;
import java.security.Permission;
import java.security.PermissionCollection;
import java.security.Permissions;
import java.security.Policy;
import java.security.PrivilegedExceptionAction;
import java.security.PrivilegedActionException;
import java.security.cert.Certificate;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.PropertyPermission;
import org.apache.avalon.util.io.FileUtil;
import org.apache.avalon.Component;
import org.apache.avalon.Loggable;
import org.apache.log.Logger;
/**
* Abstract policy extended in avalon.
*
* @author a href="mailto:[EMAIL PROTECTED]"Peter Donald/a
*/
public abstract class AbstractPolicy
extends Policy
implements Component, Loggable
{
protected final static boolean DEBUG = true;
protected final ArrayListm_entries = new ArrayList();
protected Logger m_logger;
/**
* Internal Policy Entry holder class.
*/
protected final static class PolicyEntry
{
CodeSource m_codeSource;
Permissions m_permissions;
}
public void setLogger( final Logger logger )
{
m_logger = logger;
}
/**
* Overide so we can have a per-application security policy
Re: socket.setSoTimeout(connectionTimeout)
Insofar as any of us can predict the future, I would say the answer to this is definitely yes. Among other things, the lack of a timeout creates a pretty easy DOS attack against a Tomcat server -- simply open enough socket connections to exhaust the configured pool size, and just sit there. Note : It's not that much better with 4.0 against DOS, since the connector will still sit idle for quite some time before closing the connection, so it would just be maginally harder to DOS. Over time, we will probably want to tweak how long the timeouts actually are, based on the state of the interaction so far, but AFAIKT they will always be needed. Yes, it will be in in 4.1, since the client can actually give hints about the keep alive duration with the Connection header. In 4.1, the timeout value will also be dynamic depending on how many processors are idle (the less there are, the shorter the timeout). Also, the connection timeout can be set for the connector using the connectionTimeout property. The default is 60s. This (put in the server.xml file) would set the timeout to 30s : Connector className="org.apache.catalina.connector.http.HttpConnector" port="80" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0" connectionTimeout="3"/ Other useful features in the connector would be : - Support for tranfer encodings (like deflate and gzip) which should be easy to do by layering output streams. - Add a (configurable) mechnism to limit the number of connections any given client get get. I do not anticipate that 4.1 will introduce a lot of new core features (the main one - the JNDI stuff - is already in), but will feture a number of limited code rewrite and reorganization to improve robustness and performance. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
-0. Why not make it optional for standard use as well? If I use Tomcat for development only, I'm not concerned with security and don't want to mess with policy files. Same here. There's a switch for the naming features, and I think it should be the same with the security manager. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/14/01 3:11 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: [snip] Let me also state that at this point in time, I see Velocity+Turbine as being one of the best solutions out there. I agree it has benefits over JSP, but I do think it's still too hard for HTML only coders to deal with the Velocity syntax. Does an HTML person understand what $data.Parameters.getString($key) means? I think not. So, WM/Velocity is good (or at least better than JSP :-) for developing apps where the HTML is developed by people with Java experience - but thats exactly what I believe we should be heading away from. Actually, you have missed the point entirely. I'm not expecting or even asking designers to understand what $data.Parameters.getString($key) means, however, I can expect them to be able to work around those fields in a page. There are several classifications of people who are expected to work on a web application: #1. Designers. People who know HTML. May know some javascript. Nothing more. #2. Template Engineers. People who know how to work with an API and understand the template language (ie: people who understand what $data.Parameters.getString($key) *does*, but may not understand the Java behind it). Eventually, they may become engineers. #3. Java Engineers. People who are responsible for developing the API and doing the Actions. [snip] In contrast XMLC seems to be heading in the right direction because template authors need only understand (pure) HTML. Not that I'm necessarily recommending XMLC as a practical solution, I've never used that either... but I have written YATL, so I feel I have enough experience to comment. Right, however XMLC is push based and that is bad for all the reasons documented in my Pull document. It also has the problem of tying the HTML to the Java code. For example, say you want to break elements of a form across several pages. If you can't do that without editing Java code on the back end, that is bad because then you have to pay java engineers to make the changes that template engineers should be able to do. Seems to me that your argument rests on the assumption that there exists such a beast as a "template engineer" - someone who is skilled in HTML and who understands coding without ever having had formal programming training. Call me traditionalist, but having coding done by non-coders is a recipe for disaster. For example, I think that a template engineer who was capable of rewriting templates to split a form across several pages would probably be worth paying as much as a Java coder anyway. For example, you can easily hire a qualified HTML coder or a Java coder, but it's pretty difficult to hire a qualified "template author", especially when you want them to know your own flavour of YATL. Saying all that I'm sure if you set up your organisation with these three classes of developers it would work. It's simply a question of which way would be more efficient overall. I favour the 2 role way, you the 3 role way. Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only interested in the theoretical issues. It wasn't a flame war. It really saddens me to always be guilty before being proven innocent. Quit thinking that I'm always trying to start a flame war. This is a conversation and if I don't agree with something, that isn't a flame...that is me stating an opinion. Aw, chill out man! You just come across as, er, quite opinionated, thats why people always get the wrong impression. I've been hanging around this scene for long enough to appreciate the way you do stuff... without getting _too_ upset :-) Certainly no need for any paranioa ... :-) I spent a bunch of time coming up with valid reasons why other technologies are sorely lacking. At least you could do the same. I think I am! :-) Cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
on 1/14/01 5:00 PM, "Peter Donald" [EMAIL PROTECTED] wrote: At 05:43 13/1/01 -0800, Hans Bergsten wrote: If you have any interest in the future of the Jakarta project, I think you should come. I know it's out of context but this neatly summarizes it doesn't it ;) What you may ask - well let me elaborate. When I first started working with Apache peeps it was great - I never heard any complaints or had any issues. It was Stefano who introduced of sorts to it all so if I wanted something I would bug him and it would happen ;) Then I started hearing grumblings from a few people. Usually they involved one of these points In other words, it is much easier to be critical of the people who are in public eye. 1. It is too slow to get projects hosted at Apache unless you are good friends with PMC members 2. Some people were trying to bully/intimadate others because they were on the PMC/were in the clique 3. Outside projects had to work to get hosted rather than Apache working to aquire them Right. The ASF is not trying to be sourceforge. Hosting of projects on ASF sites are strictly supposed to be reserved for: Projects which already have a community built up around it and a member is willing to sponsor it and the developers make a good match for the ASF. For example, I don't think that people who want to release their code as GPL are welcome here. :-) I may have gotten some of that wrong and missed a few points, but that is the general gist of it as I see it. In the past, we have made mistakes with dealing with people on hosting projects and have actually lost a couple projects as a result. Should we be raked over the coals for our lack of interest or ability as a volunteer organization to handle each and every request perfectly? I don't think so. I pretty much ignored them as they didn't effect me and to a large extent I don't care for the politicing. A bit later I heard even worse criticism about the process mainly from a few bitter individuals/groups thou I think most of what they said was unwarranted so it is of no use repeating it here. One thing I noticed was that some of the politicers seemed to be under stress and a little overworked - and consequently a little short ;) Correct. I think that that is a good estimation of me in fact. I tend to be short in my responses cause I don't have time to spend an hour sending each and every person a beautiful email that will make their day. :-) Recently I have been forced to stick my head up and look around at this structure. I am not a member of apache so immediately a number of doors were closed. I tried asking people things and basically they said - "I dunno" to 90% of the questions. I initially presumed it was because most people weren't members. So I asked a member and they were in the dark aswell ... hmmm. Aparently management still takes place behind closed doors away from the groups own members ! Eek. Not pretty - another member also noted this and expressed the fact they were for intents powerless to effect this. I think that your assumption about management happening behind closed doors is 100% incorrect. I would change that to be something along the lines that we are all volunteers and extremely busy and if anything *no* management is going on and hence the issues that have been coming up. I have been thinking how I would do it and I came to the conclusion that the only way to run it is by "opening" management up. This is an opensource group so why not "opensource" the leadership? Currently jakarta is led from behind closed doors by privlidged members. You can not gain access - at least easily - to the resources within Apache. Not true at all! You can send email to the PMC mailing lists and get responses. We get *very* little email to the Jakarta PMC mailing list from the public. Why? You tell me. I know there is mailing lists that the public is restricted from accessing and only the clique may get in - however why is this necessary ? I understand that there may be - on rare occasions - a need to discuss details under a NDA and thus outside the public eye. However - what about the remainder of the time. Is there any need to exclude the rest of the community? Ok, so you are asking us to double our workload in order to make you happy? I don't think so. Again, your assumptions about all this "management" happening behind closed doors is fully incorrect. It is important that corporations have the ability to have a place where they can email privately to a core select set of individuals and expect to get a timely response. That is what the PMC has been serving a role as. This is not the only exclusionary practices I have noticed either. This meeting proposed is another example of practices that (possibly inadvertently) are exclusionary. The vast majority of the jakarta/java apache community would find it impossible to actually participate due to practical reasons. Personally it would cost me
BugRat Report #765 has been filed.
Bug report #765 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/765 REPORT #765 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.2.2 Operating System: Solaris OS Release: SunOS 5.7 Platform: Sun Enterprise 450 Synopsis: tomcat teminated unexpectedly Description: 2001-01-14 04:03:46 - ThreadPool: Caught exception executing org.apache.tomcat.service.TcpWorkerThread@13c7030, terminating thread - java.lang.IllegalStateException at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Compiled Code) at java.lang.Throwable.init(Compiled Code) at java.lang.Exception.init(Compiled Code) at java.lang.RuntimeException.init(RuntimeException.java:37) at java.lang.IllegalStateException.init(IllegalStateException.java:34) at org.apache.tomcat.util.ThreadPool.runIt(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /examples ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /hld ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /cute ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /admin ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /test ) Title: BugRat Report # 765 BugRat Report # 765 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: ZhanYi ([EMAIL PROTECTED]) Date Submitted: Jan 14 2001, 08:15:38 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: tomcat teminated unexpectedly Environment: (jvm, os, osrel, platform) 1.2.2, Solaris, SunOS 5.7, Sun Enterprise 450 Additional Environment Description: Report Description: 2001-01-14 04:03:46 - ThreadPool: Caught exception executing org.apache.tomcat.service.TcpWorkerThread@13c7030, terminating thread - java.lang.IllegalStateException at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Compiled Code) at java.lang.Throwable.(Compiled Code) at java.lang.Exception.(Compiled Code) at java.lang.RuntimeException.(RuntimeException.java:37) at java.lang.IllegalStateException.(IllegalStateException.java:34) at org.apache.tomcat.util.ThreadPool.runIt(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /examples ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /hld ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /cute ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /admin ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( ) 2001-01-14 04:03:46 - ContextManager: Removing context Ctx( /test ) View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/14/01 5:34 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: Seems to me that your argument rests on the assumption that there exists such a beast as a "template engineer" - someone who is skilled in HTML and who understands coding without ever having had formal programming training. Actually, we have several TE's working for us at CollabNet and several of our clients also "supply" people with these skills to work with us. Call me traditionalist, but having coding done by non-coders is a recipe for disaster. For example, I think that a template engineer who was capable of rewriting templates to split a form across several pages would probably be worth paying as much as a Java coder anyway. For example, you can easily hire a qualified HTML coder or a Java coder, but it's pretty difficult to hire a qualified "template author", especially when you want them to know your own flavour of YATL. I agree, that is a traditionalist point of view. That is why I'm working hard to come up with solutions to break that POV and smash it to shreds. We are getting very close over in Turbine/Velocity land. There is one last major thing to do which John McNally is working on...automatic handling and generation of the objects which represent the form. In other words, we want to be able to define the business logic for our forms in a .xml file and then auto-generate Java code as needed to deal with handling of the forms. Think Object-Relational tool not for RDBMS, but for FORMS! :-) Even cooler is that this will be tied into the OR definitions in order to define things like the maxlength of a form input text field based on the size of the column definition. We will also support things like auto-populating of the form data when the page is redisplayed due to an error or in the case where we are re-displaying the page to show previously entered data. This isn't anything really "new"...however, it is fairly new in the context of Java App Frameworks that are OSS as well as being implemented within the idea of the 100% pull paradigm. If you would like to be part of this, we welcome you to subscribe to the Turbine list and start discussing it. Saying all that I'm sure if you set up your organisation with these three classes of developers it would work. It's simply a question of which way would be more efficient overall. I favour the 2 role way, you the 3 role way. Right, let me repeat what I'm hearing you say: in the 2 role way, you would have a designer and an java engineer. In that case, that is fine as well, the java engineer would simply be responsible for the template engineer's job. In CollabNet's case though, we have clients which may be "web savvy" enough to be able to learn enough template language and API's (although maybe not savvy enough to learn Java) and we need to be able to give them a way to edit/modify their sites that we create for them without having to have us involved all the time. In other words, we need to be able to scale our business without having to hire huge teams of engineers to support our ever growing client base. Aw, chill out man! You just come across as, er, quite opinionated, thats why people always get the wrong impression. I've been hanging around this scene for long enough to appreciate the way you do stuff... without getting _too_ upset :-) Certainly no need for any paranioa ... :-) I agree. I'm very opinionated. I'm also glad there is someone like me...otherwise, we would all continue to sit around the table looking silly at each other at dinner with nothing to say! :-) thanks, -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
on 1/14/01 6:42 PM, "Peter Donald" [EMAIL PROTECTED] wrote: At 05:48 14/1/01 -0800, Jon Stevens wrote: I know it's out of context but this neatly summarizes it doesn't it ;) What you may ask - well let me elaborate. When I first started working with Apache peeps it was great - I never heard any complaints or had any issues. It was Stefano who introduced of sorts to it all so if I wanted something I would bug him and it would happen ;) Then I started hearing grumblings from a few people. Usually they involved one of these points In other words, it is much easier to be critical of the people who are in public eye. not sure what you mean by this. What I mean is that I think that the ASF members as well as the PMC members are attempting to do the best job that we can possibly do (remember, we are VOLUNTEERS). Sure, we make mistakes, however getting all pissed off at us because we do make mistakes is really absurd in my opinion and I think that it is a lot easier to be critical than it is to step up and help fix the problems. Projects which already have a community built up around it and a member is willing to sponsor it and the developers make a good match for the ASF. For example, I don't think that people who want to release their code as GPL are welcome here. :-) right - well I guess this should be publicised somewhere. What about projects that "start" here - ie tomcat never had a community before it got here, nor did velocity I assume, nor possibly some of the regular expression libs. Actually, Velocity and Tomcat did already have communities from the point of view in that they had several developers (including ASF members) who were willing to be part of the development from day one. In fact, when I was explaining to the PMC why I wanted to create the Velocity project, that was a specific concern of both James and Craig. I addressed that concern by simply pointing to the fact that we had 3-4 people working on the project at the time already. As for the Regexp project, that was sponsored by myself...an ASF member as well as James Davidson, another ASF member. That was enough to pass the vote at the PMC level at the time. Well I disagree - for your lack of interest you should be but not for your lack of ability ;) I'm going to assume that was made in jest. :-) Correct. I think that that is a good estimation of me in fact. I tend to be short in my responses cause I don't have time to spend an hour sending each and every person a beautiful email that will make their day. :-) I wasn't actually referring to you ;) I understand that. But as a ASF/PMC member, I was. :-) I think that your assumption about management happening behind closed doors is 100% incorrect. I would change that to be something along the lines that we are all volunteers and extremely busy and if anything *no* management is going on and hence the issues that have been coming up. well how do I know that? I don't know who is on PMC, how many peeps are on it etc. Yawn... http://jakarta.apache.org/site/whoweare.html AND (links to the above page from:) http://jakarta.apache.org/site/roles.html Decisions are made that effect me as a developer but I have no say in it - or at least I am not given oportunity to have a say ;) Also members of Apache have stated they don't feel like they have a say - so ... somewhere along the lines there is miscommunication. Actually, you are given much of an opportunity to have a say. That is what you are doing now, correct? You are voicing your opinions. This is something that I do a lot on. The people who sit back and watch things don't have as much of a "say" because they are not taking part in the grand scheme of things. At the next ASF meeting I will nominate you to become a member because you have been contributing a lot and I would like to see you contribute more. That is how it works. Not true at all! You can send email to the PMC mailing lists and get responses. We get *very* little email to the Jakarta PMC mailing list from the public. Why? You tell me. how many people know about it? how many people feel they could approach the list. Even if they approach the list whats th guarentee they will get the full conversation. I have been cc'ed on discussions and only got half-ideas of whats going on because not everyone CC's out the mail and again there is miscommunication ;) Great suggestion! Submit a patch that includes the PMC address more prominently on the website. In other words, again, we are volunteers and we aren't going to think of each and every single little detail. We expect to get feedback from the community on things. It may be obvious to you at this point that we are missing a PMC email address on the website, however, to us, we have a bazillion other things to worry about. Therefore, it is up to the community to step up and help us out. I know there is mailing lists that the public is restricted from accessing and only
cvs commit: jakarta-tomcat-4.1/catalina/src/conf web.xml
remm01/01/14 20:26:40 Modified:catalina/src/conf web.xml Log: - Add some sound and video MIME types. Revision ChangesPath 1.12 +24 -0 jakarta-tomcat-4.1/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.1/catalina/src/conf/web.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- web.xml 2000/12/22 01:31:03 1.11 +++ web.xml 2001/01/15 04:26:40 1.12 @@ -417,6 +417,30 @@ extensionmpv2/extension mime-typevideo/mpeg2/mime-type /mime-mapping + mime-mapping +extensionasf/extension +mime-typevideo/x-ms-asf/mime-type + /mime-mapping + mime-mapping +extensionasx/extension +mime-typevideo/x-ms-asf/mime-type + /mime-mapping + mime-mapping +extensionmp2/extension +mime-typeaudio/x-mpeg/mime-type + /mime-mapping + mime-mapping +extensionmp3/extension +mime-typeaudio/x-mpeg/mime-type + /mime-mapping + mime-mapping +extensiondoc/extension +mime-typeapplication/msword/mime-type + /mime-mapping + mime-mapping +extensionrm/extension +mime-typeapplication/vnd.rn-realmedia/mime-type + /mime-mapping !-- Establish the default list of welcome files -- welcome-file-list - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Hans Bergsten wrote: [...] The spec may not be explicit enough about this, but the session object you get back from the getSession() object is a container-managed object that the application is not supposed/allowed to keep long-lived references to. It's the same as with all other container-objects made available to the application; request, response, JSP tag handlers, etc. I'm not sure why you're keeping references to the session objects in you're application, but if you describe what you're trying to do I'm sure I can give you a hint about another way to accomplish the same thing without the problems you have with your current solution. I amtrying to disallow a single user to have multiple login sessions valid at any given time. I have to enforce this even if the user tried to login from two different machines. Can you suggest a solution for this which works on tomcat 3.2.1 and uses servlet specs 2.2 only. Regds, Gokul
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory Constants.java EjbFactory.java ResourceEnvFactory.java ResourceFactory.java TransactionFactory.java
remm01/01/14 21:12:31
Modified:catalina/src/share/org/apache/naming/factory Constants.java
EjbFactory.java ResourceEnvFactory.java
ResourceFactory.java TransactionFactory.java
Log:
- Make the object factories easily pluggable.
- Now, the default factories will look for a RefAddr in the Reference which
contains the classname of the factory to use. This can be set using the
ResourceParams element in server.xml.
- Will attempt to load the factory using the thread's context class loader, so
that it can load classes from the webapp's classloader repositories.
Revision ChangesPath
1.2 +5 -3
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/Constants.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Constants.java2000/11/04 06:46:09 1.1
+++ Constants.java2001/01/15 05:12:28 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/Constants.java,v
1.1 2000/11/04 06:46:09 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2000/11/04 06:46:09 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/Constants.java,v
1.2 2001/01/15 05:12:28 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/01/15 05:12:28 $
*
*
*
@@ -92,5 +92,7 @@
Package + ".TyrexTransactionFactory";
public static final String OBJECT_FACTORIES = "";
+
+public static final String FACTORY = "factory";
}
1.2 +40 -5
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/EjbFactory.java
Index: EjbFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EjbFactory.java 2000/11/04 06:46:09 1.1
+++ EjbFactory.java 2001/01/15 05:12:29 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
1.1 2000/11/04 06:46:09 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2000/11/04 06:46:09 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
1.2 2001/01/15 05:12:29 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/01/15 05:12:29 $
*
*
*
@@ -77,7 +77,7 @@
* Object factory for EJBs.
*
* @author Remy Maucherat
- * @version $Revision: 1.1 $ $Date: 2000/11/04 06:46:09 $
+ * @version $Revision: 1.2 $ $Date: 2001/01/15 05:12:29 $
*/
public class EjbFactory
@@ -106,11 +106,46 @@
*/
public Object getObjectInstance(Object obj, Name name, Context nameCtx,
Hashtable environment)
-throws NamingException {
+throws Exception {
if (obj instanceof EjbRef) {
Reference ref = (Reference) obj;
-// Does nothing yet
+ObjectFactory factory = null;
+RefAddr factoryRefAddr = ref.get(Constants.FACTORY);
+if (factoryRefAddr != null) {
+// Using the specified factory
+String factoryClassName =
+factoryRefAddr.getContent().toString();
+// Loading factory
+ClassLoader tcl =
+Thread.currentThread().getContextClassLoader();
+Class factoryClass = null;
+if (tcl != null) {
+try {
+factoryClass = tcl.loadClass(factoryClassName);
+} catch(ClassNotFoundException e) {
+}
+} else {
+try {
+factoryClass = Class.forName(factoryClassName);
+} catch(ClassNotFoundException e) {
+}
+}
+if (factoryClass != null) {
+try {
+factory = (ObjectFactory) factoryClass.newInstance();
+} catch(Throwable t) {
+}
+}
+}
+// Note: No defaults here
+if (factory != null) {
+return factory.getObjectInstance
+(obj, name, nameCtx, environment);
+} else {
+throw new NamingException
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm01/01/14 21:51:27
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Fix a bug where a directory browse page wouldn't be served if the request
included a rage header. That fixes compatibility with the HTTP browser
included with the GetRight download manager.
Revision ChangesPath
1.23 +15 -12
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- DefaultServlet.java 2001/01/14 02:36:52 1.22
+++ DefaultServlet.java 2001/01/15 05:51:26 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.22 2001/01/14 02:36:52 remm Exp $
- * $Revision: 1.22 $
- * $Date: 2001/01/14 02:36:52 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.23 2001/01/15 05:51:26 remm Exp $
+ * $Revision: 1.23 $
+ * $Date: 2001/01/15 05:51:26 $
*
*
*
@@ -118,7 +118,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.22 $ $Date: 2001/01/14 02:36:52 $
+ * @version $Revision: 1.23 $ $Date: 2001/01/15 05:51:26 $
*/
public class DefaultServlet
@@ -1465,18 +1465,20 @@
// Parse range specifier
Vector ranges = null;
if (!resourceInfo.collection) {
+
ranges = parseRange(request, response, resourceInfo);
-
-// Last-Modified header
-if (debug 0)
-log("DefaultServlet.serveFile: lastModified='" +
-(new Timestamp(resourceInfo.date)).toString() + "'");
-response.setDateHeader("Last-Modified", resourceInfo.date);
// ETag header
response.setHeader("ETag", getETag(resourceInfo, true));
+
}
+// Last-Modified header
+if (debug 0)
+log("DefaultServlet.serveFile: lastModified='" +
+(new Timestamp(resourceInfo.date)).toString() + "'");
+response.setDateHeader("Last-Modified", resourceInfo.date);
+
ServletOutputStream ostream = null;
PrintWriter writer = null;
@@ -1499,8 +1501,9 @@
}
-if ( ((ranges == null) || (ranges.isEmpty()))
- (request.getHeader("Range") == null) ) {
+if ( (resourceInfo.collection) ||
+ ( ((ranges == null) || (ranges.isEmpty()))
+(request.getHeader("Range") == null) ) ) {
// Set the appropriate output headers
if (contentType != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Peter Donald wrote:
At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
Why not always have it optional possibly determined by a system property
value ? This way you won't have people complainig about slow down if they
don't care about security ;) It will also be easier to integrate into other
products.
Setting policies for web application contexts
-
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
};
I have actually implemented something similar this in Avalon about 7 hours
ago checking it in. Avalon has notion of .sars (Server Application
Archives) which are very similar to .wars in idea. I was having some issues
with JVM wide policy which you advocate above so I started playing around
with a per-sar policy.
To do this I had to subclass SecureClassLoader (I did this via
URLClassLoader) and overide it's method
protected PermissionCollection getPermissions( final CodeSource codeSource );
Duh! Somehow that method never popped out when I was looking at the URLClassLoader
class. That will make things even easier.
Your per application config below would work for Tomcat, but it would be nice
to see if a standard java policy file per web application could be used instead.
I overode this to access a per-sar Policy object. If no policy was given it
would give full access to the system. As I was embedding policy information
in another file (an XML file) it looked something like
policy
!--
keystore name="foo-keystore"
location="file:${sar.home}${/}conf${/}keystore"
type="JKS" /
grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
key-store="foo-keystore"
permission class="java.io.FilePermission" target="/tmp/*"
action="read,write" /
/grant
--
grant code-base="file:${sar.home}${/}blocks${/}*"
permission class="java.security.AllPermission" /
/grant
grant code-base="file:${sar.home}${/}lib${/}*"
permission class="java.security.AllPermission" /
/grant
To do this I implemented AbstractPolicy (for generic facilities) and
SarPolicy (for configuring it from XML file). I have attached the relevent
classes just in case you are interested.
Future enhancements
---
See if it is possible and secure to let an individual
web application set its security policies in its own
policy file located in its /WEB-INF/ directory.
This is a great facility - when implementing the equivelent for Avalon I
found it vital for a usable system ;)
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Gokul Singh wrote:
Hans Bergsten wrote:
[...]
The spec may not be explicit enough about this, but the session
object
you get back from the getSession() object is a container-managed
object
that the application is not supposed/allowed to keep long-lived
references
to. It's the same as with all other container-objects made available
to
the
application; request, response, JSP tag handlers, etc.
I'm not sure why you're keeping references to the session objects in
you're application, but if you describe what you're trying to do I'm
sure I can give you a hint about another way to accomplish the same
thing without the problems you have with your current solution.
I am trying to disallow a single user to have multiple login sessions
valid at any given time. I have to enforce this even if the user tried
to login from two different machines.
Okay, in that case comparing HttpSession objects wouldn't work even
if Tomcat kept the same instance throughout the session. If the user
tries to log in from two different machines, he/she would get always
get two different sessions. Even when using two different browser
windows on the same machine, he/she may end up with two different
sessions (long story, search the JSP- and SERVLET-INTEREST list
archives for details). The bottom line is that a session is associated
with a "client", not a "user".
Can you suggest a solution for this which works on tomcat 3.2.1 and
uses servlet specs 2.2 only.
Something like this should work in any compliant container.
Create an instance of a class that implements the
javax.servlet.http.HttpSessionBindingListener interface and save it
in the session when the user logs in. Give the instance references
to the ServletContext and the user's login ID. In the valueBound()
method, add the loginID to a data structure kept as a context attribute,
and in the valueUnbound() method, remove the user info from the data
structure:
public class UserBean implements HttpSessionBindingListener,
Serializable {
private ServletContext context;
private String loginID;
public UserBean(ServletContext context, String loginID) {
this.context = context;
this.loginID = loginID;
}
public void valueBound(HttpSessionBindingEvent e) {
Vector currentUsers =
(Vector) context.getAttribute("currentUsers");
if (currentUsers == null) {
currentUsers = new Vector();
}
currentUsers.addElement(loginID);
}
public void valueUnbound(HttpSessionBindingEvent e) {
Vector currentUsers =
(Vector) context.getAttribute("currentUsers");
currentUsers.removeElement(loginID);
}
}
To make sure a user only logs in once, check if the loginID is
already in the context structure before allowing a new login
and creating the UserBean.
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: FW: Jakarta PMC Meeting Agenda / Info
Well, I think I have to clear few things up. I already announced ( probably not clearly enough ) my intention to give up and spend my free time in better ways. This is a form of vote, BTW. The only thing that keeps me subscribed to this list is the fact that I wanted to finish my work on tomcat3 - quite a few people put a lot of their time and effort into it, and I'll do whatever I can to make sure their work is not lost. I don't think my presence to the PMC meeting can bring anything good - I think most of the decisions have already been taken, and most of the games done. It seems things have already been debated in productive closed-lists, and 1/2 of the judges are representing one side. I have a lot of respect for the other 1/2, but their (lack of ) open attitude during recent months is one of the main reasons for me wanting to get out of this project as soon as possible. In any case, the only thing I can do is to make clear that I ( as still a commiter on this project ) believe that tomcat 3.3 is to tomcat 3.2 what 3.2 is to 3.1 - a step forward and an evolution in the right direction. If you want to help - do the same, write to the list stating your opinion ( and don't answer to any flame ). Or write to any PMC member you like, and please mention the reasons for not writing to the list. A +1 is enough if you don't want to add more. I'm very happy with the way our evolution worked. The fact that so many people contributed so much ( Gal, Sam, Larry, Nacho, Alex, Glen, Henri, Dan - and everyone else ) is what makes tomcat 3.x a great success. And again, tomcat 3.3 is not my baby - all I did was to clean up and move code around trying to learn from Apache2.0 and others. The original design is the main value, and almost all features have been implemented by other people. I'm waiting for the moment they feel Catalina is completed and has all the promised features and it's ready to be compared with Tomcat 3. -- Costin P.S. I'll try to call in, if a line is available - and I would love to meet those of you in Bay Area, but I'm afraid my presence to the meeting will give them a chance to turn things into a personal thing ( I'm the villain, and as a consequence tc3.3 is bad ) - and I don't want to distract the attention from more important issues. BTW, 3.3 is the least important issue in this meeting - the code exists and no meeting can change that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: IM LOST, ERROR 500????
Delivery failure: javax.mail.MessagingException: 452 Filesystem error - message not accepted Delivery failure: javax.mail.MessagingException: 452 Filesystem error - message not accepted Hi Im writing my first little program that will welcome a user once she enters and submits her details into a web page.There is no problem Writing the JSP files but I cannot start a new .java file in Jbuilder, so I write it in Homesite, save it as .java and attempt to compile it to .class in Jbuilder. Im having difficulty converting the .javafile to .class I have tried compiling the .java file to a .class in JBuilder, but I keep getting the following warning: "Warning #908: check sourcepath; source c:\jakarta-tomcat\webapps\mary\Web-inf\Classes\namehandler.java cannot be found on source pathby appending \mary\namehandler.java to each sourcepath entry." (mary is the name of the package) When I try to view the program in my browser at http:// localhost etc etc I get the following error Error: 500 Location: /Mary/hellouser.jsp Internal Servlet Error:org.apache.jasper.JasperException: Bad file argument to include at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java, Compiled Code) at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:116) at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java, Compiled Code) at org.apache.jasper.compiler.Parser.parse(Parser.java, Compiled Code) at org.apache.jasper.compiler.Parser.parse(Parser.java:1038) at org.apache.jasper.compiler.Parser.parse(Parser.java:1034) at org.apache.jasper.compiler.Compiler.compile(Compiler.java, Compiled Code) at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:413) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:149) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:161) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261) at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:160) at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338) at java.lang.Thread.run(Thread.java:479)PLEASE PLEASE PLEASE, anyone with help?Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
- Original Message - From: "Hans Bergsten" [EMAIL PROTECTED] Gokul Singh wrote: Hans Bergsten wrote: [...] I am trying to disallow a single user to have multiple login sessions valid at any given time. I have to enforce this even if the user tried to login from two different machines. A small addition here. The requirement is that the user be allowed to login by creating a new session on login request and invalidating any valid session that he may have at that time. To be more elaborate. 1. A user U logs in and has a session associated with him i.e. S1. 2. user U goes to another machine and tries to login. 3. The user U should get a new session S2 with S1 being invalidated. I hope the requirements are now clear. archives for details). The bottom line is that a session is associated with a "client", not a "user". Agreed. Can you suggest a solution for this which works on tomcat 3.2.1 and uses servlet specs 2.2 only. Something like this should work in any compliant container. Thanks for putting down the whole code for me. I already implement this philosophy in my code. But the requirements are slightly different as spelled above. To make sure a user only logs in once, check if the loginID is already in the context structure before allowing a new login and creating the UserBean. The requirement is that the user can login any no. of times he wants. But he should have only one valid session and that should be the session from the last successful login attempt as mentioned above. Can you please tell me if this is possible using 2.2 specs and tomcat 3.2.1 Regds, Gokul PS: I have joined this list today only. I am not sure if this posting is appropriate for this list or not. If it is inappropriate here, then please mail to me privately. Hans -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
on 1/15/01 12:02 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Well, I think I have to clear few things up. I already announced ( probably not clearly enough ) my intention to give up and spend my free time in better ways. This is a form of vote, BTW. The only thing that keeps me subscribed to this list is the fact that I wanted to finish my work on tomcat3 - quite a few people put a lot of their time and effort into it, and I'll do whatever I can to make sure their work is not lost. How would it be lost? It is in CVS and archived on literally hundreds of people's desktops. I also heard you say previously that you were going to continue things elsewhere. Therefore, what exactly would be lost? I don't think my presence to the PMC meeting can bring anything good - I think most of the decisions have already been taken, and most of the games done. It seems things have already been debated in productive closed-lists, and 1/2 of the judges are representing one side. I have a lot of respect for the other 1/2, but their (lack of ) open attitude during recent months is one of the main reasons for me wanting to get out of this project as soon as possible. Actually NOTHING has been debated OR decided on any of the closed lists. I wonder how many times I (and others) need to repeat that to you before you actually hear and acknowledge it. In any case, the only thing I can do is to make clear that I ( as still a commiter on this project ) believe that tomcat 3.3 is to tomcat 3.2 what 3.2 is to 3.1 - a step forward and an evolution in the right direction. Uh. That point was never in contention. If you want to help - do the same, write to the list stating your opinion ( and don't answer to any flame ). Or write to any PMC member you like, and please mention the reasons for not writing to the list. A +1 is enough if you don't want to add more. Yes, I agree! I also encourage all of you to start expressing your opinions. If more people would step up and contribute here in one way or another this would be a much better place. I'm very happy with the way our evolution worked. The fact that so many people contributed so much ( Gal, Sam, Larry, Nacho, Alex, Glen, Henri, Dan - and everyone else ) is what makes tomcat 3.x a great success. And again, tomcat 3.3 is not my baby - all I did was to clean up and move code around trying to learn from Apache2.0 and others. The original design is the main value, and almost all features have been implemented by other people. As the person who probably did the most number of commits and co-restructuring, I would consider you the lead developer on Tomcat 3.x. Please stop trying to downplay your importance. Yes, others were very important, but I think it was you who really stepped up and did the core work that needed to be done to bring Tomcat 3.x up to par with what you consider as being needed done. I'm waiting for the moment they feel Catalina is completed and has all the promised features and it's ready to be compared with Tomcat 3. So am I! I personally think that Tomcat 4.0b1 is very close with regards to being a usable Servlet Container. I'm certainly much happier using it than I was with Tomcat 3.x. thanks, -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
