cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
costin 01/04/06 23:50:55
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Errors in shutdown will not stop the process, the rest of contexts
and interceptors will be shut down.
Revision ChangesPath
1.176 +10 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.175
retrieving revision 1.176
diff -u -r1.175 -r1.176
--- ContextManager.java 2001/03/25 21:53:13 1.175
+++ ContextManager.java 2001/04/07 06:50:55 1.176
@@ -578,12 +578,20 @@
public final void shutdown() throws TomcatException {
if( state==STATE_START ) stop();
while (!contextsV.isEmpty()) {
- removeContext((Context)contextsV.firstElement());
+ try {
+ removeContext((Context)contextsV.firstElement());
+ } catch(Exception ex ) {
+ log( "shutdown.removeContext" , ex );
+ }
}
BaseInterceptor cI[]=defaultContainer.getInterceptors();
for( int i=0; i< cI.length; i++ ) {
- removeInterceptor( cI[i] );
+ try {
+ removeInterceptor( cI[i] );
+ } catch( Exception ex ) {
+ log( "shutdown.removeInterceptor" , ex );
+ }
}
}
RE: [STATUS] Tomcat 3.2.2
Marc, What about removing the use of URL ? We can create a local URL object that works in a deterministic way - that would be much cleaner than guessing the OS and doing workarounds. Costin On Fri, 6 Apr 2001, Marc Saegesser wrote: > As usual, the problem turned out to be deeper then I first expected. > > Here's what happened. There was a bug in 3.2.1 that servlet paths and path > info weren't being decoded as required by the spec. This was fixed in > 3.2.2. > > It also turns out that there was bug in JDK1.2.2 that caused %HH escape > characters in file: URLs to not be decoded. I originally thought the bug > was in 1.3.0, but after re-reading the URL spec I accept that the bug was > really in 1.2.2. The bottom line is that the behavior of file URLs is > different on different versions of Java. > > Context.getResource() constructs a file: URL by concatenating the context > root with the servlet path. On JDK1.3.0 systems, this now results in the > servlet path getting decoded twice: once in RequestUtil and once by URL. > Decoding URLs more than once causes all kinds of security problems. > > So, given that file: URLs behave differently on different system, we have to > adjust the input to the URL constructor in Context.getResource() so that the > file names passed in on systems without the bug have been URL encoded so > that the URL can then decode them and get the correct file name. > > So now the question becomes determining if the system has the file: URL bug. > I don't think you can just look at the version number because not every > vendor's 1.2.2 implementation may be broken and every vendor's 1.3.x > implementation may not be fixed. So it comes down to checking the behavior > of URL to see what flavor you have. I've tried all kinds of combinations of > toString(), toExternalForm(), sameFile(), etc. and so far the only reliable > method I have for determining which version of URL you have is to actually > use it to open an InputStream and see if it works. For example a simple > routine could try to open file:%2e (i.e. the current directory). If it gets > a FileNotFoundException then it assumes that it has a broken URL > implementation, if it doesn't get an exception then it assumes that the URL > implementation is correct. Context.getResource() can now check if the URL > implementation is broken or not and do the right thing. > > This fixes the security hole, but opens up a new kind of attack. A > malicious user on a JDK1.2.2 server could create a file called %2e in > Tomcat's working directory. This would cause Tomcat to not find resources > that it legitimately should find. This better than exposing the entire > server to prying eyes, but it still doesn't feel right. > > I'm going to commit the fix as I have it now so that others can review it > and maybe come up with a better approach. I'm now planning to release beta > 3 Saturday morning (central US time). > > > > > -Original Message- > > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 06, 2001 11:29 AM > > To: [EMAIL PROTECTED] > > Subject: [STATUS] Tomcat 3.2.2 > > > > > > I've got a fix for the URL double decode security problem in Tomcat 3.2.2. > > I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly > > available. Because the only change in Beta 3 is the security > > fix, this beta > > cycle will only be one week long. If no other security issues are found, > > I'll call a vote for 3.2.2 final late next week. > > > > > > >
RE: [STATUS] Tomcat 3.2.2
As usual, the problem turned out to be deeper then I first expected. Here's what happened. There was a bug in 3.2.1 that servlet paths and path info weren't being decoded as required by the spec. This was fixed in 3.2.2. It also turns out that there was bug in JDK1.2.2 that caused %HH escape characters in file: URLs to not be decoded. I originally thought the bug was in 1.3.0, but after re-reading the URL spec I accept that the bug was really in 1.2.2. The bottom line is that the behavior of file URLs is different on different versions of Java. Context.getResource() constructs a file: URL by concatenating the context root with the servlet path. On JDK1.3.0 systems, this now results in the servlet path getting decoded twice: once in RequestUtil and once by URL. Decoding URLs more than once causes all kinds of security problems. So, given that file: URLs behave differently on different system, we have to adjust the input to the URL constructor in Context.getResource() so that the file names passed in on systems without the bug have been URL encoded so that the URL can then decode them and get the correct file name. So now the question becomes determining if the system has the file: URL bug. I don't think you can just look at the version number because not every vendor's 1.2.2 implementation may be broken and every vendor's 1.3.x implementation may not be fixed. So it comes down to checking the behavior of URL to see what flavor you have. I've tried all kinds of combinations of toString(), toExternalForm(), sameFile(), etc. and so far the only reliable method I have for determining which version of URL you have is to actually use it to open an InputStream and see if it works. For example a simple routine could try to open file:%2e (i.e. the current directory). If it gets a FileNotFoundException then it assumes that it has a broken URL implementation, if it doesn't get an exception then it assumes that the URL implementation is correct. Context.getResource() can now check if the URL implementation is broken or not and do the right thing. This fixes the security hole, but opens up a new kind of attack. A malicious user on a JDK1.2.2 server could create a file called %2e in Tomcat's working directory. This would cause Tomcat to not find resources that it legitimately should find. This better than exposing the entire server to prying eyes, but it still doesn't feel right. I'm going to commit the fix as I have it now so that others can review it and maybe come up with a better approach. I'm now planning to release beta 3 Saturday morning (central US time). > -Original Message- > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 06, 2001 11:29 AM > To: [EMAIL PROTECTED] > Subject: [STATUS] Tomcat 3.2.2 > > > I've got a fix for the URL double decode security problem in Tomcat 3.2.2. > I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly > available. Because the only change in Beta 3 is the security > fix, this beta > cycle will only be one week long. If no other security issues are found, > I'll call a vote for 3.2.2 final late next week. > > >
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util URLUtil.java
marcsaeg01/04/06 18:07:19
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32 Context.java
src/share/org/apache/tomcat/util Tag: tomcat_32 URLUtil.java
Log:
Fixes a security hole caused by URLs being decoded twice. The second
decoding is happening when an InputStream is opened on a file: URL. The
security problem does not appear when using JDK1.2.2.
Revision ChangesPath
No revision
No revision
1.100.2.6 +8 -2 jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
Index: Context.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
retrieving revision 1.100.2.5
retrieving revision 1.100.2.6
diff -u -r1.100.2.5 -r1.100.2.6
--- Context.java 2001/03/16 23:43:53 1.100.2.5
+++ Context.java 2001/04/07 01:07:18 1.100.2.6
@@ -168,6 +168,8 @@
String vhost=null;
Vector vhostAliases=new Vector();
FacadeManager facadeM;
+
+private boolean fileURLBug = URLUtil.hasFileURLBug();// Saves a
synchronized method call for each request
public Context() {
defaultContainer=new Container();
@@ -767,9 +769,13 @@
}
try {
-url=new URL("file", null, 0,realPath );
+if(!fileURLBug){
+realPath = URLEncoder.encode(realPath);
+}
+System.out.println("Context.getResource: realPath = " + realPath);
+url=new URL("file", null, 0,realPath );
if( debug>9) log( "getResourceURL=" + url + " request=" + rpath );
- return url;
+return url;
} catch( IOException ex ) {
ex.printStackTrace();
return null;
No revision
No revision
1.7.2.1 +47 -3
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/URLUtil.java
Index: URLUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/URLUtil.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- URLUtil.java 2000/05/01 23:07:48 1.7
+++ URLUtil.java 2001/04/07 01:07:19 1.7.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/URLUtil.java,v 1.7
2000/05/01 23:07:48 costin Exp $
- * $Revision: 1.7 $
- * $Date: 2000/05/01 23:07:48 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/URLUtil.java,v 1.7.2.1
2001/04/07 01:07:19 marcsaeg Exp $
+ * $Revision: 1.7.2.1 $
+ * $Date: 2001/04/07 01:07:19 $
*
*
*
@@ -65,7 +65,10 @@
package org.apache.tomcat.util;
import java.net.URL;
+import java.net.URLConnection;
import java.io.File;
+import java.io.FileNotFoundException;
+import java.io.InputStream;
import java.net.MalformedURLException;
import java.io.IOException;
@@ -76,6 +79,9 @@
public class URLUtil {
+private static boolean fileURLBug = false;
+private static boolean fileURLBugChecked = false;
+
public static URL resolve(String s)
throws MalformedURLException
{
@@ -183,4 +189,42 @@
return null;
}
+/*
+ * There was a bug in versions of Suns Java runtime
+ * in versions prior to 1.3.0 for file: URLs. In those version
+ * URL encodings (%HH) were not decoded, in 1.3.0 and later
+ * they are. For example, in 1.2.2, the URL file:%2e would try
+ * try to open a file called %2e. In 1.3.0 and later it would
+ * try to open the current directory (i.e. .).
+ *
+ * This extra URL decoding for file: URLs can open severe security
+ * holes because it causes URLs to be decoded twice. For example,
+ * a request URI containing sequences of /%252e%252e would get
+ * interpreted as sequences of /.. and could escape the web application.
+ *
+ * The only way to determine if the current VM suffers from this bug
+ * of not is to execute a URLConnection.getInputStream() on a file
+ * URL
+ *
+ */
+public static synchronized boolean hasFileURLBug()
+{
+if(!fileURLBugChecked){
+fileURLBugChecked = true;
+fileURLBug = false;
+try{
+System.out.println("URLUtil.hasFileURLBug: user.dir = " +
System.getProperty("user.dir"));
+URL url = new URL("file:%2e");
+URLConnection con = url.openConnection();
+InputStream is = con.getInputStream();
+}catch(MalformedURLException e){
+}catch(FileNotFoundException e){
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
remm01/04/06 16:42:04
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Should fix bug 1202, at least when a naming operation involving the ENC
is attempted during the init() call of a servlet which is loaded on startup.
Revision ChangesPath
1.50 +43 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- StandardContext.java 2001/04/05 19:30:39 1.49
+++ StandardContext.java 2001/04/06 23:42:04 1.50
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.49 2001/04/05 19:30:39 craigmcc Exp $
- * $Revision: 1.49 $
- * $Date: 2001/04/05 19:30:39 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.50 2001/04/06 23:42:04 remm Exp $
+ * $Revision: 1.50 $
+ * $Date: 2001/04/06 23:42:04 $
*
*
*
@@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.49 $ $Date: 2001/04/05 19:30:39 $
+ * @version $Revision: 1.50 $ $Date: 2001/04/06 23:42:04 $
*/
public class StandardContext
@@ -2255,6 +2255,13 @@
// Stop accepting requests temporarily
setPaused(true);
+if (isUseNaming()) {
+try {
+ContextBindings.bindThread(this, this);
+} catch (NamingException e) {
+}
+}
+
// Shut down the current version of all active servlets
Container children[] = findChildren();
for (int i = 0; i < children.length; i++) {
@@ -2270,6 +2277,10 @@
}
}
+if (isUseNaming()) {
+ContextBindings.unbindThread(this, this);
+}
+
// Unload sessions to persistent storage, if supported
try {
getManager().unload();
@@ -2355,6 +2366,16 @@
ok = false;
}
+if (isUseNaming()) {
+try {
+ContextBindings.bindThread(this, this);
+} catch (NamingException e) {
+log(sm.getString("standardContext.namingInitFailed",
+ getName()));
+ok = false;
+}
+}
+
// Restart our currently defined servlets
for (int i = 0; i < children.length; i++) {
if (!ok)
@@ -2372,6 +2393,10 @@
}
}
+if (isUseNaming()) {
+ContextBindings.unbindThread(this, this);
+}
+
DirContextURLStreamHandler.unbind();
// Start accepting requests again
@@ -3226,6 +3251,16 @@
list.add(wrapper);
}
+if (isUseNaming()) {
+try {
+ContextBindings.bindThread(this, this);
+} catch (NamingException e) {
+log(sm.getString("standardContext.namingInitFailed",
+ getName()));
+ok = false;
+}
+}
+
// Load the collected "load on startup" servlets
if (debug >= 1)
log("Loading " + map.size() + " load-on-startup servlets");
@@ -3246,6 +3281,10 @@
ok = false;
}
}
+}
+
+if (isUseNaming()) {
+ContextBindings.unbindThread(this, this);
}
DirContextURLStreamHandler.unbind();
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester Jndi01.java
remm01/04/06 16:40:36
Modified:tester/src/tester/org/apache/tester Jndi01.java
Log:
- Add additional operations during init and destroy to test bug #1202.
Revision ChangesPath
1.3 +15 -1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Jndi01.java
Index: Jndi01.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Jndi01.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Jndi01.java 2001/04/05 00:06:31 1.2
+++ Jndi01.java 2001/04/06 23:40:35 1.3
@@ -74,7 +74,7 @@
* should succeed.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2001/04/05 00:06:31 $
+ * @version $Revision: 1.3 $ $Date: 2001/04/06 23:40:35 $
*/
public class Jndi01 extends HttpServlet {
@@ -83,10 +83,24 @@
Context ctx = null;
try {
ctx = new InitialContext();
+ctx.lookup("java:/comp");
log("initialized successfully");
} catch (NamingException e) {
+e.printStackTrace();
log("Cannot create context", e);
throw new ServletException(e);
+}
+}
+
+public void destroy() {
+Context ctx = null;
+try {
+ctx = new InitialContext();
+ctx.lookup("java:/comp");
+log("initialized successfully");
+} catch (NamingException e) {
+e.printStackTrace();
+log("Cannot create context", e);
}
}
Re: multiple usage of same classes in different jars
"Craig R. McClanahan" wrote: > > On Fri, 6 Apr 2001, Craig R. McClanahan wrote: > > > > > > > On Fri, 6 Apr 2001, Remy Maucherat wrote: > > > > > > On Fri, 6 Apr 2001, Szymon Stasik wrote: > > > > > > > > > [...] > > > > > > > > > > Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat > > > > > or Cocoon? > > > > > > > > > > > > > It's (c) wrong behavior of Tomcat. Remy is currently investigating a fix > > > > for this. > > > > > > As I said privately, I have a fix. Should I commit it now ? > > > > > > > Yes ... I can back it out if needed. One thing I need to double check is > > what this does when you run with a security manager -- we might need to > > tweak how the default policy file works too. > > > > Yep ... it definitely messes up when you use the "-security" switch at > startup. I'm looking into it. So - I would be happy to try this path :) regards, Szymon
Tomcat processes.
When I start Tomcat I see the following- = [vikas@wow bin]$ ps -aefl --cols=300 | grep java 000 S vikas 858 1 4 60 0- 35712 rt_sig 13:47 pts/0 00:00:01 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat 040 S vikas 903 858 0 60 0- 35712 do_pol 13:47 pts/0 00:00:00 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat 040 S vikas 904 903 0 60 0- 35712 nanosl 13:47 pts/0 00:00:00 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat 040 S vikas 905 903 0 60 0- 35712 nanosl 13:47 pts/0 00:00:00 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat ... ... ... 040 S vikas 948 903 0 60 0- 35712 nanosl 13:47 pts/0 00:00:00 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat 040 S vikas 949 903 0 60 0- 35712 nanosl 13:47 pts/0 00:00:00 /net/java/jdk1.3/bin/i386/native_threads/java -Dtomcat.home=./.. org.apache.tomcat.startup.Tomcat == It looks like that PID 858 creates a process (PID-903) which in turn creates 46 Tomcat processes (PIDS: 904-949). Where is it configured? Is there any way I can change this? So that I can start Tomcat with the no. of processes I want, say 25, 100.. whatever.. Any help in this regard is appreciated. Thanks, Vikas.
Re: multiple usage of same classes in different jars
On Fri, 6 Apr 2001, Craig R. McClanahan wrote: > > > On Fri, 6 Apr 2001, Remy Maucherat wrote: > > > > On Fri, 6 Apr 2001, Szymon Stasik wrote: > > > > > > > > > > > Hi > > > > > > > > I'm running Tomcat 4.0-b3 (standalone) and have some bit weired problem. > > > > I know that it is possible to have eg.: > > > > > > > > user1/WEB-INF > > > > user2/WEB-INF > > > > > > > > with apriopriate contexts: > > > > > > > > > > > docBase="/home/userX/tomcat" > > > > debug="0" > > > > reloadable="false"> > > > >> > > prefix="framework_userX_log." suffix=".txt" > > > > timestamp="true"/> > > > > > > > > > > > > so both users can run/develop their application with no conflicts with > > > > other. My idea is to run cocoon (1.8) with this environment. I have > > > > (hopefully) solved classloader problem in cocoon, so even XSP is working > > > > good for me while having all jars in user1/WEB-INF/lib. Now I'd like > > > > user2 to have his own copy of all the jars in user2/WEB-INF/lib so he > > > > can use modified wersion of his own jars or cocoon or any other classes. > > > > AFAIK in Tomcat 4 it should be possible to allow simultanous work of > > > > both users with their own versions of same classes. > > > > > > > > However the results are that both users receive instances of classes > > > > from one of them. Strange thing - I was testing Class objects - all > > > > classes from my jars seems to be different for both users (eg testing > > > > org.apache.cocoon.Cocoon.hashCode() or any other class from WEB-INF/lib) > > > > but the code executed is the same for both users and for both staticaly > > > > (servlet) and dynamicaly (xsp) loaded code. > > > > > > > > Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat > > > > or Cocoon? > > > > > > > > > > It's (c) wrong behavior of Tomcat. Remy is currently investigating a fix > > > for this. > > > > As I said privately, I have a fix. Should I commit it now ? > > > > Yes ... I can back it out if needed. One thing I need to double check is > what this does when you run with a security manager -- we might need to > tweak how the default policy file works too. > Yep ... it definitely messes up when you use the "-security" switch at startup. I'm looking into it. But the good news is that it seems to work quite nicely without a security manager. > > Remy > > > > > > Craig > > > Craig
[PATCH] patch to make PersistentManager work with different Storeimplementations.
If you get this email twice please ignore. Our emailserver experienced problems
yesterday
so I never think my email was delivered.
..bip
-
This is a minor change so you can specify the store to use within server.xml.
Here's how you can change the Store use from server.xml:
I'll hope to have a first cut of the JDBCStore soon.
..bip
[ PersistentManager.java ]
diff -r1.2 PersistentManager.java
267c266
<
---
> store.setManager(this);
598,601d596
< // Create the FileStore object.
< // FIXME: Do this properly (configurable)
< store = new FileStore();
< store.setManager (this);
[ Catalina.java ]
diff -r1.17 Catalina.java
351a352,358
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
> mapper.objectCreate(null, "className"));
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
>mapper.setProperties());
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
> mapper.addChild("setStore", "org.apache.catalina.Store"));
>
RE: 5 Patches ...
Title: RE: 5 Patches ...
Resending with file.
Apologize for the err.
-Victor
-Original Message-
From: Vitayaudom, Victor
To: '[EMAIL PROTECTED]'
Sent: 4/2/01 6:52 PM
Subject: 5 Patches ...
Please note patch 1 and especially 4.
Just helping out.
-Victor
patchfile1.txt
--
I'm interested in sending a patches to fix a problem I'm
encountering. I'm using jasper save myself deployment time by
testing the integrity of the webapp.
The simple fix is to replace '-' with '_' with jasper's
org.apache.jasper.compiler.TagBeginGenerator
I currently have a project where a taglib contains a dash for one of
its tag elements. e.g.
The author of the taglib justly refuses to change the name of the
tag element since it is within or not out bounds with the taglib
specification.
However, jasper creates corresponding java files for these tag
elements
by
appending _jspx_th or _jspx_eval to the name.
The dash are not allowed in variable assignment and the compiler
complains.
patchfile2.txt
--
For org.apache.jasper.runtime.JspWriterImpl
my jikes compiler complains of a catch Exception that is never thrown.
I agree with it and confused by what is to be gained from
a try catch around System.getProperty("line.separator") since
the value would be null if the value was never assigned.
I think the author wanted
if (lineSeparator == null) lineSeparator = "\r\n";
However, I fail to see when this situation would occur since
each operating system environment would had a VM that would
have this value defined.
patchfile3.txt for org.apache.jasper.runtime.JspFactoryImpl
same as JspWriterImpl
patchfile4.txt
a. to reduce javadoc warning by including classpath
b. also the introduction of build.properties for centralization of
customization by using
c. Please also note the introduction of sax2.jar and w3cdom2.jar to
reduce dependency on parser.jar and focus on jaxp.jar
Analogy. avoid import java.util.*;
versus
import java.util.Vector; ... etc. to what is required.
So while jaxp-1.1 utilize crimson.jar versus
jaxp-1.0.2 utilizing parser.jar
we don't care because the only important jar files
for compiling are sax2.jar, w3cdom2.jar, and jaxp.jar.
The same does not hold true when utilizing jasper to
convert a jsp into a java file. But that is not the role
of the cvs rather than the user of the jakarta-tomcat jasper
functionality to determine which
javax.xml.parser.DocumentBuilderFactory
he/she wants to use.
p.s. Currently their is a bug in crimson.jar since it does
specifcy a necessary DTD method that jasper requires.
patchfile5.txt
update to src/test/build.xml to also change ${servlet22.jar} to
${servlet.jar}
patchfile1.txt
patchfile2.txt
patchfile3.txt
patchfile4.txt
patchfile5.txt
RE: Does soap need jdk 1.1.x? (No! It's a problem with xerces in classpath)
The simplest solution to this problem is to remove all xml related jars in your Jre\lib\ext directory and from the Jdk1.2.2\lib\ext directory . These jars are automatically loaded I guess and are the cause of the problem. In my case the cause of the problem was the parser.jar in c:jdk1.2.2\lib\ext Hope this helps! Regards Carlton
jni_connect.dll won't load
Title: jni_connect.dll won't load I am try to load the JVM inside an IIS Web Server version 5.0 on a windows 2000 Professional machine and I am getting the following in the isapi_redirect.log. I have successfully been able to run TOMCAT with this IIS by following the 'Tomcat IIS HowTo' documentation, but can't get the 'In-Process HowTo' documentation to work. [jk_jni_worker.c (921)]: In open_jvm2, setting classpath to f:\jakarta-tomcat-3.2.1\tomcat\classes;f:\jakarta-tomcat-3.2.1\tomcat\lib\jaxp.jar;f:\jakarta-tomcat-3.2.1\tomcat\lib\parser.jar;f:\jakarta-tomcat-3.2.1\tomcat\lib\jasper.jar;f:\jakarta-tomcat-3.2.1\tomcat\lib\servlet.jar;f:\jakarta-tomcat-3.2.1\tomcat\lib\webserver.jar;f:\jdk1.3.0\lib\tools.jar [jk_jni_worker.c (944)]: In open_jvm2, setting tomcat.home=f:\jakarta-tomcat-3.2.1\tomcat [jk_jni_worker.c (965)]: In open_jvm2, the JVM will ignore unknown options [jk_jni_worker.c (972)]: In open_jvm2, about to create JVM... [jk_jni_worker.c (975)]: Fail-> could not create JVM, code: -5 [jk_jni_worker.c (424)]: Fail-> can't open jvm [jk_jni_worker.c (567)]: Into destroy [jk_jni_worker.c (578)]: In destroy, JVM not intantiated [jk_worker.c (164)]: wc_create_worker validate failed for jni [jk_worker.c (229)]: build_worker_map failed to create workerjni If you can't point me in the right direction, it will be appreciated. Stephen Mills
Using JSP extension of "html" not working....
Using apache 1.3.12 and tomcat 3.2.1, we have confirmed that with using mod_jk.so we have the two communicating. However, our "jsp" files are not being processed. We have all our "jsp" files have an extension of "html" for various reasons. If we invoke the "index.html" page it is not treated as a "jsp". If we rename the *same* page to "index.jsp" it works fine. We have added a "web.xml" in the webapp/WEB-INF dir which is as follows. We added the "JkMount /*.html ajp13" to the httpd.conf and we see in the mod_jk.log that a rule is defined for the "/.html" extension but then later it is not matched (see below) What do we have to do to get a "html" extension of a "jsp" to be served as if it is a "jsp"? Many thanks... Barton ===web.xml PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> servletToJsp org.apache.jasper.runtime.JSPServlet keepgenerated true sendErrToClient true servletToJsp *.html mod_tk.log [jk_uri_worker_map.c (195)]: Into jk_uri_worker_map_t::uri_worker_map_open [jk_uri_worker_map.c (210)]: jk_uri_worker_map_t::uri_worker_map_open, rule map size is 1 [jk_uri_worker_map.c (255)]: Into jk_uri_worker_map_t::uri_worker_map_open, suffix rule /.html=ajp13 wa\ s added [jk_uri_worker_map.c (295)]: Into jk_uri_worker_map_t::uri_worker_map_open, there are 1 rules [jk_uri_worker_map.c (316)]: jk_uri_worker_map_t::uri_worker_map_open, done [jk_worker.c (82)]: Into wc_open [jk_worker.c (207)]: Into build_worker_map, creating 1 workers [jk_worker.c (213)]: build_worker_map, creating worker ajp13 [jk_worker.c (138)]: Into wc_create_worker [jk_worker.c (152)]: wc_create_worker, about to create instance ajp13 of ajp13 [jk_ajp13_worker.c (708)]: Into ajp23_worker_factory [jk_worker.c (161)]: wc_create_worker, about to validate and init ajp13 [jk_ajp13_worker.c (383)]: Into jk_worker_t::validate [jk_ajp13_worker.c (396)]: In jk_worker_t::validate for worker ajp13 contact is localhost:8009 [jk_ajp13_worker.c (422)]: Into jk_worker_t::init [jk_worker.c (177)]: wc_create_worker, done [jk_worker.c (223)]: build_worker_map, removing old ajp13 worker [jk_worker.c (235)]: build_worker_map, done [jk_worker.c (102)]: wc_open, done [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (434)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (434)]: jk_uri_worker_map_t::map_uri_to_worker, done without
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources DirContextURLConnection.java ProxyDirContext.java
remm01/04/06 12:32:03
Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java ProxyDirContext.java
Log:
- Fix for bug 1219. It makes the URLs generated more unique, to avoid confusing
the JDK's JAR URL cache.
Revision ChangesPath
1.6 +25 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
Index: DirContextURLConnection.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DirContextURLConnection.java 2001/03/31 14:06:31 1.5
+++ DirContextURLConnection.java 2001/04/06 19:31:59 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.5 2001/03/31 14:06:31 glenn Exp $
- * $Revision: 1.5 $
- * $Date: 2001/03/31 14:06:31 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.6 2001/04/06 19:31:59 remm Exp $
+ * $Revision: 1.6 $
+ * $Date: 2001/04/06 19:31:59 $
*
*
*
@@ -91,7 +91,7 @@
* content is directly returned.
*
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class DirContextURLConnection
extends URLConnection {
@@ -105,7 +105,7 @@
if (context == null)
throw new IllegalArgumentException
("Directory context can't be null");
-this.permission = new FilePermission(url.toString(),"read");
+this.permission = new FilePermission(url.toString(), "read");
this.context = context;
}
@@ -172,8 +172,26 @@
try {
date = System.currentTimeMillis();
-object = context.lookup(getURL().getFile());
-attributes = context.getAttributes(getURL().getFile());
+String path = getURL().getFile();
+if (context instanceof ProxyDirContext) {
+ProxyDirContext proxyDirContext =
+(ProxyDirContext) context;
+String hostName = proxyDirContext.getHostName();
+String contextName = proxyDirContext.getContextName();
+if (hostName != null) {
+if (!url.getHost().equalsIgnoreCase(hostName))
+return;
+}
+if (contextName != null) {
+if (!path.startsWith(contextName)) {
+return;
+} else {
+path = path.substring(contextName.length());
+}
+}
+}
+object = context.lookup(path);
+attributes = context.getAttributes(path);
if (object instanceof Resource)
resource = (Resource) object;
if (object instanceof DirContext)
1.3 +49 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java
Index: ProxyDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/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/02/05 05:10:00 1.2
+++ ProxyDirContext.java 2001/04/06 19:32:00 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
1.2 2001/02/05 05:10:00 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/02/05 05:10:00 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
1.3 2001/04/06 19:32:00 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/04/06 19:32:00 $
*
*
*
@@ -84,7 +84,7 @@
* Proxy Directory Context implementation.
*
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2001/02/05 05:10:00 $
+ * @version $Revision: 1.3 $ $Date: 2001/04/06 19:32:00 $
*/
public class ProxyDirContext implements DirContext {
@@ -93,6 +93,10 @@
// -- Constants
+public static final String CONTEXT = "context";
+public static
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationContext.java ContainerBase.java
remm01/04/06 12:31:20
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java ContainerBase.java
Log:
- Fix for bug 1219. It makes the URLs generated more unique, to avoid confusing
the JDK's JAR URL cache.
Revision ChangesPath
1.19 +20 -14
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ApplicationContext.java 2001/03/22 00:51:17 1.18
+++ ApplicationContext.java 2001/04/06 19:31:17 1.19
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.18 2001/03/22 00:51:17 remm Exp $
- * $Revision: 1.18 $
- * $Date: 2001/03/22 00:51:17 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.19 2001/04/06 19:31:17 remm Exp $
+ * $Revision: 1.19 $
+ * $Date: 2001/04/06 19:31:17 $
*
*
*
@@ -111,7 +111,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.18 $ $Date: 2001/03/22 00:51:17 $
+ * @version $Revision: 1.19 $ $Date: 2001/04/06 19:31:17 $
*/
public final class ApplicationContext
@@ -160,15 +160,17 @@
implements PrivilegedExceptionAction {
private String path;
+private String host;
private DirContext resources;
-PrivilegedGetResource(String path, DirContext resources) {
+PrivilegedGetResource(String host, String path, DirContext resources) {
+this.host = host;
this.path = path;
this.resources = resources;
}
public Object run() throws Exception {
-return new URL("jndi", null, 0, path,
+return new URL("jndi", host, 0, path,
new DirContextURLStreamHandler(resources));
}
@@ -185,7 +187,6 @@
* @param context The associated Context instance
*/
public ApplicationContext(String basePath, StandardContext context) {
-
super();
this.context = context;
this.basePath = basePath;
@@ -495,7 +496,8 @@
return (null);
// Construct a RequestDispatcher to process this request
- HttpServletRequest hrequest = (HttpServletRequest) request.getRequest();
+ HttpServletRequest hrequest =
+(HttpServletRequest) request.getRequest();
return (RequestDispatcher) new ApplicationDispatcher(wrapper,
hrequest.getServletPath(),
hrequest.getPathInfo(),
@@ -516,22 +518,26 @@
* @exception MalformedURLException if the path is not given
* in the correct form
*/
-public URL getResource(String path) throws MalformedURLException {
+public URL getResource(String path)
+throws MalformedURLException {
DirContext resources = context.getResources();
if (resources != null) {
+String fullPath = context.getName() + path;
+String hostName = context.getParent().getName();
try {
resources.lookup(path);
if( System.getSecurityManager() != null ) {
try {
PrivilegedGetResource dp =
- new PrivilegedGetResource(path,resources);
+ new PrivilegedGetResource
+(hostName, fullPath, resources);
return (URL)AccessController.doPrivileged(dp);
} catch( PrivilegedActionException pe) {
throw pe.getException();
}
} else {
-return new URL("jndi", null, 0, path,
- new DirContextURLStreamHandler(resources));
+return new URL("jndi", hostName, 0, fullPath,
+ new DirContextURLStreamHandler(resources));
}
} catch (Exception e) {
//e.printStackTrace();
@@ -805,8 +811,8 @@
(ServletContextAttributeListener) listeners[i];
try {
if (replaced) {
-context.fireContainerEvent("beforeContextAttributeReplaced",
- listener);
+context.fireContainerEvent
+("beforeContextAttributeRe
Re: multiple usage of same classes in different jars
On Fri, 6 Apr 2001, Remy Maucherat wrote: > > On Fri, 6 Apr 2001, Szymon Stasik wrote: > > > > > > > > Hi > > > > > > I'm running Tomcat 4.0-b3 (standalone) and have some bit weired problem. > > > I know that it is possible to have eg.: > > > > > > user1/WEB-INF > > > user2/WEB-INF > > > > > > with apriopriate contexts: > > > > > > > > docBase="/home/userX/tomcat" > > > debug="0" > > > reloadable="false"> > > >> > prefix="framework_userX_log." suffix=".txt" > > > timestamp="true"/> > > > > > > > > > so both users can run/develop their application with no conflicts with > > > other. My idea is to run cocoon (1.8) with this environment. I have > > > (hopefully) solved classloader problem in cocoon, so even XSP is working > > > good for me while having all jars in user1/WEB-INF/lib. Now I'd like > > > user2 to have his own copy of all the jars in user2/WEB-INF/lib so he > > > can use modified wersion of his own jars or cocoon or any other classes. > > > AFAIK in Tomcat 4 it should be possible to allow simultanous work of > > > both users with their own versions of same classes. > > > > > > However the results are that both users receive instances of classes > > > from one of them. Strange thing - I was testing Class objects - all > > > classes from my jars seems to be different for both users (eg testing > > > org.apache.cocoon.Cocoon.hashCode() or any other class from WEB-INF/lib) > > > but the code executed is the same for both users and for both staticaly > > > (servlet) and dynamicaly (xsp) loaded code. > > > > > > Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat > > > or Cocoon? > > > > > > > It's (c) wrong behavior of Tomcat. Remy is currently investigating a fix > > for this. > > As I said privately, I have a fix. Should I commit it now ? > Yes ... I can back it out if needed. One thing I need to double check is what this does when you run with a security manager -- we might need to tweak how the default policy file works too. > Remy > > Craig
missing files from web-inf?
Hello all, I have installed Tomcat & followed the instructions to start Tomcat but while doing this Tomcat throws multiple FileNotFoundExceptions regarding the files that are contained in the *.war files. Should I uncompress these files or should Tomcat be able to read these files? I have set up my environment variables also. Many thanks, Julie Mc Cabe _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
[PATCH] patch to make PersistentManager work with different Storeimplementations.
This is a minor change so you can specify the store to use within server.xml.
Here's how you can change the Store use from server.xml:
I'll hope to have a first cut of the JDBCStore soon.
..bip
[ PersistentManager.java ]
diff -r1.2 PersistentManager.java
267c266
<
---
> store.setManager(this);
598,601d596
< // Create the FileStore object.
< // FIXME: Do this properly (configurable)
< store = new FileStore();
< store.setManager (this);
[ Catalina.java ]
diff -r1.17 Catalina.java
351a352,358
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
> mapper.objectCreate(null, "className"));
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
>mapper.setProperties());
> mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
> mapper.addChild("setStore", "org.apache.catalina.Store"));
>
Re: multiple usage of same classes in different jars
> On Fri, 6 Apr 2001, Szymon Stasik wrote: > > > > > Hi > > > > I'm running Tomcat 4.0-b3 (standalone) and have some bit weired problem. > > I know that it is possible to have eg.: > > > > user1/WEB-INF > > user2/WEB-INF > > > > with apriopriate contexts: > > > > > docBase="/home/userX/tomcat" > > debug="0" > > reloadable="false"> > >> prefix="framework_userX_log." suffix=".txt" > > timestamp="true"/> > > > > > > so both users can run/develop their application with no conflicts with > > other. My idea is to run cocoon (1.8) with this environment. I have > > (hopefully) solved classloader problem in cocoon, so even XSP is working > > good for me while having all jars in user1/WEB-INF/lib. Now I'd like > > user2 to have his own copy of all the jars in user2/WEB-INF/lib so he > > can use modified wersion of his own jars or cocoon or any other classes. > > AFAIK in Tomcat 4 it should be possible to allow simultanous work of > > both users with their own versions of same classes. > > > > However the results are that both users receive instances of classes > > from one of them. Strange thing - I was testing Class objects - all > > classes from my jars seems to be different for both users (eg testing > > org.apache.cocoon.Cocoon.hashCode() or any other class from WEB-INF/lib) > > but the code executed is the same for both users and for both staticaly > > (servlet) and dynamicaly (xsp) loaded code. > > > > Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat > > or Cocoon? > > > > It's (c) wrong behavior of Tomcat. Remy is currently investigating a fix > for this. As I said privately, I have a fix. Should I commit it now ? Remy
Re: 'Just say no to JSP'
Paulo Gaspar wrote: > > Earl, > > If you think one should not discuss the merits of JSP here, you should > not take part on it even if to defend JSP. > > If you agree we should talk about the pros and cons of JSPs, it is hard > to talk about the cons of JSP in a constructive way without pointing > alternatives. Can one just say it is bad without pointing alternatives > and still give worthy input? > > Or do you just want to talk about the pros? > =;o) > > Clearly, there are some problems with JSPs. Supporting a clear > separation between logic (scripting) and presentation (templating) is > not easy to enforce with JSPs. And this is a discussion going on in > many forums. > > Now, JSPs are nice for scripting stuff (when you want to code and see > the result with no compiling/restarts). I even thought of using JSPs > for the scripting with Velocity for templating!!! And this is not such > new idea since there are people using JSPs with XSLT for the same > purposes. > > But XSLT just makes things too hard. Too much cost for not enough > profit. I just converted a XSLT based application to Velocity and I > sure know what I am talking about. > > Maybe JSPs just need something extra for the templating side. Maybe > JSPs can learn that from Velocity/WebMacro template engines. > > And this list is one of the best spots to talk about this. The right > people read this. * Isn't Tomcat the reference JSP implementation? * Is is. But the tomcat team doesn't set the spec, it just implements it. -Paul > > Have fun, > Paulo Gaspar > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 06, 2001 18:48 > > > > Why has the tomcat-dev list become a Velocity advocacy list?? > > Isn't the purpose of this list supposed to be for communation between > > Tomcat developers? Is velocity recruiting or something? > > > > =eas=
Re: multiple usage of same classes in different jars
On Fri, 6 Apr 2001, Szymon Stasik wrote: > > Hi > > I'm running Tomcat 4.0-b3 (standalone) and have some bit weired problem. > I know that it is possible to have eg.: > > user1/WEB-INF > user2/WEB-INF > > with apriopriate contexts: > >docBase="/home/userX/tomcat" > debug="0" > reloadable="false"> >prefix="framework_userX_log." suffix=".txt" > timestamp="true"/> > > > so both users can run/develop their application with no conflicts with > other. My idea is to run cocoon (1.8) with this environment. I have > (hopefully) solved classloader problem in cocoon, so even XSP is working > good for me while having all jars in user1/WEB-INF/lib. Now I'd like > user2 to have his own copy of all the jars in user2/WEB-INF/lib so he > can use modified wersion of his own jars or cocoon or any other classes. > AFAIK in Tomcat 4 it should be possible to allow simultanous work of > both users with their own versions of same classes. > > However the results are that both users receive instances of classes > from one of them. Strange thing - I was testing Class objects - all > classes from my jars seems to be different for both users (eg testing > org.apache.cocoon.Cocoon.hashCode() or any other class from WEB-INF/lib) > but the code executed is the same for both users and for both staticaly > (servlet) and dynamicaly (xsp) loaded code. > > Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat > or Cocoon? > It's (c) wrong behavior of Tomcat. Remy is currently investigating a fix for this. > > regards, > > Szymon. > Craig
multiple usage of same classes in different jars
Hi I'm running Tomcat 4.0-b3 (standalone) and have some bit weired problem. I know that it is possible to have eg.: user1/WEB-INF user2/WEB-INF with apriopriate contexts: so both users can run/develop their application with no conflicts with other. My idea is to run cocoon (1.8) with this environment. I have (hopefully) solved classloader problem in cocoon, so even XSP is working good for me while having all jars in user1/WEB-INF/lib. Now I'd like user2 to have his own copy of all the jars in user2/WEB-INF/lib so he can use modified wersion of his own jars or cocoon or any other classes. AFAIK in Tomcat 4 it should be possible to allow simultanous work of both users with their own versions of same classes. However the results are that both users receive instances of classes from one of them. Strange thing - I was testing Class objects - all classes from my jars seems to be different for both users (eg testing org.apache.cocoon.Cocoon.hashCode() or any other class from WEB-INF/lib) but the code executed is the same for both users and for both staticaly (servlet) and dynamicaly (xsp) loaded code. Is it my misconfiguration, misunderstadnig or wrong behaviour of Tomcat or Cocoon? regards, Szymon.
RE: 'Just say no to JSP'
Earl, If you think one should not discuss the merits of JSP here, you should not take part on it even if to defend JSP. If you agree we should talk about the pros and cons of JSPs, it is hard to talk about the cons of JSP in a constructive way without pointing alternatives. Can one just say it is bad without pointing alternatives and still give worthy input? Or do you just want to talk about the pros? =;o) Clearly, there are some problems with JSPs. Supporting a clear separation between logic (scripting) and presentation (templating) is not easy to enforce with JSPs. And this is a discussion going on in many forums. Now, JSPs are nice for scripting stuff (when you want to code and see the result with no compiling/restarts). I even thought of using JSPs for the scripting with Velocity for templating!!! And this is not such new idea since there are people using JSPs with XSLT for the same purposes. But XSLT just makes things too hard. Too much cost for not enough profit. I just converted a XSLT based application to Velocity and I sure know what I am talking about. Maybe JSPs just need something extra for the templating side. Maybe JSPs can learn that from Velocity/WebMacro template engines. And this list is one of the best spots to talk about this. The right people read this. * Isn't Tomcat the reference JSP implementation? * Have fun, Paulo Gaspar > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 06, 2001 18:48 > > Why has the tomcat-dev list become a Velocity advocacy list?? > Isn't the purpose of this list supposed to be for communation between > Tomcat developers? Is velocity recruiting or something? > > =eas=
Re: Where are the source for TC 4.0B3 ?
Sorry ... my fault. I'm at ApacheCon through today, and my net connectivity is intermittent. If you have CVS access, you can grab the exact sources you need by using tag "tomcat_40_b3" in both repositories (jakarta-tomcat-4.0 and jakarta-servletapi-4). Craig On Fri, 6 Apr 2001, GOMEZ Henri wrote: > Still nothing at : > > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/src/ >
Re: Where are the source for TC 4.0B3 ?
> Hi Remy, > > Did you have an idea about the jikes build problem ? Actually no. I think there's a packaging error, so I'll tweak a bit the build scripts. For some reason, it's working fine when compiled with javac ... Remy
Re: 'Just say no to JSP'
On Fri, 6 Apr 2001, Jon Stevens wrote: > on 4/6/01 9:48 AM, "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> wrote: > > > Why has the tomcat-dev list become a Velocity advocacy list?? > > Isn't the purpose of this list supposed to be for communation between > > Tomcat developers? Is velocity recruiting or something? > > > > =eas= > > Yes! > > :-) > Velocity advocacy is a fine thing for those interested in it. Unfortunately, it's off topic for TOMCAT-DEV. Can we please stop drowning out the legitimate discussions this list is for? > -jon > > Craig
RE: Where are the source for TC 4.0B3 ?
Hi Remy, Did you have an idea about the jikes build problem ? Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Remy Maucherat [mailto:[EMAIL PROTECTED]] >Sent: Friday, April 06, 2001 8:37 PM >To: [EMAIL PROTECTED] >Subject: Re: Where are the source for TC 4.0B3 ? > > > >- Original Message - >From: "GOMEZ Henri" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, April 06, 2001 11:31 AM >Subject: Where are the source for TC 4.0B3 ? > > >> Still nothing at : >> >> >http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4. 0-b3/src/ > Craig is at ApacheCon right now, so I think he'll do that when he gets back. Remy
Re: Where are the source for TC 4.0B3 ?
- Original Message - From: "GOMEZ Henri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 11:31 AM Subject: Where are the source for TC 4.0B3 ? > Still nothing at : > > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/src/ > Craig is at ApacheCon right now, so I think he'll do that when he gets back. Remy
RE: "Just say no to JSP" Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 02:00 > > ... > > My only complaints would be not > enough debug tools around to be able to single step through new code > when you are having problems, > > ... JBuilder 4 works just fine for me. And it works on Windows, Linux, Solaris and other Java platforms. Have fun, Paulo Gaspar
Where are the source for TC 4.0B3 ?
Still nothing at : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/src/
RE: [STATUS] Tomcat 3.2.2
>I've got a fix for the URL double decode security problem in >Tomcat 3.2.2. >I'm going to release Tomcat 3.2.2 beta 3 tonight to make this >fix publicly >available. Because the only change in Beta 3 is the security >fix, this beta >cycle will only be one week long. If no other security issues >are found, >I'll call a vote for 3.2.2 final late next week. I'll do the linux RPM and binaries mod_jk :)
Re: 'Just say no to JSP'
on 4/6/01 9:48 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Why has the tomcat-dev list become a Velocity advocacy list?? > Isn't the purpose of this list supposed to be for communation between > Tomcat developers? Is velocity recruiting or something? > > =eas= Yes! :-) -jon
Re: 'Just say no to JSP'
Why has the tomcat-dev list become a Velocity advocacy list?? Isn't the purpose of this list supposed to be for communation between Tomcat developers? Is velocity recruiting or something? =eas= On 6 Apr, Paulo Gaspar wrote: >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> Sent: Thursday, April 05, 2001 20:57 > > >> Arguing what is the best programming language or if interpreted is >> better than compiled is mostly a waste of time. Some people will >> prefer to learn VTL, other will prefer to use Java, other will like >> the XML-like syntax. > > Sure. And compiled is still an open option for Velocity. > > >> I think code generation is a good thing, ... > > Sure, some template use problems could be easier to debug if there is > some intermediate source code and a good debugger. > >> ... and I prefer using Jsp with Java >> for quick prototypes and taglibs when possible. > >
[STATUS] Tomcat 3.2.2
I've got a fix for the URL double decode security problem in Tomcat 3.2.2. I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly available. Because the only change in Beta 3 is the security fix, this beta cycle will only be one week long. If no other security issues are found, I'll call a vote for 3.2.2 final late next week.
RE: [Fwd: Tomcat may reveal script source code by URL trickery]
> -Original Message- > From: Jon Stevens [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 19:34 > > ... > > Now that is coming from the guy who previously flamed me to hell on this > list. :-) I love it. > > ... > > -jon Well, I often agree with you too. It even happened recently about a "scratch you own itch" situation. I am not personally after you Jon, it all depends on what you are saying. =;o) Have fun, Paulo
RE: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 20:57 > > ... > > Nothing wrong - yet another fine language, and a very nice > implementation. > And nothing good either - or I coulnd't find anything revolutionary > compared with other programming languages or other fine template-like > systems. Not revolucionary at all. The Velocity team publicly recognizes the inspiration from WebMacro. But the implementation makes a difference. I find Velocity much easier to control and mold into my own needs. (Clearer source code sure helps there.) And I am not saying it is perfect. > Arguing what is the best programming language or if interpreted is better > than compiled is mostly a waste of time. Some people will prefer to learn > VTL, other will prefer to use Java, other will like the XML-like syntax. Sure. And compiled is still an open option for Velocity. > I think code generation is a good thing, ... Sure, some template use problems could be easier to debug if there is some intermediate source code and a good debugger. > ... and I prefer using Jsp with Java > for quick prototypes and taglibs when possible. In my case, using JSP + taglibs in JServ (I still do not have a Tomcat production server here) is more trouble than using Velocity. On the other hand, I have a lot of exports to HTML - generation of static HTML from data in a database - and Velocity gives me a big help on that, while JSPs And then, I would like to be able export most of my site's dynamically generated pages to static HTML. Many pages don't change often and it is more efficient to develop dynamically and export to static HTML for production. > Costin Have fun, Paulo
Realms and webapp contexts (again..)
I'm still trying to use Realms on a per webapp context basis. This seems to be harder than I first imagined. Could someone from the tomcat developemt team please comment on whether this is possible or not at all? There are comments in the source that indicates that in theory this should be possible. But putting a anywhere else than inside the part of server.xml is ignored. I have also tried using a single realm impl., but with context specific data lookup up using jndi. This doesn't work simply because the jndi context factory is created with a different class loader, and thus jndi.lookup() simply blocks the current thread running Realm.authenticate(). -- - Torgeir
Re: mod_jk in a cluster
James Courtney wrote: > > With the exception of failover (case 4 below), I believe that the first > three cases can be handled by having your load balancer be "sticky" by > client address to any of the app servers (machines running Apache with > Tomcat). Thus if your load balancer receives a request from client > some.client.net and round robin assigns the request to server B, given > servers A, B, and C, then all subsequest requests from some.client.net > should be routed to server B. Our load balancer is very poor. He does weighted round robbin and the weights are the system load of the cluster computer. He can't look in the IP-Packets and doesn't know anything about sessions. And he also doesn't cache the client-ip's. So the load balancer can't handle the stickyness of the sessions. This is handled in the past by mod_jserv in the apache-webserver on the cluster. But now we want to use tomcat with mod_jk because of 2.2servlets and the better handling of SSL in ajp13. After playing around with mod_jk I build a new worker, my needs are more like a router (because of the sessions) with failover and not a load balancer (lb-worker). So I think my first idea to add a new property to the lb-worker wasn't clever. mod_jk is compiled, so I have to test it. This will take a little time. > If B ever goes down the session information > from some.client.net is lost and the client will have to retry their > session. To implement a failover system is highly non-trivial and my > understanding is that most application servers (even commercial ones) do not > support this. In fact I'm told by several coworkers who worked formerly for > BEA and know people there up to and including the B, the E, and the A that > WebLogic only recently got failover with session replication right. To make > this work you will need a somewhat complicated session replication mechanism > between all app servers which is n(n-1) replications (in this case 6) if > replication is done between all servers and at best n choose 2 (in this case > 3, or an extra session "write through" per request if you prefer) > replications if each app server has a single failover server. That can be a > lot of network traffic and a lot of new code. If I'm wrong and there's a > way to make this work in Tomcat then kudos to all involved and let me know > how to do it:)! > -Jamey I agree. Session replication is a solution but it isn't clever. You have to mutch traffic for the hopefully rare case of a server crash. So we make the following: If you have a session on a server wich is crashed, you get a new one on a server which is up and start at the beginning. This is handled by our servlets. So with my new worker in conjunction with our servlets I should get the desired behaviour. Thanks to the developers of mod_jk! My C-knowledge is not very well, but with the help of the comments and variable/function-names in the source I got it. The code is a little bit special to our purpose, but if there are interests in the small code I could send it to the list. But I think we should wait till it is tested :). Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED]
