BugRat Report #336 has been filed.
Bug report #336 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/336 REPORT #336 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: tomcat(jasper) JVM Release: jdk1.2 Operating System: unix OS Release: Redhat6.2,solaris7.0 Platform: unix Synopsis: tomcat cannot recognise include file tag correctly Description: this problem is like this: file1---aa.jsp %@ page contentType="text/html;charset=gb2312" % file2---bb.jsp %@ include file="aa.jsp" % ÕâÊÇÒ»¸ö²âÊÔ bb.jsp cannot display correctly you only write like this can be correctly file3---cc.jsp %@ page contentType="text/html;charset=gb2312" % ÕâÊÇÒ»¸ö²âÊÔ Title: BugRat Report # 336 BugRat Report # 336 Project: Tomcat Release: tomcat(jasper) Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Z_Tomcat Alias ([EMAIL PROTECTED]) Date Submitted: Nov 3 2000, 05:10:19 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: tomcat cannot recognise include file tag correctly Environment: (jvm, os, osrel, platform) jdk1.2, unix, Redhat6.2,solaris7.0, unix Additional Environment Description: Report Description: this problem is like this: file1--->aa.jsp <%@ page contentType="text/html;charset=gb2312" %> file2--->bb.jsp <%@ include file="aa.jsp" %> ÕâÊÇÒ»¸ö²âÊÔ bb.jsp cannot display correctly you only write like this can be correctly file3--->cc.jsp <%@ page contentType="text/html;charset=gb2312" %> ÕâÊÇÒ»¸ö²âÊÔ Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Arabic Encoding problem with tomcat!
I think this is a known bug. http://znutar.cortexity.com/BugRatViewer/ShowBug/48 I think if you report this, it will get linked to the same bug (#48). I do not know the status of this kind of behavior in TC 4.0. On Thu, 2 Nov 2000, Falcon cheetah wrote: I am using Tomcat 3.2.6 with Apache 1.3.14 on RH6.1. I am writing a WebMail application using JSP, JavaMail, etc. To write Arabic emails I wrote an applet that takes care of that and it works fine. My problem is when I send. my Editor_ar.jsp submits its form to handleMailaction.jsp where it should send the email. I have no problem sending emails using Editor.jsp, which is an all html English form. But when the handleMailaction.jsp gets the msgBody field that holds the Arabic message Tomcat starts acting on me. I keep getting messages about internal configuration error. How can I handle my input from that Applet! I am using ISO-8859-6, which is Arabic. Thanks for your help. Ahmed. __ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.0 Milestone 4
How could we find more information (and even code) about mod_warp ? I'll very happy to test it on Apache 1.3.14 . BTW will it be used in TC 3.3 ? I haven't seen the code, but if it is good code ( and knowing Pier, it'll be) we'll use it in TC3.3 too - I like mod_jk, but having more choices is good. I just hope someone will volunteer to develop the TC3.3 Interceptor for mod_wrap ( if not, I'll do it - if it also supports JNI :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk and file upload
I attempted to use the MultipartRequest utilities at http://www.servlets.com/resources/com.oreilly.servlet/ for file uploads with mod_jk/Apache and Tomcat 3.2b6 on Linux and got several errors and had trouble getting files to upload correctly. Eveything else worked fine with mod_jk. When I did uploads using Tomcat directly (pointed the browser at 8080, my tomcat port), I had no problems. I then tried to get it to work with mod_jserv and all worked fine. Does anyone know what might be causing this problem? Austin Mayberry [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #181 was closed (apparently by: Nick Bauman)
Report #181 was closed by Person #0 Synopsis: invalidate method and putValue method do not cooperate (logged in as: Nick Bauman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.0 Milestone 4
Costin, I believe there would be (or at least SHOULD be! :) many more contributors to these projects (Tomcat), but maybe some of us are intimidated by the level of apparent expertise required for this stuff. (Then again, I know we have some damn good people on these lists.) I am curious, is this the case? Have you all been writing java apps for years and are steeped in C++ and OOP for the last decade? Do you have the servlet spec pasted on your wall? How can I, a perl hacker and aspiring java coder get involved? (How do you guys know what to do?) At what point would I be considered to be "good enough" to really contribute some code? Server-side java simply rocks, and if I could help make it a more viable option for everyone (including myself and my company) then I would love to do it. Hope this isn't a totally inane question, but it has been on my mind for a couple weeks. Just wondering... Thanks, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 9:58 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 4.0 Milestone 4 How could we find more information (and even code) about mod_warp ? I'll very happy to test it on Apache 1.3.14 . BTW will it be used in TC 3.3 ? I haven't seen the code, but if it is good code ( and knowing Pier, it'll be) we'll use it in TC3.3 too - I like mod_jk, but having more choices is good. I just hope someone will volunteer to develop the TC3.3 Interceptor for mod_wrap ( if not, I'll do it - if it also supports JNI :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC3: moving jasper
In order to test and integrate the new jasper ( from catalina ) we need to move src/share/org/apache/jasper to src/jasper3/org/apache/jasper, and import jakarta-tomcat-4.0/jasper into jakarta-tomcat. I'll do that very soon - it'll generate a big diff file. I'll also integrate the invocation module, which seems very usefull, and I'm working on the webdav servlet ( well, there are big internal dependencies, but so far it seems possible to make it a trully reusable component, without dependencies on any individual container ) . Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/org/apache/tomcat - New directory
costin 00/11/03 13:15:30 jakarta-tomcat/src/webdav/org/apache/tomcat - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/org/apache/tomcat/webdav - New directory
costin 00/11/03 13:16:23 jakarta-tomcat/src/webdav/org/apache/tomcat/webdav - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/resources - New directory
costin 00/11/03 13:16:55 jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/resources - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/util - New directory
costin 00/11/03 13:17:29 jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/util DOMWriter.java MD5Encoder.java MIME2Java.java StringManager.java XMLWriter.java
costin 00/11/03 13:27:48
Modified:.build.xml
Added: src/webdav/org/apache/tomcat/webdav DefaultServlet.java
LocalStrings.properties WebdavServlet.java
src/webdav/org/apache/tomcat/webdav/resources
DirectoryBean.java FileResources.java
JarResources.java LocalStrings.properties
ResourceBean.java ResourceUtils.java Resources.java
ResourcesBase.java
src/webdav/org/apache/tomcat/webdav/util DOMWriter.java
MD5Encoder.java MIME2Java.java StringManager.java
XMLWriter.java
Log:
Initial commit for the webdav module from catalina.
Most of the junk is removed, but a bit more refactoring is still needed -
the cache generates a lot of garbage and the number of threads need to
be reduced ( and integrated with the server's thread management )
The new tomcat3 module has no external dependency ( except servlet22.jar ).
It doesn't work yet, but compiles fine ( it's very close to working :-)
Probably the resources should go to tomcat.util.resources, as we may reuse
them ( or at least the cache ) for static files ( well, that's just for
benchmark purpose, I don't think any decent admin would turn this on,
using a large cache in java will kill everything else - of course,
if only one file is cached, like in a "ab" benchmark, it looks ok ... )
The only missing part is the ServerLiaison, that will allow it to plug
into any servlet container.
Revision ChangesPath
1.90 +19 -1 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- build.xml 2000/11/02 21:56:58 1.89
+++ build.xml 2000/11/03 21:27:31 1.90
@@ -237,6 +237,24 @@
/jar
/target
+ !-- Webdav == --
+ target name="dav" depends="init"
+javac destdir="${tomcat.build}/classes"
+ debug="${debug}"
+ optimize="${optimize}"
+ deprecation="off"
+ srcdir="src/webdav"
+ classpath
+ pathelement location="${servlet22.jar}" /
+ /classpath
+ include name="org/apache/tomcat/webdav/**" /
+/javac
+jar jarfile="${tomcat.build}/lib/webdav.jar"
+ basedir="${tomcat.build}/classes"
+ include name="org/apache/tomcat/webdav/**" /
+/jar
+ /target
+
!-- Servlet 23 (default) implementation == --
target name="facade23" depends="init"
javac destdir="${tomcat.build}/classes"
@@ -315,7 +333,7 @@
/
/target
- target name="tomcat-jars-new"
depends="tomcat_util,tomcat.jar,tomcat_core,jasper,tomcat_modules,facade22,facade23,tomcat_config"
+ target name="tomcat-jars-new"
depends="tomcat_util,tomcat.jar,tomcat_core,jasper,tomcat_modules,facade22,facade23,tomcat_config,dav"
/target
!-- J2EE integration == --
1.1
jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/DefaultServlet.java
Index: DefaultServlet.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names
RE: Tomcat 4.0 Milestone 4
Costin, I believe there would be (or at least SHOULD be! :) many more contributors to these projects (Tomcat), but maybe some of us are intimidated by the level of apparent expertise required for this stuff. (Then again, I know we have some damn good people on these lists.) I am curious, is this the case? Have you all been writing java apps for years and are steeped in C++ and OOP for the last decade? Do you have the servlet spec pasted on your wall? I have probably more experience writing perl or setting up Linux than java :-) And you don't need the full spec - only few pages are so confused that you need them pasted on the walls. How can I, a perl hacker and aspiring java coder get involved? (How do you guys know what to do?) At what point would I be considered to be "good enough" to really contribute some code? Find something you don't like in tomcat ( or something you want tomcat to do ) and fix it. It's a step-by-step process, and any contribution is a step forward. In the worse case your code will brake something else, but that can be fixed. The current tomcat3.3 has a very small core, and most of the functionality is implemented in modules ( Interceptors ). In 90% of the cases you should be able to implement any new features ( or change/fix tomcat ) by just adding a new interceptor or replacing an existing one. The interceptor doesn't even have to be part of the standard distribution - you can just bundle it with tomcat or make it available ( but I can't see any reason not to check it in, except maybe lack of time ). Right now we are in a very bad need for contributors - there is so much to be done, and so little time. There are so many areas where you can improve the performance or add new features... As long as you learn something from that, it'll be a big win for tomcat too. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving jasper
The dependencies are with the resources package, to have some abstraction to the data being served, instead of just hardcoding access to the filesystem. It hasn't reduced performance in a noticeable way. So I would suggest you port the resources related stuff, instead of replacing the calls to the resources related classes with filesystem operations. Just my $0.02. If you can, please take a look at jakarta-tomcat/src/webdav, it's the first round. The code is just great, I did all that in 1 hour ( i.e. remove all deps on Catalina), and all that's missing is passing the docBase ( I have a feeling that can be done only with servlet2.2). BTW, I don't create dependencies just for the sake of creating dependencies ;) I only do it when I think I get something in return (like getting a nice abstraction layer). For example, the new naming stuff which has just been added in the Catalina tree is 100% Catalina-dependencies free. I'll try to add this to tomcat3 too, but one at a time :-) Keeping the modules independent of the container is very important - I think webdav should work in _any_ container, not only in Catalina. Portability is very important :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Arabic Encoding problem with tomcat!
Well, that is not good. I hope someone is working on it. I am launching our site soon and was hoping to have both English and Arabic. I am a Tomcat-ter, and would hate to think of something different. I do not have time either to dig up the code and see if I can fix it. Please someone help with that. Ahmed. Nick Bauman [EMAIL PROTECTED] wrote: I think this is a known bug.http://znutar.cortexity.com/BugRatViewer/ShowBug/48I think if you report this, it will get linked to the same bug (#48).I do not know the status of this kind of behavior in TC 4.0.On Thu, 2 Nov 2000, Falcon cheetah wrote: I am using Tomcat 3.2.6 with Apache 1.3.14 on RH6.1. I am writing a WebMail application using JSP, JavaMail, etc. To write Arabic emails I wrote an applet that takes care of that and it works fine. My problem is when I send. my Editor_ar.jsp submits its form to handleMailaction.jsp where it should send the email. I have no problem sending emails using Editor.jsp, which is an all html English form. But when the handleMailaction.jsp gets the msgBody field that holds the Arabic message Tomcat starts acting on me. I keep getting messages about internal configuration error. How can I handle my input from that Applet! I am using ISO-8859-6, which is Arabic. Thanks for your help. Ahmed. __ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus BaumanSoftware EngineerSimplexity Systems-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED].commands, e-mail: [EMAIL PROTECTED].Do You Yahoo!? >From homework help to love advice, Yahoo! Experts has your answer.
RE: Tomcat 4.0 Milestone 4
Craig, Thanks for the response! Definitely a helpful set of guidelines. It just seems like the Tomcat is project is so understaffed (!) and has so much potential, I would like to help out as soon as I can. Like Nacho (who replied to me privately) said, maybe it is not as much pure expertise as it is willingness to learn and contribute to the project (as he put it, being Intrepid :). Something as complicated as Tomcat, I am sure, has many aspects that could be hacked without having the servlet spec "pasted on the inside of my eyeballs"; printed next to me or in a browser window should be sufficient. Expect me to make some noise here in the future. :) Cheers! Mike -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 11:58 AM To: [EMAIL PROTECTED] Subject: Re: Tomcat 4.0 Milestone 4 Michael Percy wrote: Costin, I believe there would be (or at least SHOULD be! :) many more contributors to these projects (Tomcat), but maybe some of us are intimidated by the level of apparent expertise required for this stuff. (Then again, I know we have some damn good people on these lists.) I am curious, is this the case? Have you all been writing java apps for years and are steeped in C++ and OOP for the last decade? Do you have the servlet spec pasted on your wall? Michael, In my particular case the servlet spec is pasted on the inside of my eyeballs :-) But I'm kind of a wierd case in that respect, because I'm on the JSR-053 expert group that worked on the new specs (servlet 2.3 / JSP 1.2). Personally, I've been a software developer/designer/architect in some fashion or another for more years (and in more languages) than I care to admit. But I got involved in the Apache JServ project (predecessor to Tomcat) a few years ago when I needed a cheap server solution for an Internet-based application that I needed to build. Like everyone, I was grumbling about how long it took for JServ to get to final release (over a year from 0.9 to 1.0), until my son -- who likes PHP but I love him anyway :-) -- said "Dad, you know Java, get in there and help them finish it!". So I did. I wouldn't worry to much about expertise (although clearly Java is a must, and familiarty with the specifications that Tomcat implements -- servlet, JSP, HTTP, etc. -- is vital on this particular project). The ways that people get involved in open source are pretty varied, but a common course might go something like this: * You see something that you think should be added, or that doesn't seem to work quite right * You investigate the existing code, becoming more familiar with it along the way * You might ask a "what would you think if we did this?" type question on the developer list * You contribute to the discussion of these ideas (yours and others) - partly to gain knowledge but also partly to become known to the community * At some point, you propose a patch, or a new chunk of code that gets accepted into the code base (the detailed rules for Tomcat are on the Jakarta web site) * Iterate the above a few times, perhaps looking at bigger and bigger chunks of code as you gain more understanding * At some point, when it is evident that you're not a bozo :-), you can get nominated for committer status and voted on by the developer community, and then be able to post the changes directly yourself. How can I, a perl hacker and aspiring java coder get involved? (How do you guys know what to do?) At what point would I be considered to be "good enough" to really contribute some code? Server-side java simply rocks, and if I could help make it a more viable option for everyone (including myself and my company) then I would love to do it. It all starts by becoming familiar enough with the current code base to start understanding it. In most open source projects there is never enough architectural documentation, so this often involves asking "how does this work" type questions on the developer list. Don't feel bad about that -- NONE of us knew anything about Tomcat internals before we started working on it :-) Hope this isn't a totally inane question, but it has been on my mind for a couple weeks. Just wondering... Not at all inane -- I hope the above thoughts help. Thanks, Mike Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/webdav - New directory
costin 00/11/03 15:13:34 jakarta-tomcat/src/webdav/webdav - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/webdav/WEB-INF - New directory
costin 00/11/03 15:13:51 jakarta-tomcat/src/webdav/webdav/WEB-INF - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/webdav/webdav/WEB-INF web.xml
costin 00/11/03 15:19:01
Modified:.build.xml
src/webdav/org/apache/tomcat/webdav DefaultServlet.java
WebdavServlet.java
Added: src/webdav/webdav build.xml index.html tomcat-power.gif
tomcat.gif
src/webdav/webdav/WEB-INF web.xml
Log:
WebDav seems to work fine in DAVExplorer. Excelent code...
The directory structure is a mess, I'll fix it later ( i.e. move
all the sources in src/webdav/WEB-INF/src, make it a standalone
webapplication).
So far it seems to work with absolutely no dependency on tomcat -
if someone has another container it would be nice to test it
( the .war will be available soon, need to fix the build )
Revision ChangesPath
1.91 +10 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- build.xml 2000/11/03 21:27:31 1.90
+++ build.xml 2000/11/03 23:18:51 1.91
@@ -249,9 +249,14 @@
/classpath
include name="org/apache/tomcat/webdav/**" /
/javac
+copydir src="src/webdav/org/apache/tomcat"
+ dest="${tomcat.build}/classes/org/apache/tomcat"
+ include name="**/*.properties" /
+/copydir
jar jarfile="${tomcat.build}/lib/webdav.jar"
basedir="${tomcat.build}/classes"
include name="org/apache/tomcat/webdav/**" /
+ include name="org/apache/tomcat/webdav/**/*.properties" /
/jar
/target
@@ -354,6 +359,11 @@
javac srcdir="src/examples/jsp/plugin/applet"
optimize="${optimize}"
destdir="${tomcat.build}/webapps/examples/jsp/plugin/applet"/
+
+!-- webdav --
+mkdir dir="${tomcat.build}/webapps/webdav"/
+copydir src="src/webdav/webdav" dest="${tomcat.build}/webapps/webdav"/
+
!-- Tomcat profiling webapp - not ready for check in yet
mkdir dir="${tomcat.build}/webapps/prof"/
1.2 +25 -10
jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/webdav/org/apache/tomcat/webdav/DefaultServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DefaultServlet.java 2000/11/03 21:27:37 1.1
+++ DefaultServlet.java 2000/11/03 23:18:53 1.2
@@ -110,7 +110,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.1 $ $Date: 2000/11/03 21:27:37 $
+ * @version $Revision: 1.2 $ $Date: 2000/11/03 23:18:53 $
*/
public class DefaultServlet
@@ -282,6 +282,27 @@
// -- Protected Methods
+protected Resources getResources(HttpServletRequest req) {
+ ServletContext sc=getServletContext();
+ String docBase=sc.getRealPath("");
+ // XXX call getAttribute() to get a container-specific
+ // docBase that may work for jar resources
+ FileResources res=(FileResources)sc.
+ getAttribute( "webdav.Resources" );
+ if(res==null ) {
+ res=new FileResources();
+ res.setDocBase( docBase );
+ res.setContextPath(req.getContextPath() );
+ System.out.println("Setting docBase to " + docBase );
+ sc.setAttribute( "webdav.Resources", res );
+ }
+ // XXX the expire must be integrated in a different way,
+ // we'll not start the expire thread right now.
+
+ return res;
+}
+
+
/**
* Return the relative path associated with this servlet.
@@ -371,12 +392,6 @@
}
-protected Resources getResources() {
- // XXX get context resources
- return null;//new Container( getServletContext() );
-}
-
-
/**
* Process a POST request for the specified resource.
*
@@ -402,7 +417,7 @@
resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED);
}
-Resources resources = getResources();
+Resources resources = getResources(req);
boolean exists = resources.exists(path);
@@ -440,7 +455,7 @@
String path = getRelativePath(req);
-Resources resources = getResources();
+Resources resources = getResources(req);
boolean exists = resources.exists(path);
@@ -1147,7 +1162,7 @@
return;
}
-Resources resources = getResources();
+Resources resources = getResources(request);
ResourceInfo resourceInfo = new ResourceInfo(path, resources);
Re: cvs commit: jakarta-tomcat/src/webdav - New directory
the remaining 3.2 bugs (which you left behind on the 3.3 track) rather than duplicating work that has already been done. :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.0 Milestone 4
Thanks, Costin. You guys all make it sound like much less pain than I had previously thought. Maybe Tomcat could use a developer community site akin to what Mozilla has (www.mozillazine.org) -- people would probably be more willing to contribute if they felt invited. Also, maybe BugRat could use a user-friendly interface tweak or two? (And a visible link off the Tomcat Jakarta site!) I have some web design skills as well... I wonder if I could put them to some use? Regards, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 3:10 PM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat 4.0 Milestone 4 Costin, I believe there would be (or at least SHOULD be! :) many more contributors to these projects (Tomcat), but maybe some of us are intimidated by the level of apparent expertise required for this stuff. (Then again, I know we have some damn good people on these lists.) I am curious, is this the case? Have you all been writing java apps for years and are steeped in C++ and OOP for the last decade? Do you have the servlet spec pasted on your wall? I have probably more experience writing perl or setting up Linux than java :-) And you don't need the full spec - only few pages are so confused that you need them pasted on the walls. How can I, a perl hacker and aspiring java coder get involved? (How do you guys know what to do?) At what point would I be considered to be "good enough" to really contribute some code? Find something you don't like in tomcat ( or something you want tomcat to do ) and fix it. It's a step-by-step process, and any contribution is a step forward. In the worse case your code will brake something else, but that can be fixed. The current tomcat3.3 has a very small core, and most of the functionality is implemented in modules ( Interceptors ). In 90% of the cases you should be able to implement any new features ( or change/fix tomcat ) by just adding a new interceptor or replacing an existing one. The interceptor doesn't even have to be part of the standard distribution - you can just bundle it with tomcat or make it available ( but I can't see any reason not to check it in, except maybe lack of time ). Right now we are in a very bad need for contributors - there is so much to be done, and so little time. There are so many areas where you can improve the performance or add new features... As long as you learn something from that, it'll be a big win for tomcat too. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDBCRealm
After consultation with Carson McDonald I send this problem further to the dev list: I hope gain some help in solving a problem with the Tomcat 3.2b6 version of JDBCRealm. I'm using Postgresql as the underlying DB (I hope it's not that!). What I'm experiencing is that the usename/password pair are validated (user=paul below) but that the realm verification fails for unclear reasons. Then the object seems to go into some sort of stasis and won't handle anything correctly until Tomcat is restarted. Here is a log excerpt: 2000-11-03 03:40:58 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2000-11-03 03:41:12 - ContextManager: JDBCRealm: JDBCRealm.authenticate: SELECT passwd FROM users WHERE name = ? 2000-11-03 03:41:12 - ContextManager: JDBCRealm: Authentication unsuccessful for user null This null attempt seems to precede the initiation of a browser challenge. (?) 2000-11-03 03:41:18 - ContextManager: JDBCRealm: Authentication successful for u ser paul 2000-11-03 03:41:18 - ContextManager: JDBCRealm: Auth ok, user=paul 2000-11-03 03:41:18 - ContextManager: JDBCRealm: Controled access for paul R( /a pps + /admin/index.jsp + null) Ct (jsp(org.apache.jasper.servlet.JspServlet/null ) ) User 'paul' is verified ... 2000-11-03 03:41:18 - ContextManager: JDBCRealm: JDBCRealm.roles: SELECT role FR OM user_roles WHERE name = ? 2000-11-03 03:41:18 - ContextManager: JDBCRealm: There was an SQLException while in getUserRoles: paul The initial error is here, and I can't figure out where it comes from. If I execute the SQL manually from the command line (double checking all variable names etc. and enclosing paul in \'\s) it works correctly. 2000-11-03 03:41:18 - Ctx( /apps ): Exception in: R( /apps + /admin/index.jsp + null) - java.lang.NullPointerException at org.apache.tomcat.request.JDBCRealm.authorize(JDBCRealm.java:509) at org.apache.tomcat.core.ContextManager.doAuthorize(ContextManager.java :844) at org.apache.tomcat.core.ContextManager.internalService(ContextManager. java:778) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:732 ) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnectio n(HttpConnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java: 407) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :498) at java.lang.Thread.run(Thread.java:498) This traceback reflects the fact that roles[0] in line 509 is not there. 2000-11-03 04:12:35 - ContextManager: JDBCRealm: The database connection is null or was found to be closed. Trying to re-open it. 2000-11-03 04:12:35 - ContextManager: JDBCRealm: There was an SQLException while in authenticate: paul 2000-11-03 04:12:35 - ContextManager: JDBCRealm: The database connection is null or was found to be closed. Trying to re-open it. 2000-11-03 04:12:35 - ContextManager: JDBCRealm: There was an SQLException while in authenticate: paul 2000-11-03 04:12:35 - ContextManager: JDBCRealm: The database connection is null or was found to be closed. Trying to re-open it. 2000-11-03 04:12:35 - ContextManager: JDBCRealm: There was an SQLException while in authenticate: null 2000-11-03 04:12:46 - ContextManager: JDBCRealm: The database connection is null or was found to be closed. Trying to re-open it. 2000-11-03 04:12:46 - ContextManager: JDBCRealm: There was an SQLException while in authenticate: paul Here is where the postgres driver or JDBCRealm object has gone into some sort of lock. Best, Paul Mayer Please respond to [EMAIL PROTECTED] as well as the list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.0 Milestone 4
Michael Percy wrote: Thanks, Costin. You guys all make it sound like much less pain than I had previously thought. Maybe Tomcat could use a developer community site akin to what Mozilla has (www.mozillazine.org) -- people would probably be more willing to contribute if they felt invited. Also, maybe BugRat could use a user-friendly interface tweak or two? (And a visible link off the Tomcat Jakarta site!) I have some web design skills as well... I wonder if I could put them to some use? Some work on the web site would definitely be appreciated. Tomcat's "home page" (http://jakarta.apache.org/tomcat) is a little bit forlorn looking And it certainly not an area where anyone else is really focusing. (Code contributions are of course welcome as well. And user docs ... and answering mailing list questions ... oh yah, there's plenty to do :-) I'd be very interested in seeing any ideas in this regard that you might want to propose -- perhaps you could create some mockups for the code-oriented folks like me :-) to get a feel for it. On BugRat, I wouldn't suggest you focus there -- unless NIck, who has graciously agreed to host it for us, is ready to integrate any changes. It's really just a stop-gap solution until Scarab is completed (I've seen some of the UI for this, and it's going to be MUCH better). A hyperlink wouldn't hurt, though. Regards, Mike Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/webdav - New directory
The Tomcat community would certainly be better served if you cleaned up the remaining 3.2 bugs (which you left behind on the 3.3 track) rather than duplicating work that has already been done. Craig I agree. Well, so do I - 3.3 will have fewer bugs than 3.2, I'm working on the biggest one, wich is the encoding support. Regarding "duplicating work" - well, that's very interesting to hear, but I totally agree ( as I always did, and I'm glad other people start to agree with that) :-) By porting webdav to 3.3 we'll eliminate a lot of duplication of work, since the code will be independent of any container, so all changes can be reused in all containers, without duplicating work. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Red Alert 2 takes the world by storm
Welcome to the Westwood Online Newsletter! As a benefit of your membership on our Internet gaming service, this newsletter is sent to you absolutely free! If you would rather not receive special information, exclusive discounts and other club benefits, just follow the instructions at the bottom of this letter. Greetings Westwood Fans - Great news! Our latest installment in the Command Conquer series is now available - Red Alert 2 hit shelves all over the globe this week. It is taking the world by storm with rave press reviews and over the top fan enthusiasm. Instead of us gushing about our own game, we will let the press tell you themselves: "Westwood Studios' larger than life RTS is back and better than ever before. If you're looking for the hottest RTS this year, your ship has come in." - Gamers Depot "One of the most enthralling and addictive RTS games we've played." - Gamecenter "For us, the solid execution of Westwood's well-worn formula, backed up by enough new units to make a tangible difference in play over the original, plus the best overall production values in any Westwood game to date add up to a winner." - Daily Radar "One of the most refined, captivating and pleasing strategy games of the year." -IGN Don't miss out on the 'red' hot fun (sorry, we couldn't resist). Get your copy of Command Conquer Red Alert 2 today or find out even more by visiting http://www.westwood.com - Your friends at Westwood TO UNSUBSCRIBE FROM THIS MAILING LIST You may unsubscribe in two ways: 1. You may visit http://unsubscribe.westwood.com and enter your email address in the form provided. 2. You may reply to this mail and place the word "unsubscribe" or "unsubscribe [EMAIL PROTECTED]" in the first line of your message (not in subject field). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBCRealm
Hola Paul: I'm the responsible of the presence of JDBCRealm in tomcat 3.x and 4.x from a code contributed by Carson Mc. Donald, FYI. I'm responsible too of any bugs in JDBCRealm, by auto asignation :-), and only maintainer. The initial error is here, and I can't figure out where it comes from. If I execute the SQL manually from the command line (double checking all variable names etc. and enclosing paul in \'\s) it works correctly. Please put the class attached in your classes dir inside %TOMCAT_HOME%/classes/org/apache/tomcat/request/ dir , create it if needed , it's a slightly ( a single printstackstrace) modifyied for you to get some more info about the initial error you have... This traceback reflects the fact that roles[0] in line 509 is not there. ughh, another stupid mistake with Java Arrays , thanks.. @:-) The rest it's caused by the first error that make unstable the JDBC Driver i think, please search the archives some person some time ago, had problems with postgres too , perhaps. Saludos , Ignacio J. Ortega JDBCRealm.class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BUG TRACKING] searches re-enabled
Hello Jakarta-ers Thanks to some sharp thinking by Ignacio Ortega, I have converted the horrible sql BugRat originally used for searching with some better code. Suffice it to say, the original query would return in about 25 minutes. Ortega's code with the same data would returns in about 10 seconds. So what's that, an improvement of 150x? Hopefully with this kind of person on our side, Tomcat will eventually serve pages in the user's past. So happy searching! -- Nicolaus Bauman http://znutar.cortexity.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.0 Milestone 4
Hi Mike, to these projects (Tomcat), but maybe some of us are intimidated by the level of apparent expertise required for this stuff. (Then again, For me, it's a combination of expertise and startup time. The time and effort for us (re: aspiring, psyched Java guys), to get from "Read something in STATUS.HTML" to "Implement feature" or "Fix bug" is pretty scary, for me at least! Then again, by the time you go from read bug - fix bug, you'll have learned tons. I'm sure you've had similar experiences when you have to fix something tiny in something you've never worked on. By the end of it, you know their code probably better than they did, or else you wouldn't be in there fixing it ;) Of course all code has bugs, etc. just an exaggeration of course. for the last decade? Do you have the servlet spec pasted on your wall? I completely know what you mean. I save most all of the messages coming out of Sun and from other people who post a lot. The stuff these guys say is just gold (most of the time =) I really should get around to reading the specs, which I have Xmas ear-marked for. if I could help make it a more viable option for everyone (including myself and my company) then I would love to do it. This, and a combination of what I think Costin said (re: desire to fix something that's bothering you?)... I thought the docs were in pretty hurting shape when I was trying to learn Tomcat, which you can glean from the amount of questions I originally posted to the user list =) so anyways, yeah I took that on between summer-fall semesters and laid off when school started again. OH yeah, and there was this NullPointerException I used to get all the time, so I traced it down in the source but someone had already fixed it in a 3.2beta. I didn't know HOW to fix it, I just saw where it happened. I learned a lot about the source, and it was pretty cool. W.t.h. am I talking about again? I dunno, it's too late. I hope something I said made sense! - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Bug #27 was closed (apparently by: Ignacio Ortega)
Bug #27 was closed by Person #0 Synopsis: Race condition during servlet initialization (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory Constants.java EjbFactory.java ResourceEnvFactory.java ResourceFactory.java TransactionFactory.java TyrexDataSourceFactory.java TyrexTransactionFactory.java LocalStrings.properties
remm00/11/03 22:46:10
Modified:catalina build.xml
catalina/src/share/org/apache/catalina/core
StandardContext.java
Added: catalina/src/share/org/apache/naming EjbRef.java
ResourceEnvRef.java ResourceRef.java
TransactionRef.java
catalina/src/share/org/apache/naming/factory Constants.java
EjbFactory.java ResourceEnvFactory.java
ResourceFactory.java TransactionFactory.java
TyrexDataSourceFactory.java
TyrexTransactionFactory.java
Removed: catalina/src/share/org/apache/naming EjbRefAddr.java
ResourceEnvRefAddr.java ResourceRefAddr.java
catalina/src/share/org/apache/naming/factory
LocalStrings.properties
Log:
- Removed the address references, and replaced them with references
(EjbRefAddr - EjbRef, ResourceEnvRefAddr - ResourceEnvRef,
ResourceRefAddr - ResourceRef). It makes the code simpler and easier to
understand.
- Modified StandardContext to reflect this and create the right objects.
- Add a Tyrex resource factory. Instructions on how to use it to follow
shortly, as soon as all the issues are ironed out. Although the DataSource
is successfully instantiated, some more configuration is needed.
- The object factories are packaged in a separate JAR file
(lib/namingfactory.jar), to avoid classloading related problems.
- Object factory selector, which should be more efficient than the built in
JNDI mechanism. There will be one for each type (resource, ejb,
resource-env). The first one is the ResourceFactory, which checks the
requested type and the parameters given to select the appropritate factory.
As there's only one factory right now, it can only select that one.
- Add the selector factories for EJB and resource env (without any actual
factories)
- Add transaction reference object.
- Add a transaction factory selector.
- Add a wrapper to get a UserTransaction object from Tyrex.
- The StandardContext will now bind a reference to a user transaction in
java:comp/UserTransaction as recommended by the J2EE spec.
Revision ChangesPath
1.20 +19 -1 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- build.xml 2000/11/02 06:14:07 1.19
+++ build.xml 2000/11/04 06:46:07 1.20
@@ -26,6 +26,12 @@
mkdir dir="${catalina.build}/conf"/
mkdir dir="${catalina.build}/lib"/
mkdir dir="${catalina.build}/server"/
+
+!-- === Conditional Compilation Falgs --
+available property="tyrex.present"
+ classname="tyrex.jdbc.ServerDataSource" /
+available property="jta.present"
+ classname="javax.transaction.UserTransaction" /
/target
@@ -72,7 +78,14 @@
javac srcdir="src/share" destdir="${catalina.build}/classes"
classpath="${parser.jar}:${jaxp.jar}:${regexp.jar}:${servlet.jar}:${jcert.jar}:${jnet.jar}:${jsse.jar}:${jmxri.jar}"
deprecation="off" debug="on" optimize="off" target="1.2"
- excludes="**/CVS/**"/
+ excludes="**/CVS/**"
+ exclude name="**/factory/TyrexDataSourceFactory.java"
+ unless="tyrex.present" /
+ exclude name="**/factory/TyrexTransactionFactory.java"
+ unless="tyrex.present" /
+ exclude name="**/factory/TransactionFactory.java"
+ unless="jta.present" /
+/javac
!-- Copy static resource files --
copydir src="src/share"dest="${catalina.build}/classes"
@@ -87,6 +100,11 @@
jar jarfile="${catalina.build}/bin/naming.jar"
basedir="${catalina.build}/classes"
includes="**/org/apache/naming/**"
+ excludes="**/org/apache/naming/factory/**"
+ /
+jar jarfile="${catalina.build}/lib/namingfactory.jar"
+ basedir="${catalina.build}/classes"
+ includes="**/org/apache/naming/factory/**"
/
/target
1.28 +19 -14
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.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- StandardContext.java 2000/11/03 06:46:54 1.27
+++ StandardContext.java 2000/11/04 06:46:07 1.28
@@ -1,7 +1,7 @@
/*
- * $Header:
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Regards, Liam Magee. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, 4 November 2000 4:27 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 / 4.0 confusion, rant and plan... Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I believe that this developer community once agreed that Tomcat 4.0 _will_be_ the next major release of the Apache Software Foundation servlet engine, but, since a couple of weeks, I see a proliferation of emails talking about Tomcat 3.3. Here is where I'm getting confused... When did we vote about having a dual codebase for two different servlet engines at the same time??? Because I've never seen such a discussion taking place... Also, it seems ridiculous (at least to me) to start talking about what will be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the door, and as far as I've read (but I might have missed some emails) Beta-6 is not even compiling... Sorry, but as a long time ASF member, and one of the first kids involved in the glorious JServ, I feel that things here are getting a little bit screwed up. Are we going to screw our release cycles? Are we going out to the public with TWO servlet engines equal in features, but different in codebases? Are we all going NUTS? Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. But, I'm not _only_ a pain in the ass... I see there are some developers who prefer to work on the 3.x tree, rather than helping out on the 4.0, so, instead of cutting their wings and forcing them to fork the project, I propose to them what was proposed to Craig in february. The "Rules for Evolution and Revolutions" still stands still, as one of the major constitution documents for this community (James, WTF, post it somewhere!!! :) and IMNSHO needs to be used... I suggest to whoever is interested in further developement of the 3.3 tree to create a new proposal, as Craig did with Catalina, and stick it on the "proposals" directory in the CVS. And start working from it. I'm more than open to see, after Tomcat 4.0 sees light, to reconsider the effort, and maybe switching codebase again for what will be Tomcat 5.0. So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) 3) Release Tomcat 4.0 (with Catalina, as we all decided) 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. My 0.02 $... Take care... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
