Re: [TC4] jakarta-regexp.jar
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: On Thu, Jul 19, 2001 at 10:58:21PM -0700, Craig R. McClanahan wrote: On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: Do you have a position on including a jakarta-regexp.jar (or a jakarta-regexp-1.2.jar or a jakarta-regexp-1.3-dev.jar) directly in jakarta-tomcat-4.0/lib so we can build it without synching and building jakarta-regexp? I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. The dependencies are already there, and always will be. The only difference is that at present, the actual jars can slip out from under you at any time (which actually just happened to me -- while you weren't looking, jakarta-regexp changed the name of their jar file which broke your build). Having seen *way* too many people get burned by loading binaries into CVS (usually caused by API changes in the projects you depend on, plus the resultant inability to reliably recreate an old version from sources), I'm unalterably opposed to putting JAR files into CVS except in extreme circumstances (i.e. sealing violations). People who have known me in open source projects for a while will quickly realize how unusual that position is for me -- about most things I'm much more easygoing. But I will not willingly participate in any project that uses checked in JARs as a standard practice. I've gotten (and seen on others) too many scars from that behavior to find it acceptable. Craig
PATCH - AdaptiveClassLoader.java
Hi,
This is a patch for AdaptiveClassLoader -- it fixes the problem(s) I've
described in my previous post. In short:
The API documentation for java.lang.ClassLoader states that subclasses
of ClassLoader should implement the findResource and findResources
method. I've added these methods to AdaptiveClassLoader, and fixed up
getResource. What happens is that when the final method getResources on
java.lang.ClassLoader is called, (as is the case for
javax.naming.InitialContext when it searches for jndi.properties), it
calls findResources on the current instance of the ClassLoader. Becuase
AdaptiveClassLoader does not override this method, the default
implementation is called, which returns null. With this patch, the web
application classes and lib directory will be searched, as I would
assume correct behaivor to be.
This patch is against the 3.2.3 source tarball I downloaded when it was
first released a couple of days ago.
Also -- as I stated in a previous post there was a patch for this
submitted awhile back, but it did not get committed and I could find no
explanation why. My patch does the same thing, although it is a bit
simplier, and only changes this one file. If this cannot be committed I
would appreciate knowing the reason why, and also would like any
suggestions on what to do with a jndi.properties file in my
WEB-INF/classes directory.
Thanks,
David
--
David Haraburda - [EMAIL PROTECTED]
Everest - Helping You Manage Outsourcing
972-980-0013 x736
--- AdaptiveClassLoader.java.orig Sat Mar 3 21:47:58 2001
+++ AdaptiveClassLoader.javaFri Jul 20 01:31:24 2001
@@ -15,24 +15,24 @@
*
* 3. All advertising materials mentioning features or use of this
*software must display the following acknowledgment:
- *This product includes software developed by the Java Apache
+ *This product includes software developed by the Java Apache
*Project for use in the Apache JServ servlet engine project
*http://java.apache.org/.
*
- * 4. The names Apache JServ, Apache JServ Servlet Engine and
- *Java Apache Project must not be used to endorse or promote products
+ * 4. The names Apache JServ, Apache JServ Servlet Engine and
+ *Java Apache Project must not be used to endorse or promote products
*derived from this software without prior written permission.
*
* 5. Products derived from this software may not be called Apache JServ
- *nor may Apache nor Apache JServ appear in their names without
+ *nor may Apache nor Apache JServ appear in their names without
*prior written permission of the Java Apache Project.
*
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
- *This product includes software developed by the Java Apache
+ *This product includes software developed by the Java Apache
*Project for use in the Apache JServ servlet engine project
*http://java.apache.org/.
- *
+ *
* THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT AS IS AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
@@ -123,7 +123,7 @@
*/
public class AdaptiveClassLoader extends ClassLoader {
private static final int debug=0;
-
+
/**
* Instance of the SecurityManager installed.
*/
@@ -163,7 +163,7 @@
* compatibility, we'll duplicate the 1.2 private member var.
*/
protected ClassLoader parent;
-
+
/**
* Private class used to maintain information about the classes that
* we loaded.
@@ -194,7 +194,7 @@
return origin == null;
}
}
-
+
//--- Constructors
/**
@@ -215,7 +215,7 @@
cache = new Hashtable();
}
-public void setRepository( Vector classRepository )
+public void setRepository( Vector classRepository )
throws IllegalArgumentException
{
// Verify that all the repository are valid.
@@ -275,7 +275,7 @@
void log( String s ) {
System.out.println(AdaptiveClassLoader: + s );
}
-
+
//--- Methods
/**
@@ -326,7 +326,7 @@
return false;
} else {
return (entry.origin.lastModified() != entry.lastModified);
-
+
}
}
@@ -348,7 +348,7 @@
if( debug5 )
log( cache entry: + entry.loadedClass.getName());
if (entry.isSystemClass()) continue;
-
+
// XXX: Because we want the classloader to be an accurate
// reflection of the contents of the repository, we also
// reload if a class origin file is now missing. This
@@ -381,7 +381,7 @@
*/
public AdaptiveClassLoader reinstantiate() {
AdaptiveClassLoader cl=new AdaptiveClassLoader();
- cl.setParent(parent);
+
Re: PATCH - AdaptiveClassLoader.java (oops!)
Oops. Accidentally attached the file with output from multiple runs of
diff: Here is the correct (smaller) patch, with my apologies...
David
--
David Haraburda - [EMAIL PROTECTED]
Everest - Helping You Manage Outsourcing
972-980-0013 x736
--- AdaptiveClassLoader.java.orig Sat Mar 3 21:47:58 2001
+++ AdaptiveClassLoader.javaFri Jul 20 01:34:57 2001
@@ -15,24 +15,24 @@
*
* 3. All advertising materials mentioning features or use of this
*software must display the following acknowledgment:
- *This product includes software developed by the Java Apache
+ *This product includes software developed by the Java Apache
*Project for use in the Apache JServ servlet engine project
*http://java.apache.org/.
*
- * 4. The names Apache JServ, Apache JServ Servlet Engine and
- *Java Apache Project must not be used to endorse or promote products
+ * 4. The names Apache JServ, Apache JServ Servlet Engine and
+ *Java Apache Project must not be used to endorse or promote products
*derived from this software without prior written permission.
*
* 5. Products derived from this software may not be called Apache JServ
- *nor may Apache nor Apache JServ appear in their names without
+ *nor may Apache nor Apache JServ appear in their names without
*prior written permission of the Java Apache Project.
*
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
- *This product includes software developed by the Java Apache
+ *This product includes software developed by the Java Apache
*Project for use in the Apache JServ servlet engine project
*http://java.apache.org/.
- *
+ *
* THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT AS IS AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
@@ -123,7 +123,7 @@
*/
public class AdaptiveClassLoader extends ClassLoader {
private static final int debug=0;
-
+
/**
* Instance of the SecurityManager installed.
*/
@@ -163,7 +163,7 @@
* compatibility, we'll duplicate the 1.2 private member var.
*/
protected ClassLoader parent;
-
+
/**
* Private class used to maintain information about the classes that
* we loaded.
@@ -194,7 +194,7 @@
return origin == null;
}
}
-
+
//--- Constructors
/**
@@ -215,7 +215,7 @@
cache = new Hashtable();
}
-public void setRepository( Vector classRepository )
+public void setRepository( Vector classRepository )
throws IllegalArgumentException
{
// Verify that all the repository are valid.
@@ -275,7 +275,7 @@
void log( String s ) {
System.out.println(AdaptiveClassLoader: + s );
}
-
+
//--- Methods
/**
@@ -326,7 +326,7 @@
return false;
} else {
return (entry.origin.lastModified() != entry.lastModified);
-
+
}
}
@@ -348,7 +348,7 @@
if( debug5 )
log( cache entry: + entry.loadedClass.getName());
if (entry.isSystemClass()) continue;
-
+
// XXX: Because we want the classloader to be an accurate
// reflection of the contents of the repository, we also
// reload if a class origin file is now missing. This
@@ -381,7 +381,7 @@
*/
public AdaptiveClassLoader reinstantiate() {
AdaptiveClassLoader cl=new AdaptiveClassLoader();
- cl.setParent(parent);
+ cl.setParent(parent);
cl.setRepository(repository);
return cl;
}
@@ -435,7 +435,7 @@
if (sm != null) {
int i = name.lastIndexOf('.');
if (i = 0) {
-sm.checkPackageAccess(name.substring(0,i));
+sm.checkPackageAccess(name.substring(0,i));
sm.checkPackageDefinition(name.substring(0,i));
}
}
@@ -502,10 +502,10 @@
classCache.lastModified = classCache.origin.lastModified();
if( debug0) log( Add to cache() + name + + classCache);
cache.put(name, classCache);
-
+
if( debug0) log( Before define class + name);
try {
- classCache.loadedClass =
+ classCache.loadedClass =
doDefineClass(name, classData,
cp.getProtectionDomain());
} catch(Throwable t ) {
@@ -529,7 +529,7 @@
{
return defineClass(name, classData, 0, classData.length);
}
-
+
/**
* Load a class using the system classloader.
*
@@ -782,54 +782,76 @@
}
// Third, check our own
Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)
Bojan Smojver wrote: As for DSO, I'll have to work on that, so probably some time tomorrow (Sydney time). Just did a DSO version and couldn't replicate the problem (BTW, I've recompiled/statically linked Apache and mod_jk again since then and the problem was still there). So, maybe it has to do with statically linking Apache after all... I still have to distribute this DSO version of Apache and mod_jk to some slower machines to see if that makes any difference at all. The machine that didn't produce any errors is a 1 GHz Athlon, so timing issues could have been resolved by brute force, who knows... Is there a recommendation as to the order of loading mod_jk for both statically linked version and the DSO version? Maybe that's important. And just one other observation, I'm also using php4. When statically linked Apache doesn't contain php4 the problem is more difficult to replicate (ie. it only occurs occasionally) which sort of pointed me towards timing issues. But then again, I really don't understand the internals of Apache to say what could be causing this. All suggestions, fixes, resolutions etc. welcome ;-) Bojan
RE: [TC4] jakarta-regexp.jar
on 7/19/01 7:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
P.S. I'd like to propose that jakarta-regexp project name all their
jars jakarta-regexp.jar no matter what version they are. This doesn't
affect the decision here.
-1
Until we have a CJAN, I like version numbers on jar files.
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B6.txt
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: +Tomcat 4.0-beta-6 now includes an updated version of the Java side of the +MOD_WEBAPP connector, used to run Tomcat behind Apache. Binary versions of +the MOD_WEBAPP connector for various platforms will be published (in the same +directory where you downloaded Tomcat-4.0-beta-6 shortly). Windows coming in few days, as someone broke into my apt tonight and stole a couple of PCs and god knows what else... Other OSes, after I get back from the cops (thank god I keep my Macs in by bedroom). Pier (nothing _ever_ goes right)
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ApacheConfig.java
larryi 01/07/20 05:45:20
Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
Log:
Modified handling when forwardAll is true and using JkMount to also include
the context pattern, i.e. /ctx/*. Just /ctx defines an exact match only.
Made noRoot default to true. JkMount doesn't seem to be able to steal
/index.html from Apache, so noRoot=false doesn't completely work with
JkMount which is the default.
Locate with setHandler can get all the requests, but setHandler doesn't
currently work because mod_jk's jk_handler() gets called without a worker
name being set. This means that useJkMount=false and forwardAll=false
shouldn't be used until this is fixed.
Updated the javadoc.
Revision ChangesPath
1.18 +37 -16
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ApacheConfig.java 2001/07/16 00:00:41 1.17
+++ ApacheConfig.java 2001/07/20 12:45:20 1.18
@@ -1,4 +1,4 @@
-/* $Id: ApacheConfig.java,v 1.17 2001/07/16 00:00:41 costin Exp $
+/* $Id: ApacheConfig.java,v 1.18 2001/07/20 12:45:20 larryi Exp $
*
*
* The Apache Software License, Version 1.1
@@ -95,7 +95,7 @@
initialized during startup.
p
This config interceptor is enabled by inserting an ApacheConfig
-element in the b\ContextManager/b tag body inside
+element in the blt;ContextManagergt;/b tag body inside
the server.xml file like so:
pre
* ContextManager ...
@@ -106,26 +106,41 @@
/pre
where ioptions/i can include any of the following attributes:
ul
- libconfighome/b - default parent directory for the following paths.
+ libconfigHome/b - default parent directory for the following paths.
If not set, this defaults to TOMCAT_HOME. Ignored
whenever any of the following paths is absolute.
/li
- libjkconfig/b - path to write apacke mod_jk conf file to. If
+ libjkConfig/b - path to write apacke mod_jk conf file to. If
not set, defaults to
conf/jk/mod_jk.conf./li
- libworkersconfig/b - path to workers.properties file used by
+ libworkersConfig/b - path to workers.properties file used by
mod_jk. If not set, defaults to
conf/jk/workers.properties./li
- libmodjk/b - path to Apache mod_jk plugin file. If not set,
+ libmodJk/b - path to Apache mod_jk plugin file. If not set,
defaults to modules/mod_jk.dll on windows,
modules/mod_jk.nlm on netware, and
libexec/mod_jk.so everywhere else./li
- libjklog/b - path to log file to be used by mod_jk./li
+ libjkLog/b - path to log file to be used by mod_jk./li
+ libforwardAll/b - If true, forward all requests to Tomcat. IF
+ false, let Apache serve static resources.
+ Warning: When false, some configuration in
+ the web.xml may not be duplicated in Apache.
+ Review the mod_jk.conf file to see what
+ configuration is actually being set in Apache./li
+ libuseJkMount/b - If true, use JkMount mount directives. If false,
+ lt;Locationgt; and SetHandler directives are used.
+ the default is true./li
+ libjkDebug/b - JK Loglevel setting. May be debug, info, error, or emerg.
+ If not set, defaults to no log./li
+ libnoRoot/b - If true, the root context is not mapped to
+ Tomcat. If false, Tomcat services all requests
+ to the root context. The default is true.
+ This setting only applies if forwardAll is true./li
/ul
p
@author Costin Manolache
@author Mel Martinez
- @version $Revision: 1.17 $ $Date: 2001/07/16 00:00:41 $
+ @version $Revision: 1.18 $ $Date: 2001/07/20 12:45:20 $
*/
public class ApacheConfig extends BaseInterceptor {
@@ -168,7 +183,7 @@
private String jkDebug=null;
-private boolean noRoot=false;
+private boolean noRoot=true;
// ssl settings
private boolean sslExtract=true;
@@ -230,11 +245,13 @@
}
/** Special option - do
Re: [DOC] TC4 B6
grumble Apologies for whatever funked up attachments got sent. I'm using my university's webmail. - r On Fri, 20 Jul 2001 5:27:58 PDT [EMAIL PROTECTED] wrote: INSTALL is under $CATALINA_HOME/src? Is that the right place for it? =0D Also, here's my take on a reworked ROOT/index.html. I'd like to come up with a common look and feel for the default web-apps...=0D =0D - r=0D
RE: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
Guys, I've copied in an email returned to a support desk regarding a problem similar to this. There is a link to mikal.org that explains it in better detail, but essentially it refers to where your classes are found, as to what classloader they inherit. And the solution we found (similar to the post) is to ensure your classpath is unset before starting Tomcat. Regards, Andrew Mc.Ghee Thanks again for your help on this, Looks like we have tracked down the problem, and it was due to a reference to the Poet SDK on the CLASSPATH. References to Poet code was finding the class instance on the jar file specified within the CLASSPATH itself, and so was not having access to the classloader from tomcat, making anything within webapps/WEB-INF/lib unavailable. We have simply removed the reference to the poet jar files from the classpath, and placed the jar file within the webapps/WEB-INF/lib directory, and voila! (No need to set the database classloader now either) Thanks again for your assistance in this, pointing out the classpath loading help to isolate the problem. A useful link regarding this problem was; http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 (And probably explains the situation far better than I can) -Original Message- -Original Message- From: David Rees [mailto:[EMAIL PROTECTED]] Sent: 19 July 2001 22:27 To: [EMAIL PROTECTED] Subject: Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes (Sorry about the double-qoute, I missed the original message) -Original Message- From: Will England [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 10:49 AM To: [EMAIL PROTECTED] Subject: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes Greetings! Over on tomcat-users, theres been a discussion on JSP's finding the WEB-INF/classes directory when compiling. They can't. From searches, I understand this issue has come up before in regards to the Coocon project. The root problem is that Jasper cannot find classes located in WEB-INF/classes of the web application that the JSP's belong to. This occurs when a JSP is either first deployed or the TOMCAT_HOME/work directory is cleared, requiring a recompile of the JSP's. The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS 2.7 with JDK 1.2. I have noticed the same problem while doing some development using Tomcat 3.2.[23]. I worked around it by making sure that I unset the classpath before calling startup.sh, then things seemed to work properly and classes were found as expected. It seems that certain combinations of classes in different ares (CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't pinned it down, so it could simply be user stupidity. -Dave
[DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
A, maybe I should add this to the INSTALL.txt file - unset your CLASSPATH before starting TC? I've logged into my fair share of *nix boxes where the admins have conveniently set a system-wide CLASSPATH containing an XML parser, etc. - r On Fri, 20 Jul 2001 12:59:01 +0100 [EMAIL PROTECTED] wrote: Guys, I've copied in an email returned to a support desk regarding a problem similar to this. There is a link to mikal.org that explains it in better detail, but essentially it refers to where your classes are found, as to what classloader they inherit. And the solution we found (similar to the post) is to ensure your classpath is unset before starting Tomcat. Regards, Andrew Mc.Ghee Thanks again for your help on this, Looks like we have tracked down the problem, and it was due to a reference to the Poet SDK on the CLASSPATH. References to Poet code was finding the class instance on the jar file specified within the CLASSPATH itself, and so was not having access to the classloader from tomcat, making anything within webapps/WEB-INF/lib unavailable. We have simply removed the reference to the poet jar files from the classpath, and placed the jar file within the webapps/WEB-INF/lib directory, and voila! (No need to set the database classloader now either) Thanks again for your assistance in this, pointing out the classpath loading help to isolate the problem. A useful link regarding this problem was; http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 (And probably explains the situation far better than I can) -Original Message- -Original Message- From: David Rees [mailto:[EMAIL PROTECTED]] Sent: 19 July 2001 22:27 To: [EMAIL PROTECTED] Subject: Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes (Sorry about the double-qoute, I missed the original message) -Original Message- From: Will England [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 10:49 AM To: [EMAIL PROTECTED] Subject: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes Greetings! Over on tomcat-users, theres been a discussion on JSP's finding the WEB-INF/classes directory when compiling. They can't. From searches, I understand this issue has come up before in regards to the Coocon project. The root problem is that Jasper cannot find classes located in WEB-INF/classes of the web application that the JSP's belong to. This occurs when a JSP is either first deployed or the TOMCAT_HOME/work directory is cleared, requiring a recompile of the JSP's. The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS 2.7 with JDK 1.2. I have noticed the same problem while doing some development using Tomcat 3.2.[23]. I worked around it by making sure that I unset the classpath before calling startup.sh, then things seemed to work properly and classes were found as expected. It seems that certain combinations of classes in different ares (CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't pinned it down, so it could simply be user stupidity. -Dave
RE: Problem with mod_jk 1.2.0 (latest CVS snapshot)
Just did a DSO version and couldn't replicate the problem (BTW, I've recompiled/statically linked Apache and mod_jk again since then and the problem was still there). So, maybe it has to do with statically linking Apache after all... Strange problem. What's the difference between static and dynamic. We may have missed something at mod_jk init time ? I still have to distribute this DSO version of Apache and mod_jk to some slower machines to see if that makes any difference at all. The machine that didn't produce any errors is a 1 GHz Athlon, so timing issues could have been resolved by brute force, who knows... Thanks to tell us what happened... Is there a recommendation as to the order of loading mod_jk for both statically linked version and the DSO version? Maybe that's important. I load mod_jk after alias and before rewrite and never get any problems. Not I also use php4 LoadModule mmap_static_module lib/apache/mod_mmap_static.so LoadModule vhost_alias_module lib/apache/mod_vhost_alias.so LoadModule env_module lib/apache/mod_env.so LoadModule define_module lib/apache/mod_define.so LoadModule config_log_module lib/apache/mod_log_config.so LoadModule agent_log_module lib/apache/mod_log_agent.so LoadModule referer_log_module lib/apache/mod_log_referer.so LoadModule mime_magic_module lib/apache/mod_mime_magic.so LoadModule mime_modulelib/apache/mod_mime.so LoadModule negotiation_module lib/apache/mod_negotiation.so LoadModule status_module lib/apache/mod_status.so LoadModule info_modulelib/apache/mod_info.so LoadModule includes_modulelib/apache/mod_include.so LoadModule autoindex_module lib/apache/mod_autoindex.so LoadModule dir_module lib/apache/mod_dir.so LoadModule cgi_module lib/apache/mod_cgi.so LoadModule asis_modulelib/apache/mod_asis.so LoadModule imap_modulelib/apache/mod_imap.so LoadModule action_module lib/apache/mod_actions.so LoadModule speling_module lib/apache/mod_speling.so LoadModule userdir_module lib/apache/mod_userdir.so LoadModule alias_module lib/apache/mod_alias.so LoadModule jk_module lib/apache/mod_jk.so LoadModule auth_ldap_module lib/apache/auth_ldap.so LoadModule rewrite_module lib/apache/mod_rewrite.so LoadModule access_module lib/apache/mod_access.so LoadModule auth_modulelib/apache/mod_auth.so LoadModule anon_auth_module lib/apache/mod_auth_anon.so LoadModule dbm_auth_modulelib/apache/mod_auth_dbm.so LoadModule db_auth_module lib/apache/mod_auth_db.so LoadModule digest_module lib/apache/mod_digest.so LoadModule proxy_module lib/apache/libproxy.so LoadModule cern_meta_module lib/apache/mod_cern_meta.so LoadModule expires_module lib/apache/mod_expires.so LoadModule headers_module lib/apache/mod_headers.so LoadModule usertrack_module lib/apache/mod_usertrack.so LoadModule example_module lib/apache/mod_example.so LoadModule unique_id_module lib/apache/mod_unique_id.so LoadModule setenvif_modulelib/apache/mod_setenvif.so LoadModule php4_modulelib/apache/libphp4.so LoadModule perl_modulelib/apache/libperl.so LoadModule dav_module lib/apache/libdav.so LoadModule gzip_module lib/apache/mod_gzip.so IfDefine SSL LoadModule ssl_module lib/apache/libssl.so /IfDefine ... ClearModuleList AddModule mod_mmap_static.c AddModule mod_vhost_alias.c AddModule mod_env.c AddModule mod_define.c AddModule mod_log_config.c AddModule mod_log_agent.c AddModule mod_log_referer.c AddModule mod_mime_magic.c AddModule mod_mime.c AddModule mod_negotiation.c AddModule mod_status.c AddModule mod_info.c AddModule mod_include.c AddModule mod_autoindex.c AddModule mod_dir.c AddModule mod_cgi.c AddModule mod_asis.c AddModule mod_imap.c AddModule mod_actions.c AddModule mod_speling.c AddModule mod_userdir.c AddModule mod_alias.c AddModule mod_jk.c AddModule auth_ldap.c AddModule mod_rewrite.c AddModule mod_access.c AddModule mod_auth.c AddModule mod_auth_anon.c AddModule mod_auth_dbm.c AddModule mod_auth_db.c AddModule mod_digest.c AddModule mod_proxy.c AddModule mod_cern_meta.c AddModule mod_expires.c AddModule mod_headers.c AddModule mod_usertrack.c AddModule mod_example.c AddModule mod_unique_id.c AddModule mod_so.c AddModule mod_setenvif.c AddModule mod_php4.c AddModule mod_perl.c AddModule mod_dav.c AddModule mod_gzip.c IfDefine SSL AddModule mod_ssl.c /IfDefine
Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
On Thu, 19 Jul 2001, David Rees wrote: (Sorry about the double-qoute, I missed the original message) I have noticed the same problem while doing some development using Tomcat 3.2.[23]. I worked around it by making sure that I unset the classpath before calling startup.sh, then things seemed to work properly and classes were found as expected. Tried that. Tried hard-coding the classpath. If the web applications WEB-INF/classes directory was in the system classpath, it compiles. If it is not in the system classpath, the JSP's do not compile. So, why does Jasper not know about the web-application classpath? Will
RE: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
On Fri, 20 Jul 2001, Andrew McGhee wrote: Guys, I've copied in an email returned to a support desk regarding a problem similar to this. There is a link to mikal.org that explains it in better detail, but essentially it refers to where your classes are found, as to what classloader they inherit. And the solution we found (similar to the post) is to ensure your classpath is unset before starting Tomcat. The solution posted (unset your classpath, cause there might be a class with the same name somewhere else) is fine for first year university students. Most likely, that *is* what causes their problems. grin But, I have set, unset, hard coded, soft coded and so on the classpath. In tomcat.sh, I have a hard-coded classpath pointing to the .jar files in TOMCAT_HOME/lib, and tools.jar. Nothing else. I try to hit a JSP for the first time, the compile fails. Jasper reports that it cannot find classes that are located in the web applications WEB-INF/classes directory. Theoretically, the adaptive classloader should know about WEB-INF/classes, and I thought Jaspter used the adaptive classloader. If I change the hard-coded classpath in tomcat.sh to point to the web applications WEB-INF/classes directory, so that the WEB-INF/classes folder is in the system classpath, Jasper can now find the classes and compilation continues normally. Can one of the developers detail out where Jasper looks for classes for compiling JSPs? Thanks for any tips or suggestions! Will
Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
Oops, That's right, you can read any file you want from WEB-INF/classes using getResource() (which is probably what you are doing) -- that is implemented correctly in AdaptiveClassLoader. If you want to find all resources of a specified name (for example, you have a properties file of the same name at the web-application level and the system level, and you want to concatenate values from both places together), the ClassLoader class provides a getResources() method. (This method in turn calls findResources which is supposed to be implemented in all subclasses of ClassLoader, but isn't for AdaptiveClassLoader) I'm glad to know that fixed it. David Will England wrote: On Fri, 20 Jul 2001, David Haraburda wrote: Have you tried using the Jdk12Interceptor? That fixed class loading problems for me. In your server.xml do: RequestInterceptor className=org.apache.tomcat.request.Jdk12Interceptor/ Got that, and it fixed the finding of my .conf files that I store in WEB-INF/classes. I can now read any text file I want from WEB-INF/classes from a servlet. Note this will only fix the loading of CLASSES... if you have resources in your WEB-INF/classes directory, such as .properties files, that the ClassLoader is supposed to pick up, this will not happen. I submitted a patch for this to the mailing list last night, but haven't heard anything from a developer/committer yet. Odd. Worked well for me. As soon as the admin gets the box back up, I'll drop you a copy of my server.xml and the code I use to read a text file. A good way to see what ClassLoader is being used is by sticking in a System.out.println( CL: + Thread.currentThread().getContextClassLoader().toString() ); If it says com.sun.misc.something (I forget the package name), you are using the System classloader... if it says AdaptiveClassLoader, you are using the Tomcat one which knows about stuff in the WEB-INF directory. Nice tip - I'll try that! Will
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.h
mmanders01/07/20 08:09:48 Modified:jk/native/common jk_ajp14_worker.h Log: Added a define for snprintf under Windows. Revision ChangesPath 1.4 +6 -1 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h Index: jk_ajp14_worker.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jk_ajp14_worker.h 2001/06/18 14:15:28 1.3 +++ jk_ajp14_worker.h 2001/07/20 15:09:48 1.4 @@ -58,7 +58,7 @@ /*** * Description: ajpv14 worker header file * * Author: Henri Gomez [EMAIL PROTECTED] * - * Version: $Revision: 1.3 $ * + * Version: $Revision: 1.4 $ * ***/ #ifndef JK_AJP14_WORKER_H @@ -79,6 +79,11 @@ #endif /* __cplusplus */ #define JK_AJP14_WORKER_NAME (ajp14) + +#ifdef WIN32 +/* define snprint to match windows version */ +#define snprintf _snprintf +#endif int JK_METHOD ajp14_worker_factory(jk_worker_t **w, const char *name,
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.dsp
mmanders01/07/20 08:10:26 Modified:jk/native/apache-1.3 mod_jk.dsp Log: Fixed project so that MSDev can use it. Revision ChangesPath 1.5 +10 -10jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp Index: mod_jk.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- mod_jk.dsp2001/06/07 13:48:45 1.4 +++ mod_jk.dsp2001/07/20 15:10:26 1.5 @@ -146,23 +146,23 @@ SOURCE=.\mod_jk.c # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp14.c # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp14_worker.c # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_md5.c # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_context.c # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp_common.c # End Source File @@ -243,23 +243,23 @@ SOURCE=..\common\jk_worker_list.h # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp14.h # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp14_worker.h # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_md5.h # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_context.h # End Source File -# End Group +# Begin Source File SOURCE=..\common\jk_ajp_common.h # End Source File
Re: [TC4] jakarta-regexp.jar
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Yes, these are all possible solutions, but I'd prefer it if there
weren't a problem in the first place. Easily editing a file or
making a symlink is one more step that a local user can mess up.
(user = developer, I know, but it's an open source project; it should
be as simple as possible for people to fix bugs etc.)
Anyway, nevermind. I see I'm not going to make headway here. :-)
- A
--
Alex Chaffee mailto:[EMAIL PROTECTED]
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
jakarta-watchdog-4.0
Hi, The build complains for: [copydir] DEPRECATED - The copydir task is deprecated. Use copy instead., I should fix it? Cheers Jean-frederic
RE: problem with mod_webapp on rh7.1
hi craig, the newest CVS files compilation seems to work properly, without having defined any WebAppDeploy's - thx so far! but having definded the following in the httpd.conf of apache1.3: # 4 tomcat LoadModule webapp_module /etc/httpd/modules/mod_webapp.so AddModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppDeploy jetspeed warpConnection /jetspeed/ this error occured: Starting httpd: Syntax error on line 7 of /etc/httpd/conf/httpd.conf: Invalid virtual host name [FAILED] any idea? cu, michael. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 19. Juli 2001 17:41 To: Michael Steindl Subject: Re: problem with mod_webapp on rh7.1 Recent versions from the jakarta-tomcat-connectors CVS repository have worked for me. Can you give them a try? Craig On Thu, 19 Jul 2001, Michael Steindl wrote: hi craig, having the same problem than you've posted with mod_webapp/tomcat4.0b5/apache1.3/rh7.1 do you have any solution until now? would be great to get a working mod_webapp module. cheers and thx, michael.
Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote: A, maybe I should add this to the INSTALL.txt file - unset your CLASSPATH before starting TC? I've logged into my fair share of *nix boxes where the admins have conveniently set a system-wide CLASSPATH containing an XML parser, etc. I think it's the safe thing to do. I think Tomcat 3.3 and Tomcat 4 both do this by default. For Tomcat 3.2.X, I do this in custom startup scripts which make startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per host. I also modify bin/tomcat.sh to redirect stdout/err to log files instead of cluttering the terminal. If anyone is interested, I can send copies of the scripts and the patch to tomcat.sh... I would at least like to see the stdout/err patch integrated into Tomcat, I just don't know if there's much interest in including it into Tomcat 3.2. -Dave
Re: problem with mod_webapp on rh7.1
Make sure ServerName is configured prior to the mod_webapp config statements in httpd.conf. On Fri, Jul 20, 2001 at 12:30:49PM +0200, Michael Steindl wrote: hi craig, the newest CVS files compilation seems to work properly, without having defined any WebAppDeploy's - thx so far! but having definded the following in the httpd.conf of apache1.3: # 4 tomcat LoadModule webapp_module /etc/httpd/modules/mod_webapp.so AddModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppDeploy jetspeed warpConnection /jetspeed/ this error occured: Starting httpd: Syntax error on line 7 of /etc/httpd/conf/httpd.conf: Invalid virtual host name [FAILED] any idea? cu, michael. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 19. Juli 2001 17:41 To: Michael Steindl Subject: Re: problem with mod_webapp on rh7.1 Recent versions from the jakarta-tomcat-connectors CVS repository have worked for me. Can you give them a try? Craig On Thu, 19 Jul 2001, Michael Steindl wrote: hi craig, having the same problem than you've posted with mod_webapp/tomcat4.0b5/apache1.3/rh7.1 do you have any solution until now? would be great to get a working mod_webapp module. cheers and thx, michael. -- Eric L. Anderson [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionId.java
larryi 01/07/20 10:42:47
Modified:src/share/org/apache/tomcat/modules/session SessionId.java
Log:
req.unparsedURI may be unset. Fix NPE.
Revision ChangesPath
1.12 +7 -5
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java
Index: SessionId.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SessionId.java2001/07/18 21:06:38 1.11
+++ SessionId.java2001/07/20 17:42:47 1.12
@@ -139,11 +139,13 @@
// rewrite URL, do I need to do anything more?
request.requestURI().setString(uri.substring(0, foundAt));
-// remove from unparsedURI too, if not already
-foundAt = request.unparsedURI().indexOf(sig);
-if (foundAt!=-1) {
-uri=request.unparsedURI().toString();
-request.unparsedURI().setString(uri.substring(0, foundAt));
+// remove from unparsedURI too, if necessary
+if( !request.unparsedURI().isNull() ) {
+foundAt = request.unparsedURI().indexOf(sig);
+if (foundAt!=-1) {
+uri=request.unparsedURI().toString();
+request.unparsedURI().setString(uri.substring(0, foundAt));
+}
}
// No validate now - we just note that this is what the user
Post B6 modifications...
This is the first set of modifications I made to the Catalina code to allow
port 1024 binding under Unix. Basically, I added an initialize() method
to Server, Service and Connector, and that gets called appropriately before
start(). Now, the only thing left to do is to move the ServerSocket
creation within connectors in initialize(), and launch Catalina with a
wrapper around the Service code I committed last week.
Basically, during load() in service, we build the whole components tree
and call initialize() on the Server. Then during start() and stop() we
call the same methods in Server, and (in theory) the trick should be done.
I'd need to modify Remy's BootstrapService and CatalinaService to perform a
two-stage initialization process (and I don't know what JavaService, the one
he's using under Windows does), but, more or less, that should be it...
This patch actually starts fixing things, but doesn't break the build
neither compromises functionality (checked it already), but I would like
someone (Craig/Remy/Amy/Glenn...) to review it and, if ok, apply it...
Cheers...
Pier (back from the cops)
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
retrieving revision 1.5
diff -c -3 -r1.5 Connector.java
*** Connector.java 2001/05/09 23:42:07 1.5
--- Connector.java 2001/07/20 17:38:25
***
*** 240,244
--- 240,252
*/
public Response createResponse();
+ /**
+ * Invoke a pre-startup initialization. This is used to allow connectors
+ * to bind to restricted ports under Unix operating environments.
+ *
+ * @exception LifecycleException If this server was already initialized.
+ */
+ public void initialize()
+ throws LifecycleException;
}
Index: Server.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java,v
retrieving revision 1.2
diff -c -3 -r1.2 Server.java
*** Server.java 2000/09/30 19:15:43 1.2
--- Server.java 2001/07/20 17:38:25
***
*** 163,167
*/
public void removeService(Service service);
!
}
--- 163,174
*/
public void removeService(Service service);
! /**
! * Invoke a pre-startup initialization. This is used to allow connectors
! * to bind to restricted ports under Unix operating environments.
! *
! * @exception LifecycleException If this server was already initialized.
! */
! public void initialize()
! throws LifecycleException;
}
Index: Service.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Service.java,v
retrieving revision 1.2
diff -c -3 -r1.2 Service.java
*** Service.java2000/12/14 02:56:13 1.2
--- Service.java2001/07/20 17:38:25
***
*** 150,154
--- 150,162
*/
public void removeConnector(Connector connector);
+ /**
+ * Invoke a pre-startup initialization. This is used to allow connectors
+ * to bind to restricted ports under Unix operating environments.
+ *
+ * @exception LifecycleException If this server was already initialized.
+ */
+ public void initialize()
+ throws LifecycleException;
}
Index: connector/http/HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
retrieving revision 1.18
diff -c -3 -r1.18 HttpConnector.java
*** connector/http/HttpConnector.java 2001/07/10 07:36:42 1.18
--- connector/http/HttpConnector.java 2001/07/20 17:38:26
***
*** 258,263
--- 258,269
/**
+ * Has this component been initialized yet?
+ */
+ private boolean initialized = false;
+
+
+ /**
* Has this component been started yet?
*/
private boolean started = false;
***
*** 1055,1060
--- 1061,1079
lifecycle.removeLifecycleListener(listener);
+ }
+
+
+ /**
+ * Initialize this connector (create ServerSocket here!)
+ */
+ public void initialize()
+ throws LifecycleException {
+ if (initialized)
+ throw new LifecycleException (
+ sm.getString(httpConnector.alreadyInitialized));
+ this.initialized=true;
+ System.err.println(HTTP Connector initialized);
}
Index: connector/http/LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/LocalStrings.properties,v
retrieving revision 1.3
diff -c -3 -r1.3
Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
I don't think unsetting your CLASSPATH is necessary, especially since other applications may rely on it. I would guess that most problems occur when: 1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them to be loaded by the system class loader, not the Tomcat web app class loader, which causes problems) or, as the case would appear to be with the POET sdk referred to before, 2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib directory, but unbeknownst to you, there is actually another JAR (perhaps an older version of the software) sitting in your classpath, which gets loaded first. Remember, a classloader always asks it's parent classloader to load a resource first, and then only loads it itself if the parent cannot find it. Just make sure things your web application requires are in your WEB-INF/libs directory, and not in your classpath. Craig McClanahan has two good posts about this: http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 http://mikal.org/interests/java/tomcat/archive/view?mesg=8512 As far as logging goes, you may want to check out the Logger elements is your server.xml file. They provide a good way to keep your terminal un-cluttered. :-) David David Rees wrote: On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote: A, maybe I should add this to the INSTALL.txt file - unset your CLASSPATH before starting TC? I've logged into my fair share of *nix boxes where the admins have conveniently set a system-wide CLASSPATH containing an XML parser, etc. I think it's the safe thing to do. I think Tomcat 3.3 and Tomcat 4 both do this by default. For Tomcat 3.2.X, I do this in custom startup scripts which make startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per host. I also modify bin/tomcat.sh to redirect stdout/err to log files instead of cluttering the terminal. If anyone is interested, I can send copies of the scripts and the patch to tomcat.sh... I would at least like to see the stdout/err patch integrated into Tomcat, I just don't know if there's much interest in including it into Tomcat 3.2. -Dave
Re: jakarta-watchdog-4.0
I'm going to take a pass through all the build stuff for jakarta-tomcat-4.0, jakarta-servletapi-4, and jakarta-watchdog-4.0 in the next couple of days. I'll incorporate appropriate stuff from your READMEs as well. Craig On Fri, 20 Jul 2001, jean-frederic clere wrote: Hi, The build complains for: [copydir] DEPRECATED - The copydir task is deprecated. Use copy instead., I should fix it? Cheers Jean-frederic
cvs commit: jakarta-tomcat/src/doc readme
larryi 01/07/20 11:42:33 Modified:src/doc readme Log: Update some information on the connector interceptors. Revision ChangesPath 1.17 +7 -4 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- readme2001/07/19 20:20:10 1.16 +++ readme2001/07/20 18:42:33 1.17 @@ -1,4 +1,4 @@ -$Id: readme,v 1.16 2001/07/19 20:20:10 larryi Exp $ +$Id: readme,v 1.17 2001/07/20 18:42:33 larryi Exp $ Release Notes for: @@ -99,9 +99,12 @@ Conf file:conf/jk/obj.conf-auto Workers file:conf/jk/workers.properties - Note: The old organization used in Tomcat 3.2 where all the configuration is - placed in server.xml is still supported by Tomcat 3.3b1 for Apache. However, - you will need to set the appropriate parameters on the interceptor. + Note: The ApacheConfig, JservConfig, and IISConfig by default write a + config file that tries to send all requests for a context to Tomcat. That + is the best way to insure that behavior specified in the web application's + web.xml functions properly. If you desire, you can copy the auto generated + file and modify it to have the web server serve some of the web application's + resources. - Tomcat Testing:
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ApacheConfig.java
costin 01/07/20 11:46:04
Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
Log:
Remove the SetHandler option.
This is new code, and will probably be available with all the new
features and ajp14 as part of j-t-c.
There is no need to put it into the official 3.3 beta/release - people
who need this feature will be better served by a standalone module, as
this is likely to evolve in the future ( as oposed to the 3.3 main codebase,
which is supposed to remain freezed - so we can focus on features and modules
knowing the base is stable and it's not going to change )
The current autoconfiguration mechanism in 3.3 ( using JkMount ) should work
as well ( or better ) than before, with either the old mod_jk or the new
one.
Revision ChangesPath
1.19 +10 -36
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ApacheConfig.java 2001/07/20 12:45:20 1.18
+++ ApacheConfig.java 2001/07/20 18:46:04 1.19
@@ -1,4 +1,4 @@
-/* $Id: ApacheConfig.java,v 1.18 2001/07/20 12:45:20 larryi Exp $
+/* $Id: ApacheConfig.java,v 1.19 2001/07/20 18:46:04 costin Exp $
*
*
* The Apache Software License, Version 1.1
@@ -127,9 +127,6 @@
the web.xml may not be duplicated in Apache.
Review the mod_jk.conf file to see what
configuration is actually being set in Apache./li
- libuseJkMount/b - If true, use JkMount mount directives. If false,
- lt;Locationgt; and SetHandler directives are used.
- the default is true./li
libjkDebug/b - JK Loglevel setting. May be debug, info, error, or emerg.
If not set, defaults to no log./li
libnoRoot/b - If true, the root context is not mapped to
@@ -140,7 +137,7 @@
p
@author Costin Manolache
@author Mel Martinez
- @version $Revision: 1.18 $ $Date: 2001/07/20 12:45:20 $
+ @version $Revision: 1.19 $ $Date: 2001/07/20 18:46:04 $
*/
public class ApacheConfig extends BaseInterceptor {
@@ -237,13 +234,6 @@
forwardAll=b;
}
-/** Use JkMount directives ( default ) or Location
- and SetHandler ( if false )
-*/
-public void setUseJkMount( boolean b ) {
- useJkMount=b;
-}
-
/** Special option - do not generate mappings for the ROOT
context. The default is true, and will not generate the mappings,
not redirecting all pages to tomcat (since /* matches everything).
@@ -579,17 +569,11 @@
log(Ignoring root context in mount-all mode );
return true;
}
- if( useJkMount ) {
- mod_jk.println(indent + JkMount + nPath + + jkProto );
-if( .equals(ctxPath) )
-mod_jk.println(indent + JkMount + nPath + * + jkProto );
-else
-mod_jk.println(indent + JkMount + nPath + /* + jkProto );
- } else {
- mod_jk.println(indent + Location \ + nPath + \);
- mod_jk.println(indent + SetHandler jakarta-servlet);
- mod_jk.println(indent + /Location);
- }
+ mod_jk.println(indent + JkMount + nPath + + jkProto );
+ if( .equals(ctxPath) )
+ mod_jk.println(indent + JkMount + nPath + * + jkProto );
+ else
+ mod_jk.println(indent + JkMount + nPath + /* + jkProto );
if( vhost != null ) {
mod_jk.println(/VirtualHost);
indent=;
@@ -685,25 +669,15 @@
private boolean addExtensionMapping( String ctxPath, String ext,
PrintWriter mod_jk )
{
- mod_jk.println(indent + LocationMatch + ctxPath + /(.*/)*.*\\. +
-ext + );
- mod_jk.println(indent + SetHandler jakarta-servlet );
- mod_jk.println(indent + /LocationMatch);
+ mod_jk.println(indent + JkMount + ctxPath + /*. + ext
++ + jkProto);
return true;
}
private boolean addMapping( String fullPath, PrintWriter mod_jk ) {
log( Adding map for + fullPath );
- if( useJkMount ) {
- mod_jk.println(indent + JkMount + fullPath ++ jkProto );
- } else {
- mod_jk.println(indent + Location + fullPath + );
- mod_jk.println(indent + SetHandler jakarta-servlet );
- // XXX Other nice things like setting servlet and other
Re: [TC4] jakarta-regexp.jar
[EMAIL PROTECTED] wrote:
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Yes, these are all possible solutions, but I'd prefer it if there
weren't a problem in the first place. Easily editing a file or
making a symlink is one more step that a local user can mess up.
(user = developer, I know, but it's an open source project; it should
be as simple as possible for people to fix bugs etc.)
Anyway, nevermind. I see I'm not going to make headway here. :-)
-1 For putting jar files in cvs ;-)
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
RE: sun.tools.javac.Main will be removed from JDK1.4
Over in HP middleware, we're not to happy with this development either our JSP implementation will suffer for the same reasons Jasper will We can work with an external compiler, but for speed, we much prefer sun.tool.javac.Main. Tim Julien HP Middleware -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 1:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: sun.tools.javac.Main will be removed from JDK1.4 There are some pretty intense discussions going on about this, and the story hasn't yet been finished ... On the other hand, the new compiler entry point has an absolutely horrible feature (from the point of view of Jasper) -- you have to modify System.out and System.err to redirect the compiler output. Unless system variables are unique per classloader (they weren't last time I checked), that means we can only do one compile at a time :-(. An additional note of interest to Ant developers - there is evidence that running the compiler (either old or new) leaves a fair amount of cruft lying around in static variables, after the compile has completed. The recommended solution is to load the compiler itself in its own class loader, so that you can throw it all away afterwards. That's the approach we'll take when modifying Jasper. Craig On Fri, 20 Jul 2001, Sam Ruby wrote: FYI. Bye bye classic compiler. Ant looks safe (it uses reflection), but Jasper looks like it will be affected. - Sam Ruby -- Forwarded by Sam Ruby/Raleigh/IBM on 07/20/2001 07:30 AM --- Davanum Srinivas [EMAIL PROTECTED] on 07/20/2001 06:16:57 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: sun.tools.javac.Main will be removed from JDK1.4 FYI, -Original Message- From: Leclair, Donald Sent: Thursday, July 19, 2001 7:15 PM To: J2EE Communications Subject: Message 14: Class change impact Sent: Thursday, July 19, 2001 7:08 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Class change impact Dear Licensee, The Java(TM) 2 Platform, Standard Edition team will be making a change that might impact you. The change is that the class sun.tools.javac.Main (used for compiling java classes) will be removed in J2SE 1.4. This is not a public API change. If you depend on this class you may be impacted. If you have questions, please follow-up with your designated Licensee Engineer. Regards, Jill Smith Java Partner Engineering = Davanum Srinivas, JNI-FAQ Manager http://www.jGuru.com/faq/JNI __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [TC4] jakarta-regexp.jar
on 7/19/01 10:58 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. In the case of Catalina, I'm against it since you have setup a system of defining things in the build.properties file and requiring people to already download a ton of other stuff anyway. The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: [TC4] jakarta-regexp.jar
on 7/20/01 1:29 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: Why could still use symlink as I do in my RPM :) ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar Doesn't work on winblows. -jon
Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B6.txt
on 7/20/01 1:36 AM, Pier P. Fumagalli [EMAIL PROTECTED] wrote: Windows coming in few days, as someone broke into my apt tonight and stole a couple of PCs and god knows what else... Other OSes, after I get back from the cops (thank god I keep my Macs in by bedroom). Pier (nothing _ever_ goes right) Oh my god! That sucks! I'm sorry Pier!!! -jon
Re: sun.tools.javac.Main will be removed from JDK1.4
JULIEN,TIMOTHY (HP-NewJersey,ex2) at [EMAIL PROTECTED] wrote: Over in HP middleware, we're not to happy with this development either our JSP implementation will suffer for the same reasons Jasper will We can work with an external compiler, but for speed, we much prefer sun.tool.javac.Main. That's why probably TWO MONTHS ago I encouraged this mailing list to put someone on the javax-compiler group at Yahoo. But apparently no one cared :) Pier
RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released
Have I done something wrong or do the directory listing still read Apache Tomcat/4.0-b5? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 12:21 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released The Tomcat team is proud to announce the availability of the latest beta release of Tomcat 4.0. This next-generation servlet and JSP container boasts the following new and improved features: * Fix for the security vulnerability reported on July 16, 2001. * Support for the Proposed Final Draft 3 versions of the Servlet 2.3 and JSP 1.2 Specifications. * Many bug fixes and performance improvements. * Support for executing external CGI scripts and programs. * An updated version of the Apache web connector (binaries for various platforms will be available soon) * A new experimental installer for the Windows platform that lets you download and install Tomcat 4.0 in a manner typical of other Windows based programs (including installation of Tomcat as an NT service). Binary distributions of Tomcat 4.0-beta-6 are available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/ and source distributions are available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/ Please see the included RELEASE-NOTES-4.0-B6.txt file for details about the changes included in this release. Craig McClanahan
RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released
NEVER MIND I just need to recompile my applications. -Original Message- From: Ken Torimaru [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 1:49 PM To: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released Have I done something wrong or do the directory listing still read Apache Tomcat/4.0-b5? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 12:21 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released The Tomcat team is proud to announce the availability of the latest beta release of Tomcat 4.0. This next-generation servlet and JSP container boasts the following new and improved features: * Fix for the security vulnerability reported on July 16, 2001. * Support for the Proposed Final Draft 3 versions of the Servlet 2.3 and JSP 1.2 Specifications. * Many bug fixes and performance improvements. * Support for executing external CGI scripts and programs. * An updated version of the Apache web connector (binaries for various platforms will be available soon) * A new experimental installer for the Windows platform that lets you download and install Tomcat 4.0 in a manner typical of other Windows based programs (including installation of Tomcat as an NT service). Binary distributions of Tomcat 4.0-beta-6 are available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/ and source distributions are available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/ Please see the included RELEASE-NOTES-4.0-B6.txt file for details about the changes included in this release. Craig McClanahan
cvs commit: jakarta-tomcat-4.0 build.xml
jon 01/07/20 14:46:32 Modified:.build.xml Log: added some echo statements for my own amusement. Revision ChangesPath 1.30 +3 -0 jakarta-tomcat-4.0/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- build.xml 2001/07/18 18:32:49 1.29 +++ build.xml 2001/07/20 21:46:32 1.30 @@ -33,8 +33,11 @@ !-- == DEPLOY: Deploy Components === -- target name=deploy-main depends=deploy-static +echoTarget: Catalina - Deploy.../echo ant dir=./catalina target=deploy/ +echoTarget: Jasper - Deploy.../echo ant dir=./jasper target=deploy/ +echoTarget: Webapps - Deploy.../echo ant dir=./webapps target=deploy/ /target
t4 - jasper go boo boo
I just did a fresh cvs update, ant clean, ant and I get this... -jon [176][ ~/checkout/jakarta-tomcat-4.0 ]% ant clean Buildfile: build.xml clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: BUILD SUCCESSFUL Total time: 2 seconds [177][ ~/checkout/jakarta-tomcat-4.0 ]% ant Buildfile: build.xml deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build deploy-static: deploy-main: [echo] Target: Catalina - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/b in [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c lasses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c onf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/l ib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-static: [copy] Copying 9 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-main: [javac] Compiling 278 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [copy] Copying 26 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/ build/classes [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ bin/bootstrap.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/naming.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/resources.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ lib/namingfactory.jar deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/logs [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/work deploy-static: [copy] Copying 10 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [copy] Copying 4 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/comm on/lib [copy] Copying 3 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/serv er/lib deploy-main: [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/catalina.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/warp.jar deploy: [echo] Target: Jasper - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/cla sses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil d/lib build-static: [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/jasper/bui ld/bin [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil d/lib build-main: [javac] Compiling 91 source files to /Users/jon/checkout/jakarta-tomcat-4.0/ jasper/build/classes [javac] [javac] Found 2 semantic errors compiling /Users/jon/checkout/jakarta-tomca t-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java : [javac] [javac]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
mmanders01/07/20 15:08:16 Modified:src/share/org/apache/tomcat/modules/server Ajp13.java Log: When calling setUserPrincipal, use the RemoteUser we just read instead of reading the next string in the message. Otherwise, we through the message/protocol off. Revision ChangesPath 1.21 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java Index: Ajp13.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- Ajp13.java2001/07/17 04:06:29 1.20 +++ Ajp13.java2001/07/20 22:08:16 1.21 @@ -330,7 +330,7 @@ req.setRemoteUser( msg.getString()); // XXX recycle ? // Note that roles are not integrated with apache - req.setUserPrincipal( new SimplePrincipal( msg.getString())); + req.setUserPrincipal( new SimplePrincipal( req.getRemoteUser() )); break; case SC_A_AUTH_TYPE:
RE: t4 - jasper go boo boo
you need a new servlet.jar. update and build jakarta-servletapi-4. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 4:50 PM To: tomcat-dev Subject: t4 - jasper go boo boo I just did a fresh cvs update, ant clean, ant and I get this... -jon [176][ ~/checkout/jakarta-tomcat-4.0 ]% ant clean Buildfile: build.xml clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: BUILD SUCCESSFUL Total time: 2 seconds [177][ ~/checkout/jakarta-tomcat-4.0 ]% ant Buildfile: build.xml deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build deploy-static: deploy-main: [echo] Target: Catalina - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/b in [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c lasses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c onf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/l ib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-static: [copy] Copying 9 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-main: [javac] Compiling 278 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [copy] Copying 26 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/ build/classes [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ bin/bootstrap.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/naming.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/resources.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ lib/namingfactory.jar deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/logs [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/work deploy-static: [copy] Copying 10 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [copy] Copying 4 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/comm on/lib [copy] Copying 3 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/serv er/lib deploy-main: [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/catalina.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/warp.jar deploy: [echo] Target: Jasper - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/cla sses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil d/lib build-static: [copy] Copying 5 files to
Re: t4 - jasper go boo boo
on 7/20/01 3:13 PM, Kevin Seguin [EMAIL PROTECTED] wrote: you need a new servlet.jar. update and build jakarta-servletapi-4. Ok...cool... Fyi...i'm getting these javadoc errors when building it... [javadoc] javadoc: warning - Tag @see: Class or Package not found: java.io.Buf feredWriter [javadoc] javadoc: warning - Tag @see: Class or Package not found: java.lang.I nteger#toString(int) [javadoc] javadoc: warning - Tag @see: Class or Package not found: java.lang.L ong#toString(long) [javadoc] javadoc: warning - Tag @see: Class or Package not found: java.lang.F loat#toString(float) [javadoc] javadoc: warning - Tag @see: Class or Package not found: java.lang.D ouble#toString(double) -jon
Re: sun.tools.javac.Main will be removed from JDK1.4
JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote: Over in HP middleware, we're not to happy with this development either our JSP implementation will suffer for the same reasons Jasper will We can work with an external compiler, but for speed, we much prefer sun.tool.javac.Main. Just a question to satisfy my own curiosity (and possibly point out my compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation [since I don't do JSP]). You mention speed being the primary factor in using the Main compiler. Since Jikes is infinitely faster than javac (which I assume is derived from or otherwise related to Main), I have two questions. 1) Is it possible to even use Jikes in a JSP-compilation module, or are there technical issues which make it difficult to incorporate in a JSP environment? 2) If it is not a JSP-specific issue, then I assume that the problem is due to Jikes not exposing some kind of API that can be imported and/or called from Java classes, and that it would therefore require the invokation of a separate external process (which is of course out of the question). Is that the case? Again, I have very little knowledge of programatic compilation in Java, so I am just asking out of wild curiousity. It's an interesting problem. Regards, Christopher
Re: sun.tools.javac.Main will be removed from JDK1.4
on 7/20/01 3:45 PM, Christopher Cain [EMAIL PROTECTED] wrote: Just a question to satisfy my own curiosity (and possibly point out my compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation [since I don't do JSP]). You mention speed being the primary factor in using the Main compiler. Since Jikes is infinitely faster than javac (which I assume is derived from or otherwise related to Main), I have two questions. 1) Is it possible to even use Jikes in a JSP-compilation module, or are there technical issues which make it difficult to incorporate in a JSP environment? 2) If it is not a JSP-specific issue, then I assume that the problem is due to Jikes not exposing some kind of API that can be imported and/or called from Java classes, and that it would therefore require the invokation of a separate external process (which is of course out of the question). Is that the case? Jikes works fine. The issue is that Jikes is a C++ binary and isn't ported to every platform. It also makes installation/distribution issues a bit more tricky than simply calling a Java class file... The real solution is to get Sun to get off their high horse and OSS the javac compiler and/or not do stupid things like remove something that tons of people depend on and not give an alternative way to do things. -jon
Re: sun.tools.javac.Main will be removed from JDK1.4
Jon Stevens wrote: Time to drop Javac and just use Jikes... LOL! I hadn't even read this one when I (just now) asked my why not just go with Jikes question. I've started noticing that Jon and I think alot alike, from HTML-formatted e-mail to documention approaches to JSP to compiler technologies ... and I'm not entirely sure how I feel about that. It's an odd combination of intellectual validation ... and a vague sense of horror ;-) (j/k) Oh well, it's funner to fight with someone who's brilliant anyway. You can be the Moriarty to my Holmes =) - Christopher
Re: [TC4] jakarta-regexp.jar
On Fri, 20 Jul 2001, Jon Stevens wrote: The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: [TC4] jakarta-regexp.jar
On Fri, 20 Jul 2001, Jon Stevens wrote: on 7/19/01 10:58 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. In the case of Catalina, I'm against it since you have setup a system of defining things in the build.properties file and requiring people to already download a ton of other stuff anyway. The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Yep. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg That's why I even autographed it for you :-) -jon Craig
Re: sun.tools.javac.Main will be removed from JDK1.4
Jon Stevens wrote: Jikes works fine. The issue is that Jikes is a C++ binary and isn't ported to every platform. Oh yeah ... =) It also makes installation/distribution issues a bit more tricky than simply calling a Java class file... Yep. I figured the issue was that it would require an external process. Damn! The real solution is to get Sun to get off their high horse and OSS the javac compiler and/or not do stupid things like remove something that tons of people depend on and not give an alternative way to do things. Granted, I'm a Jikes butt-boy, but what I would really love to see is a Java port of it rather than a new OSS project based on the javac code. I'm actually not sure what the license on Jikes looks like, but if it's a GPL-type license then of course it might be a bit of a bundling problem. *Quickly ducks the the flames of the GPL-pro camp* One other thing, just to (slightly) defend Sun here. They have always been quite unequivocal about not relying on any sun.* classes, as it is the equivalent of coding to an undocumented API feature in the DLL world (which, as we all know, are liable to change on a whim). I actually give Sun a little credit here for providing advanced notice of the situation, especially at this apparently early stage in the debate. Of course, that's to say nothing of why there isn't a published compiler extension (or classes), or why the javac is not OSS in the first place, or why there is really no alternative to relying on the Main compiler in many cases. I'm not saying it's right, I'm just saying that everyone knew it was a possibility from the get-go. - Christopher
Re: sun.tools.javac.Main will be removed from JDK1.4
On Fri, 20 Jul 2001, Christopher Cain wrote: JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote: Over in HP middleware, we're not to happy with this development either our JSP implementation will suffer for the same reasons Jasper will We can work with an external compiler, but for speed, we much prefer sun.tool.javac.Main. Just a question to satisfy my own curiosity (and possibly point out my compiler ignorance WRT using sun.tool.javac.Main and/or JSP compilation [since I don't do JSP]). You mention speed being the primary factor in using the Main compiler. Since Jikes is infinitely faster than javac (which I assume is derived from or otherwise related to Main), I have two questions. 1) Is it possible to even use Jikes in a JSP-compilation module, or are there technical issues which make it difficult to incorporate in a JSP environment? It is certainly technically feasible. And I *thought* that, at least somewhere in the Jasper lineage, it had actually been implemented. Ant has interfaces for Jikes already, also. 2) If it is not a JSP-specific issue, then I assume that the problem is due to Jikes not exposing some kind of API that can be imported and/or called from Java classes, and that it would therefore require the invokation of a separate external process (which is of course out of the question). Is that the case? I haven't looked at Jikes, so can't comment on the suitability of any APIs it exposes. Would someone like to look at this and report back? Again, I have very little knowledge of programatic compilation in Java, so I am just asking out of wild curiousity. It's an interesting problem. Regards, Christopher Craig
Updates to build processes and docs on jakarta-servletapi-4 andjakarta-watchdog-4
Hey folks, As I mentioned earlier, I've gone through the jakarta-servletapi-4 and jakarta-watchdog-4.0 build processes, and brought them up to date with our current practices. In addition, I've brought the following docuemntation files up to date for both repositories: README.txtQuick intro, documentation of the contents of the release, and pointers to other info BUILDING.txt Building a binary distribution from source RUNNING.txt (Watchdog only) Running the Watchdog tests against your servlet container In particular, folks working on Tomcat 4 will want to note the revised (simpler) test execution procedures for Watchdog tests. The revisions are in CVS now, and will show up in tonight's nightly builds. Please take a look, and provide feedback on the correctness and ease of use of the updated documentation. Craig McClanahan PS: The jakarta-tomcat-4.0 repository is next on my target list :-)
Re: cvs commit: jakarta-tomcat-4.0 build.xml
You are easily amused. I'm surprised at how neutral your echo is for Jasper, I would have thought you would use something like echoTarget: Jasper - Tracking, Firing, Hit.../echo ;-) Glenn [EMAIL PROTECTED] wrote: jon 01/07/20 14:46:32 Modified:.build.xml Log: added some echo statements for my own amusement. Revision ChangesPath 1.30 +3 -0 jakarta-tomcat-4.0/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- build.xml 2001/07/18 18:32:49 1.29 +++ build.xml 2001/07/20 21:46:32 1.30 @@ -33,8 +33,11 @@ !-- == DEPLOY: Deploy Components === -- target name=deploy-main depends=deploy-static +echoTarget: Catalina - Deploy.../echo ant dir=./catalina target=deploy/ +echoTarget: Jasper - Deploy.../echo ant dir=./jasper target=deploy/ +echoTarget: Webapps - Deploy.../echo ant dir=./webapps target=deploy/ /target -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: cvs commit: jakarta-tomcat-4.0 build.xml
on 7/20/01 4:38 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: You are easily amused. I'm surprised at how neutral your echo is for Jasper, I would have thought you would use something like echoTarget: Jasper - Tracking, Firing, Hit.../echo ;-) Glenn This is the new nicer Jon. JSP still sucks though. -jon
Re: tar bundle of latest mod-Web source?
Craig R. McClanahan at [EMAIL PROTECTED] wrote: On Fri, 20 Jul 2001, Thom Park wrote: Hi all, is there a tarbundle somewhere of the latest (circa-Tomcat 4-b6) web-app connector stuff anywhere? Will, it would have been there already if the person slated to do the work (Pier) hadn't been broken into last night, with several PCs and a bunch of other stuff stolen :-(. No, it would have been already there if I didn't forget to copy them to the WWW server after I rolled them today at the cops station :) They're up now, at http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src Sources only... Whoever tries to build them is more than welcome (meaning I'm going to shoot you if you don't) to tell so, report problems and so on. For B6, I didn't update the Makefiles for Win32, so, those still need to be fixed, but they should work on any platform where APR has been ported to. The APR version included is quite old, pre SMS (those who don't know what it is, SMS is a huge piece of code that was committed some weeks ago dealing with memory and so on, even though I trust David Reid and he told me it was OK, I'd rather bundle an older and more secure version, found to compile almost everywhere) and I'm planning to update to the more recent one after I hear what comes up with Apache 2.0b21 (shouldn't change anything, just some testing). It's not yet a beta as it doesn't include documentation (especially for the WARP protocol, and Jean Frederic will kill me if I don't write it - he's in France, much closer to me than you guys in California, and so way more scary :), and because there are still some WatchDog tests not working. Apart from all this bullshit, it's _way_ more stable than the previous one, the new protocol (WARP/0.9, getting close to 1.0 if this one proves satisfactory) holds much better than the previous one (in several tests I made, approximately 5 hits, I never dropped the socket - whohooo!). So, have fun, try it out, and get me some feedback :) Cheers... Pier
Re: sun.tools.javac.Main will be removed from JDK1.4
Craig R. McClanahan at [EMAIL PROTECTED] wrote: I haven't looked at Jikes, so can't comment on the suitability of any APIs it exposes. Would someone like to look at this and report back? Last time I looked at the sources (when I was at IBM, 1+1/2 years ago), Jikes was not relying on threads, and had a decent code base (it wasn't printing error messages to stderr, but was mirroring its FILE * in an internal variable, if I remember it right)... If that's the case, it _would_ be possible (probably, but not guaranteed) to compile it as a library with some hacks and wrap it somehow with a nice class, with all callbacks we need... Should check the code at this point, though... Pier (ROTFL for the new MTV-ringtones ad)
Re: sun.tools.javac.Main will be removed from JDK1.4
Christopher Cain at [EMAIL PROTECTED] wrote: Pier P. Fumagalli wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: I haven't looked at Jikes, so can't comment on the suitability of any APIs it exposes. Would someone like to look at this and report back? Last time I looked at the sources (when I was at IBM, 1+1/2 years ago), Jikes was not relying on threads, and had a decent code base (it wasn't printing error messages to stderr, but was mirroring its FILE * in an internal variable, if I remember it right)... If that's the case, it _would_ be possible (probably, but not guaranteed) to compile it as a library with some hacks and wrap it somehow with a nice class, with all callbacks we need... Should check the code at this point, though... That would be SWEET. I would be willing to help with the Java wrapper part, but since I know just enough C to be dangerous, I wouldn't really be of much help with that aspect. Are we talking a specialized wrapper targetting specifically the stuff required for JSP, or are we talking about a general all-purpose Java wrapper that we could possibly release as a separate tool? Generic interface, of course :) But I didn't say I'm going to do it... :) Pier (ROTFL for the new MTV-ringtones ad) WTF? I must have missed that one. A pop-up web ad, you mean? Nope... New ring tones for your cellphone from MTV (only GSM in Europe, and the ad is _way_too_funny_) Pier
Re: [FAQ] jGuru FAQ Update
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Sure, it could, but (a) I don't think one message a week will be enough traffic to bother anyone, and (b) sometimes developer-related FAQs show up on the Tomcat list. It's pretty cool, but check your scripts, as it's coming once a day, not once a week... Pier (again on the floor laughing for that MTV ad: gotta MPG it)
Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)
GOMEZ Henri wrote: Just did a DSO version and couldn't replicate the problem (BTW, I've recompiled/statically linked Apache and mod_jk again since then and the problem was still there). So, maybe it has to do with statically linking Apache after all... Strange problem. What's the difference between static and dynamic. We may have missed something at mod_jk init time ? This only happens during a graceful restart. Normal restart is OK. What does mod_jk do when it receives SIGUSR1? Does it actually do anything? Maybe that's the problem. Or it could have to do with Apache's behaviour on SIGUSR1. Something like, if DSO then modules are reloaded and therefore reinitialised, if static then the configuration file is re-read and that's it (pure speculative BS, I have no idea what Apache actually does). I kind of remember that people from mod_ssl were saying something about Apache init process being a bit strange (something like two passes) but that I think has to do with startup. Not sure. I still have to distribute this DSO version of Apache and mod_jk to some slower machines to see if that makes any difference at all. The machine that didn't produce any errors is a 1 GHz Athlon, so timing issues could have been resolved by brute force, who knows... Thanks to tell us what happened... Well, once I actually do that I surely will. I don't know if you've been in the position to run your own business, but I can only 'hack' when nothing else requires my immediate attention :-( Is there a recommendation as to the order of loading mod_jk for both statically linked version and the DSO version? Maybe that's important. I load mod_jk after alias and before rewrite and never get any problems. Not I also use php4 Thanks for the tips about module order. I'll see how that affects the whole thing. Bojan
Re: sun.tools.javac.Main will be removed from JDK1.4
Christopher Cain at [EMAIL PROTECTED] wrote: Generic interface, of course :) Nice ... What's the point of doing otherwise? But I didn't say I'm going to do it... :) D'oh! Maybe I'll have to send my men into your home again, and maybe this time they steal your primary mod_webapp development box ... you know, free up a little of your development time. =) Yeah, then Craig will send a couple of nuclear missiles over Colorado (and London :) [...] Anyway, sorry to hear about your situation. That blows. Just my Win32/RedHat 7.1 box... Seriously, though, based on your knowledge of the codebase, how much effort would you estimate it to be? And how hard would you estimate the C portion to be (assuming we didn't use JNI or some other Java/C abstraction layer)? Would anyone else have the inclination and time to have a go at it, too? Where would be the best place for development to happen? I'd say _at_least_ two weeks to come up with a very-very-very rough implementation (based on what was there last year, and what I can remember). I just re-downloaded it, and they made even better, check out jikesapi.h and check out the C++ class JikesAPI... Very well designed, indeed, everything you need is in there... FileReader and FileWriter would have to be represented in Java, as well as something to handle JikesError, but then, it would be fairly done. The biggest changes would be in jikes.cpp (where everything is created, basically). BUT, the problem is then to strengthen it. C is a bitch, takes the same amount of time to write, and 10 times more to debug it (also, no throw Exception means a LOT of gdb involved) To get with something fairly working, I'd give it 1/2 months... [...] Finally, a way be a real live MTV Jackass without setting myself on fire. Or wrestling a bear :) Pier
Re: Compiler API Features [Was: sun.tools.javac.Main will be removedfrom JDK1.4}
Craig R. McClanahan wrote: On Fri, 20 Jul 2001, Christopher Cain wrote: [snip] Are we talking a specialized wrapper targetting specifically the stuff required for JSP, or are we talking about a general all-purpose Java wrapper that we could possibly release as a separate tool? As an absolute minimum, Jasper doesn't need much -- just a way to invoke the compiler in a multi-threaded server environment without multiple instances clashing with each other. Even external processes work, albeit much more slowly than one would like. I'm interested in accumulating a list of nicer features that we'd like to see in a compiler API. Here's some of my initial thoughts: - Small, fast, lightweight, but generates good (optimized) bytecodes. (Who says goals can't conflict with each other? :-). Hmm. I wonder how much optimization is needed in the generated byte code for something that will get profiled and optimized to native opcodes by HotSpot server. Of course things other than Jasper, like Ant, might want to use it with a great deal of optimization. Inclusion/use of the optimization should be optional. I would rather have a small footprint fast JSP java source compile and let HotSpot server do the profiling and optimization. - Full support for all the features currently in, and about to be added to, the Java Language Specification (i.e. assertions and generics as soon as possible). - Written in Java (and so embeddable in the Tomcat JVM) or accessible easily and reliably via JNI on lots of platforms. - Published, stable, and supported invocation API. - Packaged in such a way that multiple compiles can be initiated simultaneously (on different threads) with no conflicts. - Accepts source input from configurable-per-class input stream, not just files. - Writes the bytecodes of its output to a configurable-per-class output stream, not just files. - Accepts its notion of a class path for looking up dependencies by handing it a class loader, instead of a CLASSPATH-type environment. - Generates debugging information usable to map lines of Java code back to a non-Java language that the Java code was generated from (i.e. the outcome of JSR-045). What did I miss? Craig McClanahan That is a very good list of requirements, can't think of any additons. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Compiler API Features [Was: sun.tools.javac.Main will beremovedfrom JDK1.4}
Glenn Nielsen at [EMAIL PROTECTED] wrote: Hmm. I wonder how much optimization is needed in the generated byte code for something that will get profiled and optimized to native opcodes by HotSpot server. Of course things other than Jasper, like Ant, might want to use it with a great deal of optimization. Inclusion/use of the optimization should be optional. I would rather have a small footprint fast JSP java source compile and let HotSpot server do the profiling and optimization. Now, I didn't believe it myself until I got the proof, but, IT SEEMS, that with HotSpot interpreting something like JSPs is actually FASTER than compiling them... It was applied to an XSP derivate by some Italian weirdos, and maybe Gianugo can enlighten us on what he found out... Gianugo? Pier
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
larryi 01/07/20 21:04:46
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Set version to Beta 1
Revision ChangesPath
1.185 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.184
retrieving revision 1.185
diff -u -r1.184 -r1.185
--- ContextManager.java 2001/07/19 05:55:30 1.184
+++ ContextManager.java 2001/07/21 04:04:46 1.185
@@ -148,7 +148,7 @@
public final class ContextManager {
/** Official name and version
*/
-public static final String TOMCAT_VERSION = 3.3 Milestone 4;
+public static final String TOMCAT_VERSION = 3.3 Beta 1;
public static final String TOMCAT_NAME = Tomcat Web Server;
/** System property used to set the base directory ( tomcat home ).
WebDAV interoperability report
Hi, I've been attending a WebDAV interoperability event today. There was a lot of people, and it was very interesting. The results for the Tomcat 4 WebDAV servlet were relatively bad. Apparently there has been a few areas where there has been some regressions, but it resulted in quite a number of failures (and of course I was so confident in the robustness of my code that I didn't even bother to make a special debug build ;-) OTOH, the code which *did* have some debug didn't break nearly as much). I filed the problems I've found in Bugzilla. Tomcat 4.0 interoperated well in the HTTP area with the HTTP/1.1 connector. I have a proposal to make regarding all these interop issues, but that will have to wait for another mail. Remy
