[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-03-23/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE init: prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 19 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 42 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 89 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 6 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/parser.jar to copy. [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common tomcat_util: [javac] Compiling 82 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/core_util.jar [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_util.jar tomcat.jar: [javac] Compiling 1 source file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/tomcat.jar stop-tomcat.jar: [javac] Compiling 1 source file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [copy] Copying 4 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/tomcat/resources [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/stop-tomcat.jar tomcat_core: [javac] Compiling 10 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/tomcat_core.jar jasper: [javac] Compiling 76 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [copy] Copying 5 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/jasper [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/jasper-runtime.jar [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/jasper.jar tomcat_modules: [javac] Compiling 39 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_modules.jar facade22: [javac] Compiling 17 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] /home/rubys/jakarta/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java:189: incompatible types [javac] found : java.util.Vector [javac] required: boolean [javac] if( removed=null) removed=new Vector(); [javac] ^
BugRat Bug #24 - bootstrap.bat/sh classpath setup
Bug #24 Details Project: Ant Category: Feature Requests SubCategory: Enhancement Class: support State: closed Priority: medium Severity: non-critical Confidence: public Environment: Release: CVS Snapshot (1.2alpha) JVM Release: Sun 1.3 JRE Operating System: Windows 2K OS Release: No Service Pack Platform: x86 Synopsis: bootstrap.bat/sh classpath setup Description: In order to build Ant with an old copy of Ant in the classpath, the classpath should be changed From: SET CLASSPATH=%CLASSPATH%;%LOCALCLASSPATH%;%CLASSDIR%;src\main To: SET CLASSPATH=%LOCALCLASSPATH%;%CLASSDIR%;src\main;%CLASSPATH% The bootstrap.sh file will have the same issue Title: BugRat Bug # 24 BugRat Bug # 24 Project: Ant Release: CVS Snapshot (1.2alpha) Category: Feature Requests SubCategory: Enhancement Class: support State: closed Priority: medium Severity: non-critical Confidence: public Date Opened: Sep 8 2000, 09:31:55 CDT Date Closed: Sep 8 2000, 09:39:47 CDT Responsible: Z_Ant Alias ([EMAIL PROTECTED]) Synopsis: bootstrap.bat/sh classpath setup Environment: (jvm, os, osrel, platform) Sun 1.3 JRE, Windows 2K, No Service Pack, x86 Additional Environment Description: Report Description: In order to build Ant with an old copy of Ant in the classpath, the classpath should be changed From: SET CLASSPATH=%CLASSPATH%;%LOCALCLASSPATH%;%CLASSDIR%;src\main To: SET CLASSPATH=%LOCALCLASSPATH%;%CLASSDIR%;src\main;%CLASSPATH% The bootstrap.sh file will have the same issue How To Reproduce: Workaround: View this Bug online...
Realm design
I have a few questions about the Realm design: a) How does a Realm find details of the Login Config for the Context currently being authenticated? When developing a Realm it may be very useful to determine the authentication method used. However, at the moment the Realm is just told to authenticate. The Realm may also be attached to the global level and therefore have no idea which Context the authentication request came from. Seems to me that it would be useful for the Realm to be able to determine the Login Config so that it can adjust any authentication processes as required. b) Why aren't CLIENT-CERT authentications passed onto the registered Realm? At the moment, Realms only see to be passed to process BASIC authentication requests. At the moment certificate requests are processed by the automatically injected CertificateValve. Why can't Realms process CLIENT-CERT requests? Thanks, David.
SSI Update
Here's the latest version of the SSI package which now *fully* implements: Echo Config errmsg sizefmt timefmt Fsize flastmod include exec is the only command from the NCSA SSI standard that is not supported. Enjoy, Bip tomcat-4.x.SSI.zip
[TC322] Code Freeze
I am about to start the tag and build for Tomcat 3.2.2 beta 2. Please do not make any changes to the tomcat_32 branch until further notice.
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade Servlet22Interceptor.java
costin 01/03/23 08:32:21
Modified:src/facade22/org/apache/tomcat/facade
Servlet22Interceptor.java
Log:
Ops, thanks Gump.
Restarting the nightly builds is now on the top of the todo list...
Revision ChangesPath
1.15 +1 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java
Index: Servlet22Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Servlet22Interceptor.java 2001/03/23 03:28:55 1.14
+++ Servlet22Interceptor.java 2001/03/23 16:32:21 1.15
@@ -186,7 +186,7 @@
if( value instanceof HttpSessionBindingListener) {
((HttpSessionBindingListener) value).valueUnbound
(new HttpSessionBindingEvent(httpSess , key));
- if( removed=null) removed=new Vector();
+ if( removed==null) removed=new Vector();
removed.addElement( key );
}
}
Re: Mod_jk for Solaris 8- Apache 1.3.17-Tomcat 3.2.1
Take a look at the most recent 3.2.x code -- people have cleaned up some of the mod_jk docs, and there may be something there which will help you. You could either download TC 3.2.2b1 (or 2, once Marc gets that out), or pull the latest thing from cvs (the tomcat_32 tag). -Dan "Hardy, Maurice" wrote: Hi, I need to compile mod_jk for Tomcat 3.2.1 and Apache 1.3.17. Apparently, the source code directory structure doesn't match the Mod_jk compile instructions. On this particular source the file seems missing . Is there an easier or another way to compile this ? Are there some updated instructions on "How To Get Mod_jk Working" ? i need any help that you can offer. Thanks -M- Name: Notebook.jpg Notebook.jpgType: JPEG Image (image/jpeg) Encoding: base64 -- Dan Milstein // [EMAIL PROTECTED]
Re: Timestamps in mod_jk.log
Shahed, As one of the current mod_jk maintainers, I can tell you that (sadly), I'm not going to be able to work on that any time soon (there are a bunch of more pressing connector-related things on my plate). However, I *did* just finish adding a raft of comments to the mod_jk code, and I'm hoping to add more (that's high on my list). So, if you wanted to take a crack at this yourself, you might check out the most recent version of 3.3 (jakarta-tomcat), and take a look through the mod_jk code there. the src/native/mod_jk/common/jk_util.c has the logging code... -Dan Shahed Ali wrote: Hi, Could the developers of mod_jk please add timestamp logging and if possible request url to mod_jk.log ? Thanks Shahed. -- Dan Milstein // [EMAIL PROTECTED]
Re: [STATUS] Tomcat 3.2.2
Marc, I just want to say that it is fantastic that you have managed to corral all those loose bug reports. -Dan Marc Saegesser wrote: Well, it took longer than I had hoped, but we have finally managed to review *all* open bug reports against Tomcat-3! The only reports left in the NEW state are those specifically opened against Tomcat 3.3. All the others have either been closed as FIXED, WORKSFORME or INVALID. A big THANK YOU to everyone who helped make this happen. My plan is to use tomorrow, Thursday (3/22/01) for some final testing. On Friday morning (Central US time) I will tag and build Tomcat 3.2.2 beta 2. This beta will last two weeks, during which time the only commits to the tomcat_32 branch will be for fixing critical bugs identified during the beta period. At the end of the beta period I will call a vote for the release of Tomcat 3.2.2. Marc Saegesser -- Dan Milstein // [EMAIL PROTECTED]
RE: mod_webapp status?
Since mod_jk is using just a few APR-like functions, the transition woulnd't be difficult - but it's important to do it at the right time. And IMHO that should come as a decision from tomcat-dev - I would feel very bad if Henri or Dan would decide to switch to APR without a serious discussion on tomcat-dev. Don't worry, I never said I'll modify mod_jk to use APR, and I didn't remember Dan speak about it. We're correcting the remaining bugs. And at this moment I would be strongly -1: APR is still beta, while tomcat is used in production, the code we use works and has been ported on most platforms we care, the extra overhead will hurt users, and I don't know any real-world use of APR as a portable runtime with NES or IIS or AOLServer - it should work, but I need to see at least one proof before we start depending on that. +1 and you know I use Tomcat in production and the current mod_jk works well for me on Linux Boxes. Let's be pragmatic. mod_jk works on many Unix systems, Windows and Netware. The most important build feature to add is the configure (autoconf) stuff to help build mod_jk on many more targets. We even can take a look at APR configure which detect the various envs. There was a confusion on mod_jk, mod_webapp and APR. I said : APR is a great piece of code but it will restrict Tomcat to have only one front-end, Apache Web Server. and little time after What I wanted to say is that mod_webapp didn't have wrapper code for use with IIS or NES or JNI. Only a module for Apache 1.3/2.0 Now only mod_jk let you connect Tomcat to Apache (1.3/2.0), IIS or NES. I really feel that mod_jk will be the reference connector for many months. it use a network protocol, ajp13, which works well even if the protocol could be improved. I allready speak about that improvement (ajp13++ or ajp14). In that case a new protocol will be added but the core of mod_jk will stay the same. mod_jk works well now with ajp12, ajp13 why not an ajp14 which features like strongest ACL (connect time), forward load/unload of context/webapp to Apache web server, better recovery in updload mode Of course, I can't -1 something in mod_webapp - since nobody asked or proposed or discussed any of the mod_webapp developments ( or even requirements, or anything else for that matter - except announcements about the progress ). +1 Pier you need to make more reports on mod_webapp if you want others people involved into that project. For example, the switch to APR was not discussed on the list. You may read the various discussions between I and Dan about mod_jk and everybody known what we're doing.
Re: VHosting
Thom,
There was vigorous back and forth about this on the mailing list a few
weeks back -- I'll paste in the final message in the thread -- you could
also take a look in the archives for more details. This is from Henri:
-Dan
==
The correct config for mod_jk is :
in httpd.conf :
JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
# set it to error since warn just load to many apache
JkLogLevel error
for virtuals
VirtualHost host1.com:80
DocumentRoot"/home/httpd/host1/html"
Directory "/home/httpd/host1/html"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
/Directory
ServerName host1.com
ServerAdmin [EMAIL PROTECTED]
ErrorLog/home/httpd/host1/var/log/httpd/error_log
TransferLog /home/httpd/host1/var/log/httpd/access_log
JkMount /app1/servlet/* workerhost1
JkMount /app1/*.jsp workerhost1
/VirtualHost
VirtualHost host1.com:443
DocumentRoot"/home/httpd/host1/htmls"
Directory "/home/httpd/host1/htmls"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
/Directory
Alias /usage/ "/home/httpd/host1/usage/"
Directory "/home/httpd/host1/usage"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
ServerName host1.com
ServerAdmin [EMAIL PROTECTED]
ErrorLog/home/httpd/host1/var/log/httpd/error_log
TransferLog /home/httpd/host1/var/log/httpd/access_log
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile
/home/httpd/host1/etc/httpd/conf/ssl.crt/host1.com-server.crt
SSLCertificateKeyFile
/home/httpd/host1/etc/httpd/conf/ssl.key/host1.com-server.key
Files ~ "\.(cgi|shtml|phtml|php3?)$"
SSLOptions +StdEnvVars
/Files
Directory "/home/httpd/cgi-bin"
SSLOptions +StdEnvVars
/Directory
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
CustomLog /home/httpd/host1/var/log/httpd/ssl_request_log "%t %h
%{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
JkMount /secureapp1/servlet/* workerhost1
JkMount /secureapp1/*.jsp workerhost1
/VirtualHost
.
Note the way to use SSL in this case to use secureapp1 webapp ;-)
Thom May wrote:
Folks,
has anything happened with vhost support with mod_jk/apache 1.3 in 3.3?
I've not had a chance to look recently and I really need it...
ta,
-Thom, stuck in wet and miserable london for the next 3 weeks
--
Dan Milstein // [EMAIL PROTECTED]
RE: java.lang.OutOfMemoryError
Title: RE: java.lang.OutOfMemoryError StringWriter wraps StringBuffer. So you are using StringBuffer. -Original Message- From: chu luk [SMTP:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 6:26 PM To: [EMAIL PROTECTED] Subject: RE: java.lang.OutOfMemoryError i am not doing a whole lot of contatenation, but i do use stringWriter -- is it the same as stringBuffer? thanks --- Parayali, Jayesh 1065 [EMAIL PROTECTED] wrote: Here is one suggestion. Use StringBuffer instead of String if you are doing string contatenation. -Original Message- From: chu luk [SMTP:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 5:17 PM To: [EMAIL PROTECTED] Subject: java.lang.OutOfMemoryError Hi, I have a servlet listens for HTTP POST request. then query the oracle database and response -- request / response are XML. I had 10 Load Test client keep sending HTTP request to servlet as fast as they can -- for 10 hours But within 10 hours, all the response are OK, except i got a couple of servlet internal error says Out of Memory for some of the client. Error: 500 Location: /test/server Internal Servlet Error: java.lang.OutOfMemoryError Do I have a memory leak? or that means too servlet is overLoad? or Any thing cause this error? Is this a common error? I believe my servlet's memeory requirement is not that big. but i had at least 100 String object in it. thanks. P.S, my Config is: oracle 8.1.6 tomcat 3.2 apache 1.3.17 Sun OS 5.6 use HTTP / XML for request / response average run time / request = 500 milli - second # of client = 10 __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
TC3.3 - building javadoc
Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
bug in SimpleSessionStore/ServerSession id
I posted on this earlier (last night), but the tomcat-dev list is now so slow that I don't know if it ever really made it to the list. I'm encountering a bug now in SimpleSessionStore. In the inner class (gawd I hate inner classes :-)) SimpleSessionManager's getNewSession() method, a NullPointerException is thrown when the method tries to add the new session to the 'sessions' hashtable because the newly created session ID is null. This happens because, as near as I can tell, it is never set. I'm not sure who is working on this code or why it is not getting set, but it is very reproduceable - every time I try to access any servlet it crashes! :-) My app does not depend on sessions (we use a portable, non-servlet API dependent session management system) so it would be nice if this bit of code wasn't crashing on me. In my early post, if it ever made it, I proposed altering the MessageBytes.toString() function to never return a null (I think it is very bad form for a non-null object to return a null value from it's toString()) and instead simply return "null". However, I realize now that MessageBytes is a bit special in that it has a type T_NULL and that this could have larger impact if other code relies on this. Thus, I'd leave this for someone more knowledgeable with how MessageBytes is used to make that change if at all. The only thing I can think of to do right now is to modify the getNewSession() method to check the returned String representation of the session's id to see if it is null. If so, use "null". This fixes the crash and shouldn't, I believe, cause any new problems since the dang thing is null at this point anyway. I'm going to go ahead and commit this change, if this is bad, let me know or go ahead and change it back - but if so, please fix the underlying problem. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Catalina vs. preServletInit et. al.
Hello, I'm a newbie to the Catalina code line and need some guidance (lots actually)... I have a custom interceptor that works really well with Tomcat 3.x that does some special setup work in the preServletInit/postServletInit, preService/postService and preServletDestroy/postServletDestroy methods of the special RequestInterceptor. My problem is determining functional equivalents to these in Catalina. Can anyone give me any pointers - I sort of lost my way in the source code and documentation (primarily due to existing references to 'interceptors' in both comments and docs.) Is there still a way to do some pre/post processing for each corresponding servlet call (init,destroy and service). I looked at VavleBase and couldn't see any direct comparison. -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Still have XML loading problems
Craig, I'm playing with the 22nd March drop of Catalina, and I've come across a scenario where the new classloading architecture doesn't quite work. I'm using Xerces and Xalan (although Xalan is irrelevant to this). If I access a servlet that uses XML and I don't put Xerces in my web-app/myapp/lib my code fails (exactly what I'd expect). If I put Xerces.jar into web-app/myapp/lib it works, again what I'd expect. However, if I put my XML code into an application listener then Jasper fails to load - I get a Security Exception, sealing violation, while it's load the 'jsp' servlet. It seems that what's happening is that my listener loads, loads Xerces and executes OK. The jsp Servlet then tries to load crimson/JAXP and *bang* sealing violation. Sorry about this - the XML stuff had been going so well until then! Kevin Jones DevelopMentor www.develop.com
Re: Still have XML loading problems
Kevin Jones wrote: Craig, I'm playing with the 22nd March drop of Catalina, and I've come across a scenario where the new classloading architecture doesn't quite work. I'm using Xerces and Xalan (although Xalan is irrelevant to this). If I access a servlet that uses XML and I don't put Xerces in my web-app/myapp/lib my code fails (exactly what I'd expect). If I put Xerces.jar into web-app/myapp/lib it works, again what I'd expect. However, if I put my XML code into an application listener then Jasper fails to load - I get a Security Exception, sealing violation, while it's load the 'jsp' servlet. It seems that what's happening is that my listener loads, loads Xerces and executes OK. The jsp Servlet then tries to load crimson/JAXP and *bang* sealing violation. I will bet you're using a JDK 1.3 platform, right? It turns out that all the changes we made are very effective for JDK 1.2, but the 1.3 version of URLClassLoader still doesn't like it. :-( Sorry about this - the XML stuff had been going so well until then! I think the only workaround for this is to ship our own copy of the JAXP JAR files, with the "sealed" attribute removed. I'm also going to be talking with the JAXP folks about removing that in their next release. Kevin Jones DevelopMentor www.develop.com Craig
RE: TC3.3 - building javadoc
Normally i use a custom build that generates org.apache.tomcat.* javadocs instead of the normal reduced set.. I'm +1 on this change for release.. Saludos , Ignacio J. Ortega -Mensaje original- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Enviado el: viernes 23 de marzo de 2001 18:44 Para: [EMAIL PROTECTED] Asunto: TC3.3 - building javadoc Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
cvs commit: jakarta-tomcat/src/webpages index.html
marcsaeg01/03/23 11:13:16
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
Constants.java
src/webpages Tag: tomcat_32 index.html
Log:
Updating version numbers for the Tomcat 3.2.2 beta 2 release.
Revision ChangesPath
No revision
No revision
1.22.2.12 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java,v
retrieving revision 1.22.2.11
retrieving revision 1.22.2.12
diff -u -r1.22.2.11 -r1.22.2.12
--- Constants.java2001/02/26 17:20:33 1.22.2.11
+++ Constants.java2001/03/23 19:13:15 1.22.2.12
@@ -67,7 +67,7 @@
public class Constants {
public static final String TOMCAT_NAME = "Tomcat Web Server";
-public static final String TOMCAT_VERSION = "3.2.2 beta 1";
+public static final String TOMCAT_VERSION = "3.2.2 beta 2";
public static final String JSP_NAME = "JSP";
public static final String JSP_VERSION = "1.1";
No revision
No revision
1.13.2.14 +2 -2 jakarta-tomcat/src/webpages/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
retrieving revision 1.13.2.13
retrieving revision 1.13.2.14
diff -u -r1.13.2.13 -r1.13.2.14
--- index.html2001/03/09 18:52:18 1.13.2.13
+++ index.html2001/03/23 19:13:15 1.13.2.14
@@ -4,13 +4,13 @@
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
meta name="GENERATOR" content="Mozilla/4.72 [en] (WinNT; U) [Netscape]"
meta name="Author" content="Anil K. Vijendran"
-titleTomcat v3.2.2 beta 1/title
+titleTomcat v3.2.2 beta 2/title
/head
body bgcolor="#FF"
img SRC="tomcat.gif" height=92 width=130 align=LEFTbfont face="Arial,
Helvetica, sans-serif"font size=+3Tomcat/font/font/b
br
bfont face="Arial, Helvetica, sans-serif"font size=-1Version
-3.2.2 beta 1/font/font/b
+3.2.2 beta 2/font/font/b
pThis is the default Tomcat home page. This page serves as a quick reference
guide to related resources and is located at:
ul
Is Apache web server 1.3.x multithreaded
Hi, Is Apache web server 1.3.x multithreaded? that's each request and handle by a thread. OR each request is handle by a child process fork by parent? thanks. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: Any plan to support status 304 ?
Hola a todos, Remy: All HTTP/1.1 ifs headers should be supported in 4.0, as well as ranged requests (for resuming), and many other things. After too much reading on HTTP RFC specs, and many documents around that, i see no problems on implementing ifs honoring on Tomcat 3.3 as HTTP 1.0 RFC it's only a ground base for old HTTP implementations not a real RFC as HTTP 1.1 has.. What do you think? As an aside where it's this code on Tomcat 4.0 ? If you're using TC in standalone mode, I would recommend upgrading to 4.0 beta 2 when it's released. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Saludos , Ignacio J. Ortega
limit servlet access to user
Hi, I have a web application running on tomcat. there are 2 httpServlet in that web app. how can i limit user access to one of the httpServlet? I read the example application in tomcat under \tomcat\webapps\examples\jsp\security which demo form base authentication. I looked through all the property files but can't find where it defines the directory restrict access. OR the defualt dir is \protected on the same directory as JSP? i really not quite sure how it works. thanks. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: bug in SimpleSessionStore/ServerSession id
Hi Mel, I'm working on the SimpleSessionStore, it had problems with recycling the ServerSession objects and I tried to fix them while removing some complexity and spaghetti code. I'll check that - probably after this weekend I'll be done with the session and threading changes. Regarding MessageBytes - it must be able to store null ( it's a holder for a String - which can be null ). The session Id can also be null, before it is set by the session id generator, and is also null after the session expires. So the fix is not in not returning null, but in making sure the code that uses the session id will access it when the session is in the right state. Defining the state of a ServerSession object is not yet completed, and it would certainly help to get some review - as well as for the other core objects. Costin On Fri, 23 Mar 2001, Mel Martinez wrote: I posted on this earlier (last night), but the tomcat-dev list is now so slow that I don't know if it ever really made it to the list. I'm encountering a bug now in SimpleSessionStore. In the inner class (gawd I hate inner classes :-)) SimpleSessionManager's getNewSession() method, a NullPointerException is thrown when the method tries to add the new session to the 'sessions' hashtable because the newly created session ID is null. This happens because, as near as I can tell, it is never set. I'm not sure who is working on this code or why it is not getting set, but it is very reproduceable - every time I try to access any servlet it crashes! :-) My app does not depend on sessions (we use a portable, non-servlet API dependent session management system) so it would be nice if this bit of code wasn't crashing on me. In my early post, if it ever made it, I proposed altering the MessageBytes.toString() function to never return a null (I think it is very bad form for a non-null object to return a null value from it's toString()) and instead simply return "null". However, I realize now that MessageBytes is a bit special in that it has a type T_NULL and that this could have larger impact if other code relies on this. Thus, I'd leave this for someone more knowledgeable with how MessageBytes is used to make that change if at all. The only thing I can think of to do right now is to modify the getNewSession() method to check the returned String representation of the session's id to see if it is null. If so, use "null". This fixes the crash and shouldn't, I believe, cause any new problems since the dang thing is null at this point anyway. I'm going to go ahead and commit this change, if this is bad, let me know or go ahead and change it back - but if so, please fix the underlying problem. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: Still have XML loading problems
Yep 1.3 I think the only workaround for this is to ship our own copy of the JAXP JAR files, with the "sealed" attribute removed. I'm also going to be talking with the JAXP folks about removing that in their next release. :-( What would happen if you made a special case of the JSP servlet and loaded it early? Could you preload jasper somewhere else? Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 23 March 2001 19:05 To: Kevin Jones Cc: Tomcat-Dev Subject: Re: Still have XML loading problems Kevin Jones wrote: Craig, I'm playing with the 22nd March drop of Catalina, and I've come across a scenario where the new classloading architecture doesn't quite work. I'm using Xerces and Xalan (although Xalan is irrelevant to this). If I access a servlet that uses XML and I don't put Xerces in my web-app/myapp/lib my code fails (exactly what I'd expect). If I put Xerces.jar into web-app/myapp/lib it works, again what I'd expect. However, if I put my XML code into an application listener then Jasper fails to load - I get a Security Exception, sealing violation, while it's load the 'jsp' servlet. It seems that what's happening is that my listener loads, loads Xerces and executes OK. The jsp Servlet then tries to load crimson/JAXP and *bang* sealing violation. I will bet you're using a JDK 1.3 platform, right? It turns out that all the changes we made are very effective for JDK 1.2, but the 1.3 version of URLClassLoader still doesn't like it. :-( Sorry about this - the XML stuff had been going so well until then! I think the only workaround for this is to ship our own copy of the JAXP JAR files, with the "sealed" attribute removed. I'm also going to be talking with the JAXP folks about removing that in their next release. Kevin Jones DevelopMentor www.develop.com Craig
limit servlet access to user
Hi, I have a web application running on tomcat. there are 2 httpServlet in that web app. how can i limit user access to one of the httpServlet? I read the example application in tomcat under \tomcat\webapps\examples\jsp\security which demo form base authentication. I looked through all the property files but can't find where it defines the directory restrict access. OR the defualt dir is \protected on the same directory as JSP? i really not quite sure how it works. thanks. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: TC3.3 - building javadoc
In the change I propose to make (I've already done it locally and it seems to work well) we'd have the following sorts of targets: target name="dist" depends="dist.prepare,javadoc,dist.war" target name="dist.prepare" depends="main,webapps,tomcat-jars-new" target name="javadoc" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.core" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.modules" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.util" depends="main,webapps,tomcat-jars-new" target name="javadoc.jasper" depends="main,webapps,tomcat-jars-new" ... etc... target name="dist.war" depends="dist.prepare" target name="dist.nojavadoc" depends="dist.war" Thus, the changed behavior would be that when you build 'dist' you would get ALL the javadocs generated. If you want to build 'dist' with no javadocs, just use build dist.war or build dist.nojavadoc If you want to build just a subset of the javadoc (with or without any other targets), just specify the particular javadoc. target in your list of targets. build dist.war javadoc.tomcat.core At this point, the javadoc targets are somewhat exclusive - generating one wipes the index.html of the previous build, although the actual doc pages are not wiped. There are ways to address this, but not worth the effort right now. Is this cool with folks? Note - I'll try to add a separate javadoc. target for most of the major tomcat packages but not all. mel --- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Normally i use a custom build that generates org.apache.tomcat.* javadocs instead of the normal reduced set.. I'm +1 on this change for release.. Saludos , Ignacio J. Ortega -Mensaje original- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Enviado el: viernes 23 de marzo de 2001 18:44 Para: [EMAIL PROTECTED] Asunto: TC3.3 - building javadoc Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: TC3.3 - building javadoc
In the change I propose to make (I've already done it locally and it seems to work well) we'd have the following sorts of targets: target name="dist" depends="dist.prepare,javadoc,dist.war" target name="dist.prepare" depends="main,webapps,tomcat-jars-new" target name="javadoc" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.core" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.modules" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.util" depends="main,webapps,tomcat-jars-new" target name="javadoc.jasper" depends="main,webapps,tomcat-jars-new" ... etc... target name="dist.war" depends="dist.prepare" target name="dist.nojavadoc" depends="dist.war" Thus, the changed behavior would be that when you build 'dist' you would get ALL the javadocs generated. If you want to build 'dist' with no javadocs, just use build dist.war or build dist.nojavadoc If you want to build just a subset of the javadoc (with or without any other targets), just specify the particular javadoc. target in your list of targets. build dist.war javadoc.tomcat.core At this point, the javadoc targets are somewhat exclusive - generating one wipes the index.html of the previous build, although the actual doc pages are not wiped. There are ways to address this, but not worth the effort right now. Is this cool with folks? Note - I'll try to add a separate javadoc. target for most of the major tomcat packages but not all. mel --- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Normally i use a custom build that generates org.apache.tomcat.* javadocs instead of the normal reduced set.. I'm +1 on this change for release.. Saludos , Ignacio J. Ortega -Mensaje original- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Enviado el: viernes 23 de marzo de 2001 18:44 Para: [EMAIL PROTECTED] Asunto: TC3.3 - building javadoc Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/res StringManager.java
melaquias01/03/23 13:55:55
Modified:src/share/org/apache/tomcat/util/res StringManager.java
Log:
Changes getString(String key) to return null if the requested resource is not found.
This is consistent with general java container pattern usage and enables calling code
to detect that the requested string was not found via a null check.
Revision ChangesPath
1.2 +33 -15
jakarta-tomcat/src/share/org/apache/tomcat/util/res/StringManager.java
Index: StringManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/res/StringManager.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StringManager.java2001/02/20 03:12:46 1.1
+++ StringManager.java2001/03/23 21:55:55 1.2
@@ -1,4 +1,5 @@
/*
+ * $Id: StringManager.java,v 1.2 2001/03/23 21:55:55 melaquias Exp $
*
*
* The Apache Software License, Version 1.1
@@ -81,8 +82,12 @@
* pPlease see the documentation for java.util.ResourceBundle for
* more information.
*
+ * @version $Revision: 1.2 $ $Date: 2001/03/23 21:55:55 $
+ *
* @author James Duncan Davidson [[EMAIL PROTECTED]]
* @author James Todd [[EMAIL PROTECTED]]
+ * @author Mel Martinez [[EMAIL PROTECTED]]
+ * @see java.util.ResourceBundle
*/
public class StringManager {
@@ -114,32 +119,45 @@
private StringManager(String packageName,Locale loc) {
String bundleName = packageName + ".LocalStrings";
try {
- bundle = ResourceBundle.getBundle(bundleName,loc);
- } catch( MissingResourceException ex ) {
- bundle= ResourceBundle.getBundle( bundleName, Locale.US);
- }
+bundle = ResourceBundle.getBundle(bundleName,loc);
+} catch( MissingResourceException ex ) {
+bundle= ResourceBundle.getBundle( bundleName, Locale.US);
+}
}
/**
- * Get a string from the underlying resource bundle.
- *
- * @param key
+Get a string from the underlying resource bundle or return
+null if the String is not found.
+
+@param key to desired resource String
+@return resource String matching ikey/i from underlying
+bundle or null if not found.
+@throws IllegalArgumentException if ikey/i is null.
*/
public String getString(String key) {
-if (key == null) {
-String msg = "key is null";
+if(key == null){
+String msg = "key may not have a null value";
-throw new NullPointerException(msg);
+throw new IllegalArgumentException(msg);
}
String str = null;
-try {
- str = bundle.getString(key);
-} catch (MissingResourceException mre) {
-str = "[cannot find message associated with key '" + key + "' due to "
+ mre + "]";
- // mre. print Stack Trace();
+try{
+ str = bundle.getString(key);
+}catch(MissingResourceException mre){
+//bad: shouldn't mask an exception the following way:
+// str = "[cannot find message associated with key '" + key + "' due
to " + mre + "]";
+ // because it hides the fact that the String was missing
+ // from the calling code.
+ //good: could just throw the exception (or wrap it in another)
+ // but that would probably cause much havoc on existing
+ // code.
+ //better: consistent with container pattern to
+ // simply return null. Calling code can then do
+ // a null check.
+ str = null;
}
return str;
[STATUS] Tomcat 3.2.2 beta 2
The tomcat_322_b2 tag is now available. The binary and source distributions have been uploaded. I've got a couple more download tests to finish before I update the website and send the announcement messages. If anyone has binaries that they want included in the distribution please send them to me and I'll add them to the download area. Thanks for everyone help getting this release wrapped up.
RE: Any plan to support status 304 ?
Quoting "Ignacio J. Ortega" [EMAIL PROTECTED]: Hola a todos, Remy: All HTTP/1.1 ifs headers should be supported in 4.0, as well as ranged requests (for resuming), and many other things. After too much reading on HTTP RFC specs, and many documents around that, i see no problems on implementing ifs honoring on Tomcat 3.3 as HTTP 1.0 RFC it's only a ground base for old HTTP implementations not a real RFC as HTTP 1.1 has.. What do you think? I think to be consistent, you should only implement HTTP/1.0 features. The only if header required in HTTP/1.0 is if-modified-since. HTTP/1.1 requires stuff in both the connector and the static page server (servlet or interceptor). As an aside where it's this code on Tomcat 4.0 ? In the default servlet, and it's not very optimized, esp when dealing with the complex cases (which I think is ok, since most cases will be GET with perhaps a if-modified-since). Remy
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/resources LocalStrings.properties LocalStrings_es.properties LocalStrings_fr.properties
melaquias01/03/23 14:50:16
Added: src/share/org/apache/jasper/resources
LocalStrings.properties LocalStrings_es.properties
LocalStrings_fr.properties
Log:
LocalString.properties replaces messages.properties
Name change necessary to shift Jasper over to using
org.apache.tomcat.util.res.StringManager for String resource access.
The 'messages.properties' files shall be deleted.
Revision ChangesPath
1.1
jakarta-tomcat/src/share/org/apache/jasper/resources/LocalStrings.properties
Index: LocalStrings.properties
===
# $Id: LocalStrings.properties,v 1.1 2001/03/23 22:50:16 melaquias Exp $
#
# Default localized string information
# Localized this the Default Locale as is en_US
jsp.error.bad.servlet.engine=Incorrect servlet engine version!
jsp.error.no.scratch.dir=The JSP engine is not configured with a scratch dir.\
\n Please add \"jsp.initparams=scratchdir=dir-name\" \
\n in the servlets.properties file for this context.
jsp.error.bad.scratch.dir=The scratchDir you specified: {0} is unusable.
jsp.message.scratch.dir.is=Scratch dir for the JSP engine is: {0}
jsp.message.parent_class_loader_is=Parent class loader is: {0}
jsp.message.dont.modify.servlets=IMPORTANT: Do not modify the generated servlets
jsp.error.not.impl.comments=Internal error: Comments not implemented
jsp.error.not.impl.directives=Internal error: Directives not implemented
jsp.error.not.impl.declarations=Internal error: Declarations not implemented
jsp.error.not.impl.expressions=Internal error: Expressions not implemented
jsp.error.not.impl.scriptlets=Internal error: Scriptlets not implemented
jsp.error.not.impl.usebean=Internal error: useBean not implemented
jsp.error.not.impl.getp=Internal error: getProperty not implemented
jsp.error.not.impl.setp=Internal error: setProperty not implemented
jsp.error.not.impl.plugin=Internal error: plugin not implemented
jsp.error.not.impl.forward=Internal error: forward not implemented
jsp.error.not.impl.include=Internal error: include not implemented
jsp.error.usebean.missing.attribute=useBean: id attribute missing or misspelled
jsp.error.usebean.missing.type=useBean ({0}): Either class or type attribute must be
\
specified:
jsp.error.usebean.duplicate=useBean: Duplicate bean name: {0}
jsp.error.usebean.prohibited.as.session=Can't use as session bean {0} since it is
prohibited \
by jsp directive defined earlier:
jsp.error.usebean.not.both=useBean: Can't specify both class and beanName attribute:
jsp.error.usebean.bad.type.cast=useBean ({0}): Type ({1}) is not assignable from
class ({2})
jsp.error.usebean.invalid.scope=Invalid scope ({1}) in useBean: ({0}).
jsp.error.classname=Can't determine classname from .class file
jsp.warning.bad.type=Warning: bad type in .class file
jsp.error.data.file.write=Error while writing data file
jsp.error.page.multiple.contenttypes=Page directive: can't have multiple occurrences
of contentType
jsp.error.page.invalid.contenttype=Page directive: invalid value for contentType
jsp.error.page.multiple.session=Page directive: can't have multiple occurrences of
session
jsp.error.page.invalid.session=Page directive: invalid value for session
jsp.error.page.multiple.buffer=Page directive: can't have multiple occurrences of
buffer
jsp.error.page.invalid.buffer=Page directive: invalid value for buffer
jsp.error.page.multiple.autoflush=Page directive: can't have multiple occurrences of
autoFlush
jsp.error.page.invalid.autoflush==Page directive: invalid value for autoFlush
jsp.error.page.multiple.threadsafe=Page directive: can't have multiple occurrences
of isThreadSafe
jsp.error.page.invalid.threadsafe==Page directive: invalid value for isThreadSafe
jsp.error.page.multiple.info=Page directive: can't have multiple occurrences of info
jsp.error.page.invalid.info==Page directive: invalid value for info
jsp.error.page.multiple.iserrorpage=Page directive: can't have multiple occurrences
of isErrorPage
jsp.error.page.invalid.iserrorpage==Page directive: invalid value for isErrorPage
jsp.error.page.multiple.errorpage=Page directive: can't have multiple occurrences of
errorPage
jsp.error.page.multiple.language=Page directive: can't have multiple occurrences of
language
jsp.error.page.defafteruse.language=Page directive: can't define language after a
scriptlet
jsp.error.page.nomapping.language=Page directive: No mapping for language:
jsp.error.page.multiple.extends=Page directive: can't have multiple occurrences of
extends
jsp.error.page.bad_b_and_a_combo=Page directive: Illegal combination of
buffer=\"none\" autoFlush=\"false\"
jsp.error.not.impl.taglib=Internal error: Tag extensions not implemented
jsp.error.include.missing.file=Missing file argument to include
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/res StringManager.java
melaquias01/03/23 14:51:13
Modified:src/share/org/apache/tomcat/util/res StringManager.java
Log:
Fix bug in getString() that throws nullpointerexception if args==null.
Revision ChangesPath
1.3 +28 -23
jakarta-tomcat/src/share/org/apache/tomcat/util/res/StringManager.java
Index: StringManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/res/StringManager.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- StringManager.java2001/03/23 21:55:55 1.2
+++ StringManager.java2001/03/23 22:51:13 1.3
@@ -1,5 +1,5 @@
/*
- * $Id: StringManager.java,v 1.2 2001/03/23 21:55:55 melaquias Exp $
+ * $Id: StringManager.java,v 1.3 2001/03/23 22:51:13 melaquias Exp $
*
*
* The Apache Software License, Version 1.1
@@ -82,7 +82,7 @@
* pPlease see the documentation for java.util.ResourceBundle for
* more information.
*
- * @version $Revision: 1.2 $ $Date: 2001/03/23 21:55:55 $
+ * @version $Revision: 1.3 $ $Date: 2001/03/23 22:51:13 $
*
* @author James Duncan Davidson [[EMAIL PROTECTED]]
* @author James Todd [[EMAIL PROTECTED]]
@@ -172,33 +172,38 @@
*/
public String getString(String key, Object[] args) {
- String iString = null;
+String iString = null;
String value = getString(key);
- // this check for the runtime exception is some pre 1.1.6
- // VM's don't do an automatic toString() on the passed in
- // objects and barf out
+// this check for the runtime exception is some pre 1.1.6
+// VM's don't do an automatic toString() on the passed in
+// objects and barf out
- try {
+try {
// ensure the arguments are not null so pre 1.2 VM's don't barf
-Object nonNullArgs[] = args;
+if(args==null){
+args = new Object[1];
+}
+
+Object[] nonNullArgs = args;
for (int i=0; iargs.length; i++) {
- if (args[i] == null) {
- if (nonNullArgs==args) nonNullArgs=(Object[])args.clone();
- nonNullArgs[i] = "null";
- }
- }
-
+if (args[i] == null) {
+if (nonNullArgs==args){
+nonNullArgs=(Object[])args.clone();
+}
+nonNullArgs[i] = "null";
+}
+}
iString = MessageFormat.format(value, nonNullArgs);
- } catch (IllegalArgumentException iae) {
- StringBuffer buf = new StringBuffer();
- buf.append(value);
- for (int i = 0; i args.length; i++) {
- buf.append(" arg[" + i + "]=" + args[i]);
- }
- iString = buf.toString();
- }
- return iString;
+} catch (IllegalArgumentException iae) {
+StringBuffer buf = new StringBuffer();
+buf.append(value);
+for (int i = 0; i args.length; i++) {
+buf.append(" arg[" + i + "]=" + args[i]);
+}
+iString = buf.toString();
+}
+return iString;
}
/**
cvs commit: jakarta-tomcat/src/share/org/apache/jasper Constants.java
melaquias01/03/23 14:55:38
Modified:src/share/org/apache/jasper Constants.java
Log:
Refactored to use org.apache.tomcat.util.res.StringManager for String Resource
retrieval. [i.e. maximize code re-use].
affects:
Jasper message strings in org.apache.jasper.resources no longer stored in
"messages.properties", but rather "LocalStrings.properties" as required by
StringManager.
Revision ChangesPath
1.18 +8 -34 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- Constants.java2001/03/09 22:26:12 1.17
+++ Constants.java2001/03/23 22:55:37 1.18
@@ -61,9 +61,11 @@
import java.text.MessageFormat;
import org.apache.tomcat.util.log.Log;
+import org.apache.tomcat.util.res.StringManager;
/**
- * Some constants and other global data that are used by the compiler and the
runtime.
+ * Some constants and other global data that are used by the compiler
+ * and the runtime.
*
* @author Anil K. Vijendran
* @author Harish Prabandham
@@ -186,15 +188,11 @@
/**
* This is where all our error messages and such are stored.
*/
-private static ResourceBundle resources;
+private static StringManager resources;
private static void initResources() {
- try {
- resources =
- ResourceBundle.getBundle("org.apache.jasper.resources.messages");
- } catch (MissingResourceException e) {
- throw new Error("Fatal Error: missing resource bundle: "+e.getClassName());
- }
+resources = StringManager.getManager(
+"org.apache.jasper.resources");
}
/**
@@ -209,34 +207,10 @@
* Format the string that is looked up using "key" using "args".
*/
public static final String getString(String key, Object[] args) {
-if (resources == null)
+if(resources==null){
initResources();
-
-try {
-String msg = resources.getString(key);
-if (args == null)
-return msg;
- if( msg==null ) {
- //System.out.println("Can't find resource for " + key );
- return key;
- }
-MessageFormat form = new MessageFormat(msg);
- // JDK1.1 will throw NullPointer if args[0] == null
- // JDK1.2+ will work fine.
-
- //System.out.println(" XXX " + msg + " "+key + " " +args.length );
- if( args.length 0 ) {
- for( int i=0; i args.length; i++ ) {
- if( args[i]==null ) {
- //System.out.println("Null argument " +msg + " " + key);
- return msg;
- }
- }
- }
-return form.format(args);
-} catch (MissingResourceException ignore) {
-throw new Error("Fatal Error: missing resource:
"+ignore.getClassName());
}
+return resources.getString(key,args);
}
/**
cvs commit: jakarta-tomcat/src/share/org/apache/jasper Constants.java
melaquias01/03/23 14:58:09
Modified:src/share/org/apache/jasper Constants.java
Log:
Put check in message() behavior for null return value from getString(key) call.
If string resource not there, log key parameter as the message.
Revision ChangesPath
1.19 +3 -1 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- Constants.java2001/03/23 22:55:37 1.18
+++ Constants.java2001/03/23 22:58:09 1.19
@@ -243,7 +243,9 @@
jasperLog = Log.getLog("JASPER_LOG", null);
if (jasperLog != null)
- jasperLog.log(getString(key, args), verbosityLevel);
+ String msg = getString(key,args);
+ msg=(msg==null)?key:msg;
+ jasperLog.log(msg, verbosityLevel);
}
public static Log jasperLog = null;
Re: Still have XML loading problems
Kevin Jones wrote: Yep 1.3 I think the only workaround for this is to ship our own copy of the JAXP JAR files, with the "sealed" attribute removed. I'm also going to be talking with the JAXP folks about removing that in their next release. :-( What would happen if you made a special case of the JSP servlet and loaded it early? Could you preload jasper somewhere else? It (the JSP servlet) is loaded early already. It (and its XML parser) are now loaded by another classloader (not sure that was true on the 22nd -- if your Tomcat 4.0 has "jasper-compiler.jar" and "jasper-runtime.jar" separated, then it is for you). The problem is the following scenario: * JSP servlet loads early, parses TLDs from the web.xml file (which causes some JAXP parser classes to be loaded). * You do something with Xerces that causes Xerces classes to be loaded, from your webapps class loader (parent of the one used by the JSP servlet). * You do something with a JSP page that causes more parser classes to be loaded (from the JSP servlet's classloader), including a class with the same fully qualified name as one of the Xerces classes you just loaded. * Under 1.2 this worked. Under 1.3 it gives sealing violation errors The only other possible workaround I can think if is to exhaustively load every single class file out of jaxp.jar and crimson.jar at startup time. That seems horrendously wasteful of memory (especially when you consider that this has to be done for each web app). Kevin Jones DevelopMentor www.develop.com Craig
cvs commit: jakarta-tomcat/src/share/org/apache/jasper Constants.java
melaquias01/03/23 15:00:10
Modified:src/share/org/apache/jasper Constants.java
Log:
Oops. Fix to put in missing {} or won't compile!
Revision ChangesPath
1.20 +7 -6 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Constants.java2001/03/23 22:58:09 1.19
+++ Constants.java2001/03/23 23:00:10 1.20
@@ -239,13 +239,14 @@
* level.
*/
public static final void message(String key, Object[] args, int verbosityLevel)
{
- if (jasperLog == null)
- jasperLog = Log.getLog("JASPER_LOG", null);
+ if (jasperLog == null)
+ jasperLog = Log.getLog("JASPER_LOG", null);
- if (jasperLog != null)
- String msg = getString(key,args);
- msg=(msg==null)?key:msg;
- jasperLog.log(msg, verbosityLevel);
+ if (jasperLog != null){
+ String msg = getString(key,args);
+ msg=(msg==null)?key:msg;
+ jasperLog.log(msg, verbosityLevel);
+}
}
public static Log jasperLog = null;
RE: Still have XML loading problems
It (the JSP servlet) is loaded early already. It (and its XML parser) are now loaded by another classloader (not sure that was true on the 22nd -- if your Tomcat 4.0 has "jasper-compiler.jar" and "jasper-runtime.jar" separated, then it is for you). I have jasper-compiler.jar in 'jasper' and jasper-runtime.jar in 'lib' The problem is the following scenario: * JSP servlet loads early, parses TLDs from the web.xml file (which causes some JAXP parser classes to be loaded). * You do something with Xerces that causes Xerces classes to be loaded, from your webapps class loader (parent of the one used by the JSP servlet). * You do something with a JSP page that causes more parser classes to be loaded (from the JSP servlet's classloader), including a class with the same fully qualified name as one of the Xerces classes you just loaded. * Under 1.2 this worked. Under 1.3 it gives sealing violation errors I'm not seeing this sequence (I don't think) * I'm loading Xerces in my listener (in fact all I'm doing is using the DocumentBuilder and DocumentBuilderFactory), in the contextInitialized method, this is getting loaded first. * JSP servlet is trying to load - in it's init() method I get the exception No TLDs but I see a call to TldLocationsCache.init This is part of the trace I'm seeing ContextConfig[/KRJ]: Added certificates - request attribute Valve xmlSetupListener: enter contextInitialized xmlSetupListener: leave contextInitialized StandardWrapper[/KRJ:default]: Loading container servlet default default: init StandardWrapper[/KRJ:invoker]: Loading container servlet invoker invoker: init StandardWrapper[/KRJ:jsp]: Using Jasper classloader for servlet jsp jsp: init StandardContext[/KRJ]: Servlet /KRJ threw load() exception javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:791) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3135) ... lines omitted for brevity ... - Root Cause - java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader .java:646) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader .java:1013) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader .java:912) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml(TldLocationsCa che.java:161) The only other possible workaround I can think if is to exhaustively load every single class file out of jaxp.jar and crimson.jar at startup time. That seems horrendously wasteful of memory (especially when you consider that this has to be done for each web app). Agreed Kevin Jones DevelopMentor www.develop.com
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-03-23/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE init: prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 19 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 42 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 89 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 6 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/parser.jar to copy. [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common tomcat_util: [javac] Compiling 82 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/core_util.jar [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_util.jar tomcat.jar: [javac] Compiling 1 source file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/tomcat.jar stop-tomcat.jar: [javac] Compiling 1 source file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [copy] Copying 4 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/tomcat/resources [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/stop-tomcat.jar tomcat_core: [javac] Compiling 10 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/tomcat_core.jar jasper: [javac] Compiling 76 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [copy] Copying 5 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/jasper [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/jasper-runtime.jar [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/jasper.jar tomcat_modules: [javac] Compiling 39 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_modules.jar facade22: [javac] Compiling 17 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] /home/rubys/jakarta/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java:189: incompatible types [javac] found : java.util.Vector [javac] required: boolean [javac] if( removed=null) removed=new Vector(); [javac] ^
Re: Mod_jk for Solaris 8- Apache 1.3.17-Tomcat 3.2.1
Hi, The option "-lposix4" is required. This is my script to make mod_jk.so $APACHE_HOME/bin/apxs -o mod_jk.so -DSOLARIS -I../jk \ -I$JAVA_HOME/include -I$JAVA_HOME/include/solaris\ -lposix4 -c *.c ../jk/*.c Regards, Kim On Thu, 22 Mar 2001, Hardy, Maurice wrote: Hi, I need to compile mod_jk for Tomcat 3.2.1 and Apache 1.3.17. Apparently, the source code directory structure doesn't match the Mod_jk compile instructions. On this particular source the file seems missing . Is there an easier or another way to compile this ? Are there some updated instructions on "How To Get Mod_jk Working" ? i need any help that you can offer. Thanks -M-
Re: Still have XML loading problems
Kevin Jones wrote: It (the JSP servlet) is loaded early already. It (and its XML parser) are now loaded by another classloader (not sure that was true on the 22nd -- if your Tomcat 4.0 has "jasper-compiler.jar" and "jasper-runtime.jar" separated, then it is for you). I have jasper-compiler.jar in 'jasper' and jasper-runtime.jar in 'lib' If I had looked at my calendar I would have figured that one out ... The problem is the following scenario: * JSP servlet loads early, parses TLDs from the web.xml file (which causes some JAXP parser classes to be loaded). * You do something with Xerces that causes Xerces classes to be loaded, from your webapps class loader (parent of the one used by the JSP servlet). * You do something with a JSP page that causes more parser classes to be loaded (from the JSP servlet's classloader), including a class with the same fully qualified name as one of the Xerces classes you just loaded. * Under 1.2 this worked. Under 1.3 it gives sealing violation errors I'm not seeing this sequence (I don't think) * I'm loading Xerces in my listener (in fact all I'm doing is using the DocumentBuilder and DocumentBuilderFactory), in the contextInitialized method, this is getting loaded first. Yep, Listeners (and Filters) get initialized before any load-on-startup servlets do. * JSP servlet is trying to load - in it's init() method I get the exception No TLDs but I see a call to TldLocationsCache.init The constructor calls processWebDotXml(), which scans web.xml looking for taglib directives (using an XML parse, of course). You're seeing the same symptom from operations in a different order, but the cause is identical -- when a JAXP class is loaded *after* a Xerces class (even though the Xerces class is loaded from a parent class loader), you get the error on a 1.3 JVM. Kevin Jones Craig
Re: Catalina vs.preServletInit et. al.
Hmm.. interesting - In my modification(s) I was setting some thread-local objects which were then used by some objects referred to in my servlet. i.e. I was setting a naming-context such that it referred to the naming context that was appropriate for my execution thread. If I register an event-listener - can I be assured that it will run in the same thread as that using the servlet-instance? - in which case I home free. If not, then one way to solve my problem would be to alter the wrapper class and 'wrap' the points where the servlet init, service and destroy method calls are invoked. Not very pluggable though and involves a nasty hack of the Catalina source. Are there any other alternatives to this? -Thom On Fri, 23 Mar 2001, T. Park wrote: Hello, I'm a newbie to the Catalina code line and need some guidance (lots actually)... I have a custom interceptor that works really well with Tomcat 3.x that does some special setup work in the preServletInit/postServletInit, preService/postService and preServletDestroy/postServletDestroy methods of the special RequestInterceptor. My problem is determining functional equivalents to these in Catalina. The model for customized request processing in Catalina is quite a bit different than Tomcat 3.x. Fundamentally, you use a Valve for most processing. Valves implement the "chain of responsibility" pattern from the GoF book -- and once you understand them, you will also understand how Filters work in the servlet 2.3 spec :-). However, Valves don't directly do what you're asking for here. The Context element supports the registration of InstanceListener objects, which receive InstanceEvent notifications of the six events you mentioned above, plus beforeFilter and afterFilter (2.3 specific). This follows the usual JavaBeans patterns for event notification. From server.xml, you can configure instance listeners by nesting a new element inside the Context Context path="/..." ... InstanceListener className="com.mycompany.MyListener/ /Context Can anyone give me any pointers - I sort of lost my way in the source code and documentation (primarily due to existing references to 'interceptors' in both comments and docs.) Is there still a way to do some pre/post processing for each corresponding servlet call (init,destroy and service). I looked at VavleBase and couldn't see any direct comparison. -Thom Craig McClanahan
Re: Catalina vs.preServletInit et. al.
On Fri, 23 Mar 2001, Thom Park wrote: Hmm.. interesting - In my modification(s) I was setting some thread-local objects which were then used by some objects referred to in my servlet. i.e. I was setting a naming-context such that it referred to the naming context that was appropriate for my execution thread. If I register an event-listener - can I be assured that it will run in the same thread as that using the servlet-instance? - in which case I home free. Yes, it currently works that way. And the J2EE RI (which embeds Tomcat 4.0) relies on this, for the same kinds of reasons you are talking about. If not, then one way to solve my problem would be to alter the wrapper class and 'wrap' the points where the servlet init, service and destroy method calls are invoked. Not very pluggable though and involves a nasty hack of the Catalina source. Are there any other alternatives to this? -Thom Just as an aside, Tomcat 4.0 also provides a per-webapp JNDI context containing resources configured in the server.xml file (and optionally referenced in web.xml elements like env-entry and resource-ref). It's pretty straightforward to create your own object factories as well -- you might want to see if leveraging that makes sense for you. Craig
cvs commit: jakarta-tomcat-4.0/lib - New directory
craigmcc01/03/23 17:10:56 jakarta-tomcat-4.0/lib - New directory
cvs commit: jakarta-tomcat-4.0/lib crimson.jar jaxp.jar
craigmcc01/03/23 17:23:23 Modified:.README.txt RELEASE-NOTES-4.0-B2.txt build.bat build.sh Added: lib crimson.jar jaxp.jar Log: Add a special version of the jaxp.jar and crimson.jar files (from JAXP/1.1 final release) that have had the "sealed" attribute removed. These JARs are used for the XML parser that Jasper uses (in directory "jasper"), to avoid "package sealing violation" errors that occurred when the sealed versions were used on JDK 1.3 systems when a web application loaded its own parser from WEB-INF/lib. WARNING: you MUST NOT replace jasper/jaxp.jar and jasper/crimson.jar with versions from a different (even if newer) release of JAXP, unless the "sealed" attribute has been removed from those files. WARNING: The Tomcat 4.0 build process now ignores any JASPER_JAXP_HOME and JASPER_JAXP_PARSER_JAR environment variables you may have set. The scripts are hard coded to use the files in the "lib" directory being checked in with this patch. PR: Bugzilla #1002 Submitted by: [EMAIL PROTECTED] Revision ChangesPath 1.14 +8 -0 jakarta-tomcat-4.0/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/README.txt,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- README.txt2001/03/23 01:12:10 1.13 +++ README.txt2001/03/24 01:23:21 1.14 @@ -266,3 +266,11 @@ JASPER_JAXP_HOME [default: JAXP_HOME] JASPER_JAXP_PARSER_JAR [default: JAXP_PARSER_JAR] + + WARNING: The current build process uses a special copy of the + jaxp.jar and crimson.jar files from JAXP/1.1 (Final) + that has had the "sealed" attribute removed. This works + around "sealing violation" errors that occur when Tomcat 4.0 + is run under JDK 1.3. As a result of this, the + JASPER_JAXP_HOME and JASPER_JAXP_PARSER_JAR environment + variables are currently ignored. 1.2 +15 -19jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt Index: RELEASE-NOTES-4.0-B2.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RELEASE-NOTES-4.0-B2.txt 2001/03/20 04:14:48 1.1 +++ RELEASE-NOTES-4.0-B2.txt 2001/03/24 01:23:21 1.2 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.0-B2.txt,v 1.1 2001/03/20 04:14:48 craigmcc Exp $ +$Id: RELEASE-NOTES-4.0-B2.txt,v 1.2 2001/03/24 01:23:21 craigmcc Exp $ @@ -260,16 +260,9 @@ Previous versions of Tomcat 4.0 exposed the XML parser used by Jasper (the JAXP/1.1 reference implementation) to web applications. This is no longer the case, because Jasper loads its parser with a new class loader instead. +Keep the following points in mind when considering how to use XML parsers +in Tomcat 4.0 and your web applications: -This change was primarily made to deal with "package sealing violation" errors -caused by the fact that the "jaxp.jar" and "crimson.jar" files (supplied with -the JAXP/1.1 release) are sealed. While this change appears to have eliminated -sealing violation problems when running under JDK 1.2, problems have still been -reported under JDK 1.3. - -Until a solution to this problem is implemented, keep the following -information in mind with respect to XML parsers. - * If you wish to make the JAXP/1.1 RI XML parser available to all web applications, simply move the "jaxp.jar" and "crimson.jar" files from the "$TOMCAT_HOME/jasper" directory to the "$TOMCAT_HOME/lib" directory. @@ -284,13 +277,16 @@ be able to utilize JSP pages in XML syntax (which requires a parser that is compatible with JAXP/1.1) until Xerces completely implements this specification. - -* If you wish to include an XML parser (such as Xerces) in the WEB-INF/lib - directory of your web application, you may encounter "package sealing - violation" errors under JDK 1.3. One solution would be to manually modify - the JAXP JAR files (jaxp.jar and crimson.jar) so that they are not sealed - (Remove the "sealed" line from META-INF/MANIFEST.MF and re-JAR the files). - This is being considered as a permanent solution to the sealing problem, - so feedback is requested about successful (or unsuccessful) attempts to - use this approach. +* If you wish to use an XML parser (such as Xerces) in the WEB-INF/lib + directory of your web application, this should now be possible, because + of the modified JAXP 1.1 parser mentioned below. + +WARNING: Tomcat 4.0
RE: Still have XML loading problems
Craig, bear with my ignorance of how Catalina works at this point. I'm assuming that the JSP servlet compiles the 'raw' JSP-XML-Java and then compiles this to a .class file. Why does the Jasper class-loader delegate to the web-apps classloader, isn't the Jasper step entirely independent. If so, couldn't the JSP servlet create its own CL that doesn't delegate to the webapps loader, but delegates straight to the shared classloader. In fact we could take tools.jar off-of the classpath and make it available to this classloader only. So the Jasper CL would pick up tools.jar, crimson.jar and jaxp.jar and everything from my webapp lib and classes, but doesn't delegate to the webapp CL. This should have the effect of making Jasper independent of my webapp CL. The other CLs would work the same. It makes the CL architecture slightly more complicated (but it already is complicated). Will this work? Another thought. If Jasper is a two step process (.jsp-XML, XML-Java) as step 1, java-.class as step 2, only the first step needs an XML parser, can we isolate that first step with a separate CL? Kevin (waiting to be shot down in flames) Jones
Re: trouble compiling mod_jk.so
Hi, Retry with Apache 1.3.14 or 1.3.17 Regards, Kim On Fri, 23 Mar 2001, Jim Yiu wrote: Hi, I am trying to compile the Tomcat-Apache plugin for Solaris and am unsuccessful,, I am trying to follow the mod_jk faq but it does not explain what to do when there are compile errors. For Solaris, there is no binary available and we have to create our own shared object. Here is the problem: after running apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include -I/usr/java/include/solaris -lposix4 -c *.c ../jk/*.c the object files seem to compile fine, and they exist in the directory after compiling, but there seems to be a link error and the ".so" file is never created.. here is the error.. [top snipped] gcc -DSOLARIS2=251 -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -I/d/d1/apache_1.3.12/include -I../jk -I/usr/java/include -I/usr/java/include/solaris -DSOLARIS -c ../jk/jk_util.c gcc -DSOLARIS2=251 -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -I/d/d1/apache_1.3.12/include -I../jk -I/usr/java/include -I/usr/java/include/solaris -DSOLARIS -c ../jk/jk_worker.c -o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_sockbuf.o jk_pool.o jk_nwmain.o jk_msg_buff.o jk_map.o jk_lb_worker.o jk_jni_worker.o jk_connect.o jk_ajp13_worker.o jk_ajp13.o jk_ajp12_worker.o mod_jk.o apxs:Break: Command failed with rc=16711680 I am running the apxs script from within the apache directory [path to apache]/apache/bin and I have Perl 5.004_04 installed, i am using SunOS 5.7 with a SPARC station 20 .. Could someone point out the problem ? Any help is appreciated. Jim
Catalina vs.preServletInit et. al.
Hello, I'm a newbie to the Catalina code line and need some guidance (lots actually)... I have a custom interceptor that works really well with Tomcat 3.x that does some special setup work in the preServletInit/postServletInit, preService/postService and preServletDestroy/postServletDestroy methods of the special RequestInterceptor. My problem is determining functional equivalents to these in Catalina. Can anyone give me any pointers - I sort of lost my way in the source code and documentation (primarily due to existing references to 'interceptors' in both comments and docs.) Is there still a way to do some pre/post processing for each corresponding servlet call (init,destroy and service). I looked at VavleBase and couldn't see any direct comparison. -Thom
trouble compiling mod_jk.so
Hi, I am trying to compile the Tomcat-Apache plugin for Solaris and am unsuccessful,, I am trying to follow the mod_jk faq but it does not explain what to do when there are compile errors. For Solaris, there is no binary available and we have to create our own shared object. Here is the problem: after running apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include -I/usr/java/include/solaris -lposix4 -c *.c ../jk/*.c the object files seem to compile fine, and they exist in the directory after compiling, but there seems to be a link error and the ".so" file is never created.. here is the error.. [top snipped] gcc -DSOLARIS2=251 -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -I/d/d1/apache_1.3.12/include -I../jk -I/usr/java/include -I/usr/java/include/solaris -DSOLARIS -c ../jk/jk_util.c gcc -DSOLARIS2=251 -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -I/d/d1/apache_1.3.12/include -I../jk -I/usr/java/include -I/usr/java/include/solaris -DSOLARIS -c ../jk/jk_worker.c -o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_sockbuf.o jk_pool.o jk_nwmain.o jk_msg_buff.o jk_map.o jk_lb_worker.o jk_jni_worker.o jk_connect.o jk_ajp13_worker.o jk_ajp13.o jk_ajp12_worker.o mod_jk.o apxs:Break: Command failed with rc=16711680 I am running the apxs script from within the apache directory [path to apache]/apache/bin and Ihave Perl 5.004_04 installed, i am using SunOS 5.7 with a SPARC station 20 .. Could someone point out the problem ? Any help is appreciated. Jim
Performance of Tomcat outprocess model
Hi, As per the User Guide the performance of outprocess servlet container is not good. Can any body tell me after for how many clients it is creating problem. Any body developed and tested the application using Apache, Tomcat and JOnAS, whats the performance with this combination. Regards Surendra _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
