RE: [Bug 3600] New: - /etc/rc.d scripts of the rpm
Move tomcat configuration to /etc ? I did an rc.d script myself a while ago in this style (sorry - I forgot to pass it on) but I was following the convention of Redhat 7.1 and put my configurations in /etc/sysconfig/tomcat Does this break the FHS (What is FHS??) Cheers, jr Well that would be also great (missed this one, damned:) What this bug is about is just moving *** PATH=$PATH:/opt/IBMJava2-13/bin:/opt/IBMJava2-13/jre/bin JAVA_HOME=/opt/IBMJava2-13 TOMCAT_HOME=/var/tomcat export PATH JAVA_HOME TOMCAT_HOME *** to a file in /etc, for example /etc/tomcat.conf and add the lines *** TOMCATCFG=/etc/tomcat.conf if [ -f $TOMCATCFG ]; then . $TOMCATCFG else echo $(no tomcat configuration found) exit 1 fi *** to /etc/rc.d/init.d/tomcat This way /etc/rc.d/init.d/tomcat can change from one rpm to the next one, but /etc/tomcat.conf can be marked as a config file so users will keep their own parameters. (a more complete solution is reading /etc/tomcat.conf if it exists, and putting defaults in /etc/rc.d/init.d/tomcat) *** TOMCATCFG=/etc/tomcat.conf [ -e $TOMCATCFG ] . $TOMCATCFG if [ -z $JAVA_HOME ]; then JAVA_HOME=/opt/IBMJava2-13 fi *** and so on. Hope this is clear (mon anglais n'est pas fantastique) -- Nicolas Mailhot
[PATCH TC4] catalina/build.xml - bug #3194 - Javadoc errors during build
Heres a patch to fix the javadoc errors that were appearing for me. Because its not possible to exclude files from a javadoc task, this patch makes a temporary copy of the src, excluding files it doesn't need and then generates the javadocs from that copy of the src. Cheers, jr John Reilly, System Administrator Xelector Ltd., 1st Floor, 76 Talbot St., Dublin 1, Ireland. Email : [EMAIL PROTECTED] catalina_build.diff
RE: Extending Server.xml configurability (for additional classpaths)
I don't understand why you would want this - doesn't the WEB-INF/lib and WEB-INF/classes not already provide seperation of classpaths for the various webapps. Am I missing something? jr I've seen lots of discussion on the user list desiring the ability to have additional classpaths available to web applications, but not necessarily available to all web apps. Ideally, this could be specified in the web.xml file, but that would require changing a spec, and I can think of some arguments against doing so anyway. But, perhaps it would be possible to add classpath specifications in the Server.xml file. Inside a context tag, you could specify something like this: additional-classpath~someuser/somedir/classesadditional-classpath Multiple occurrences of this would just add to the locations where classes can be found. An alternative for us would be to do something with the class loaders in our own web apps, if that's possible, but I'd like to see Tomcat have the functionality. Can someone give me some pointers to get started adding this particular configuration tag? I'd really appreciate it. BTW, I'm currently working with the 4.0b7 codebase. Thanks!
[PATCH TC4] added jndi.jar to classpath in javac task
Catalina would not compile without adding jndi.jar to the classpath for catalina and the webapp/examples. Presumably this is not affecting people because they have it in there environment classpath. (I think I submitted this a while ago also.) diffed against current cvs update Cheers, jr -- John Reilly - [EMAIL PROTECTED] Xelector Ltd. 76 Talbot St. Dublin 1. -- catalina_build.diff
RE: [PATCH TC4] added jndi.jar to classpath in javac task
Hi John,
I did not need to do this to build tc4 out of the box.
What was the build error? Is your build.properties pointing
to jndi OK? If you do an ant -verbose, does ${jndi.home}
get set correctly? TC4 will automatically include
${jndi.home}/lib/jndi.jar (see catalina/build.xml:28)
The problem is that the javac task on line 138 did not use ${jndi.jar}. The
build error was that it could not import the javax.naming classes. Changing
the javac task as per the diff fixed the problem (this would not have worked
if I did not have jndi.home set in my build.properties).
If you do a grep on the build.xml you will see that the unpatched version
only defines ${jndi.jar} and uses it on line 93 to copy jndi.jar to
common/lib
The only way you would be able to compile without the changes I suggested
would be to have jndi.jar in your environment CLASSPATH or in the ext
directory of your jre/jdk. (I think)
Keith
| -Original Message-
| From: Reilly, John [mailto:[EMAIL PROTECTED]]
| Sent: Monday, August 27, 2001 11:09 AM
| To: Tomcat Dev (E-mail)
| Subject: [PATCH TC4] added jndi.jar to classpath in javac task
|
|
|
| Catalina would not compile without adding jndi.jar to the
classpath for
| catalina and the webapp/examples. Presumably this is not
affecting people
| because they have it in there environment classpath. (I
think I submitted
| this a while ago also.)
|
| diffed against current cvs update
|
| Cheers,
| jr
RE: Addition of 'dirty' field to Session interface
For permanent business objects, that is probably true ... but the use cases we'd like to be able to deal with include: * Load-balanced distributed container that can move sessions around as various servers get overloaded. * Fail-safe distributed container that automatically recovers from server failures and reconnects you to a different one with your session intact. without the application developer having to worry about this for his/her session beans. The first case isn't so hard -- the only time you have to persist is when you are going to migrate, so you would just do it unconditinally. The second case is harder, unless you can afford the performance hit of persisting after *every* request. I don't think there's a single policy that will cover all reasonable use cases, so configurable selection of different policies is likely to be useful. I've been interested in getting my teeth into this problem for a while but I didn't have the time I may get a chance the near future though. Cheers, jr
RE: Addition of 'dirty' field to Session interface
This is just an idea from the top of my head, would it be possible having a second vector that contains a footprint(not a full clone) of the object for a session and have a reaper thread checking the footprints against the real objects and determine if they changed or not and based on that replicate of whatever we want to do. My thoughts exactly. If you want to be able to support transparent fail-over for sessions within a cluster, you are going to have to take the performance hit of persisting the session data on at least 1 other machine in the cluster after every request. If you're already taking that step, you might as well maintain an in-memory image of the serialized session object. You could compare an MD5 on the bytes comprising the session before the request was handled with the MD5 for after the request completed. Could this work? The overhead could be fairly signifigant. - osama.
RE: A couple of questions, please!
Sorry for intruding on the dev list, but I am having no luck getting emails from the user list. I greatly appreciate it if someone could answer these two questions: a) Can Tomcat do a forward to an anchor in a JSP page, such as: RequestDispatcher rd = getServletContext().getRequestDispatcher(/page.jsp#anchorName); rd.forward(request, response); The anchor is never processed on the server side - it is only used by browsers.
RE: RPM for tomcat 3.2.2-1 : any problems reported?
Just a quick recall of build of rpms. There are built under Redhat 6.2 / Redhat 7.1 (validation) - using latest jikes 1.14 - using latest IBM SDK 1.3 (javadoc) - with latest ant 1.3, xerces-j 1.4, xalan-j 2.1.0 I encounter rare problems when building with jikes, at least one with a previous release of TC 4.0 One of the guys here came across a problem using jikes 1.13-1 Doing an intern on two strings and checking for equality failed in cases where it should have worked. jr
RE: Missing CGIServlet from nightly build
On Tue, 19 Jun 2001, Kevin Jones wrote: Thanks John. Does this make the nightlies unusable? Is there a plan to move to 1.3? I thought that I had already :-( ... I will check as soon as I get home from a trip (Thursday). The nightlies are built on my home server, and it's behind a firewall. Sorry, my mistake. By default it wasn't building the jdk1.3 dependant classes until Amy changed the build.xml on Monday. Cheers, jr Kevin Jones DevelopMentor www.develop.com Craig -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: Missing CGIServlet from nightly build
I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: Missing CGIServlet from nightly build
Does this make the nightlies unusable? Only if you want to use tomcat to run cgi scripts. Is there a plan to move to 1.3? I think thats up to Craig. jr Kevin Jones DevelopMentor www.develop.com -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 13:28 To: '[EMAIL PROTECTED]' Subject: RE: Missing CGIServlet from nightly build I'm trying to use the Tomcat nightly's, and found that the org.apache.catalina.servlets.CGIServlet class is missing from the 16th, 17th and 18th June builds, although it (an its related classes) is in the earlier nightlys, As far as I know the build environment for the nightly builds is still using jdk1.2 but CGIServlet requires 1.3 - therefore it is not built. jr
RE: [j-t-c] OS poll = [j-t-c] webserver poll
Apache1.3 on Redhat 6.1, 6.2, 7.1 Apache1.3 on Solaris 2.6 and Solaris 8
RE: [j-t-c] OS poll
Redhat 6.x/7.1 currently Solaris 2.6, 8 (and maybe WinNT/2K) soon. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 1:54 PM To: [EMAIL PROTECTED] Subject: [j-t-c] OS poll Hi, A quick poll to get informations about OS used by j-t-c developpers users ... I: Redhat 6.2 / 7.1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Fix to build for TC4 jdk1.2
Hi folks, Attached is a patch to allow tc4 to build with jdk1.2. It uses an extra property in the build.properties using.jdk.1.3=true. Add this if you want to compile the files that use 1.3 APIs. Can someone commit this to the cvs (unless there is a better solution of course). Cheers, jr John Reilly[EMAIL PROTECTED] http://www.xelector.com/ build.patch.diff
RE: Fix to build for TC4 jdk1.2
Sorry, there was a small error in that patch. This is what I should have sent :) jr -Original Message- From: Reilly, John [mailto:[EMAIL PROTECTED]] Sent: Friday, June 08, 2001 12:46 PM To: Tomcat Dev (E-mail) Subject: Fix to build for TC4 jdk1.2 Hi folks, Attached is a patch to allow tc4 to build with jdk1.2. It uses an extra property in the build.properties using.jdk.1.3=true. Add this if you want to compile the files that use 1.3 APIs. Can someone commit this to the cvs (unless there is a better solution of course). Cheers, jr -- -- John Reilly[EMAIL PROTECTED] http://www.xelector.com/ -- -- build.patch.diff
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util ProcessHelper.java ProcessEnvironment.java CGIProcessEnvironment.java
When compiling ProcessHelper.java and ../servlets/CGIServlet.java against jdk1.2 there is an error. ProcessHelper line 381 and CGIServlet line 1567. Both lines try to call Runtime.exec(String, String[], File) which does not exist in jdk1.2 John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 1:21 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util ProcessHelper.java ProcessEnvironment.java CGIProcessEnvironment.java amyroh 01/05/31 17:21:15 Added: catalina/src/share/org/apache/catalina/util ProcessHelper.java ProcessEnvironment.java CGIProcessEnvironment.java Log: Add CGI supporting classes submitted by Martin Dengler. Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util /ProcessHelper.java
RE: question
Hi Pier, Apparently there is a virus in the index.htm - I got the following attached to your mail. John Network Associates GroupShield Exchange ** Alert generated at: Thursday, May 24, 2001 11:23:27 GMT Daylight Time ** The file index.htm has been replaced as it contains the SunOS/BoxPoison.worm virus. Please consult your administrator for further help. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 24, 2001 11:18 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: FW: question Here's what it seems they did with the exploit... Rerolling the binaries *balls of Tomcat putting a new index.htm... I'm downloading the supposedly wrong binary as we speak, but it's kinda slow from my 56kbps connection... Fuck shit... Pier
RE: Trying New Connectors Build Stuff
Hi Pier, I've followed the howto compile doc (apache-1.3.html I presume). I got a slightly different error this time. [jreilly@lorien bin]$ ./httpd Syntax error on line 957 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: /usr/local/apache/libexec/mod_webapp.so: undefined symbol: pthread_sigmask [jreilly@lorien bin]$ lines 957-960 of httpd.conf are LoadModule webapp_module libexec/mod_webapp.so AddModule webapp_module WebAppConnection warpConnection warp localhost:8008 WebAppDeploy examples warpConnection /examples/ I've attached logs of the apr and mod_webapp builds. This is using apr_20010511121424.tag.gz and jakarta-tomcat-4.0 checked out from cvs this morning. Cheers, John -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 2:07 AM To: [EMAIL PROTECTED] Subject: Re: Trying New Connectors Build Stuff Reilly, John at [EMAIL PROTECTED] wrote: Hi, I had the same problem but I'm using a heavily modified Redhat 6.1 system so that seems to indicate that its not limited to a glibc2.2 problem. Everything compiled fine, but when starting up httpd it gave the undefined symbol: pthread_create error as below. I have libpthread installed in /lib which is in /etc/ld.so.conf. I did a strings on the library and the symbol does exist in it. I can provide more info if it helps. I just checked in an howto compile file in the docs directory... Can you follow it like the bible and tell me what happens ? :) Thanks :) Pier apr.install.log mod_webapp.inst.log
RE: Trying New Connectors Build Stuff
Hi, I had the same problem but I'm using a heavily modified Redhat 6.1 system so that seems to indicate that its not limited to a glibc2.2 problem. Everything compiled fine, but when starting up httpd it gave the undefined symbol: pthread_create error as below. I have libpthread installed in /lib which is in /etc/ld.so.conf. I did a strings on the library and the symbol does exist in it. I can provide more info if it helps. John Problem 3 - configtest fails Moved mod_webapp.so into /usr/local/apache/libexec and added some config directives to the httpd.conf file, including LoadModule webapp_module libexec/mod_webapp.so but running the configtest option throws this error: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: /usr/local/lib/libapr.so.0: undefined symbol: pthread_create As you can see, it correctly found where my libapr.so shared library is, but cannot find the pthreads library - even though it's installed. This *could* be because Red Hat 7.1 uses libc-2.2.2.so, and I've heard others have had problems with this.
