Re: Tomcat 4.0
Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
Well in fact we would like to use Tomcat 4.0 but our customers may want to use Bea Weblogic, ATG dynamo .. We don't want to force them to use a specific server. My question should be : is there a way in Tomcat 4.0 to make it behave as a servlet 2.2, jsp 1.1 server. I looked at web.xml and there is the path to the dtd which could be constraint to force the customer not to use filter (for example). But for my jsps can i make them specific to a JSP version. Since we are developping demos it could be great to port on any server the customer would like. Am i clear? Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Thomas Colin de Verdière SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
There are not very involved since they should use another servlet container, even an application server. We have many of our customers using Tomcat 3.2.4 but some use Websphere, other WebLogic ... Our product work on tomcat we have our own Servlets and taglib delivered in WEB-INF/lib/ of our demos applications, we have configuration files in a subdirectory of the conf directory. There are some properties file for jndi access. Our product can be customized. This customization is on the properties file but also on jsps and servlets we deliver. For example we can have the customer can change an init-param for a servlet and he could also want to modify a Jsp page by adding custom tags. This customization the customer can do it anytime. But if he wants to port his customized application to another server we don't want him to use some jsp 1.2 specific features like using JSTL in our jsp since most of products are not jsp 1.2 compatible. The fact is that i want to migrate my taglib to jsp 1.2 compatible and i don't want to write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a smooth migration .. Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Thomas Colin de Verdière SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
On Wed, 31 Jul 2002, Thomas Colin de Verdière wrote: Date: Wed, 31 Jul 2002 18:04:55 +0200 From: Thomas Colin de Verdière [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Tomcat 4.0 There are not very involved since they should use another servlet container, even an application server. We have many of our customers using Tomcat 3.2.4 but some use Websphere, other WebLogic ... Our product work on tomcat we have our own Servlets and taglib delivered in WEB-INF/lib/ of our demos applications, we have configuration files in a subdirectory of the conf directory. There are some properties file for jndi access. Our product can be customized. This customization is on the properties file but also on jsps and servlets we deliver. For example we can have the customer can change an init-param for a servlet and he could also want to modify a Jsp page by adding custom tags. This customization the customer can do it anytime. But if he wants to port his customized application to another server we don't want him to use some jsp 1.2 specific features like using JSTL in our jsp since most of products are not jsp 1.2 compatible. The fact is that i want to migrate my taglib to jsp 1.2 compatible and i don't want to write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a smooth migration .. As with web.xml files, tag library descriptors declare which version of JSP they are written for (1.1 or 1.2). Tomcat 4 runs apps with JSP 1.1 tag library descriptors just fine, with no changes. Craig Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Thomas Colin de Verdière SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0 remote shutdown question ...
On Sat, 27 Jul 2002, HAVENS,PETER (HP-Cupertino,ex3) wrote:
Date: Sat, 27 Jul 2002 18:35:23 -0400
From: HAVENS,PETER (HP-Cupertino,ex3) [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: tomcat 4.0 remote shutdown question ...
I have found that I cannot connect to the tomcat shutdown port remotely.
Using code highly leveraged from the tomcat source, I wrote a simple java
app to issue the shutdown command to a given server and port #. It only
seems to work if I use localhost as the server name. If I try to use the
hostname or the fully qualified host name (even of the local system) it will
fail. I have tried using this to stop Tomcat on linux and Windows XP with
the same results. I have included the output I get when I run it and the
source code. Any help understanding this would be greatly appreciated.
Tomcat deliberately accepts connections to the shutdown port only from
localhost as a security precaution. After all, you really don't want
anyone on the Internet to be able to shut down your Tomcat instance.
To change this behavior, you'd need to change the Tomcat source code for
the logic that opens the shutdown port's socket. It's not configurable.
Craig
-Sample output
Attempting to shut down the tomcat server on ovwpc574/15.27.245.212 using
port 8085
tomcat_stop: java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:295)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:161)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:148)
at java.net.Socket.connect(Socket.java:425)
at java.net.Socket.connect(Socket.java:375)
at java.net.Socket.init(Socket.java:290)
at java.net.Socket.init(Socket.java:146)
at tomcat_stop.main(tomcat_stop.java:40)
-End of Sample
output
-Source Code
import java.io.*;
import java.io.IOException;
import java.net.Socket;
import java.net.InetAddress;
class tomcat_stop
{
public static void main( String [] args )
{
int port_number;
InetAddress server_address=null;
Socket socket;
if (args.length != 2)
usage();
port_number = Integer.parseInt(args[1]);
try
{
server_address =
InetAddress.getByName(args[0]);
}
catch (IOException e)
{
System.out.println();
System.out.println(Unable to get
InetAddress using getByName on +
args[0]);
System.out.println(:tomcat_stop + e);
e.printStackTrace(System.out);
System.exit(1);
}
// Stop the existing server
try {
System.out.println(\n\nAttempting to
shut down the tomcat server on +
server_address + using
port + port_number + \n\n);
socket = new Socket(server_address,
port_number);
OutputStream stream =
socket.getOutputStream();
String shutdown = SHUTDOWN;
for (int i = 0; i shutdown.length();
i++)
stream.write(shutdown.charAt(i));
stream.flush();
stream.close();
socket.close();
}
catch (IOException e)
{
System.out.println(tomcat_stop: + e);
e.printStackTrace(System.out);
System.exit(1);
}
}
public static void usage()
{
System.out.println(\nUsage:\n\ttomcat_stop system
name port\n\n);
System.exit(1);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tomcat 4.0 remote shutdown question ...
Wow! What a quick response. Thank you for your information.
-Peter
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 27, 2002 3:41 PM
To: Tomcat Developers List
Subject: Re: tomcat 4.0 remote shutdown question ...
On Sat, 27 Jul 2002, HAVENS,PETER (HP-Cupertino,ex3) wrote:
Date: Sat, 27 Jul 2002 18:35:23 -0400
From: HAVENS,PETER (HP-Cupertino,ex3) [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: tomcat 4.0 remote shutdown question ...
I have found that I cannot connect to the tomcat shutdown port remotely.
Using code highly leveraged from the tomcat source, I wrote a simple java
app to issue the shutdown command to a given server and port #. It only
seems to work if I use localhost as the server name. If I try to use
the
hostname or the fully qualified host name (even of the local system) it
will
fail. I have tried using this to stop Tomcat on linux and Windows XP with
the same results. I have included the output I get when I run it and the
source code. Any help understanding this would be greatly appreciated.
Tomcat deliberately accepts connections to the shutdown port only from
localhost as a security precaution. After all, you really don't want
anyone on the Internet to be able to shut down your Tomcat instance.
To change this behavior, you'd need to change the Tomcat source code for
the logic that opens the shutdown port's socket. It's not configurable.
Craig
-Sample output
Attempting to shut down the tomcat server on ovwpc574/15.27.245.212 using
port 8085
tomcat_stop: java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:295)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:161)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:148)
at java.net.Socket.connect(Socket.java:425)
at java.net.Socket.connect(Socket.java:375)
at java.net.Socket.init(Socket.java:290)
at java.net.Socket.init(Socket.java:146)
at tomcat_stop.main(tomcat_stop.java:40)
-End of Sample
output
-Source Code
import java.io.*;
import java.io.IOException;
import java.net.Socket;
import java.net.InetAddress;
class tomcat_stop
{
public static void main( String [] args )
{
int port_number;
InetAddress server_address=null;
Socket socket;
if (args.length != 2)
usage();
port_number = Integer.parseInt(args[1]);
try
{
server_address =
InetAddress.getByName(args[0]);
}
catch (IOException e)
{
System.out.println();
System.out.println(Unable to get
InetAddress using getByName on +
args[0]);
System.out.println(:tomcat_stop +
e);
e.printStackTrace(System.out);
System.exit(1);
}
// Stop the existing server
try {
System.out.println(\n\nAttempting to
shut down the tomcat server on +
server_address + using
port + port_number + \n\n);
socket = new Socket(server_address,
port_number);
OutputStream stream =
socket.getOutputStream();
String shutdown = SHUTDOWN;
for (int i = 0; i shutdown.length();
i++)
stream.write(shutdown.charAt(i));
stream.flush();
stream.close();
socket.close();
}
catch (IOException e)
{
System.out.println(tomcat_stop: +
e);
e.printStackTrace(System.out);
System.exit(1);
}
}
public static void usage
Re: tomcat 4.0 nightly builds broken since 5/30
[EMAIL PROTECTED] wrote: The tomcat nightly builds are broken since 5/30. This is the last day before no good downloadable builds will be available. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ The plan is to rely on Gump for the nightlies. There were some issues, which got fixed. Now, we may have to wait a bit for a build to succeed ;-) My plan is to release a new Tomcat 4.1.5 milestone today or tomorrow. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: tomcat 4.0 nightly builds broken since 5/30
I've been testing all those versions... there seems to be a couple issues I have seen with each... let me test 4.1.5 and I'll let you know how it goes... t [EMAIL PROTECTED] wrote: The tomcat nightly builds are broken since 5/30. This is the last day before no good downloadable builds will be available. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/ The plan is to rely on Gump for the nightlies. There were some issues, which got fixed. Now, we may have to wait a bit for a build to succeed ;-) My plan is to release a new Tomcat 4.1.5 milestone today or tomorrow. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0 nightly builds broken since 5/30
[EMAIL PROTECTED] wrote: I've been testing all those versions... there seems to be a couple issues I have seen with each... let me test 4.1.5 and I'll let you know how it goes... 4.1.5 currently does not exist, but otherwise looks good. At the moment, there are some issues which still needs to be cleared out dealing with the JNDI resources handling in the admin webapp. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 nightly build binary downloads broken?
I found that it looks like the nightly binary builds are broken. As you can see, for some reason the many of the file sizes are only 45 bytes. Also, the .zip file builds are missing. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/ The switch to Jasper 2 probably killed it (but it was really bad to keep Jasper 1 in there). Craig could fix it when he has some time, or we could decide it's (finally) time to switch to Gump. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 nightly build binary downloads broken?
On Fri, 7 Jun 2002, Remy Maucherat wrote: Date: Fri, 7 Jun 2002 10:24:00 -0700 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jonathan Eric Miller [EMAIL PROTECTED] Subject: Re: Tomcat 4.0 nightly build binary downloads broken? I found that it looks like the nightly binary builds are broken. As you can see, for some reason the many of the file sizes are only 45 bytes. Also, the .zip file builds are missing. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/ The switch to Jasper 2 probably killed it (but it was really bad to keep Jasper 1 in there). Craig could fix it when he has some time, or we could decide it's (finally) time to switch to Gump. +1 (for Gump-built nightly builds). It wasn't Jasper2 that killed it ... it was the switch to Ant 1.5b2. I'll try to get that working again on my box over the weekend, but it would be better to migrate the standard nightly build process somewhere else. Just let me know and I'll remove it from my nightly cron job. Remy Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 nightly build binary downloads broken?
On Fri, 7 Jun 2002, Craig R. McClanahan wrote: It wasn't Jasper2 that killed it ... it was the switch to Ant 1.5b2. I'll try to get that working again on my box over the weekend, but it would be better to migrate the standard nightly build process somewhere else. Well, jakarta-tomcat-utils is now killing all tomcat gump builds. I'm working on it. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 with SSL
Henry Lu [EMAIL PROTECTED] writes: I followed the every steps in the doc for how-to do ssl. But I got failure when I start the tomcat. Since I couldn't see all error message, here is the on on the screen: at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.io.IOException: java.security.UnrecoverableKeyException: Cannot recover key at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSoc ketFactory.java:422) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSo cketFactory.java:334) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServer SocketFactory.java:287) at org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.j ava:946) at org.apache.catalina.connector.http.HttpConnector.initialize(HttpConne ctor.java:1114) at org.apache.catalina.core.StandardService.initialize(StandardService.j ava:454) at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav a:552) at org.apache.catalina.startup.Catalina.start(Catalina.java:775) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) Is there any answer? I'd guess that this is a password problem. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 with SSL
I followed the every steps in the doc for how-to do ssl. But I got failure when I start the tomcat. Since I couldn't see all error message, here is the on on the screen: at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.io.IOException: java.security.UnrecoverableKeyException: Cannot recover key at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSoc ketFactory.java:422) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSo cketFactory.java:334) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServer SocketFactory.java:287) at org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.j ava:946) at org.apache.catalina.connector.http.HttpConnector.initialize(HttpConne ctor.java:1114) at org.apache.catalina.core.StandardService.initialize(StandardService.j ava:454) at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav a:552) at org.apache.catalina.startup.Catalina.start(Catalina.java:775) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) Is there any answer? Thanks, Henry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 Beginner's Guide
Marty Hall you are a good guy. Thanks! At 03:00 PM 1/21/02 -0500, you wrote: Hi- Daniel Savarese suggested I contact [EMAIL PROTECTED] with this info. I've discovered that a surprising number of readers of my servlet and JSP books (Core Servlets and JSP, More Servlets JSP) need a lot of handholding to get Tomcat running even in the simple standalone mode. So, I grudgingly put together a very step-by-step guide, and to my surprise readers really went for it. It is http://www.moreservlets.com/Using-Tomcat-4.html; please feel free to link to it from the Tomcat docs page if you think it would be useful. Cheers- - Marty -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0 on IIS
On Fri, 16 Nov 2001, Rajan Gupta wrote: Date: Fri, 16 Nov 2001 13:49:56 -0800 (PST) From: Rajan Gupta [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], EKR [EMAIL PROTECTED] Subject: Tomcat 4.0 on IIS I managed to run Tomcat 4.0 with IIS using the ISAPI module provided for Tomcat 3.3 for AJPV13. I had to use the workers.properties uriworkers.properties to make it work from Tomcat 3.3. If the Tomcat Developer Community does not know of any known issue with using Tomcat 3.3 ISAPI Module for Tomcat 4.0, I will be happy to provide an Installation Guide sample files to be put as a part of Tomcat 4.0. That would be quite useful. I say this because I have seen repeated request by Tomcat 4.0 Users for IIS support. Craig, can u take a minute to advise. The best way to integrate documentation into the Tomcat 4 bundle would be to write them using the XML formats used for all the other docs -- they are in webapps/tomcat-docs in the source repository. Second best would be to provide raw text (or HTML) versions of the docs that someone else could convert into the same style. To actually propose the new docs, you would send them as an attachment to the Tomca-Dev list, in accordance with the guidelines on the Jakarta web site, starting at: http://jakarta.apache.org/site/getinvolved.html Thanks, Rajan Gupta Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.0 license
dear list ... HOW THE HELL CAN I UNSUBSCRIBE FROM THIS LIST ??? Or at least to switch to digest mode ? -Original Message- From: HO,ELWIN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 3:30 PM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Tomcat 4.0 license Hi, I am trying to build the tomcat 4.0 from source. I notice that I need to download a lot of packages from sun to build the tomcat. Anyone know are there any special license we need to get from sun? As when I try to download those packages, sun asks me to agree on a lot of license. I also notice the Tomcat 4.0 binary came with all those packages (common/lib). And there is one LICESENCE file in the package. It is a standard Apache license. Question: 1. Do I ONLY need to agree on the Apache License to use tomcat 4.0? Thanks Elwin
RE: Tomcat 4.0 RPMs?
Jaxp and crimson are built from xml-commons and xml-crimson ( both are Apache packages ). We do check in binaries - which is consistent with apache licence, but anyone can built them from sources as well. In the RPM case, we use dependencies to have them included from allready installed RPM. But it's not the case in the CURRENT version of RPM where we install crimson which is allready present in sources. Should I change to make xerces/crimson (jaxp requirement) required for both build and runtime (easy to do) ? I'm sure that some of my friend in RPM packaging (hello Guillaume) will prefer this method. The only problem is JSSE - it's clear the official RPM can't include JSSE, nor the classes that depend on it ( since that would mean the source RPM couldn't be distributed ). We can distribute a separate RPM with JSSE-dependent classes. That's not a major problem for linux - since Henri is already building mod_jk, Yep, JSSE is of course the most restrictive license of them all, because of the goofy crypto laws. :( Why couldn't we use the today JSSE as we use OpenSSL. I was told that some legals aspect on RSA has been relaxed this year. so SSL will be supported via Apache, which is the best (and fastest) solution anyway. Arrggg! Why does Standalone + SSL get no respect? It performs quite well, in my (extensive) experience. Also, I've never hit a single real bug in it, in either tree. Whether Apache is slightly better at SSL than Tomcat standalone isn't even a relevant comparison. If you're running TC behind another web server, then that web server needs to handle it. If you're running standalone, then Tomcat needs to handle it. Installing Apache to run in front of TC *just* to handle SSL is compeltely unnecessary. You know that my friend, crypto is a hog cpu task and having it handled by Java code will be more expensive that the native (even asm) code in OpenSSL for example. But you're rigth when you tell we could use SSL in 100% java mode... Anyway, I'm trying very hard to build confidence in standalone SSL, write extensive docs for it, enhance it, patch it, and work out what I see as its weak points. Please don't impune it :) Never ;) Regarding the jars included in 4.0 - I do have few issues. First, how in the world did we got to depend on mail.jar and activation.jar and the other ? Dunno, I'll let someone else answer that one. I believe including such features could be decided by vote, I don't have a problem with that. Technically, of course, it would only be a vote for what kind of RPM can be officially hosted on the download site. Anyone can package an RPM however they like, they just have to distribute it themselves. Yes even Sun could do such packaging :) More seriously the problem here is all the requirement and I'll be to have a Tomcat 4.0 ligth, with less external dependencies. Or may be we must mark that TC 4.0 is for J2EE 1.3 only ! and only after the PMC and ASF clearly posts the policy that allow such things. If ASF has any rule that allow us to take any package we want that is redistributable and use it - that's great news. If ASF has a list of 'aproved' licences that we can include - that's even better ( and I hope LGPL makes it to the list - at least it has source code available :-). It would be nice to have this posted somewhere - so we all know the rules. Agreed. But in the absence of an official policy, I'll go by what that one PMC dude said in response to Jon's concerns: By and large, and code checked into the tree by Sun employees falls under the Sun-Apache agreement. I don't think it's unreasonable to accept that at face value until there *is* an official policy posted. Without a specific policy disallowing it, I operate under the assumption that it is left up to the discretion of the particular community, and good old- fashioned common sense. I'm -1 on including any non-apache binary unless the ASF/PMC explicitely allows it. That's my vote in case this is put to a vote on tomcat-dev I'm -1 making anything bad for ASF in general and will wait for Craig validation for my packaging proposal : - Get jar in tomcat binary - Get source in tomcat source = provide tomcat RPM Because if Craig's interpretation of the licenses is correct, then I don't see a licensing problem at all. It just becomes a matter of packaging philosophies. Incidentally, there are only about 500 people in here from Sun. Can't somone just run it down to Legal ;-) Yes some lobbying should be nice and many people in PMC ask Sun to OpenSource Java. May be Sun could start by OpenSource more external libs, as they do for servlet/JSP API
RE: Tomcat 4.0 cluster-mode
-Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Friday, September 28, 2001 7:36 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 4.0 cluster-mode [stuff deleted] I had some problems getting multicasting to work under Linux and according to Sun it was a Linux kernel issue rather than a JDK issue. I have now switched to openBSD and hopefully I'll be able to continue the work and commit some code for the clustering package again. I'll try that. There's also an issue with the cookies if you want the cluster to be able to continue a replicated session that origined on a other machine in the cluster. I think that mod_jk might solve this with some sort of rewrite if you run it in loadbalancing mode? Maybe Henri Gomez or someone could comment on this? We are using a hardware-loadbalancer here. It does the cookie-rewriting for us... If you want to try it out and maybe submit some code/patches that would be gladly appreciated. I'll try my best... ;-) Thanks Thomas
Re: Tomcat 4.0 RPMs?
Hi Vic. We're currently trying to sort out the best way of packaging a 4.0 RPM. TC4 has quite a few external jar dependencies ... some optional, some mandatory. We're kind of between a rock and a hard place with both a few of the RPM packaging policies as well as some jar redistribution issues. The prevailing theory seems to be that the RPM should include just the absolute minimum number of jars required to successfully run a minimal build of Tomcat. The rest will still have to be downloaded separately (although we might make a tomcat-supplimental.tar.gz available containing all of the optional jars that we can safely redistribute). The problem is that RPM packaging policies frown upon including external binaries (in our case non-TC jars) in the RPM, and beyond that, doing so is not really good form anyway. In other words, the RPM install isn't going to be as painless as we would like. If you are comfortable with building from source, and if you need anything other than a minimal build, the source might be your best bet. (You could also just download the binaries, of course.) I'm not even sure that an exact approach for TC4 RPMs has been decided upon, and I'm also not sure what Henri's (our RPM packager) timeframe is, so AFAIK the date on having an RPM is still up in the air. Quoting Vic Ricker [EMAIL PROTECTED]: Hi. Will RPMs for Tomcat 4.0 be released on the web site any time soon? I have no problem installing from the tar but I'd prefer the RPM since that's how I installed the previous version. Thanks, -Vic - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
RE: Tomcat 4.0 RPMs?
Hi Vic. We're currently trying to sort out the best way of packaging a 4.0 RPM. TC4 has quite a few external jar dependencies ... some optional, some mandatory. We're kind of between a rock and a hard place with both a few of the RPM packaging policies as well as some jar redistribution issues. I'm still waiting for Craig answer on externals jars avaibility outside Sun site (jta, jmx, ldap, ). I've asked to have them all of them in a tomcat-supplemental tarball available on jakarta.apache.org to have them included in TC 4.0 RPM, of course if license permit that also. Something to be validated by Sun Lawyers. The interest of the RPM is that it provides a ready-to-run solution but it won't be the case if the users need to grab and then install (where) the external jars by hand. Some could think we could get the TC 4.0 binary and package it in RPM but it's also not a solution since RPM policies ask to have a binary generated from one or many sources and in that case it won't be the case. Only some vendors provide RPM like this, JDK/SDK from Sun/IBM for example but these tools are not OpenSource... Until I got a positive answer from Craig, I'll have to delay TC 4.0 RPM (allready done in-house) and I'm more than sorry about that.
Re: Tomcat 4.0-b7 doesnt compile jsp pages
Dear Roland, Please write down the error, else no one can help you. My servlet and Jsp files are runing fine in Tomcat 4.0 beta7 ~ . Ok, here again, I'm using Tomcat 4.0-b7 under Windows NT Server I unzip the Tomcat 4.0-b7 zip file to a directory. Start it, everything seems to run fine. I got to the start page http://localhost:8080 Then I click on the link JSP examples. All examples are listed. If I click on any example that has a link to a JSP page I receive always the SAME error message: A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:852) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:602) etc... Its no surprise, since, if I take a look at tomcat-4.0-b7/work/localhost/examples the directory is EMPTY. I know there should be placed the compiled jsp pages. BUT it is empty. That means, the JSP pages have not been compiled to servelts. Why not? I used Tomcat 4.0-b5 before and never had this problems, everything worked fine. During the startup process there is no error message whatsoever, Catalina works fine. I only get an error message when I try to access the jsp pages. The servlet examples work fine, and if I try to access a pure HTML file trough Tomcat it also works fine, its just the JSP pages that don`t work. Any ideas here? Thanks...Roland
Re: Tomcat 4.0 (7/11) nightly build
Prasad Subramanian [Contractor] at [EMAIL PROTECTED] wrote: Hi , I was trying to get the latest nightly build for Tomcat 4.0 from the website and I found that there are two files a tar.Z and a tar.gz with a size of 1 k. I am unable to get the build from these. I would appreciate any help in getting the latest (07/11) nightly build. Means that the build didn't succeed for that day... Either too much latency on Daedalus while downloading the sources, or something screwed up... Pier
Re: Tomcat 4.0 (7/11) nightly build
On Wed, 11 Jul 2001, Prasad Subramanian [Contractor] wrote: Hi , I was trying to get the latest nightly build for Tomcat 4.0 from the website and I found that there are two files a tar.Z and a tar.gz with a size of 1 k. I am unable to get the build from these. I would appreciate any help in getting the latest (07/11) nightly build. My bad ... problems on my home machine where they are generated. I *think* it's fixed for tonight. Thnaks Prasad Craig
Re: Tomcat 4.0 (7/11) nightly build
Prasad Subramanian [Contractor] at [EMAIL PROTECTED] wrote: Hi , I was trying to get the latest nightly build for Tomcat 4.0 from the website and I found that there are two files a tar.Z and a tar.gz with a size of 1 k. I am unable to get the build from these. I would appreciate any help in getting the latest (07/11) nightly build. Means that the build didn't succeed for that day... Either too much latency on Daedalus while downloading the sources, or something screwed up... I think the builds are down because of the servlet API update. Remy
Re: tomcat-4.0-doc/config/index.html in Netscape 6
kris at [EMAIL PROTECTED] wrote: tomcat-4.0-doc/config/index.html does not view in Netscape 6 Forwarding to the Tomcat developers mailing list. Pire
Re: Tomcat 4.0/Solaris why doesn't tomcat follow soft links?
Craig, Thanks! I missed that in the docs when I first went through them. I found the documentation on this feature, and now am wondering how much you know about it. On the system I am forced to configure this on, the users accounts are mounted from a central nfs server. This means that they do not have entries in the /etc/passwd file, which I gather from the documentation is used to generate the default Contexts. It appears there is a homeBase option which allows you to specify the location of a series of home directories. Do you know if I can use /home, as the students directories are automounted there? Or do the home directories have to be hardmounted? I'm experimenting with this option on a test server I have, and haven't gotten it to work with a test case yet...If I get something working I'll let you know. A very appreciative, Bob Evans At 10:56 AM 6/14/2001 -0700, you wrote: On Thu, 14 Jun 2001, Robert Evans wrote: Greetings, I am in the process of configuring Tomcat to be used with several classes at the Johns Hopkins University. I would like to have each student have their own webapp in their public_html directory. I tried Tomcat 3.2.1, but couldn't get the security policy to work right (all jsp pages kept wanting to use the examples directory?) I am trying Tomcat 4.0B5, and was going to use soft links in the webapps directory to point to each students public_html directory. The only problem is that Tomcat doesn't seem to want to follow the soft links. If I make a real directory in the webapps dir, everything works fine, but if I try to use a soft linked one, I get: Http Status 503 - This application is not currently available The requested service(This application is not currently available) is not currently available Any suggestions/help would be greatly appreciated. If I don't get this working within a week, it'll be back to the Java Web Server. :-( Bob Not following symlinks is an unfortunate side effect of the processing that Tomcat has to do to avoid directory name spoofing (/WeB-iNf) on case insensitive platforms). :-( For Tomcat 4, have you tried using the user home directories option, to automatically recognize each student's public_html directory? This will save you having to configure them all into server.xml: Host name=localhost ... ... Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase/ ... /Host Craig McClanahan
Re: Tomcat 4.0/Solaris server.xml file and public_html option
Craig, I figured I'd follow up on my last question with one more, since I noticed that the in the documentation there is a sample bit of code that says http://www.mycompany.com:8080/~craigmcc, which I am assuming is you...indicating you may indeed know quite a bit about this particular feature. Unfortunately, I have been unable to get anything to work yet, even on my test server. In my server.xml file under the Host name=localhost ... section, I have: !-- Automatically map a request path starting with a tilde character(~) and a username to a directory. In this case to ~username/public.html -- Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html homeBase=/export/home userClass=org.apache.catalina.startup.PasswdUserDatabase/ I tried this with and without the homeBase option above. I am using my own account as a test. The entry in the /etc/passwd file is as follows: rbevans:x:5756:20:Robert Evans:/home/rbevans:/bin/csh The account is automounted from /export/home/rbevans. I tried the /export/home and /home options to homeBase, neither worked. Any comments, hints or suggestions? Bob At 10:56 AM 6/14/2001 -0700, you wrote: On Thu, 14 Jun 2001, Robert Evans wrote: Greetings, I am in the process of configuring Tomcat to be used with several classes at the Johns Hopkins University. I would like to have each student have their own webapp in their public_html directory. I tried Tomcat 3.2.1, but couldn't get the security policy to work right (all jsp pages kept wanting to use the examples directory?) I am trying Tomcat 4.0B5, and was going to use soft links in the webapps directory to point to each students public_html directory. The only problem is that Tomcat doesn't seem to want to follow the soft links. If I make a real directory in the webapps dir, everything works fine, but if I try to use a soft linked one, I get: Http Status 503 - This application is not currently available The requested service(This application is not currently available) is not currently available Any suggestions/help would be greatly appreciated. If I don't get this working within a week, it'll be back to the Java Web Server. :-( Bob Not following symlinks is an unfortunate side effect of the processing that Tomcat has to do to avoid directory name spoofing (/WeB-iNf) on case insensitive platforms). :-( For Tomcat 4, have you tried using the user home directories option, to automatically recognize each student's public_html directory? This will save you having to configure them all into server.xml: Host name=localhost ... ... Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase/ ... /Host Craig McClanahan
Re: Tomcat 4.0/Solaris why doesn't tomcat follow soft links?
On Fri, 15 Jun 2001, Robert Evans wrote: Craig, Thanks! I missed that in the docs when I first went through them. I found the documentation on this feature, and now am wondering how much you know about it. On the system I am forced to configure this on, the users accounts are mounted from a central nfs server. This means that they do not have entries in the /etc/passwd file, which I gather from the documentation is used to generate the default Contexts. It appears there is a homeBase option which allows you to specify the location of a series of home directories. Do you know if I can use /home, as the students directories are automounted there? Or do the home directories have to be hardmounted? I'm experimenting with this option on a test server I have, and haven't gotten it to work with a test case yet...If I get something working I'll let you know. Well, since you're willing to be a bleeding edge pioneer (and since I wrote this stuff), I'd *better* be willing to help! :-) If the users do not have entries in /etc/passwd, you are going to want to use an alternative strategy to tell Tomcat what directories to look at. Try something like this: Listener className=org.apache.catalina.startup.UserConfig directory_name=public_html homeBase=/home userClass=org.apache.catalina.startup.HomesUserDatabase/ The key difference is that we're using a different userClass attribute -- the one that says mount all the user directories found in the directory named by the 'homeBase' attribute instead of the one that says mount all the user directories found in /etc/passwd. Note also that, currently, Tomcat requires a user's public_html directory to have a WEB-INF/web.xml file in it before it's recognized as a web app. That requirement is subject to negotiation (or perhaps even a configuration flag) as far as I'm concerned, but it seemed correct when I originally wrote this code. And, of course, the operating system username under which you're running Tomcat must have read access to the contents of the users's public_html directories, and all the directories above them in the filesystem. A very appreciative, Bob Evans Craig At 10:56 AM 6/14/2001 -0700, you wrote: On Thu, 14 Jun 2001, Robert Evans wrote: Greetings, I am in the process of configuring Tomcat to be used with several classes at the Johns Hopkins University. I would like to have each student have their own webapp in their public_html directory. I tried Tomcat 3.2.1, but couldn't get the security policy to work right (all jsp pages kept wanting to use the examples directory?) I am trying Tomcat 4.0B5, and was going to use soft links in the webapps directory to point to each students public_html directory. The only problem is that Tomcat doesn't seem to want to follow the soft links. If I make a real directory in the webapps dir, everything works fine, but if I try to use a soft linked one, I get: Http Status 503 - This application is not currently available The requested service(This application is not currently available) is not currently available Any suggestions/help would be greatly appreciated. If I don't get this working within a week, it'll be back to the Java Web Server. :-( Bob Not following symlinks is an unfortunate side effect of the processing that Tomcat has to do to avoid directory name spoofing (/WeB-iNf) on case insensitive platforms). :-( For Tomcat 4, have you tried using the user home directories option, to automatically recognize each student's public_html directory? This will save you having to configure them all into server.xml: Host name=localhost ... ... Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase/ ... /Host Craig McClanahan
Re: Tomcat 4.0/Solaris why doesn't tomcat follow soft links?
On Thu, 14 Jun 2001, Robert Evans wrote: Greetings, I am in the process of configuring Tomcat to be used with several classes at the Johns Hopkins University. I would like to have each student have their own webapp in their public_html directory. I tried Tomcat 3.2.1, but couldn't get the security policy to work right (all jsp pages kept wanting to use the examples directory?) I am trying Tomcat 4.0B5, and was going to use soft links in the webapps directory to point to each students public_html directory. The only problem is that Tomcat doesn't seem to want to follow the soft links. If I make a real directory in the webapps dir, everything works fine, but if I try to use a soft linked one, I get: Http Status 503 - This application is not currently available The requested service(This application is not currently available) is not currently available Any suggestions/help would be greatly appreciated. If I don't get this working within a week, it'll be back to the Java Web Server. :-( Bob Not following symlinks is an unfortunate side effect of the processing that Tomcat has to do to avoid directory name spoofing (/WeB-iNf) on case insensitive platforms). :-( For Tomcat 4, have you tried using the user home directories option, to automatically recognize each student's public_html directory? This will save you having to configure them all into server.xml: Host name=localhost ... ... Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase/ ... /Host Craig McClanahan
RE: Tomcat 4.0/Solaris why doesn't tomcat follow soft links?
We have for all developers apache + tomcat running on different ports. (7401, 7501, 7601 and 7701). Most of the stuff from apache is symlinked and the core of tomcat is shared. so the home directory looks a bit like this : (please think /home/username/ in front of the directories apache bin (shell scripts such as tomcat.sh, startup.sh, apachectl etc) conf (tomcat and apache conf, using the correct port numbers) devel (developers stuff, such as checkout) htdocs lib logs - /home/martin/apache/logs shared - /home/shared webapps work Have fun, Martin van den Bemt -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 7:56 PM To: Robert Evans Cc: [EMAIL PROTECTED] Subject: Re: Tomcat 4.0/Solaris why doesn't tomcat follow soft links? On Thu, 14 Jun 2001, Robert Evans wrote: Greetings, I am in the process of configuring Tomcat to be used with several classes at the Johns Hopkins University. I would like to have each student have their own webapp in their public_html directory. I tried Tomcat 3.2.1, but couldn't get the security policy to work right (all jsp pages kept wanting to use the examples directory?) I am trying Tomcat 4.0B5, and was going to use soft links in the webapps directory to point to each students public_html directory. The only problem is that Tomcat doesn't seem to want to follow the soft links. If I make a real directory in the webapps dir, everything works fine, but if I try to use a soft linked one, I get: Http Status 503 - This application is not currently available The requested service(This application is not currently available) is not currently available Any suggestions/help would be greatly appreciated. If I don't get this working within a week, it'll be back to the Java Web Server. :-( Bob Not following symlinks is an unfortunate side effect of the processing that Tomcat has to do to avoid directory name spoofing (/WeB-iNf) on case insensitive platforms). :-( For Tomcat 4, have you tried using the user home directories option, to automatically recognize each student's public_html directory? This will save you having to configure them all into server.xml: Host name=localhost ... ... Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase/ ... /Host Craig McClanahan
Re: tomcat-4.0 and JSP class reloading
i was litlle un detailed sorry but i try to explain.
This can be test with Tomcat 4.0 b6-dev (last week CVS version at least i haven't see
this to be fixed)
make app dir like test/ then create index.jsp.
make some class like test.testIt that context is like
package test;
public class TestIt
public TestIt
}
public int getNumber(){
return 303
}
public String getString(){
return TestString
}
}
and turn reloading on to test/ context then create servlet that uses this Class
[test.TestIt] (i think you know how to do it) make it print number and string to HTML
page. then do same to index.jsp (i all so think you can do it)
then compile these to test/WEB-INF/classes and run tomcat. then Look what you have
there (what are outputs) and changes those string and number and recompile classes.
after about 15 secs servlet has new context but JSP doesn't. I allready have fix this
and submit a patch but now one have replyed anything:) it's just a little bug there..
Tuukka
ps. need for more details??
pss. if someone allready has this fixed he/she is really glad because this BUG forces
to stop Tomcat and reload it again everytime when Classes that belongs to JSP changes.
I have spent to much time waiting:P
---
--Me olemme keskella jotain. jossa olemme totaalisen ulkopuolisia--
On Wed, 30 May 2001 10:46:39
Craig R. McClanahan wrote:
On Wed, 30 May 2001, Tuukk4 |[:)-| p4s4n3n wrote:
hey, Is anyone fixing that point? Problem is that JSP doesn't reload
classes when servlet container in same context does?
Can you provide a small example that illustrates this?
Tuukka
Craig McClanahan
Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/
Re: tomcat-4.0 and JSP class reloading
See below. On Thu, 31 May 2001, Remy Maucherat wrote: i was litlle un detailed sorry but i try to explain. This can be test with Tomcat 4.0 b6-dev (last week CVS version at least i haven't see this to be fixed) and turn reloading on to test/ context then create servlet that uses this Class [test.TestIt] (i think you know how to do it) make it print number and string to HTML page. then do same to index.jsp (i all so think you can do it) then compile these to test/WEB-INF/classes and run tomcat. then Look what you have there (what are outputs) and changes those string and number and recompile classes. after about 15 secs servlet has new context but JSP doesn't. I allready have fix this and submit a patch but now one have replyed anything:) it's just a little bug there.. Tuukka ps. need for more details?? pss. if someone allready has this fixed he/she is really glad because this BUG forces to stop Tomcat and reload it again everytime when Classes that belongs to JSP changes. I have spent to much time waiting:P Ok, I understand the bug a bit better now. To fix it, I would always load the external classes using the thread's context class loader instead of trying to keep an up to date reference on it, using something like : RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/Jasp erLoader.java,v retrieving revision 1.3 diff -r1.3 JasperLoader.java 174c174 // Class is in a package, delegate to parent --- // Class is in a package, delegate to thread context class loader 176c176,177 clazz = parent.loadClass(name); --- clazz = Thread.currentThread().getContextClassLoader() .loadClass(name); [ Note : Since the parent is now not used anymore, a lot of useless code should be removed. ] I'm not a Jasper guru, so I don't know if it's a good idea to do this. Remy I'm not sure this proposed change would really make any difference. The parent classloader here is the web app classloader already, which is the same thing that the context class loader is set to. NOTE: If we do something like this, we need to make sure that getResource() and getResourceAsStream() work in JasperLoader as well. I'll do some more investigation today. Craig
Re: tomcat-4.0 and JSP class reloading
Quoting Craig R. McClanahan [EMAIL PROTECTED]: See below. On Thu, 31 May 2001, Remy Maucherat wrote: I'm not sure this proposed change would really make any difference. The parent classloader here is the web app classloader already, which is the same thing that the context class loader is set to. NOTE: If we do something like this, we need to make sure that getResource() and getResourceAsStream() work in JasperLoader as well. I'll do some more investigation today. Apparently, the problem was that the parent reference wasn't reset after reloading. So using a dynamic call would solve this. Remy
Re: tomcat-4.0 and JSP class reloading
On Thu, 31 May 2001 12:40:34
Remy Maucherat wrote:
Quoting Craig R. McClanahan [EMAIL PROTECTED]:
See below.
On Thu, 31 May 2001, Remy Maucherat wrote:
I'm not sure this proposed change would really make any difference.
The
parent classloader here is the web app classloader already, which is
the
same thing that the context class loader is set to.
NOTE: If we do something like this, we need to make sure that
getResource() and getResourceAsStream() work in JasperLoader as well.
I'll do some more investigation today.
Apparently, the problem was that the parent reference wasn't reset after
reloading. So using a dynamic call would solve this.
Remy
hey,
I can show point because i know i have been workin on this problem a while (2 weeks).
Main problem is in org.apache.catalina.loader.StandardLoader in setClassLoader()
method and there in
if (servletContext instanceof ApplicationContext)
((ApplicationContext) servletContext).setAttributeReadOnly
(Globals.CLASS_LOADER_ATTR);
Because this preverts ClassLoader rereshing for Jasper (One can write only once).
Then we have to 'ReLoad' reloaded ClassLoader in org.apache.jasper.servlet.JspServlet
e.g in
loadJSP(String jspUri, String classpath,
boolean isErrorPage, HttpServletRequest req,
HttpServletResponse res)
Because Jasper's ClassLoader doesn't point to our new ClassLoader
URLClassLoader classLoader =
(URLClassLoader)context.getAttribute(Constants.SERVLET_CLASS_LOADER);
if(classLoader != parentClassloader){
..Do the securing stuff..
}
and make little If whether it has changed or not.
this is simpliest Answer and were the 'problem' is.
after this everything has worked for me just fine:)
Tuukka
ps. I can submit a patch:)
Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/
Re: tomcat-4.0 and JSP class reloading
On Wed, 30 May 2001, Tuukk4 |[:)-| p4s4n3n wrote: hey, Is anyone fixing that point? Problem is that JSP doesn't reload classes when servlet container in same context does? Can you provide a small example that illustrates this? Tuukka Craig McClanahan
Re: Tomcat 4.0 Beta3 and Request Attributes Error - why me ?
Hello Ana, Wednesday, May 02, 2001, 8:23:09 PM, you wrote: A Hi, Hello! A We think we have discovered an error. That's nice! But why are you mailing me? I'm not a tomcat developer! :-) Best regards, Anthonymailto:[EMAIL PROTECTED]
RE: Tomcat 4.0 Beta3 and Request Attributes Error
RequestDispatcher.forward() returns immediately BUT the JSP page has not
been processed yet! The JSP page will only be processed after the servlet
finishes the work, i.e., your doGet or doPost returns. Therefore, there is
no way to access attributes in the JSP page inside the calling servlet.
Cheers,
Charles Chen
-Original Message-
From: Ana [mailto:[EMAIL PROTECTED]]
Sent: 02 May 2001 17:23
To: :
Subject: Tomcat 4.0 Beta3 and Request Attributes Error
Hi,
We think we have discovered an error. We call the include method of the
RequestDispatcher from a servlet. Then, we call the setAttribute method
of the request object of the included JSP. If we call the getAttribute
method of the request object in the servlet (after the include call), then
there is not attribute.
Example:
MyServlet.java:
...
public void service(ServletRequest request, ServletResponse response){
...
getServletConfig().getServletContext().getRequestDispatcher(MyJSP.jsp).for
ward(request,
response);
Object obj = request.getAttribute(MyAttribute);
// obj is null
...
}
MyJSP.jsp:
...
request.setAttribute(MyAttribute, obj);
...
Thank you.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Tomcat 4.0 Beta3 and Request Attributes Error
On Wed, 2 May 2001, Ana wrote: Hi, We think we have discovered an error. We call the include method of the RequestDispatcher from a servlet. Then, we call the setAttribute method of the request object of the included JSP. If we call the getAttribute method of the request object in the servlet (after the include call), then there is not attribute. Yes, you definitely found an error. The spec is silent on whether an included servlet can modify the request attributes of the request it receives, but it seems like an obviously useful thing that should be possible. I just checked in a patch to fix it, which will show up in tonight's nightly build (20010503). Craig McClanahan
Re: Tomcat 4.0 Beta3 and Request Attributes Error
On Wed, 2 May 2001, Ana wrote: Hi, We think we have discovered an error. We call the include method of the RequestDispatcher from a servlet. Then, we call the setAttribute method of the request object of the included JSP. If we call the getAttribute method of the request object in the servlet (after the include call), then there is not attribute. Yes, you definitely found an error. The spec is silent on whether an included servlet can modify the request attributes of the request it receives, but it seems like an obviously useful thing that should be possible. I just checked in a patch to fix it, which will show up in tonight's nightly build (20010503). Really ? According to the spec (#8.3), I was under the impression that the included servlet couldn't do anything but : - Write data to either the Writer or the OutputStream - Access (and I understood that as read) the request object So to be consistent with what is done with everything else, I wouldn't allow the modification. Perhaps we should ask the question to Danny ;-) Remy
Re: Tomcat 4.0 Beta3 and Request Attributes Error
On Wed, 2 May 2001, Remy Maucherat wrote: On Wed, 2 May 2001, Ana wrote: Hi, We think we have discovered an error. We call the include method of the RequestDispatcher from a servlet. Then, we call the setAttribute method of the request object of the included JSP. If we call the getAttribute method of the request object in the servlet (after the include call), then there is not attribute. Yes, you definitely found an error. The spec is silent on whether an included servlet can modify the request attributes of the request it receives, but it seems like an obviously useful thing that should be possible. I just checked in a patch to fix it, which will show up in tonight's nightly build (20010503). Really ? According to the spec (#8.3), I was under the impression that the included servlet couldn't do anything but : - Write data to either the Writer or the OutputStream - Access (and I understood that as read) the request object So to be consistent with what is done with everything else, I wouldn't allow the modification. Perhaps we should ask the question to Danny ;-) For those who don't know who Danny is, that is Danny Coward -- specification lead for the servlet spec. I did ask. He agreed that it's not spec'd but that it makes sense to give the included servlet a sense that it is talking to the same request that the calling servlet is, even though it's not technically true. The only change that the original servlet can make when it accesses the request is to set or remove attributes, so an included servlet should be able to as well. Remy Craig
RE: Tomcat 4.0-beta-2 Security Vulnerability
I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. +1 for Tomcat-4.0-beta-3 And what about including in TC 4.0b3 my patches which help build tc 4.0 on non standard distro, ie jsse.jar not in JSSE_HOME/lib or jmxri.jar not in JMX_HOME/lib.
Re: Tomcat 4.0-beta-2 Security Vulnerability
Jon Stevens wrote: on 4/2/01 2:20 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? Craig -1 on an update. it just adds confusion imho and i don't see a reason to resist having many beta releases. Just make a beta 3. -jon I agree, beta 3 avoids confusion. +1 for a beta 3 release. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat 4.0-beta-2 Security Vulnerability
- Original Message - From: "Glenn Nielsen" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 12:39 AM Subject: Re: Tomcat 4.0-beta-2 Security Vulnerability Jon Stevens wrote: on 4/2/01 2:20 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? Craig -1 on an update. it just adds confusion imho and i don't see a reason to resist having many beta releases. Just make a beta 3. -jon I agree, beta 3 avoids confusion. +1 for a beta 3 release. Glenn +1 for beta 3 ;-) is too confusing to create update version
Re: Tomcat 4.0-beta-2 Security Vulnerability
--- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. By labeling it 'beta-3' it is CLEARLY the latest build and CLEARLY newer than beta-2. fwiw, Dr. Mel Martinez G1440, Inc. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: Tomcat 4.0-beta-2 Security Vulnerability
On Mon, 2 Apr 2001, Mel Martinez wrote: --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. By labeling it 'beta-3' it is CLEARLY the latest build and CLEARLY newer than beta-2. Makes sense to me. "Beta 3" it is. fwiw, Dr. Mel Martinez G1440, Inc. Craig
Re: Tomcat 4.0-beta-2 Security Vulnerability
And I think it is also good to state in the mail-announcement and in the jakarta website that the b2 have such security vulnerability when b3 is rolled out. Punky - Original Message - From: "Craig R. McClanahan" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 7:38 AM Subject: Re: Tomcat 4.0-beta-2 Security Vulnerability On Mon, 2 Apr 2001, Mel Martinez wrote: --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. By labeling it 'beta-3' it is CLEARLY the latest build and CLEARLY newer than beta-2. Makes sense to me. "Beta 3" it is. fwiw, Dr. Mel Martinez G1440, Inc. Craig
Re: Tomcat 4.0-beta-2 Security Vulnerability
On Tue, 3 Apr 2001, Punky Tse wrote: And I think it is also good to state in the mail-announcement and in the jakarta website that the b2 have such security vulnerability when b3 is rolled out. It will. The beta-2 release is also going to get pulled so that no one will download it accidentally. Punky Craig - Original Message - From: "Craig R. McClanahan" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 7:38 AM Subject: Re: Tomcat 4.0-beta-2 Security Vulnerability On Mon, 2 Apr 2001, Mel Martinez wrote: --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. By labeling it 'beta-3' it is CLEARLY the latest build and CLEARLY newer than beta-2. Makes sense to me. "Beta 3" it is. fwiw, Dr. Mel Martinez G1440, Inc. Craig
Re: Tomcat 4.0 Class Loader Reorganization
Hi, I build tomcat-4.0 from CVS this morning and tried it with the TDK and everything looks good! No "sealing violoation", and the XML-RPC service which requires xerces started up without a hitch. It was starting the XML-RPC service which made the "sealing violation" visible. I haven't tried Jetspeed but I assume it will fix the problem they are seeing as well. Thanks! jvz. someone (jason?) wanna test this? -jon -- From: "Craig R. McClanahan" [EMAIL PROTECTED] Date: Sat, 17 Feb 2001 19:40:29 -0800 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Tomcat 4.0 Class Loader Reorganization I've changed the way that Tomcat 4.0 loads classes so that we should no longer have the "package sealing violation" problems! It should be possible to plug and play any app that has Xerces in its "WEB-INF/lib" directory, even if that app also chooses to use JSP pages (which rely on the JAXP 1.1 parser, which is causing the package sealing issues). I'd appreciate it if you guys would try tonight's nightly build with Cocoon and Turbine based apps, and report any problems that you run into, so that we can fix them before a "beta 2" release of Tomcat 4.0. Craig To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/turbine%40list.working-dogs.com/ Problems?: [EMAIL PROTECTED] To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/turbine%40list.working-dogs.com/ Problems?: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 4.0 and JSP
Maybe he was concerned about users like you. -Original Message- From: John Golubenko [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 07:43 Why would you complain about HTML mail, if you using M$ software (outlook)? If you were the person like me, the Linux user, then I'll understand. ;) Original Message On 2/13/01, 10:19:16 PM, "Remy Maucherat" [EMAIL PROTECTED] wrote regarding Re: Tomcat 4.0 and JSP: How in apache do I get all my .jsp files to be executed by tomcat. Even when I use the WebAppMount, the servlets work, but it won't execute the jsp. Basically I don't car about servlets, I just want my server to recognize any *.jsp and have tomcat 4.0 execute without having to specify a port in the URL like 8080. There are a few things I would do : - Don't send HTML mails to mailing lists ;) - You can run TC 3.2 with Apache just fine. mod_webapp is very alphaish right now. - You can run TC 4.0 standalone. The port on which the HTTP connector runs can be changed in the conf/server.xml file (so set it to be 80 instead of 8080). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4.0 and JSP
1) It's a good habit to get into. HTML mail is evil, wastes bandwidth and most mailers won't format it. 2) If you post html to say, [EMAIL PROTECTED], you would get flamed so hard your mailbox would be filled for months to come. 3) JUST DON't DO IT! Oh, and wrap at 76 characters too please :-) -Thom * John Golubenko ([EMAIL PROTECTED]) wrote on Wed Feb 14, 2001 at 06:42:45 +: Why would you complain about HTML mail, if you using M$ software=20 (outlook)? If you were the person like me, the Linux user, then I'll understand. ;)= Original Message On 2/13/01, 10:19:16 PM, "Remy Maucherat" [EMAIL PROTECTED] wrote regard= ing=20 Re: Tomcat 4.0 and JSP: How in apache do I get all my .jsp files to be executed by tomcat. Even when I use the WebAppMount, the servlets work, but it won't exe= cute the jsp. Basically I don't car about servlets, I just want my serve= r to recognize any *.jsp and have tomcat 4.0 execute without having to= specify a port in the URL like 8080. There are a few things I would do : - Don't send HTML mails to mailing lists ;) - You can run TC 3.2 with Apache just fine. mod_webapp is very alphais= h right now. - You can run TC 4.0 standalone. The port on which the HTTP connector = runs can be changed in the conf/server.xml file (so set it to be 80 instead= of 8080). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4.0 and JSP
How in apache do I get all my .jsp files to be executed by tomcat. Even when I use the WebAppMount, the servlets work, but it won't execute the jsp. Basically I don't car about servlets, I just want my server to recognize any *.jsp and have tomcat 4.0 execute without having to specify a port in the URL like 8080. There are a few things I would do : - Don't send HTML mails to mailing lists ;) - You can run TC 3.2 with Apache just fine. mod_webapp is very alphaish right now. - You can run TC 4.0 standalone. The port on which the HTTP connector runs can be changed in the conf/server.xml file (so set it to be 80 instead of 8080). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4.0 and JSP
Why would you complain about HTML mail, if you using M$ software (outlook)? If you were the person like me, the Linux user, then I'll understand. ;) Original Message On 2/13/01, 10:19:16 PM, "Remy Maucherat" [EMAIL PROTECTED] wrote regarding Re: Tomcat 4.0 and JSP: How in apache do I get all my .jsp files to be executed by tomcat. Even when I use the WebAppMount, the servlets work, but it won't execute the jsp. Basically I don't car about servlets, I just want my server to recognize any *.jsp and have tomcat 4.0 execute without having to specify a port in the URL like 8080. There are a few things I would do : - Don't send HTML mails to mailing lists ;) - You can run TC 3.2 with Apache just fine. mod_webapp is very alphaish right now. - You can run TC 4.0 standalone. The port on which the HTTP connector runs can be changed in the conf/server.xml file (so set it to be 80 instead of 8080). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
This is a good idea. And as we already did with watchdog we should do the same here. +1 for the change. Thanks -Ramesh Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Date: Thu, 01 Feb 2001 09:30:19 -0800 From: "Craig R. McClanahan" [EMAIL PROTECTED] X-Accept-Language: en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: [Tomcat 4.0] Proposed Change in Build Scripts Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N There is movement in the various Jakarta subprojects towards modifying build scripts so that "build" and "dist" targets are created *within* the top-level source directory, rather than "up and over" the way they are now. For Tomcat 4.0, that would mean you'd end up with the following directory structure: jakarta-tomcat-4.0 build/-- Build destination for Tomcat dist/ -- Dist destinatino for Tomcat catalina/ build/-- Build destination for Catalina portion dist/ -- Dist destination for Catalina portion (and so on for other subdirectories). When executing the Tomcat you just built, the only difference is that you would set CATALINA_HOME to point at "jakarta-tomcat-4.0/build" or "jakarta-tomcat-4.0/dist" instead of "../build/tomcat-4.0" or "../dist/tomcat-4.0". I propose to change all of the build scripts (and associated README files) to reflect this new structure, in time for the next beta release. Comments? Thoughts? Questions? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
This makes a heck of a lot of sense to me... ( an unofficial +1 I guess :) David - Original Message - From: "Craig R. McClanahan" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 01, 2001 09:30 Subject: [Tomcat 4.0] Proposed Change in Build Scripts There is movement in the various Jakarta subprojects towards modifying build scripts so that "build" and "dist" targets are created *within* the top-level source directory, rather than "up and over" the way they are now. For Tomcat 4.0, that would mean you'd end up with the following directory structure: jakarta-tomcat-4.0 build/-- Build destination for Tomcat dist/ -- Dist destinatino for Tomcat catalina/ build/-- Build destination for Catalina portion dist/ -- Dist destination for Catalina portion (and so on for other subdirectories). When executing the Tomcat you just built, the only difference is that you would set CATALINA_HOME to point at "jakarta-tomcat-4.0/build" or "jakarta-tomcat-4.0/dist" instead of "../build/tomcat-4.0" or "../dist/tomcat-4.0". I propose to change all of the build scripts (and associated README files) to reflect this new structure, in time for the next beta release. Comments? Thoughts? Questions? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
GOMEZ Henri wrote: And +1 for TC 3.x branch. Yes, please. =) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Tomcat 4.0] Proposed Change in Build Scripts
+1 And +1 for TC 3.x branch. On ne peut rsoudre les problmes les plus graves avec le mme esprit qui les a cres. -- Albert Einstein -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 01, 2001 7:45 PM To: [EMAIL PROTECTED] Subject: Re: [Tomcat 4.0] Proposed Change in Build Scripts Craig R. McClanahan wrote: I propose to change all of the build scripts (and associated README files) to reflect this new structure, in time for the next beta release. +1. Please add appropriate .cvsignore files. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
on 2/1/01 9:30 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: There is movement in the various Jakarta subprojects towards modifying build scripts so that "build" and "dist" targets are created *within* the top-level source directory, rather than "up and over" the way they are now. YEA! -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
"Craig R. McClanahan" wrote: jakarta-tomcat-4.0 build/-- Build destination for Tomcat dist/ -- Dist destinatino for Tomcat catalina/ build/-- Build destination for Catalina portion dist/ -- Dist destination for Catalina portion (and so on for other subdirectories). You have a big (non-binding, of course) +1 from me. Having a script create files "up and over" its own directory was always a little bizarre. This new approach is much more *nix standard and makes for a cleaner directory structure overall ... much easier to explain when telling someone how to build Tomcat. Regards, Christopher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
Craig R. McClanahan wrote: I propose to change all of the build scripts (and associated README files) to reflect this new structure, in time for the next beta release. +1. Please add appropriate .cvsignore files. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Tomcat 4.0] Proposed Change in Build Scripts
As long as this works with sandboxing different versions of the system, it should be fine. That is, jakarta-tomcat-4.0 will use, by default, the ant in ../jakarta-ant/dist and the servlet api in ../jakarta-servletapi-4/dist, and so on. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 01, 2001 12:30 PM To: [EMAIL PROTECTED] Subject: [Tomcat 4.0] Proposed Change in Build Scripts There is movement in the various Jakarta subprojects towards modifying build scripts so that "build" and "dist" targets are created *within* the top-level source directory, rather than "up and over" the way they are now. For Tomcat 4.0, that would mean you'd end up with the following directory structure: jakarta-tomcat-4.0 build/-- Build destination for Tomcat dist/ -- Dist destinatino for Tomcat catalina/ build/-- Build destination for Catalina portion dist/ -- Dist destination for Catalina portion (and so on for other subdirectories). When executing the Tomcat you just built, the only difference is that you would set CATALINA_HOME to point at "jakarta-tomcat-4.0/build" or "jakarta-tomcat-4.0/dist" instead of "../build/tomcat-4.0" or "../dist/tomcat-4.0". I propose to change all of the build scripts (and associated README files) to reflect this new structure, in time for the next beta release. Comments? Thoughts? Questions? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Proposed Change in Build Scripts
Craig R. McClanahan [EMAIL PROTECTED] wrote: jakarta-tomcat-4.0 build/-- Build destination for Tomcat dist/ -- Dist destinatino for Tomcat catalina/ build/-- Build destination for Catalina portion dist/ -- Dist destination for Catalina portion Oh yes... You got a +252 from me :) Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] I'm selling my Sony Vaio Z505. Check out http://www.betaversion.org/~pier/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4.0 merge done
Remy Maucherat wrote: I've just completed the merge, which was way easier to do than what I expected. Feel free to send bugs reports / comments ... Remy, the new code causes three Watchdog-4.0 test fails: /jsp-tests/jsp/tagext/tld_resource_path/positive_JAR_URI.jsp /jsp-tests/jsp/tagext/tld_resource_path/positive_JAR_URIXML.jsp /servlet-tests/GetResource_1Test All of these tests pass in 4.0-b1. Remy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4.0] Updated Documentation
Craig R. McClanahan typed the following on 09:06 PM 1/13/2001 -0800 The information that is presented in the Server Configuration section is all up to date AFAIKT, but several sections are not yet written. With this, as with the rest of the docs (and the code, of course :-), feel free to suggest changes, send patches, or volunteer to do some of the writing! I can do the Manager section, since I've been mucking around with that code recently. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [tomcat-4.0] Session Creation Slowness
I have confirmed that: The latest nightly build fixes this problem and Turbine/Catalina now starts up and initializes and returns a request in about 3-4 seconds on my machine...more than acceptable now. :-) thanks craig for tracking it down. this is going to save months of development time. :-) -jon
Re: [tomcat-4.0] Session Creation Slowness
Jon Stevens wrote:
Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...
Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");
As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...
[Thu Dec 21 13:34:15 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE -- RunDataFactory: 12
This is the first session create since the webapp was started, right?
Currently, that is when the RNG is initialized.
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 12
And this is the behavior you would see after the first one.
As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.
The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).
That's definitely strange ... 4-5 seconds is my experience even on much slower
hardware, on both 1.2.2 and 1.3.
So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.
This part isn't. Aleady on my TODO list is moving the RNG initialization to
webapp startup time -- that will normally hide it for a 4-5 second delay, but
certainly won't fix a 45-second delay.
If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).
http://scarab.tigris.org/
You mean it's not just "check out, compile, and run"??? :-) :-)
Will do.
thanks,
-jon
Craig
RE: [tomcat-4.0] Session Creation Slowness
This is probably due to the new SecureRandom-based session IDs.
There is an option to turn that off somewhere.
-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 21, 2000 1:47 PM
To: tomcat-dev
Cc: [EMAIL PROTECTED]
Subject: [tomcat-4.0] Session Creation Slowness
Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...
Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");
As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...
[Thu Dec 21 13:34:15 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE -- RunDataFactory: 12
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 12
As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.
The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).
So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.
If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).
http://scarab.tigris.org/
thanks,
-jon
RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
For the large ones, like GCC, the recommended way is to build in an obj directory outside of the source directory. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 1:08 PM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard) I agree with Stuart! Let me also state that 99% of the OSS C projects built with "configure" out there build into their own directory by default. However, most have the option to build to another directory. That is something I'm willing to support. -jon on 12/15/2000 7:45 AM, "Stuart Roebuck" [EMAIL PROTECTED] wrote: On Friday, December 15, 2000, at 03:24 PM, [EMAIL PROTECTED] wrote: /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. +1 ! I would be inclined to change 'not nice' to 'potentially dangerous', because any build script that alters files outside the checkout by default may cause harm. It relies on assumptions that: 1. developers have write access to the parent directory 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". You make them all and... disaster... All the jakarta projects have put their builds into named directories inside the directory with my favourite "build" build tool - messing it up with extra files that are nothing to do with it. Then "omega" completely wiped my build directory when I did a clean build - it doesn't use subdirectories of "../build". I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Being able to build outside of the checkout is an option some users may prefer, but I don't think we should be providing this as a default unless we can be sure of the 3 assumptions above. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Mac OS X, Java, XML, etc. ADOLOS http://www.adolos.com/ -- Honk if you love peace and quiet. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
Re: [tomcat-4.0] bug in directory listing
It doesn't include the port number in the links of the output and therefore, the links are invalid. Also, what is responsible for generating the directory listings? I tried to find the source code for it so that I could patch it myself, but I couldn't find it! Originally it was in DefaultServlet, but now it's in resources.DirectoryBean. I'll move the code back to the DefaultServlet, eventually (we plan to remove the Resources stuff after 4.0). Remy
Re: [tomcat 4.0] Turning off random number seeding
Jon, I thought the RNG only took around 5 seconds on that kind of machine. Are you sure it's not classloading taking the time? I found removing the manifest from my .jar files can make up to an order of magnitude difference on some servlet engines... Cheers Geoff - Original Message - From: "Jon Stevens" [EMAIL PROTECTED] To: "tomcat-dev" [EMAIL PROTECTED] Cc: "Turbine" [EMAIL PROTECTED] Sent: Monday, December 18, 2000 1:03 PM Subject: [tomcat 4.0] Turning off random number seeding Sorry for the cross posting. See log file below. Ok, between "doGet() Start 1" and "doGet() Start 2" is essentially a call to getServletConfig(). Obviously, Tomcat must be initializing the RNG at that point because the next round doesn't produce that in the log and also it is quite fast. So: How the heck do I turn that off or at least speed it up? It is taking bloody forever (over a minute on a PIII 500mhz!)! I thought that this problem was related to Turbine's loading of Services or at least Tomcat's classloader, but now I see that the problem is definitely in the RNG! :-( :-( -jon 2000-12-17 17:56:28 StandardHost[localhost]: Deploying web application at context path /scarab from URL file:e:\projects\scarab2\target\webapps\scarab 2000-12-17 17:56:29 ContextConfig[/scarab]: Configured an authenticator for method BASIC 2000-12-17 17:56:29 StandardWrapper[/scarab:default]: Loading container servlet default 2000-12-17 17:56:29 default: init 2000-12-17 17:56:29 StandardWrapper[/scarab:invoker]: Loading container servlet invoker 2000-12-17 17:56:29 invoker: init 2000-12-17 17:56:29 jsp: init 2000-12-17 17:56:31 scarab: init 2000-12-17 17:56:31 scarab: Turbine: init() Start Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: init() Finish Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: ready to rumble! 2000-12-17 17:56:32 scarab: Turbine: doGet() Start 1! 2000-12-17 17:56:32 Manager[/scarab]: Seeding random number generator class java.security.SecureRandom 2000-12-17 17:56:32 Manager[/scarab]: Seeding of random number generator has been completed 2000-12-17 17:57:23 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:23 scarab: Turbine: doGet() Start Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Finish Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Start 3! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 1! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 3! -- Honk if you love peace and quiet.
Re: [tomcat 4.0] Turning off random number seeding
I think that my log file below shows that it clearly isn't classloading. Everything that would probably need to be loaded is loaded already. -jon on 12/17/2000 6:58 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: Jon, I thought the RNG only took around 5 seconds on that kind of machine. Are you sure it's not classloading taking the time? I found removing the manifest from my .jar files can make up to an order of magnitude difference on some servlet engines... Cheers Geoff - Original Message - From: "Jon Stevens" [EMAIL PROTECTED] To: "tomcat-dev" [EMAIL PROTECTED] Cc: "Turbine" [EMAIL PROTECTED] Sent: Monday, December 18, 2000 1:03 PM Subject: [tomcat 4.0] Turning off random number seeding Sorry for the cross posting. See log file below. Ok, between "doGet() Start 1" and "doGet() Start 2" is essentially a call to getServletConfig(). Obviously, Tomcat must be initializing the RNG at that point because the next round doesn't produce that in the log and also it is quite fast. So: How the heck do I turn that off or at least speed it up? It is taking bloody forever (over a minute on a PIII 500mhz!)! I thought that this problem was related to Turbine's loading of Services or at least Tomcat's classloader, but now I see that the problem is definitely in the RNG! :-( :-( -jon 2000-12-17 17:56:28 StandardHost[localhost]: Deploying web application at context path /scarab from URL file:e:\projects\scarab2\target\webapps\scarab 2000-12-17 17:56:29 ContextConfig[/scarab]: Configured an authenticator for method BASIC 2000-12-17 17:56:29 StandardWrapper[/scarab:default]: Loading container servlet default 2000-12-17 17:56:29 default: init 2000-12-17 17:56:29 StandardWrapper[/scarab:invoker]: Loading container servlet invoker 2000-12-17 17:56:29 invoker: init 2000-12-17 17:56:29 jsp: init 2000-12-17 17:56:31 scarab: init 2000-12-17 17:56:31 scarab: Turbine: init() Start Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: init() Finish Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: ready to rumble! 2000-12-17 17:56:32 scarab: Turbine: doGet() Start 1! 2000-12-17 17:56:32 Manager[/scarab]: Seeding random number generator class java.security.SecureRandom 2000-12-17 17:56:32 Manager[/scarab]: Seeding of random number generator has been completed 2000-12-17 17:57:23 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:23 scarab: Turbine: doGet() Start Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Finish Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Start 3! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 1! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 3! -- Honk if you love peace and quiet. -- Honk if you love peace and quiet.
RE: [tomcat 4.0] Turning off random number seeding
The SecureRandom used in Tomcat 3.2 (and I assume in Tomcat 4.0, as well) takes 10-15 seconds to initialize on my PIII/600. I posted a patch a while back to move the PRNG initialization into context initialization (again for Tomcat 3.2). I think that since we're initializing something inside the servlet container it makes sense for it be part of the container startup and not a big hit that's visible to the first user that runs my servlet. -Original Message- From: Geoff Soutter [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 17, 2000 8:59 PM To: [EMAIL PROTECTED] Subject: Re: [tomcat 4.0] Turning off random number seeding Jon, I thought the RNG only took around 5 seconds on that kind of machine. Are you sure it's not classloading taking the time? I found removing the manifest from my .jar files can make up to an order of magnitude difference on some servlet engines... Cheers Geoff - Original Message - From: "Jon Stevens" [EMAIL PROTECTED] To: "tomcat-dev" [EMAIL PROTECTED] Cc: "Turbine" [EMAIL PROTECTED] Sent: Monday, December 18, 2000 1:03 PM Subject: [tomcat 4.0] Turning off random number seeding Sorry for the cross posting. See log file below. Ok, between "doGet() Start 1" and "doGet() Start 2" is essentially a call to getServletConfig(). Obviously, Tomcat must be initializing the RNG at that point because the next round doesn't produce that in the log and also it is quite fast. So: How the heck do I turn that off or at least speed it up? It is taking bloody forever (over a minute on a PIII 500mhz!)! I thought that this problem was related to Turbine's loading of Services or at least Tomcat's classloader, but now I see that the problem is definitely in the RNG! :-( :-( -jon 2000-12-17 17:56:28 StandardHost[localhost]: Deploying web application at context path /scarab from URL file:e:\projects\scarab2\target\webapps\scarab 2000-12-17 17:56:29 ContextConfig[/scarab]: Configured an authenticator for method BASIC 2000-12-17 17:56:29 StandardWrapper[/scarab:default]: Loading container servlet default 2000-12-17 17:56:29 default: init 2000-12-17 17:56:29 StandardWrapper[/scarab:invoker]: Loading container servlet invoker 2000-12-17 17:56:29 invoker: init 2000-12-17 17:56:29 jsp: init 2000-12-17 17:56:31 scarab: init 2000-12-17 17:56:31 scarab: Turbine: init() Start Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: init() Finish Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: ready to rumble! 2000-12-17 17:56:32 scarab: Turbine: doGet() Start 1! 2000-12-17 17:56:32 Manager[/scarab]: Seeding random number generator class java.security.SecureRandom 2000-12-17 17:56:32 Manager[/scarab]: Seeding of random number generator has been completed 2000-12-17 17:57:23 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:23 scarab: Turbine: doGet() Start Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Finish Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Start 3! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 1! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 3! -- Honk if you love peace and quiet.
Re: [tomcat-4.0] setting the root context seems broken as well
on 12/17/2000 7:31 PM, "Jon Stevens" [EMAIL PROTECTED] wrote: In tomcat-4.0/conf/server.xml, I have defined: Context path="/" docBase="scarab" reloadable="true" /Context I figured out this problem...it should be: Context path="" docBase="scarab" reloadable="true" /Context No "/" in there. That is a bug. :-) -jon -- Honk if you love peace and quiet.
Re: [tomcat-4.0] setting the root context seems broken as well
Jon Stevens wrote: on 12/17/2000 7:31 PM, "Jon Stevens" [EMAIL PROTECTED] wrote: In tomcat-4.0/conf/server.xml, I have defined: Context path="/" docBase="scarab" reloadable="true" /Context I figured out this problem...it should be: Context path="" docBase="scarab" reloadable="true" /Context No "/" in there. That is a bug. :-) I'd say that is actually a feature :-) * It is consistent with what you get back from request.getContextPath() when your webapp is the root context. * It is consistent with the way that Tomcat 3.0/3.1/3.2 refer to the context path of the root context. -jon Craig
Re: [tomcat-4.0] running on MacOSX Beta 2
Any ideas why a stock m5 won't run on MacOSX beta 2? java version "1.2.2" Java HotSpot(TM) Client VM (1.3.0, mixed mode, internal release build) Craig forgot to package jndi.jar with the M5 distribution, so if you're running JDK 1.2 it will complain :( Download JNDI 1.2 from Sun, and put the jndi.jar in the bin directory. Remy
RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
John Morrison wrote: While jakarta-servletapi-4.0 and TC4.0 builds are being re-developed, could we please *stop* them creating directories higher in the hierarchy thantheir own root? ie /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. - Sam Ruby
RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Jon Stevens wrote: I would say that the servlet api build process should be "fixed" to build/install into directories with the version number attached. Agreed. In the case of jakarta-regexp, can this be done instead of putting the version number on the name of the jar file itself? - Sam Ruby
RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Yeh, I see your point. But CVS ignores any files it doesn't know about and it _is_ a common idiom amongst open source projects... If you don't like cluttering the CVS co (and you're using Linux), create a linked dir to build into. -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: 15 December 2000 11:59 am To: [EMAIL PROTECTED] Subject: RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard) John Morrison wrote: While jakarta-servletapi-4.0 and TC4.0 builds are being re-developed, could we please *stop* them creating directories higher in the hierarchy thantheir own root? ie /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. - Sam Ruby === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)
While jakarta-servletapi-4.0 and TC4.0 builds are being re-developed, could we please *stop* them creating directories higher in the hierarchy thantheir own root? ie /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. +1 ! Costin
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
On Friday, December 15, 2000, at 03:24 PM, [EMAIL PROTECTED] wrote: /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. +1 ! I would be inclined to change 'not nice' to 'potentially dangerous', because any build script that alters files outside the checkout by default may cause harm. It relies on assumptions that: 1. developers have write access to the parent directory 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". You make them all and... disaster... All the jakarta projects have put their builds into named directories inside the directory with my favourite "build" build tool - messing it up with extra files that are nothing to do with it. Then "omega" completely wiped my build directory when I did a clean build - it doesn't use subdirectories of "../build". I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Being able to build outside of the checkout is an option some users may prefer, but I don't think we should be providing this as a default unless we can be sure of the 3 assumptions above. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Mac OS X, Java, XML, etc. ADOLOS http://www.adolos.com/
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)
on 12/15/2000 3:56 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: In the case of jakarta-regexp, can this be done instead of putting the version number on the name of the jar file itself? - Sam Ruby There is nothing wrong with putting the version number on the .jar file and it help WAY to many people to do so. One thing I just thought of that I would be willing to do is to build the .jar file into /bin without a version number on it and then "build dist" would then put the version number on it. -jon
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)
I agree with Stuart! Let me also state that 99% of the OSS C projects built with "configure" out there build into their own directory by default. However, most have the option to build to another directory. That is something I'm willing to support. -jon on 12/15/2000 7:45 AM, "Stuart Roebuck" [EMAIL PROTECTED] wrote: On Friday, December 15, 2000, at 03:24 PM, [EMAIL PROTECTED] wrote: /jakarta-tomcat/ shouldn't then create ../build/ - it's not nice! An alternate perspective - I like the fact that building a cvs checkout does not modify the checkout itself. +1 ! I would be inclined to change 'not nice' to 'potentially dangerous', because any build script that alters files outside the checkout by default may cause harm. It relies on assumptions that: 1. developers have write access to the parent directory 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". You make them all and... disaster... All the jakarta projects have put their builds into named directories inside the directory with my favourite "build" build tool - messing it up with extra files that are nothing to do with it. Then "omega" completely wiped my build directory when I did a clean build - it doesn't use subdirectories of "../build". I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Being able to build outside of the checkout is an option some users may prefer, but I don't think we should be providing this as a default unless we can be sure of the 3 assumptions above. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Mac OS X, Java, XML, etc. ADOLOS http://www.adolos.com/ -- Honk if you love peace and quiet.
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Jon Stevens wrote: There is nothing wrong with putting the version number on the .jar file and it help WAY to many people to do so. I'm sure that putting the version number in a conspiquous place has helped innumerable people. However, as Craig pointed out: That makes building scripts dependent on these packages much more painful than it needs to be -- it's not enough to know what directory you've got these packages in, you have to specify the version number as well. In concrete terms, to build jakarta tomcat 4.0 with the latest regexp, one needs to do the following: -Dregexp.home=D:\jakarta-regexp\jakarta-regexp-1.2 -Dregexp.jar=D:\jakarta-regexp\jakarta-regexp-1.2\jakarta-regexp-1.2.jar To me, the last like seems to be kinda over doing it a bit ;-) What I would prefer, and would be much more consistent with the overwhelming majority of existing jakarta projects is "build dist" produced the following jar file: D:\dist\jakarta-regexp-1.2\regexp.jar Additionally, I would be in favor of standardizing - even if it is only across jakarta projects - a mechanism for embedding the version number in a standard location inside the jar file itself. - Sam Ruby
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
[ disclaimer: I am a fan of keeping the source separate from the outputs, but in the interest of fairness, I feel I must point out a few items ] Craig R. McClanahan wrote: 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If the projects are really different, you should be building them someplace other than in your "Jakarta" build directory. Then there are no clashes. I'd like to point out that the lines between "jakarta", "java", and "xml" Apache projects is a bit arbitrary. As a concrete example, there is a lot more in common between the xml-soap and the jakarta-tomcat build processes (in terms of names of targets, where output is placed, etc) than there is between jakarta-tomcat and jakarta-regexp. Many developers have their own ideas of related projects, and mine includes a few project not only at working-dogs, but also at exolab and even IBM developerworks. Even more importantly, the distinction between significant versions of a project needs to be factored into this. In particular, the versions of the servletapi project need to be handled as easily as the versions of the tomcat project. I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Try doing a "cvs commit" or "cvs update" in your source directory -- are the files marked with "?" ones that I forgot to register with CVS or are they just outputs of the build process? You have to think about that *every single time*. There is a technological solution to this problem: .cvsignore files http://www.cvshome.org/docs/manual/cvs_18.html#SEC173 - Sam Ruby
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)
on 12/15/2000 10:50 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: That makes building scripts dependent on these packages much more painful than it needs to be -- it's not enough to know what directory you've got these packages in, you have to specify the version number as well. In concrete terms, to build jakarta tomcat 4.0 with the latest regexp, one needs to do the following: -Dregexp.home=D:\jakarta-regexp\jakarta-regexp-1.2 -Dregexp.jar=D:\jakarta-regexp\jakarta-regexp-1.2\jakarta-regexp-1.2.jar To me, the last like seems to be kinda over doing it a bit ;-) What I would prefer, and would be much more consistent with the overwhelming majority of existing jakarta projects is "build dist" produced the following jar file: D:\dist\jakarta-regexp-1.2\regexp.jar Additionally, I would be in favor of standardizing - even if it is only across jakarta projects - a mechanism for embedding the version number in a standard location inside the jar file itself. - Sam Ruby Actually, it doesn't. Ant 1.2 has features to deal with these issues now. I have also discovered neat little tricks to deal with it as well. I'm going to be repairing the broken things in Tomcat's build system. Again, Sam, you keep trying to solve the wrong problems. The problem is in the build system not dealing with things properly, not in the fact that there are version numbers in the .jar files. thanks, -jon -- Honk if you love peace and quiet.
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
On Friday, December 15, 2000, at 05:51 PM, Craig R. McClanahan wrote: If you follow the recommended approach (create a "Jakarta" directory in your home directory or wherever, and install all the project source distros inside it), this is a given. Apologies, I didn't realise I had to download all of the Jakarta projects as one whole CVS checkout - I wrongly presumed that I could download the ones I was needing and that they stood on their own as well as together. 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. If you follow the recommended approach (you will hear that a few times :-), this directory ends up by default inside your "Jakarta" directory, completely segregated from anything else on your disk. Where do I put my jakarta-ant sources that are running a different version than that required by cocoon and tomcat? If they are all part of one big project then I must assume that there are possible inter-relationships, and that some change I make to ant may break something in Tomcat or Cocoon. Or is there a way in which I can be certain that there are no dependencies? 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If the projects are really different, you should be building them someplace other than in your "Jakarta" build directory. Then there are no clashes. Okay, I get the point, I really hadn't appreciated that the Jakarta directory was an absolute must do. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". See above -- the recommended development approach is there for a reason. Perhaps if the separate references to the CVS archives for xml-cocoon and ant etc. were removed from the web site it would be clearer that you have to downloaded them all at once. You make them all and... disaster... All the jakarta projects have put their builds into named directories inside the directory with my favourite "build" build tool - messing it up with extra files that are nothing to do with it. Then "omega" completely wiped my build directory when I did a clean build - it doesn't use subdirectories of "../build". I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Try doing a "cvs commit" or "cvs update" in your source directory -- are the files marked with "?" ones that I forgot to register with CVS or are they just outputs of the build process? You have to think about that *every single time*. Yes, I can understand that being a frustration. I use a graphical CVS tool on MacOS X which shows the checkout directory hierarchically, so all I do is ignore the build directory when I'm looking. If your using command line tools, isn't there a facility for ignoring certain files that would allow you to ignore the "build" directory too? And no, I am not willing to avoid this by doing a "build clean" every time I want to do a check-in, and then waste the time to rebuild from scratch again. I will rebuild when *I* want to or need to. I completely agree Being able to build outside of the checkout is an option some users may prefer, but I don't think we should be providing this as a default unless we can be sure of the 3 assumptions above. The recommended development approach avoids the problems you have described, without requiring building inside the source directory. But in effect, this *is* in the source directory, because the existence of the Jakarta directory is a requirement - it is therefore part of the source. It also means you have control over which versions of dependent packages you use to build Tomcat, even though you might be using a different version of Ant or an XML parser on some other project. Okay, I think you've answered my earlier question. Am I right in saying that you are suggesting that I have multiple "Jakarta" directories for working on different versions of different parts of the jakarta project? If so I would have a "Jakarta (for ant work)" directory with the latest Ant CVS and whatever versions of everything else; and a "Jakarta (for Cocoon)" directory which would have Ant 1.2 and Tomcat 4m4 lets say. Isn't this going to take up a lot of hard disc space, and be fairly unfriendly to people with slow internet connections? Stuart.
Re: [tomcat-4.0] don't touch any of the build system in CVS for tomcat/servletapi
Jon Stevens wrote: i'm re-doing it this weekend and i don't want to have to merge conflicts. yes craig, i will keep the same level of functionality and simply add clean ness, ease of building, ant 1.2 features and more functionality. Please give us a chance to discuss before comitting? I've spent the last two days building a meta-build system. It consists of an abstract definition of the system that you want to build, in XML. A concrete user profile, also in XML, binding names to locations to where you want them to reside on disk. And, finally, an XSLT transform which will convert these two into a script designed for your native platform (I've been focusing on with Windows and Linux). One could easily image extending this with a graphical front end. One thing that would make life much easier would be if we could agree on some simple things, like the names of targets - it is "package" or "dist"? Where to find outputs. How to specify inputs (environment var / properties file / class path). What we have now is Jon doing all of "his" projects one way and Craig doing all of "his" projects another. I know that Jon keeps telling me that I'm focusing on the wrong things, but I would like to get to the point where the various projects are standardized building blocks, with each project describing in a machine readable fashion their dependencies. - Sam Ruby
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Sam Ruby wrote: Additionally, I would be in favor of standardizing - even if it is only across jakarta projects - a mechanism for embedding the version number in a standard location inside the jar file itself. I have a suggestion for how to approach this one. The JDK 1.3 docs describe a convention for defining the product name and version number of a package included in a JAR file, plus the dependencies of that JAR file on specific versions of external JARs -- all done in the META-INF/MANIFEST.MF file. A 2.3 container (like Tomcat 4.0) is even required to enforce checking for availability of the dependent JARs when you include depenencies in your WEB-INF/lib/*.jar files. It's worth taking a look at this. http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html - Sam Ruby Craig
Re: [tomcat-4.0] don't touch any of the build system in CVS fortomcat/servletapi
on 12/15/2000 11:31 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: Please give us a chance to discuss before comitting? I've spent the last two days building a meta-build system. It consists of an abstract definition of the system that you want to build, in XML. A concrete user profile, also in XML, binding names to locations to where you want them to reside on disk. And, finally, an XSLT transform which will convert these two into a script designed for your native platform (I've been focusing on with Windows and Linux). One could easily image extending this with a graphical front end. One thing that would make life much easier would be if we could agree on some simple things, like the names of targets - it is "package" or "dist"? Where to find outputs. How to specify inputs (environment var / properties file / class path). What we have now is Jon doing all of "his" projects one way and Craig doing all of "his" projects another. I know that Jon keeps telling me that I'm focusing on the wrong things, but I would like to get to the point where the various projects are standardized building blocks, with each project describing in a machine readable fashion their dependencies. - Sam Ruby I didn't remember you posting about building such a system, but it is MOST appreciated and wanted. I will wait to use whatever you have. -jon
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
WARNING: Comments below relate to the build process the way it currently is. After Jon gets done, it will undoubtedly look quite different. Stuart Roebuck wrote: On Friday, December 15, 2000, at 05:51 PM, Craig R. McClanahan wrote: If you follow the recommended approach (create a "Jakarta" directory in your home directory or wherever, and install all the project source distros inside it), this is a given. Apologies, I didn't realise I had to download all of the Jakarta projects as one whole CVS checkout - I wrongly presumed that I could download the ones I was needing and that they stood on their own as well as together. The README.txt file in the top-level directory of the source distribution identifies the specifics of the dependencies, and the steps needed to set up your environment. 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. If you follow the recommended approach (you will hear that a few times :-), this directory ends up by default inside your "Jakarta" directory, completely segregated from anything else on your disk. Where do I put my jakarta-ant sources that are running a different version than that required by cocoon and tomcat? If they are all part of one big project then I must assume that there are possible inter-relationships, and that some change I make to ant may break something in Tomcat or Cocoon. Or is there a way in which I can be certain that there are no dependencies? If you want to use the "latest and greatest" Ant code, you would download the jakarta-ant source repository parallel to jakarta-tomcat-4.0. If you want to use the version of Ant 1.2 already installed in production on your development server, set the ANT_HOME environment variable to point at it. See the comments at the top of "build.sh" or "build.bat" for the similar mechanisms for finding all the other dependent packages. I think Jon is looking at using project-specific Ant properties files, rather than environment variables, to accomplish pretty much the same goal. 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If the projects are really different, you should be building them someplace other than in your "Jakarta" build directory. Then there are no clashes. Okay, I get the point, I really hadn't appreciated that the Jakarta directory was an absolute must do. There's still the "religious" war over "build inside my source directory" versus "build someplace else". I am of the latter camp -- partly because that's the way Tomcat has built ever since it was first released to Apache, and partly because I've grown to like it -- but if everyone wants it different, I'm game. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". See above -- the recommended development approach is there for a reason. Perhaps if the separate references to the CVS archives for xml-cocoon and ant etc. were removed from the web site it would be clearer that you have to downloaded them all at once. Are you thnking of particular web site references that are confusing and should be fixed? I always follow the steps in the README.txt file (or equivalent) when setting up to build a project I've never done before. You make them all and... disaster... All the jakarta projects have put their builds into named directories inside the directory with my favourite "build" build tool - messing it up with extra files that are nothing to do with it. Then "omega" completely wiped my build directory when I did a clean build - it doesn't use subdirectories of "../build". I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical to the original, but what are the practical disadvantages of having the build directory inside the checkout, especially if a 'clean' build cleans out the build stuff automatically if you require? Try doing a "cvs commit" or "cvs update" in your source directory -- are the files marked with "?" ones that I forgot to register with CVS or are they just outputs of the build process? You have to think about that *every single time*. Yes, I can understand that being a frustration. I use a graphical CVS tool on MacOS X which shows the checkout directory hierarchically, so all I do is ignore the build directory when I'm looking. If your using command line tools, isn't there a facility for ignoring certain files that would allow you to ignore the "build" directory too? Yep ... Sam pointed it out ... .cvsignore
Re: [tomcat-4.0] don't touch any of the build system in CVS for tomcat/servletapi
Jon Stevens wrote: I didn't remember you posting about building such a system, but it is MOST appreciated and wanted. Posted innumerable times, but here it is once again: http://oss.software.ibm.com/developerworks/opensource/jakarta/buildall.html I will wait to use whatever you have. I didn't mean to stop your work, please continue. I'm not changing anything within these projects, I am simply automating the generations of tailored build scripts. Again, what would make my life easier (and I suspect the lives of our precious users) would be if we could settle on simple things like whether the target names are dist or package? Are the build.xml files to be found in the top directory or in a build subdirectory? Are they, in fact, named build.xml or named build-project.xml? And how does one determine and specify the dependencies? Not to mention the innumerable schemes used to specify outputs. There are a number of these issues where I have expressed preferences, but most of all I would like some consistency amongst the various Jakarta and Jakarta related projects. - Sam Ruby
Re: [tomcat-4.0] don't touch any of the build system in CVS for tomcat/servletapi
I've spent the last two days building a meta-build system. It consists of an abstract definition of the system that you want to build, in XML. A concrete user profile, also in XML, binding names to locations to where you want them to reside on disk. And, finally, an XSLT transform which will convert these two into a script designed for your native platform (I've been focusing on with Windows and Linux). One could easily image extending this with a graphical front end. That looks cool. Could you post a sample project build file (the abstract one + the user preferences) to see how things are done using this ? Remy
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
There's still the "religious" war over "build inside my source directory" versus "build someplace else". I am of the latter camp -- partly because that's the way Tomcat has built ever since it was first released to Apache, and partly because I've grown to like it -- but if everyone wants it different, I'm game. I like the "build somewhere else" better too. I work on multiple projects, and I like to have all the binaries in the same place. Remy
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)
on 12/15/2000 12:00 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
Let me describe what I just had to do, to get a feel for why I like the
current approach.
Recently, there were security issues with Tomcat 3.1 that required creating a
3.1.1 release. Now, Tomcat 3.1 was dependent on the Ant that was current at
that time, and a whole bunch of other old stuff. But 3.2 (and 4.0) require
the current Ant. What to do?
I left my "Jakarta" directory (with the current 3.2 and 4.0 stuff in it)
alone, and created a separate one ("Jakarta-3.1"), in which I could download
the version of Ant that 3.1 depended on, grabbed the 3.1 sources for Tomcat,
and built/tested/packaged it -- all completely separate from my usual work
environment. The relative references work well in that scenario, because I
organized things to keep mutually dependent stuff together. Worked like a
champ.
Ant in particular is a tool you will need to have available in multiple
versions if you are building lots of open source projects of different ages.
The dramatic (almost radical) deprecations and syntax changes between pre-1.0,
1.0, 1.1, and 1.2 will get you in loads of trouble otherwise. To say nothing
of the right XML parser, servletapi classes, ...
The same scenario happens when you build other open source projects, too --
they all have dependencies on particular versions of particular packages.
Whether you build inside the project directory or outside doesn't make any
difference in that regard.
Personally, I find it easiest to organize top-level development directories
around mutually interdependent projects.
This is EXACTLY why I currently vote to check .jar files into CVS (until
CJAN is available). It is also EXACTLY why I vote to add version numbers to
*everything*.
If we had had the right ant.jar and parser and blah blah blah checked into
Tomcat's CVS, then you would have been able to simply just check it out of
CVS and build it without having to do ANY other work to set things up.
Again, I don't think checking .jar files into CVS is the end solution as
CJAN and properly versioned directories in /build and /dist is, but in the
end, if we had simply had the .jar files in CVS for now, it would have been
a 5 second process.
It is way to confusing and a PITA to have to rename directories yourself to
get the desired results.
p.s. I'm now waiting on Sam to make his "buildmaker" toolset available for
review. That is definitely the right way to go.
thanks,
-jon
--
Honk if you love peace and quiet.
Re: [tomcat-4.0] don't touch any of the build system in CVS fortomcat/servletapi
on 12/15/2000 11:59 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: Jon Stevens wrote: I didn't remember you posting about building such a system, but it is MOST appreciated and wanted. Posted innumerable times, but here it is once again: http://oss.software.ibm.com/developerworks/opensource/jakarta/buildall.html no no no no no...keep reading... I will wait to use whatever you have. I didn't mean to stop your work, please continue. I'm not changing anything within these projects, I am simply automating the generations of tailored build scripts. ok, i thought you were doing something new...keep reading... Again, what would make my life easier (and I suspect the lives of our precious users) would be if we could settle on simple things like whether the target names are dist or package? Are the build.xml files to be found in the top directory or in a build subdirectory? Are they, in fact, named build.xml or named build-project.xml? And how does one determine and specify the dependencies? Not to mention the innumerable schemes used to specify outputs. There are a number of these issues where I have expressed preferences, but most of all I would like some consistency amongst the various Jakarta and Jakarta related projects. I proposed this a while ago on the PMC list, but what I would like to do now is something more like what I created for the jakarta-site2 module. Essentially a basis buildmaker project for people to work from. That is what I thought that you just said you were creating. -jon -- Honk if you love peace and quiet.
Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Craig, Thanks for this. If my analysis is correct I think our preferences are very similar, but we started with different viewpoints: 1. I saw Tomcat as a stand-alone project dependent on other stand-alone projects : you saw Tomcat as part of one interdependent Jakarta project. 2. I saw the build directory as being completely outside the project by default and saw this as a 'problem/side-effect' : you saw the build directory as being out-of-the-way-of sub-project directories but nevertheless still within the overall jakarta project as specified in the README. So, the differences of view, if my analysis is right, revolve around whether or not Tomcat, Ant, Cocoon, etc, should be see as stand-alone projects which happen to sometimes rely on one another, or parts of one interdependent project. I prefer the idea of smaller stand-alone projects because I think they are easier to 'get into' as an outsider. But as long as folk know which way to look at things I guess it works either way. Cheers, Stuart. On Friday, December 15, 2000, at 08:00 PM, Craig R. McClanahan wrote: WARNING: Comments below relate to the build process the way it currently is. After Jon gets done, it will undoubtedly look quite different. Stuart Roebuck wrote: On Friday, December 15, 2000, at 05:51 PM, Craig R. McClanahan wrote: If you follow the recommended approach (create a "Jakarta" directory in your home directory or wherever, and install all the project source distros inside it), this is a given. Apologies, I didn't realise I had to download all of the Jakarta projects as one whole CVS checkout - I wrongly presumed that I could download the ones I was needing and that they stood on their own as well as together. The README.txt file in the top-level directory of the source distribution identifies the specifics of the dependencies, and the steps needed to set up your environment. 2. creating a "build" directory in the parent directory is not a problem or nuisance to the management of other files on the hard-disc. If you follow the recommended approach (you will hear that a few times :-), this directory ends up by default inside your "Jakarta" directory, completely segregated from anything else on your disk. Where do I put my jakarta-ant sources that are running a different version than that required by cocoon and tomcat? If they are all part of one big project then I must assume that there are possible inter-relationships, and that some change I make to ant may break something in Tomcat or Cocoon. Or is there a way in which I can be certain that there are no dependencies? If you want to use the "latest and greatest" Ant code, you would download the jakarta-ant source repository parallel to jakarta-tomcat-4.0. If you want to use the version of Ant 1.2 already installed in production on your development server, set the ANT_HOME environment variable to point at it. See the comments at the top of "build.sh" or "build.bat" for the similar mechanisms for finding all the other dependent packages. I think Jon is looking at using project-specific Ant properties files, rather than environment variables, to accomplish pretty much the same goal. 3. different projects will create subdirectories of the "build" directory and these subdirectory names will never clash, despite the huge number of open source projects in existence. If the projects are really different, you should be building them someplace other than in your "Jakarta" build directory. Then there are no clashes. Okay, I get the point, I really hadn't appreciated that the Jakarta directory was an absolute must do. There's still the "religious" war over "build inside my source directory" versus "build someplace else". I am of the latter camp -- partly because that's the way Tomcat has built ever since it was first released to Apache, and partly because I've grown to like it -- but if everyone wants it different, I'm game. If you have a directory of open source projects on your hard drive, lets call it "opensource". Inside that you put all your open source work in separate checkout directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse". See above -- the recommended development approach is there for a reason. Perhaps if the separate references to the CVS archives for xml-cocoon and ant etc. were removed from the web site it would be clearer that you have to downloaded them all at once. Are you thnking of particular web site references that are confusing and should be fixed? I always follow the steps in the README.txt file (or equivalent) when setting up to build a project I've never done before. You make them all and... disaster... All the
Re: [tomcat-4.0] don't touch any of the build system in CVS for tomcat/servletapi
Jon Stevens wrote: no no no no no...keep reading... Essentially a basis buildmaker project for people to work from. That is what I thought that you just said you were creating. We probably need a higher bandwidth communication at some point. I'm building exactly what I described. It should be in a state where I can post it for public ridicule within a few days. - Sam Ruby
Re: [tomcat-4.0] don't touch any of the build system in CVS fortomcat/servletapi
on 12/15/2000 5:05 PM, "Sam Ruby" [EMAIL PROTECTED] wrote: We probably need a higher bandwidth communication at some point. You are welcome to come out and stay at my house in Berkeley. :-) I have an extra futon with a featherbed on it as well as plenty of hardware for us to develop on. :-) I'm building exactly what I described. It should be in a state where I can post it for public ridicule within a few days. Ok. That is what I would rather wait for as it will be the proper way to do things in the end. I would love to convert other projects to be based on something like that. It is similar in concept to what I did with the jakarta-site2 module. thanks, -jon -- Honk if you love peace and quiet.
Re: [tomcat-4.0] building is hard
Jon, I *absolutely* agree with the need to make the Tomcat build environment easier to setup. The current situation is a *serious* barrier to encouraging wider participation. There's no rocket science required at present, but few of us have time to mess about and I for one gave up at least three times before circumstances forced me to work through the process. However, I don't know if it's just me, but I really find it frustrating when build environments depend upon relative file structures extending beyond the filepath of the root project. Inotherwords, I totally agree with the idea of having a standard directory structure option, but I would much prefer that this standard directory structure appear inside of the jakarta-tomcat-4.0 directory. Here are some reasons: 1. Good old programming 'side-effects' - intuitively, you do not expect that changes to directories outside of the tomcat directory will impact on the building of tomcat. If you are moving your tomcat build directory to a new location, you don't want to have to look at readme files to work out what has to move with the directory at the same time. 2. If the 'jakarta-ant' and 'jakarta-servletapi' directories are full source distributions and a developer is involved in the ongoing development of one of these projects as well (e.g. ant) there can be a conflict between the version requirements of Tomcat and the ongoing work on the latest version of a project it depends upon. To put it in other words, if you are working on adding new features to the very latest version of ant you may be working with a version which is incompatible with the current build of tomcat. You are therefore forced to maintain two separate copies of ant - one to make tomcat work, one for ant development. My preference would be to simply include the distributable jar files of required libraries in a lib/ or similar directory inside the tomcat directory. Those libraries that are distributable could be included in the CVS but optionally excluded from the nightly builds and distributions (to reduce file size). Users would be asked to place the relevant .jar files of non-distributable libraries in the same place. This is basically the model for cocoon - which is *way* simpler to build than tomcat. This also makes life a lot easier when moves are made to use newer versions of libraries for Tomcat, because they can simply be updated in the CVS (if they are distributable). Stuart. On Thursday, December 14, 2000, at 04:54 AM, Jon Stevens wrote: i would just like to point out that setting up an environment to build the java portion of tomcat-4.0 from CVS is WAY to hard. you have to know way to much about where things should go and such. for example, the documentation states that you should point to your JSSE installation directory. given that JSSE instructs you to put things into $JAVA_HOME/lib/ext, the tomcat build system doesn't assume that, it assumes is to be the place where you downloaded and un-tar'ed JSSE. i think that the documentation should be more clear and also the build system should not require you to set a bunch of environment variables if you have a well defined directory structure...keep reading... what i propose is to ask people to either setup their directory structure in a certain way or to set environment variables. for example: /stuff /jakarta-tomcat-4.0 /jakarta-ant /jakarta-servletapi /jsse* /jmx* /jndi* ... Then, Tomcat's build files will first try to find relative paths to the other directories and if it can't find them, it will then look for env variables. I think that this is a perfectly acceptable build system for now. one thing i'm working on right now is adding the above functionality and won't check in my changes until after m5. thanks, -jon - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Mac OS X, Java, XML, etc. ADOLOS http://www.adolos.com/
Re: [tomcat-4.0] building is hard
Stuart Roebuck [EMAIL PROTECTED] wrote: Jon, I *absolutely* agree with the need to make the Tomcat build environment easier to setup. The current situation is a *serious* barrier to encouraging wider participation. There's no rocket science required at present, but few of us have time to mess about and I for one gave up at least three times before circumstances forced me to work through the process. Oh, by the way. Despite what I said to Jon (with whom I was discussing right this week-end about this), I too agree that building Tomcat 4.0 is a major pain. It took me 1 day to figure out what was needed and so on. I had a chat with him on that last time we talked on the phone and we agreed that we need to make it simpler before going beta and final. Thank you very much Stuart for outlining what were your difficulties trying to build, when you get used to it, it's really hard to see what are the weak points in the process... 1. Good old programming 'side-effects' - intuitively, you do not expect that changes to directories outside of the tomcat directory will impact on the building of tomcat. If you are moving your tomcat build directory to a new location, you don't want to have to look at readme files to work out what has to move with the directory at the same time. I agree... The most weird thing to see is when you type "./build.sh" and aparently nothing gets generated, until you don't look in "../build" 2. If the 'jakarta-ant' and 'jakarta-servletapi' directories are full source distributions and a developer is involved in the ongoing development of one of these projects as well (e.g. ant) there can be a conflict between the version requirements of Tomcat and the ongoing work on the latest version of a project it depends upon. To put it in other words, if you are working on adding new features to the very latest version of ant you may be working with a version which is incompatible with the current build of tomcat. You are therefore forced to maintain two separate copies of ant - one to make tomcat work, one for ant development. Right... But also Ant changes behavior of its core components every other week, it's hard to keep that in sync. I believe it would be good to "freeze" one version and keep using that. My preference would be to simply include the distributable jar files of required libraries in a lib/ or similar directory inside the tomcat directory. Those libraries that are distributable could be included in the CVS but optionally excluded from the nightly builds and distributions (to reduce file size). Users would be asked to place the relevant .jar files of non-distributable libraries in the same place. This is basically the model for cocoon - which is *way* simpler to build than tomcat. This also makes life a lot easier when moves are made to use newer versions of libraries for Tomcat, because they can simply be updated in the CVS (if they are distributable). Someone (me! :) proposed to do as they do in XML land with the Xerces project. They distribute a simple "xerces-tools..." JAR containing all libraries required for the build. What do you think? Would it be a good idea to do the same for Tomcat? I'd rather not check in JARs in the CVS, but I believe that a single big zip with all libraries would be great... Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED]
