PATCH: Aliases again - this time tested and working, but...
Hi,
Unfortunately, the patch I submitted a few days ago for host aliases isn't
enough. Looks like tags are just ignored - they're supposed to be
handled in org.apache.catalina.startup.Catalina, which is uninteligible to
me (I use only JDOM for XML in my projects).
I made a quick fix, but it's using a dirty hack violating (or enhancing ;> )
current server.xml syntax. After applying this patch you can use syntax
like:
First name is hostname, the rest are aliases, allowed separators are ";" ":"
",", whitespace is ignored. I know it's quick and dirty, but it works and
looks stable - I need it before yesterday, and I'm sure I'm not the only
one.
Patch:
File: org.apache.catalina.core.StandardHost, line 325, method setName
=
public void setName(String name) {
if (name == null)
throw new IllegalArgumentException
(sm.getString("standardHost.nullName"));
name = name.toLowerCase(); // Internally all names are lower case
// * patch start
java.util.StringTokenizer st = new java.util.StringTokenizer( name,
":;," );
name = st.nextToken().trim();
while( st.hasMoreTokens() )
{
addAlias( st.nextToken().trim() );
}
// * patch end
String oldName = this.name;
this.name = name;
support.firePropertyChange("name", oldName, this.name);
}
=
Greetings,
deacon Marcus
Re: Jasper34: static output changes
[EMAIL PROTECTED] wrote: > > On Fri, 15 Jun 2001, Casey Lucas wrote: > > > > > Costin, > > > > sounds good. > > > > btw, when do you think the generator code in 34 will settle down > > a little? > > Soon :-) > > There is only one more change in the generator layout - switching to > a "visitor" pattern, with the tree representation of the page separated > from the actual generator. > > If you are thinking to tagpool changes - please wait until RuntimeLiaison > gets a bit of shape, I would like to provide some hooks for the container > to control the pools. Again, the idea is to allow a "toolkit" model, where > different components can be plugged in. ok. just let me know when you think it's appropriate to start adding some tag optimizations. > Separating tree is very important to allow modules to do various > optimizations ( like replacing common tags with equivalent in-line java > code ) and to do the direct bytecode generation. regarding "replacing common tags with equivalent in-line java code": what exactly did you have in mind? -casey
cvs commit: jakarta-tomcat-4.0/catalina/docs/dev/xdocs/stylesheets project.xml
craigmcc01/06/15 15:53:06 Modified:catalina/docs/dev/xdocs/stylesheets project.xml Added: catalina/docs/dev/xdocs fs-jdbc-realm.xml Log: Add a functional spec for JDBCRealm also, since it's pretty similar. Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/docs/dev/xdocs/fs-jdbc-realm.xml Index: fs-jdbc-realm.xml === Craig McClanahan JDBCRealm - Functional Specification $Id: fs-jdbc-realm.xml,v 1.1 2001/06/15 22:53:03 craigmcc Exp $ The purpose of the JDBCRealm implementation is to provide a mechanism by which Tomcat 4.0 can acquire information needed to authenticate web application users, and define their security roles, from a relational database accessed via JDBC APIs. For integration with Catalina, the resulting class(es) must implement the org.apache.catalina.Realm interface. This specification reflects a combination of functionality that is already present in the org.apache.catalina.realm.JDBCRealm class, as well as requirements for enhancements that have been discussed. Where appropriate, requirements statements are marked [Current] and [Requested] to distinguish them. The current status of this functional specification is PROPOSED. It has not yet been discussed and agreed to on the TOMCAT-DEV mailing list. The implementation of this functionality depends on the following external specifications: http://java.sun.com/products/jdbc/";>Java Database Connectivity (version 2.0 or later) http://java.sun.com/products/jdbc/";>Java Database Connectivity Optional Package (version 2.0 or later) The implementation of this functionality shall conform to the following requirements: Be realized in one or more implementation classes. Implement the org.apache.catalina.Realm interface. [Current] Implement the org.apache.catalina.Lifecycle interface. [Current] Subclass the org.apache.catalina.realm.RealmBase base class. Live in the org.apache.catalina.realm package. [Current] Support a configurable debugging detail level. [Current] Log debugging and operational messages (suitably internationalized) via the getContainer().log() method. [Current] The following environmental dependencies must be met in order for JDBCRealm to operate correctly: The desire to utilize JDBCRealm must be registered in $CATALINA_HOME/conf/server.xml, in aelement that is nested inside a corresponding , , or element. Correct operation of JDBCRealm depends on the following specific features of the surrounding container: Interactions with JDBCRealm will be initiated by the appropriate Authenticator implementation, based on the login method that is selected. JDBCRealm must have the JDBC standard API classes available to it. For a JDK 1.2 or later container, these APIs are included in the standard platform. When connection pooling is implemented, JDBCRealm must have the JDBC Optional Package (version 2.0 or later) APIs available to it. This library is available as a separate download (and will be included in Tomcat binary distributions). The main purpose of JDBCRealm is to allow Catalina to authenticate users, and look up the corresponding security roles, from the information found in a relational database accessed via JDBC APIs. For maximum flexibility, the details of how this is done (for example, the names of the required tables and columns) should be configurable. Each time that Catalina needs to authenticate a user, it will call the authenticate() method of this Realm implementation, passing the username and password that were specified by the user. If we find the user in the database (and match on the password), we accumulate all of the security roles that are defined for this user, and create a new GenericPrincipal object to be returned. If the user is not authenticated, we return null instead. The GenericUser object caches the set of security roles that were owned by this user at the time of authentication, so that calls to isUserInRole() can be answered without going back to the database every time. Configurable Properties The implementation shall support the following properties t
JNDIRealm Functional Specifications
Finally getting back to this, which John and Ellen have (justifably) been a little impatient about ... I'd like us to agree on top-level goals for JNDIRealm before we dive into the code. This document is an attempt to extract out of the historical discussions all the features that it sounded like we wanted, but did I get them all? Can they be organized better? Once we've got that down, it will be straightforward to figure out how to refactor the current code to support all of the requirements. (I wouldn't be surprised to see us have a JNDIRealmBase class that is then subclassed for various operational modes, but we'll see what makes the most sense.) Craig McClanahan
cvs commit: jakarta-tomcat-4.0/catalina/docs/dev/xdocs/stylesheets project.xml
craigmcc01/06/15 15:19:54 Modified:catalina/docs/dev/xdocs/stylesheets project.xml Added: catalina/docs/dev/xdocs fs-jndi-realm.xml Log: Publish the first draft of a Functional Specification for the overall set of capabilities we want to provide in a JNDIRealm implementation for Tomact 4.0. Once we agree on the overall requirements, we can talk about how to refactor the existing code to support it. To generate the HTML version of these docs, you must have Ant 1.3's "bin" directory on your PATH, the Ant optional.jar file in $ANT_HOME/lib, and JAXP/1.1 on your CLASSPATH. Then, issue the following commands: cd catalina ant dev-doc The resulting docs will end up in catalina/build/dev-doc. This will get integrated into the standard published webapp at some future point. NOTE: One section of this document that is not yet complete is "Testable Assertions". When we're talking about features (versus issues of spec compliance), we need to define what we think correct behavior is in order to test it. I invite suggestions on what assertions we think might go here. For ideas, you might look at the assertions I've listed on the other functional specs in this directory (the invoker servlet and the default file-serving servlet). Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/docs/dev/xdocs/fs-jndi-realm.xml Index: fs-jndi-realm.xml === Craig McClanahan JNDIRealm - Functional Specification $Id: fs-jndi-realm.xml,v 1.1 2001/06/15 22:19:53 craigmcc Exp $ The purpose of the JNDIRealm implementation is to provide a mechanism by which Tomcat 4.0 can acquire information needed to authenticate web application users, and define their security roles, from a directory server or other service accessed via JNDI APIs. For integration with Catalina, this class must implement the org.apache.catalina.Realm interface. This specification reflects a combination of functionality that is already present in the org.apache.catalina.realm.JNDIRealm class, as well as requirements for enhancements that have been discussed. Where appropriate, requirements statements are marked [Current] and [Requested] to distinguish them. The current status of this functional specification is PROPOSED. It has not yet been discussed and agreed to on the TOMCAT-DEV mailing list. The code in the current version of JNDIRealm, and the ideas expressed in this functional specification, are the results of contributions from many individuals, including (alphabetically): Holman, John <[EMAIL PROTECTED]> Lockhart, Ellen <[EMAIL PROTECTED]> McClanahan, Craig <[EMAIL PROTECTED]> The implementation of this functionality depends on the following external specifications: http://java.sun.com/products/jndi/";>Java Naming and Directory Interface (version 1.2.1 or later) The implementation of this functionality shall conform to the following requirements: Be realized in one or more implementation classes. Implement the org.apache.catalina.Realm interface. [Current] Implement the org.apache.catalina.Lifecycle interface. [Current] Subclass the org.apache.catalina.realm.RealmBase base class. Live in the org.apache.catalina.realm package. [Current] Support a configurable debugging detail level. [Current] Log debugging and operational messages (suitably internationalized) via the getContainer().log() method. [Current] The following environmental dependencies must be met in order for JNDIRealm to operate correctly: The desire to utilize JNDIRealm must be registered in $CATALINA_HOME/conf/server.xml, in aelement that is nested inside a corresponding , , or element. If the Administrator Login operational mode is selected, the configured administrator username and password must be configured in the corresponding directory server. If the Username Login operational mode is selected, the corresponding directory server must be configured to accept logins with the username and password that will be passed to JNDIRealm by the appropriate Authenticator. Correct operation of JNDIRealm depends on the following specific features of the surrounding container: Interactions with JNDIRealm will be initiated by the appropriate Authenticator implementa
Re: Poor Tomcat 3.2.2 performance on Win32 with class reloadingenabled
Thanks for the report - if you can think of a patch we can use it for 3.2.3. The reloading system has been almost completely rewritten for 3.3, with far fewer accesses to the file system. Have you tried with a different VM ? ( I don't think we can avoid getCanonicalPath, is a very useful call and is very important for security too ) Costin On Fri, 15 Jun 2001, Brett M. Bergquist wrote: > I just upgraded or application from Tomcat 3.1 to Tomcat 3.2.2 and noticed a dramatic slowdown and increased CPU utilization. This is on WinN 4.0 SP5. To figure out what was happening, I fired up OptimizeIT and ook a look. I found that 68% time was being spent in "org.apache.tomcat.core.ServletWrapper.handleReload" and of the time within this method, 51% of the time was being spent in "java.io.File.getCanonicalPath" and of the time spend within this method, all of it was spent within "java.io.Win32FileSystem.canonicalize". > > My question is is this normal and what in the hell is taking so long in "java.io.Win32FileSystem.canonacalize"? Once I disabled class reloading, by performance and CPU utilization went back to what was present with 3.1. > > Thanks for any input. > > Brett M. Bergquist > Canoga Perkins Corp. >
RE: next 3.3 milestone
On Fri, 15 Jun 2001, Larry Isaacs wrote: > Next week sounds good for a Milestone 4. I'll try to propose > a new RELEASE-PLAN-3.3 this weekend. > > What is involved in enabling jasper34? Assuming that is > fairly simple I don't have a problem enabling jasper34. > We will need to document how to switch back to the JSP > configuration in Milestone3 for those who would prefer > not to use jasper34. The only change is instead of . I'm almost done with JspServlet, and I'll start running tests ( last time I did we were passing all watchdog/sanity, as expected :-). There are few new 3.3 bugs we need to evaluate, but so far nothing seems blocking. Costin
Re: Jasper34: static output changes
On Fri, 15 Jun 2001, Casey Lucas wrote: > > Costin, > > sounds good. > > btw, when do you think the generator code in 34 will settle down > a little? Soon :-) There is only one more change in the generator layout - switching to a "visitor" pattern, with the tree representation of the page separated from the actual generator. If you are thinking to tagpool changes - please wait until RuntimeLiaison gets a bit of shape, I would like to provide some hooks for the container to control the pools. Again, the idea is to allow a "toolkit" model, where different components can be plugged in. Separating tree is very important to allow modules to do various optimizations ( like replacing common tags with equivalent in-line java code ) and to do the direct bytecode generation. Costin
Poor Tomcat 3.2.2 performance on Win32 with class reloading enabled
I just upgraded or application from Tomcat 3.1 to Tomcat 3.2.2 and noticed a dramatic slowdown and increased CPU utilization. This is on WinNT 4.0 SP5. To figure out what was happening, I fired up OptimizeIT and took a look. I found that 68% time was being spent in "org.apache.tomcat.core.ServletWrapper.handleReload" and of the time within this method, 51% of the time was being spent in "java.io.File.getCanonicalPath" and of the time spend within this method, all of it was spent within "java.io.Win32FileSystem.canonicalize". My question is is this normal and what in the hell is taking so long in "java.io.Win32FileSystem.canonacalize"? Once I disabled class reloading, by performance and CPU utilization went back to what was present with 3.1. Thanks for any input. Brett M. Bergquist Canoga Perkins Corp.
cvs commit: jakarta-tomcat-4.0/catalina build.xml
amyroh 01/06/15 13:51:17 Modified:catalina build.xml Log: Add fix to build with jdk1.2. It excludes jdk 1.3 dependent files unless "using.jdk.1.3=true" in build.properties. Submitted by John Reilly Revision ChangesPath 1.44 +4 -0 jakarta-tomcat-4.0/catalina/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v retrieving revision 1.43 retrieving revision 1.44 diff -u -r1.43 -r1.44 --- build.xml 2001/06/01 00:30:26 1.43 +++ build.xml 2001/06/15 20:51:16 1.44 @@ -146,6 +146,10 @@ unless="javamail.present" /> + +
cvs commit: jakarta-tomcat-4.0 build.properties.sample
amyroh 01/06/15 13:48:41
Modified:.build.properties.sample
Log:
Add fix to build with jdk1.2. Uses an extra property in the build.properties
"using.jdk.1.3=true".
Uncomment this to compile CGI using jdk 1.3.
Submitted by John Reilly
Revision ChangesPath
1.5 +6 -1 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.properties.sample 2001/06/01 18:30:20 1.4
+++ build.properties.sample 2001/06/15 20:48:41 1.5
@@ -6,7 +6,7 @@
# to "build.properties" in the same directory that contains the top level
# "build.xml" file.
#
-# $Id: build.properties.sample,v 1.4 2001/06/01 18:30:20 jon Exp $
+# $Id: build.properties.sample,v 1.5 2001/06/15 20:48:41 amyroh Exp $
# -
# The path that is base for the rest of the paths in this file.
@@ -52,3 +52,8 @@
# The directory containing your binary distribution of the Servlet 2.3
# and JSP 1.2 API classes
servletapi.home=${base.path}/jakarta-servletapi-4/dist
+
+# This property should be uncommented if you are using JDK 1.3
+# If it is not defined, classes that depend on 1.3 APIs will not
+# be compiled.
+#using.jdk.1.3=true
Re: Jasper34: static output changes
Costin,
sounds good.
btw, when do you think the generator code in 34 will settle down
a little?
-casey
[EMAIL PROTECTED] wrote:
>
> Ok, time to discuss the first mini-optimization.
>
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
>
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
>
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
>
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
>
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
>
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
>
> The main benefits:
>
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
>
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
>
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
>
> - a single output model - easier to test and optimize than 2.
>
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
>
> Costin
>
Re: Jasper34: static output changes
+1
[EMAIL PROTECTED] wrote:
>
> Ok, time to discuss the first mini-optimization.
>
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
>
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
>
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
>
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
>
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
>
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
>
> The main benefits:
>
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
>
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
>
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
>
> - a single output model - easier to test and optimize than 2.
>
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
>
> Costin
>
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote:
[snip]
> > > But it makes only sense if someone want to use a new module with a old core
> > > code.
> > > That means a protocol developed in 1.3.x could be used in 1.2.x.
> > > Well could be nice, but difficult to handle. Backport a new protocol to an old
> > > mod_jk!
> >
> > It makes sense for the kind of code I'm writing for the Domino connector
> > though. The source supports/will support the latest protocols, but
> > should still be buildable in cases where those protocols aren't
> > available.
>
> The protocols should be in one place, the interface to a WebServer in another
> place.
> Domino is a WebServer so you should not care about the protocols but just
> provide the calls the core part needs, otherwise we will have a huge quantity of
> code copied in several places (Hard for maintenance).
> These version things should be only when making a backport of something new to a
> old version or when adding a code that cannot work in an old version.
I'm obviously missing the point here: in common with other connectors
the Domino connector makes calls /to/ the common jk code -- the external
interface it provides faces the other way -- towards Domino. That means
that as the interface to the jk code changes the Domino connector has to
change too. I want to be able to build a Domino connector for Tomcat 3.2
(for example) and a Domino connector for the current bleeding edge code
from the same source base. At the moment I can do that, but it involves
me having switches that are local to my source tree to select features
suitable for the current jk version. What I'm proposing is that the
version information should be exposed by the common jk code for /all/
connectors to use.
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT >= TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT("HTTPS_KEYSIZE", &dummy, 0);
if (workBuf[0] == '[')
s->ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
--
Andy Armstrong, Tagish
structure for Tomcat-Connectors
Hi, I am trying to think about a structure for our connectors: From httpd From httpd | | +| + AP1.3 | AP2.0 | NETSCAPE | DOMINO | others|| + + core mod_jk + + mod_backhand + + + ajp12 | ajp13 | apj14 | warp | new protocols +| +| | | To JVMTo JVM | | + +++ + ajp12 | ajp13 | apj14 | warp | new protocols + + HTTP + + +++ + Tomcat layers + + + +++ + .. + That would means that if we are writting a warp connector we should only be worried by the protocol and have 2 sets of routines one to get/send information from/to a core module, one to send/get information to/from a Tomcat. In a configuration like that the Apache 2.0 specialist would write the AP2.0 part, the Apache1-3 the AP1.3 and so on. Having a defined interface to Tomcat there should be not problem to get a protocol supported by all Tomcat versions. * mod_backhand is not (yet) ours. Any comments? Nice week-end Jean-frederic
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote: > > jean-frederic clere wrote: > [snip] > > > #if defined(JK_VERSION) && JK_VERSION >= 1 > > > ... newer stuff ... > > > #endif > > > > Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) > > Yup. > > > But it makes only sense if someone want to use a new module with a old core > > code. > > That means a protocol developed in 1.3.x could be used in 1.2.x. > > Well could be nice, but difficult to handle. Backport a new protocol to an old > > mod_jk! > > It makes sense for the kind of code I'm writing for the Domino connector > though. The source supports/will support the latest protocols, but > should still be buildable in cases where those protocols aren't > available. The protocols should be in one place, the interface to a WebServer in another place. Domino is a WebServer so you should not care about the protocols but just provide the calls the core part needs, otherwise we will have a huge quantity of code copied in several places (Hard for maintenance). These version things should be only when making a backport of something new to a old version or when adding a code that cannot work in an old version. > At the moment I'm doing that with switches in a header that's > local to the Domino connector, but it would be better if it was part of > the jk/common source tree. > > > > b) People working on the cutting edge j-t-c stuff who will be using the > > > latest versions of everything. > > > > ? That is CVS ? > > Yes. > > -- > Andy Armstrong, Tagish
RE: next 3.3 milestone
Next week sounds good for a Milestone 4. I'll try to propose a new RELEASE-PLAN-3.3 this weekend. What is involved in enabling jasper34? Assuming that is fairly simple I don't have a problem enabling jasper34. We will need to document how to switch back to the JSP configuration in Milestone3 for those who would prefer not to use jasper34. Larry > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 15, 2001 6:05 AM > To: [EMAIL PROTECTED] > Subject: next 3.3 milestone > > > Hi ( Larry ), > > I'll review the new bugs over the weekend, and I hope we can get a new > milestone out for next week. > > Do you think it would be possible to enable jasper34 in the next > milestone? It would help me a lot in the refactoring process, > the code is > stable ( the generated code is almost identical ). > > ( jasper33 will still be used and default for beta and the official > release, no chance of finishing all the changes in 34 until then ). > > Please let me know what you think - if we could do that I'll focus on > finsihing the line number mapping and running tests, if not > I'll just go > to the next stage of refactoring the generator. > > Costin >
RE: Tomcat Admin Web Interface
On Fri, 15 Jun 2001, Morrison, John wrote: > Would/could this be implemented as a web context with (possibly) some > 'administration' flag set in it's context that way, if you didn't want to > have a GUI (security?) you could just remove the context? > My thinking to date has been that we should support multiple faces (webapp, SOAP-based, perhaps Jini and/or RMI) that talks to the same "business logic" underneath, so that people could choose different integration approaches to meet their needs. WRT shipping as a webapp, the current Tomcat 4 "manager" application is shipped with a security constraint that requires role "manager", but there are no such users in the default usernames database (i.e. you have to explicitly add one). If we trust container-managed security, I don't see much need for a separate "administrative application" flag in the configuration. > Just my 2p worth ;) > Craig > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 14 June 2001 23:13 > To: '[EMAIL PROTECTED]' > Subject: RE: Tomcat Admin Web Interface > > > > It would be very good at this stage to go back 1 1/2 years in tomcat > archives and re-read the "admin" thread. It was a huge discussion, with > many ideas - but nothing happened. > > As usual, my opinion is that you should start with a prototype and/or > existing code - and figure out what is the best way to do it by trying > different aproaches. > > Costin > > > > > On Thu, 14 Jun 2001, Eric Anderson wrote: > > > Count me in on working on an admin interface for Tomcat. This along with > a > > better install/connector config program would go a long way to improve the > > overall usability of Tomcat for me. > > > > Having had experience working on server product GUIs, the plan to decide > > what goes into the GUI before starting the project is definitely the best > > way to go. Even though there is a considerable amount of planning and > > discussion that goes into the GUI requirements sheet, in the end it is > > easier to deny unreasonable requests like, "we have this new functionality > > two weeks before the release can you incorporate it into the admin > > interface?", or "I'd like the GUI to wash and wax my car." A hard and > fast > > list of GUI features for each release is essential to keeping the GUI > > project manageable > > > > My 2 cents. > > > > Eric > > > > > > On Thu, 14 Jun 2001, M B wrote: > > > > > Hello All, > > > > > > In response to the recent postings regarding Tomcat > > > documentation and administration (Re: ~rant~ Docs, > > > user list, etc.), I am willing to contribute much > > > effort in this area. In addition to documentation, I > > > am particularly interested in helping to build an > > > administrative web interface for Tomcat 4.0, something > > > similar to JRun Management Console, for example. > > > > > > > That would be awesome! > > > > > Naturally, I want to coordinate my efforts with the > > > Tomcat community. Can anyone please point out where I > > > should begin, or who I should contact? Is there a > > > project for this? The Catalina TODO identifies John > > > Shin as volunteer for producing an admin interface, > > > but I thought I should email this list before > > > contacting him directly. > > > > > > > He volunteered long, long, ago but I haven't heard anything from him > > lately. > > > > As it happens, I've been accumulating a list of functional requirements > > for admin capabilities that I'd like to post for discussion. I'll be > > finished with what I'm thinking in the next couple of days. > > > > What I'd like to see us do on issues like this is to discuss and agree on > > a functional specs document that is checked in to the CVS repository, and > > then start working together on the pieces. It's a little more formal than > > the usual :-) open source approach, but I think it will help in the long > > run. Does that sound like a useful plan? > > > > > Thanks, > > > Matt > > > > > > > Craig > > > > > === > 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: Changing the TomCat Directory structure...
On Fri, 15 Jun 2001, Vishy Kasar wrote:
> Hi,
>
> We are thinking of embedding TomCat4.0 in our app server. We have
> limited number of top level directories and want to rearrange the TomCat
> files in that directory structure.
>
> Specifically we want the common/lib to be present as lib/common and
> server/lib to be present as lib/server. This will reduce the top level
> directories from three (lib, server, common) to just one.
>
Actually, you'd need at least two ("/classes" and "/lib") for this
strategy to completely replace the current model. The complete current
model looks like this:
classes/ Unpacked classes for "Shared" classloader
common/
classes/ Unpacked classes for "Common" classloader
lib/ JAR files for "Common" classloader
server/
classes/ Unpacked classes for "Catalina" classloader
lib/ JAR files for "Catalina" classloader
lib/ JAR files for "Shared" classloader
An alternative based on your desires might look like:
classes/
common/
server/
shared/
lib/
common/
server/
shared/
> Here are a few options that are available to me. Can you folks suggest a
> good one for this situation?
>
> 1. Make the change only in our copy of bootstrap.java and remember to do
> this change each time we get a new version of tomcat from apache.
>
> 2. Make the directory names configurable by adding 2 more variables
> CATALINA_SERVER_LIB and CATALINA_COMMON_LIB and contribute the change
> back to apache.
>
> 3. Assume that reducing top level directories is a good idea in general,
> do the change suggested in #1 above and contribute it back to apache.
>
> --
> Cheers!
I don't see "reducing the number of top level directories" as a very
compelling goal, and prefer to see the stuff sorted at the top level based
on which classloader it's going to go into.
Note also that having a top-level "lib" directory for user application
classes is getting pretty common.
What do others think?
Craig
Re: [t4] FYI: usual problems building according to README...
On Fri, 15 Jun 2001, Geoff Soutter wrote: > Hi tc4 people, > > I'm putting myself through the regular "build TC4 from source" hell that I > do whenever I want to test the latest version. (this is on WinNT4) > > I came across the following issues, you may be aware of them already but I > thought I'd report 'em just in case... > > 1) It no longer builds on JDK1.2. The README indicates 1.2 or later is > required. > Yep ... that's a known issue with the new CGI support. It will get set up so that this is (at least) optional until we resolve the underlying dependency. > I get the following errors on build dist for tomcat: > > build-main: > [javac] Compiling 2 source files to > D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\build\classes > [javac] > D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\src\share\org\apache\ca > talina\servlets\CGIServlet.java:1567: Wrong number of arguments in metho > d. > [javac] proc = rt.exec(cmdAndArgs.toString(), > hashToStringArray(env), wd); > [javac] ^ > [javac] > D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\src\share\org\apache\ca > talina\util\ProcessHelper.java:381: Wrong number of arguments in method. > > [javac] proc = rt.exec(cmdAndArgs.toString(), > hashToStringArray(env), wd); > [javac] ^ > [javac] 2 errors > > BUILD FAILED > > Seems it's relying on a Runtime.exec() method overload which was added in > JDK1.3 (interesting, the @since tag is missing? weird. Hope I'm not > suffering brain-fade on this one...) > > 2) it seems to be depending on old versions of the projects it depends on: > > For example, the bootstrap.bat file for building jakarta-ant from source > doesn't co-operate well with the other stuff. > > It sets > > - ANT_HOME=. > - stuffs up the classpath (adds extra ""'s in there) > - puts ant.jar in /bootstrap/lib rather than /lib where the other build > scripts expect it. > The revised instructions say to use a released version of Ant that has "$ANT_HOME/bin" on your PATH. Then, you can just say "ant dist" or whatever. > Also, jakarta-regexp currently builds jakarta-regexp-1.3-dev.jar rather than > the jakarta-regexp-1.2.jar that the catalina build.xml expects. Seems you > can just rename the jar file or I guess you could use > > cvs checkout -r RELEASE_1_2 jakarta-regexp > Classic reason I think putting version numbers in JAR filenames is not the right answer ... The other alternative (just copy all the JARs from that directory) runs the risk of getting multiple copies. > 3) seems theres co-ordination problem between the jakarta-servletapi-4 and > jakarta-tomcat. > > When I build I get the following error: > > BUILD FAILED > > D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\build.xml:129: > D:\apps\jakarta\src\40b5\jakarta-servletapi-4\docs\api not found. > > build dist for the servlet API does create javadoc, but they are in the > dist\docs\api dir... > You need to do a "ant dist" in jakarta-servletapi-4 to create the API docs. I'll add that to the How To stuff. > Apart from that it went well though :-) I'm cookin' with gas now... > > Geoff > -- > Keep cool till after school! > > Craig
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: 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: > > > > > > > > ... > > > >> directoryName="public_html" > > userClass="org.apache.catalina.startup.PasswdUserDatabase"/> > > > > ... > > > > > > > >Craig McClanahan > > >
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip] > >If nothing else such a constant could be used to throw a compile time > >error if people attempt to build a connector using incompatible shared > >jk code. > > Could you develop ? D'you mean could I write code that throws a compile time error? If so, it's just #if !defined(JK_MODULE_RELEASE) || JK_MODULE_RELEASE < REQUIRED #error "You need to have a later of the jk module. See source for details" #endif Is that what you meant or were you expecting something more glamorous? -- Andy Armstrong, Tagish
Jasper34: static output changes
Ok, time to discuss the first mini-optimization.
Right now jasper has 2 ways to output data - one is the common
out.println("String ");
The other ( not very used ) is using an additional file to store the
strings, and it's enabled by "largefile" option.
The output system is probably the most important part of jasper ( except
taglibs ) with regard to performance.
My proposal is to drop the first option, which is also failing for chunks
bigger than 64k ( due to .class file limitations on constant pool
strings), and use the second ( with some changes ) in all cases.
The main problem is that the java file will be less readable (
out.println( strings[4] ) instead of the real string ). That can be
resolved easily by generating a comment with the real string ( most users
will not read the java file - now that we are close to line number
mapping it'll happen even less ).
Note that this is nothing new for jasper - the option has been present in
jasper and is tested.
The main benefits:
- full control over static content allocation. If the strings are part of
the constant pool, they are loaded with the class and garbage collected
only if the class itself is gc. By loading them from the file we could
easily add a LRU cache for the static chunks and reduce the runtime memory
usage quite significantly.
- ability for containers to control the static content. For a large file
the connector could send only the file and offsets to apache, instead of
reading and sending the large chunk.
- it will work with large files without requiring users to set options
( that could be resolved by detecting large chunks and turning it on
automatically )
- a single output model - easier to test and optimize than 2.
Let me know if you see any problem with that - it'll probably happen next
week, I'm still stuck with the JspServlet.
Costin
RE: Tomcat Admin Web Interface
On Fri, 15 Jun 2001, Morrison, John wrote: > Would/could this be implemented as a web context with (possibly) some > 'administration' flag set in it's context that way, if you didn't want to > have a GUI (security?) you could just remove the context? This is how it is implemented today in tomcat 3.x. It has some nice features already - you can use it to deploy/undeploy apps, see informations about the server, run watchdog and tests ( from a web interface, no more command line and class path hacking ). What's missing the most is a nice look and improvement in the presentation part, and maybe other pages. We are using simple JSP pages, with few special taglibs to allow access to the internals. ( the development was mostly driven by need to have a convenient way to test and check internal state - there are few pages that still need to be checked in, the auth admin and few more state info, but right now I'm overloaded ) Costin > > Just my 2p worth ;) > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 14 June 2001 23:13 > To: '[EMAIL PROTECTED]' > Subject: RE: Tomcat Admin Web Interface > > > > It would be very good at this stage to go back 1 1/2 years in tomcat > archives and re-read the "admin" thread. It was a huge discussion, with > many ideas - but nothing happened. > > As usual, my opinion is that you should start with a prototype and/or > existing code - and figure out what is the best way to do it by trying > different aproaches. > > Costin > > > > > On Thu, 14 Jun 2001, Eric Anderson wrote: > > > Count me in on working on an admin interface for Tomcat. This along with > a > > better install/connector config program would go a long way to improve the > > overall usability of Tomcat for me. > > > > Having had experience working on server product GUIs, the plan to decide > > what goes into the GUI before starting the project is definitely the best > > way to go. Even though there is a considerable amount of planning and > > discussion that goes into the GUI requirements sheet, in the end it is > > easier to deny unreasonable requests like, "we have this new functionality > > two weeks before the release can you incorporate it into the admin > > interface?", or "I'd like the GUI to wash and wax my car." A hard and > fast > > list of GUI features for each release is essential to keeping the GUI > > project manageable > > > > My 2 cents. > > > > Eric > > > > > > On Thu, 14 Jun 2001, M B wrote: > > > > > Hello All, > > > > > > In response to the recent postings regarding Tomcat > > > documentation and administration (Re: ~rant~ Docs, > > > user list, etc.), I am willing to contribute much > > > effort in this area. In addition to documentation, I > > > am particularly interested in helping to build an > > > administrative web interface for Tomcat 4.0, something > > > similar to JRun Management Console, for example. > > > > > > > That would be awesome! > > > > > Naturally, I want to coordinate my efforts with the > > > Tomcat community. Can anyone please point out where I > > > should begin, or who I should contact? Is there a > > > project for this? The Catalina TODO identifies John > > > Shin as volunteer for producing an admin interface, > > > but I thought I should email this list before > > > contacting him directly. > > > > > > > He volunteered long, long, ago but I haven't heard anything from him > > lately. > > > > As it happens, I've been accumulating a list of functional requirements > > for admin capabilities that I'd like to post for discussion. I'll be > > finished with what I'm thinking in the next couple of days. > > > > What I'd like to see us do on issues like this is to discuss and agree on > > a functional specs document that is checked in to the CVS repository, and > > then start working together on the pieces. It's a little more formal than > > the usual :-) open source approach, but I think it will help in the long > > run. Does that sound like a useful plan? > > > > > Thanks, > > > Matt > > > > > > > Craig > > > > > === > 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 >
Mail Delivery Status Notification
MAIL ESSENTIALS SENDER NOTIFICATION The following message: TO: [EMAIL PROTECTED] FROM:[EMAIL PROTECTED] DATE: Thu, 14 Jun 2001 23:31:32 +0100 (BST) Subject: Fwd: My First Contribution... has been quarantined by Mail Essentials for the following reason(s): Message contains attachments: isapi_install.vbs Mail essentials And like a true genius I forgot to attach the script... BTW - on most machines the web Server Name is "Default Web Site" and you have to use quotes. Pete --- Peter Horne <[EMAIL PROTECTED]> wrote: > From Peter Horne Thu Jun 14 23:27:42 2001 > Received: from [210.8.224.2] by > web13507.mail.yahoo.com; Thu, 14 Jun 2001 23:27:42 > BST > Date: Thu, 14 Jun 2001 23:27:42 +0100 (BST) > From: Peter Horne <[EMAIL PROTECTED]> > Subject: My First Contribution... > To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > Content-Length: 1466 > > Hi... > > I'm not sure if any others have looked at what's > required to automate the install of the ISAPI filter > on IIS/Win2k - by the time I'd finished > understanding > the IIS metabase I'd completed the attached vb > script. > It does all the required metabase additions/changes > to install both as filter and an extension (the dll > does both) by creating a virtual directory and > setting > all the appropriate attributes. > > I've tested it pretty thouroughly - I'd appreciate > any > feedback (good/bad/indifferent). > > I've also got a windows installer in progress that > does it all as well - anyone interested? > > Cheers...Pete > > Tomcat ISAPI Redirector Installation Utility > usage: isapi_install > > > server: The Web Server Name > fdir: the full path to the directory that > contains the isapi filter > worker: Full path and file name of the > worker > properties file > mount: Full path and file name of the > worker > mount properties file > log:Full path and file name of the log > file > level: The log level emerg | info > (Re-runs are ok and will change/reset settings) > > = > Peter S. Horne > [EMAIL PROTECTED] > > To know and not to do is not to know > > > > Do You Yahoo!? > Get your free @yahoo.co.uk address at > http://mail.yahoo.co.uk > or your free @yahoo.ie address at > http://mail.yahoo.ie > = Peter S. Horne [EMAIL PROTECTED] To know and not to do is not to know Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie <>
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf MessageBytes.java
mmanders01/06/15 10:05:10
Modified:util/java/org/apache/tomcat/util/buf MessageBytes.java
Log:
Updated setString to just return if the string passed in is a null. This prevents
problems later on when we try and access the string member.
Revision ChangesPath
1.3 +2 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java
Index: MessageBytes.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MessageBytes.java 2001/05/29 06:22:53 1.2
+++ MessageBytes.java 2001/06/15 17:05:09 1.3
@@ -163,6 +163,8 @@
public void setString( String s ) {
recycle();
+if (s == null)
+return;
strValue=s;
hasStrValue=true;
type=T_STR;
next 3.3 milestone
Hi ( Larry ), I'll review the new bugs over the weekend, and I hope we can get a new milestone out for next week. Do you think it would be possible to enable jasper34 in the next milestone? It would help me a lot in the refactoring process, the code is stable ( the generated code is almost identical ). ( jasper33 will still be used and default for beta and the official release, no chance of finishing all the changes in 34 until then ). Please let me know what you think - if we could do that I'll focus on finsihing the line number mapping and running tests, if not I'll just go to the next stage of refactoring the generator. Costin
Re: Fwd: Tomcat & JDK Version
On Fri, 15 Jun 2001, Pier P. Fumagalli wrote: > Haydn Haines - Sun UK - Partner Support at [EMAIL PROTECTED] wrote: > > > Hi All, > > > > The tomcat 3.2.2 README file states that jdk 1.1 or later AND JSSE > > 1.0.2 or later are required... > > > > However, the JSSE 1.0.2 install.html states that JSSE 1.0.2 requires > > Java 2 SDK 1.2.1 or greater OR Java 2 RE 1.2.1... > > > > So, doesn't that mean the tomcat 3.2.2 README file shouldn't say "jdk > > 1.1 or later" or am I missing something (a brain perhaps :) )??? Not quite - you can run tomcat 3.2.2 with JDK1.1. Some of it's features that require JDK1.2 will not be available - JSSE, sandboxing, context class loader. I agree the doc is not very clear on this issue. If you need SSL in a JDK1.1 environment you can use Apache/SSL. For sandboxing and context class loader - unfortunately there is no solution for 1.1. Tomcat is a modular server, and the "core" and "base" modules ( those implementing the essentials of a servlet container ) are using minimal features of JDK ( there are few minimal changes to make 3.3 run in J2ME for example ). In addition, we do provide advanced modules that take advantage of latest VM features. Costin
Debian Package (was RE: ~rant~ Docs, user list, etc.)
On Fri, 15 Jun 2001, GOMEZ Henri wrote: > We should add a DEB (Debian package) and PKG used by Solaris. > If there is people on the list who have to .deg/.pkg, may we > suggest them send their build file. I could commit the .spec > for RPM building with it's companion files (patches, init...) There's already a deb package of Tomcat 3.2.2 and mod_jk in the contrib section Debian's testing and unstable distributions. According to Debian's website, Stefan Gybas ([EMAIL PROTECTED]) is the packager.
Problem with JCE and Tomcat
Hello. I have read about the JCE and Tomcat problem (BugRat Report #116). Please, if you discovered how to solve the problem, let me know. Thank you very much. Fabrizio
Changing the TomCat Directory structure...
Hi, We are thinking of embedding TomCat4.0 in our app server. We have limited number of top level directories and want to rearrange the TomCat files in that directory structure. Specifically we want the common/lib to be present as lib/common and server/lib to be present as lib/server. This will reduce the top level directories from three (lib, server, common) to just one. Here are a few options that are available to me. Can you folks suggest a good one for this situation? 1. Make the change only in our copy of bootstrap.java and remember to do this change each time we get a new version of tomcat from apache. 2. Make the directory names configurable by adding 2 more variables CATALINA_SERVER_LIB and CATALINA_COMMON_LIB and contribute the change back to apache. 3. Assume that reducing top level directories is a good idea in general, do the change suggested in #1 above and contribute it back to apache. -- Cheers!
Fwd: My First Contribution...
And like a true genius I forgot to attach the script... BTW - on most machines the web Server Name is "Default Web Site" and you have to use quotes. Pete --- Peter Horne <[EMAIL PROTECTED]> wrote: > From Peter Horne Thu Jun 14 23:27:42 2001 > Received: from [210.8.224.2] by > web13507.mail.yahoo.com; Thu, 14 Jun 2001 23:27:42 > BST > Date: Thu, 14 Jun 2001 23:27:42 +0100 (BST) > From: Peter Horne <[EMAIL PROTECTED]> > Subject: My First Contribution... > To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > Content-Length: 1466 > > Hi... > > I'm not sure if any others have looked at what's > required to automate the install of the ISAPI filter > on IIS/Win2k - by the time I'd finished > understanding > the IIS metabase I'd completed the attached vb > script. > It does all the required metabase additions/changes > to install both as filter and an extension (the dll > does both) by creating a virtual directory and > setting > all the appropriate attributes. > > I've tested it pretty thouroughly - I'd appreciate > any > feedback (good/bad/indifferent). > > I've also got a windows installer in progress that > does it all as well - anyone interested? > > Cheers...Pete > > Tomcat ISAPI Redirector Installation Utility > usage: isapi_install > > > server: The Web Server Name > fdir: the full path to the directory that > contains the isapi filter > worker: Full path and file name of the > worker > properties file > mount: Full path and file name of the > worker > mount properties file > log:Full path and file name of the log > file > level: The log level emerg | info > (Re-runs are ok and will change/reset settings) > > = > Peter S. Horne > [EMAIL PROTECTED] > > To know and not to do is not to know > > > > Do You Yahoo!? > Get your free @yahoo.co.uk address at > http://mail.yahoo.co.uk > or your free @yahoo.ie address at > http://mail.yahoo.ie > = Peter S. Horne [EMAIL PROTECTED] To know and not to do is not to know Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie <>
My First Contribution...
Hi... I'm not sure if any others have looked at what's required to automate the install of the ISAPI filter on IIS/Win2k - by the time I'd finished understanding the IIS metabase I'd completed the attached vb script. It does all the required metabase additions/changes to install both as filter and an extension (the dll does both) by creating a virtual directory and setting all the appropriate attributes. I've tested it pretty thouroughly - I'd appreciate any feedback (good/bad/indifferent). I've also got a windows installer in progress that does it all as well - anyone interested? Cheers...Pete Tomcat ISAPI Redirector Installation Utility usage: isapi_install server: The Web Server Name fdir: the full path to the directory that contains the isapi filter worker: Full path and file name of the worker properties file mount: Full path and file name of the worker mount properties file log:Full path and file name of the log file level: The log level emerg | info (Re-runs are ok and will change/reset settings) = Peter S. Horne [EMAIL PROTECTED] To know and not to do is not to know Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
[Bug 219] - tomcat cannot recognise include file tag correctly BugRat Report#336
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=219 *** shadow/219 Sun May 20 17:19:11 2001 --- shadow/219.tmp.22635Fri Jun 15 08:54:10 2001 *** *** 1,19 ! Bug#: 219 ! Product: tomcat ! Version: tomcat(jasper) ! Platform: ! OS/Version: ! Status: NEW ! Resolution: ! Severity: Normal ! Priority: High ! Component: ! AssignedTo: [EMAIL PROTECTED] ! ReportedBy: [EMAIL PROTECTED] ! URL: ! Cc: ! Summary: tomcat cannot recognise include file tag correctly BugRat Report#336 ! this problem is like this: file1--->aa.jsp <%@ page contentType="text/html;charset=gb2312" %> --- 1,19 ! ++ ! | tomcat cannot recognise include file tag correctly BugRat Report#336 | ! ++ ! |Bug #: 219 Product: Tomcat 3| ! | Status: RESOLVEDVersion: Unknown | ! | Resolution: WORKSFORME Platform: All | ! | Severity: Normal OS/Version: All | ! | Priority: High Component: Unknown | ! ++ ! | Assigned To: [EMAIL PROTECTED]| ! | Reported By: [EMAIL PROTECTED]| ! | CC list: Cc: | ! ++ ! | URL: | ! ++ ! | DESCRIPTION | this problem is like this: file1--->aa.jsp <%@ page contentType="text/html;charset=gb2312" %> *** *** 30,32 --- 30,38 <%@ page contentType="text/html;charset=gb2312" %> ÕâÊÇÒ»¸ö²âÊÔ + + --- Additional Comments From [EMAIL PROTECTED] 2001-06-15 08:54 --- + I'm not sure what version of Tomcat this was reported against, but I've tested + it with 3.2.2 and the latest betas of 3.3 and 4.0 and it works correctly in all + cases. In fact, the work around presented below will cause a translation time + exception because the contentType attribute can't be set more than once. \ No newline at end of file
Fwd: Tomcat & JDK Version
Haydn Haines - Sun UK - Partner Support at [EMAIL PROTECTED] wrote: > Hi All, > > The tomcat 3.2.2 README file states that jdk 1.1 or later AND JSSE > 1.0.2 or later are required... > > However, the JSSE 1.0.2 install.html states that JSSE 1.0.2 requires > Java 2 SDK 1.2.1 or greater OR Java 2 RE 1.2.1... > > So, doesn't that mean the tomcat 3.2.2 README file shouldn't say "jdk > 1.1 or later" or am I missing something (a brain perhaps :) )??? > > Regards, > > Haydn. Darn... I'll forward it to the tomcat-dev mailing list... (Please do remember to include Haydin in the reply... Pier
Re: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll => [j-t-c] webserver poll
Henri, This is actually very easy with the existing code and a tiny patch I submitted a few weeks ago. We're using it in production mode, so it is known to be stable. The first version I submitted had some additional logging added, but I'm attaching a minimal patch. All you have to do is set the lbfactor in workers.properties to 0, and it should never select that worker unless the session route points to it, or the primary worker is down. This also has the added benefit of making externally load balanced clusters behave properly for AOL/Compuserve users without special configuration of the load balancer. Those services use IP randomizing proxies which break generic IP-based sticky. This will cause the sessions to be re-routed from the Apache that receives the request to the Tomcat that initiated the session. This actually works, because we were able to remove all of our special configurations to deal with this from our load balancers. The problem is described at http://webmaster.info.aol.com/index.cfm?article=15 This patch changes the behavior by pre-initializing lb_value for each worker. The selection algorithm searches for the worker with the lowest lb_value that is not in a failed state. It then increments the lb_value by the lb_factor. lb_factor is set to the inverse (1/x) of the lb_factor specified in the config file. When lb_factor in the config file is 0, this number becomes basically MAX_DOUBLE. That means that lb_value becomes MAX_DOUBLE, so it will never be selected for any practical purposes. This patch has been tested extensivly in production use, and works perfectly. Paul Frieden GOMEZ Henri wrote: > > >On Thu, Jun 14, 2001 at 10:28:47AM +0200, GOMEZ Henri wrote: > >> mod_jk support Apache 2.0 > >> > >> And TC 4.0 as preliminary support for ajp13 used > >> in mod_jk. > >> > >> Could you take a look at it ? > > > >Okay, what's the difference between mod_webapp and mod_jk? I thought > >that mod_webapp was the preferred TC 4.0 connector? This seems like > >this is worthy of a FAQ. We've still got people using mod_jserv... > > One of the goal of j-t-c, is to be the answer to : > > 'how to connect my webserver to tomcat ?' > > A great effort has been deployed in having an easy to use > build stuff. > Next effort will be documentation and ... lobbying :) > > >Oh, is it that mod_webapp uses the Warp protocol, not ajp13? Does > >ajp13 support the TC 4.0 hot-deploy functionality? -- justin > > not in ajp13. But it's successor ajp14, have a strongest login > procedure, and autoconf support (uri handled passed to web-server). > Also planned is to inform the web-server of context state, ie > when a context is put down (for admin purpose), the web-servlet > must learn it and route request to another servlet-engine (if we > are in load-balancing configuration). > > what make me think we should add a fault-tolerant/backup-mode worker > in mod_jk. A la load-balancing, having a group of worker (servlet engine), > with one principal, and many as backup. If the principal could no more > handle a request (failure or context down), just have the request > routed to next worker in list. > > What about ? --- jk_lb_worker.orig Fri Jun 15 10:23:42 2001 +++ jk_lb_worker.c Fri Jun 15 10:23:54 2001 @@ -426,7 +426,7 @@ p->lb_workers[i].lb_factor = jk_get_lb_factor(props, worker_names[i]); p->lb_workers[i].lb_factor = 1/p->lb_workers[i].lb_factor; -p->lb_workers[i].lb_value = 0.0; +p->lb_workers[i].lb_value = p->lb_workers[i].lb_factor; p->lb_workers[i].in_error_state = JK_FALSE; p->lb_workers[i].in_recovering = JK_FALSE; if(!wc_create_worker(p->lb_workers[i].name,
RE: #define JK_VERSION in j-t-c (doesn't exist)
>> Why did we start j-t-c ? >> >> - a connector is mainly native code, how to build apxs or >use autoconf >> has nothing to do in tomcat dev/users list. I hope we could have a >> separate dev/users lists later. >> >> - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 >is to freeze >> features and only correct bugs. >> I add some features (AP2.0 support, TimeStamp in log, more >robust handling >> >> of Tomcat failure or reboot) in the mod_jk for TC 3.3 and >now the version >> have diverged :! >> Frankly having 2 code branchs to support is too just much job. >> And then Kevin proposed the ajp13 port to TC 4.0, and so >the need for >> an independant repository >> >> - a connector could/should be independant from the core container >> and we could have a different release rate. >> >> - j-t-c make possible reflexion on how to build connections >> common to TC 3.2/3.3/4.0. See the excellent Coyote >Proposal which live >> now in jtc. > >I understand all that, but I'm not quite clear how that negates the >possible advantage of making it possible to know at compile time which >version of the jk code is being used, and in general if there is a >version number at all defining a way of mapping it to a >numeric constant also seems to be a good idea. We'll keep the idea of version number, cf JF could you add it in version.h. ? +/- how Apache http team use ===> /* Numeric release version identifier: MMNNFFRBB: major minor fix final beta * Always increases along the same track as the source branch. * For example, Apache 1.4.2 would be '10402100', 2.5b7 would be '2057'. */ #define APACHE_RELEASE 10320100 <=== #define JK_MODULE_RELEASE 1021 (1.2.0-b1 ) >Is your concern that, if we were to do >that, the code would end up polluted with many conditionally compiled >sections making testing and maintenance harder? Yep >If nothing else such a constant could be used to throw a compile time >error if people attempt to build a connector using incompatible shared >jk code. Could you develop ?
RE: ~rant~ Docs, user list, etc.
MSI is used by office 2000, which runs well as from win 98 (probably also win95, but that thing is 6 years old ;-)) . (it needs to install itself first, if not present). NT 4 doesn't also come with the MSI pre-installed. As from win me and 2000 it's part of the default install. Mvgr, Martin > -Original Message- > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 15, 2001 7:56 AM > To: [EMAIL PROTECTED] > Subject: RE: ~rant~ Docs, user list, etc. > > > >> Or maybe a configuration validation program that does more > >than just check > >> syntax (a la httpd's)? > > > >I like this idea - but more usefull would be a simple > >InstallShield ( or > >whatever ) installer for windows > > We could use the NullSoft install system instead of InstallShield. > HTTP team use MSI (Microsoft Software Installer) but I'm not sure > it's available on all Windows release (may be just WinNT/Win2K) > > >( the RPMs on linux are magic, soon I > >might forget how to install :-), maybe for other platforms ( since most > >installers can now generate cross platform things ). > > We should add a DEB (Debian package) and PKG used by Solaris. > If there is people on the list who have to .deg/.pkg, may we > suggest them send their build file. I could commit the .spec > for RPM building with it's companion files (patches, init...) > > What about adding that in subdirs in tomcat src/build/pkg : ? > > jakarta-tomcat/src/build/pkg > jakarta-tomcat/src/build/pkg/DEB (debian packaging) > jakarta-tomcat/src/build/pkg/RPMS (redhat packaging) > jakarta-tomcat/src/build/pkg/MSI (microsoft install system) > jakarta-tomcat/src/build/pkg/NIS (nullsoft install system) > jakarta-tomcat/src/build/pkg/PKG (solaris pkg system) > >
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip] > As I said Domino need to be compiled. It could be marked as experimental > and only Domino users will have this warning. > > Why did we start j-t-c ? > > - a connector is mainly native code, how to build apxs or use autoconf > has nothing to do in tomcat dev/users list. I hope we could have a > separate dev/users lists later. > > - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 is to freeze > features and only correct bugs. > I add some features (AP2.0 support, TimeStamp in log, more robust handling > > of Tomcat failure or reboot) in the mod_jk for TC 3.3 and now the version > have diverged :! > Frankly having 2 code branchs to support is too just much job. > And then Kevin proposed the ajp13 port to TC 4.0, and so the need for > an independant repository > > - a connector could/should be independant from the core container > and we could have a different release rate. > > - j-t-c make possible reflexion on how to build connections > common to TC 3.2/3.3/4.0. See the excellent Coyote Proposal which live > now in jtc. I understand all that, but I'm not quite clear how that negates the possible advantage of making it possible to know at compile time which version of the jk code is being used, and in general if there is a version number at all defining a way of mapping it to a numeric constant also seems to be a good idea. Is your concern that, if we were to do that, the code would end up polluted with many conditionally compiled sections making testing and maintenance harder? If nothing else such a constant could be used to throw a compile time error if people attempt to build a connector using incompatible shared jk code. -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
>OK, I get that but the Domino connector (in particular) is fairly >immature -- it's quite likely that bugs will be found that would affect >both people using stable Tomcat releases and those on the development >track -- it would nice to fix any such bugs in a single source file. The Domino connector will be marked experimental as long you didn't find it stable. Don't worry Apache 1.3 users won't compile use Domino connector code :) >I suppose my requirement is unusual in that the Domino connector is >available both as a retrofit for current Tomcat releases and as part of >the j-t-c development track -- most other connector code will have been >frozen as part of the relevant Tomcat release. If the versioning >information isn't useful to other people I'll happily sort my >particular >requirements some other way, but I'm still inclined to use #if/#endif >with some suitable swicth to bracket code that's only usable with the >latest jk code. As I said Domino need to be compiled. It could be marked as experimental and only Domino users will have this warning. Why did we start j-t-c ? - a connector is mainly native code, how to build apxs or use autoconf has nothing to do in tomcat dev/users list. I hope we could have a separate dev/users lists later. - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 is to freeze features and only correct bugs. I add some features (AP2.0 support, TimeStamp in log, more robust handling of Tomcat failure or reboot) in the mod_jk for TC 3.3 and now the version have diverged :! Frankly having 2 code branchs to support is too just much job. And then Kevin proposed the ajp13 port to TC 4.0, and so the need for an independant repository - a connector could/should be independant from the core container and we could have a different release rate. - j-t-c make possible reflexion on how to build connections common to TC 3.2/3.3/4.0. See the excellent Coyote Proposal which live now in jtc. We're far from a release, we have to finish ajp14 in mod_jk, ease installation of warp under Apache 1.3/2.0 (rpm/apr...). And Coyote as a specialised HTTP ORB, is an excellent area of reflexion about request/services in the HTTP/WWW world. So Domino could be alpha or beta quality, it should be in all j-t-c release, millenium, beta, final
RE: Plans for Tomcat 3.2.3 and later
+1 Larry > -Original Message- > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 14, 2001 11:49 AM > To: [EMAIL PROTECTED] > Subject: Plans for Tomcat 3.2.3 and later > > > Now that Tomcat 3.2.2 is out it's time to starting thinking > about 3.2.3. My > thoughts are to have a release for 3.2.3 in three or four > months. This will > be strictly a bug fix release. The only hard and fast > release requirements > are to fix any specification compliance issues that may be > discovered in > 3.2.2 and that are no regression failures. Beyond that, any > bugs are fair > game and 3.2.3 will roll these up into a public release. > I'll volunteer to > be the release manager for this release (unless someone else > is crazy enough > to want the job). Any discussion? Comments? I'll put > together a formal > release plan in the next couple days. > > Marc Saegesser > > >
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: > > >OK, but I was thinking of something numeric so it could easily > >be tested > >at compile time, for example > > > >#if defined(JK_VERSION) && JK_VERSION >= 1 > >... newer stuff ... > >#endif > > > >Strings are fine for user readable versioning, but hard to test at > >compile time. > > I understand better there :=) > > Instead of avoid #ifdef/#endif in all the sources, we'll use the > CVS and make release. People who want STABLE release, will grab > a STABLE SNAPSHOT. JTC developpers will continue from CVS. OK, I get that but the Domino connector (in particular) is fairly immature -- it's quite likely that bugs will be found that would affect both people using stable Tomcat releases and those on the development track -- it would nice to fix any such bugs in a single source file. I suppose my requirement is unusual in that the Domino connector is available both as a retrofit for current Tomcat releases and as part of the j-t-c development track -- most other connector code will have been frozen as part of the relevant Tomcat release. If the versioning information isn't useful to other people I'll happily sort my particular requirements some other way, but I'm still inclined to use #if/#endif with some suitable swicth to bracket code that's only usable with the latest jk code. > >b) People working on the cutting edge j-t-c stuff who will be using the > >latest versions of everything. > > > >Ideally I'd like the source for the connector to be the same in either > >case with conditional stuff to include functionality required by later > >jk versions. I assume this would be useful for other connector > >developers too. > > Let be carefull here since having too much #ifdef/#endif will 'pollute' > the code. I'd like better have the EXPERIMENTAL switch as used I take the point about excessive #ifdef/#endif use -- I've seen plenty of C source code rendered practically unreadable in this way. I didn't know about the EXPERIMENTAL switch. What are the semantics of that? > >As to the mapping between textual versions and numeric one way to do it > >would be to reserve a certain number of digits for each part of the > >version string so you'd have something like this: > > > > 1.0.1 ==> 10001 > >12.3.6 ==> 120306 > > Ok -- Andy Armstrong, Tagish
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 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: > > > > ... > >directoryName="public_html" > userClass="org.apache.catalina.startup.PasswdUserDatabase"/> > > ... > > > >Craig McClanahan
RE: #define JK_VERSION in j-t-c (doesn't exist)
>OK, but I was thinking of something numeric so it could easily >be tested >at compile time, for example > >#if defined(JK_VERSION) && JK_VERSION >= 1 >... newer stuff ... >#endif > >Strings are fine for user readable versioning, but hard to test at >compile time. I understand better there :=) Instead of avoid #ifdef/#endif in all the sources, we'll use the CVS and make release. People who want STABLE release, will grab a STABLE SNAPSHOT. JTC developpers will continue from CVS. >b) People working on the cutting edge j-t-c stuff who will be using the >latest versions of everything. > >Ideally I'd like the source for the connector to be the same in either >case with conditional stuff to include functionality required by later >jk versions. I assume this would be useful for other connector >developers too. Let be carefull here since having too much #ifdef/#endif will 'pollute' the code. I'd like better have the EXPERIMENTAL switch as used >As to the mapping between textual versions and numeric one way to do it >would be to reserve a certain number of digits for each part of the >version string so you'd have something like this: > > 1.0.1 ==> 10001 >12.3.6 ==> 120306 Ok
Re: Solaris Performance Problem + linux issue
Hi , My name is mohan I work on smtp pop3 and Imap server protocols .The entire system is written in such a way I can be directly ported on any OS . It is a pure java code . I too written a web mail client which runs on tomcat . I had some issues running tomcat 3.2.1 on Linux . Problem faced: When I invoke a servlet through tomcat it generates response before it could finish transmitting the response to the http client .I invoke another servlet what happens is Tomcat throws an exception connection closed by pear thats right but it doesn't accepts any more connection . What I did to solve the issue is under package org.apache.tomcat.service File by name SimpleTcpEndPoint.java had a Boolean variable by name "running" when Exception raised this variable was made to false if it is false it does not accept any more connection so I took out the part from the exception block . Now it is working fine. Question is : Will it give nay problem by doing this work .Please let me know weather I'm write or not . One more NOTE is I never got this problem in windows .. Please help me out in this area thanking you mohan. --- "Douglas E. Hornig" <[EMAIL PROTECTED]> wrote: > For those of you who remember my question from > several weeks ago regarding a response time delay > between tomcat running standalone on Solaris and a > Windows client. I modified my own tomcat 3.2.2 as > Gal suggested and the delay is gone. > > I'll leave this to the pros to decide how to > incorporate this into tomcat properly. > > Thanks to everyone who helped me out with this > problem (especially Gal!) > > Doug > > > --- Forwarded message from Gal Shalif - Sun Israel - > Software Engineer --- > > >From: Gal Shalif - Sun Israel - Software Engineer > <[EMAIL PROTECTED]> > >Date: Sun, 10 Jun 2001 14:47:44 +0300 (IDT) > >To: "Douglas E. Hornig" <[EMAIL PROTECTED]> > >Subject: Re: Solaris Performance Problem > > Hello, > > It should be fixed with a call to > Socket.setTcpNoDelay() on the Tomcat > server socket. > A C program that I wrote had the same problem as the > Tomcat server. > and the problem was fixed with the setting of the > TCP NODELAY > transmission. > > Anybody there who volunteer to add this option to > the Tomcat Java > server code? > > My analysis of the problem is attached at the end of > this mail. > > > >From: [EMAIL PROTECTED] (Douglas E. Hornig) > > Subject: Solaris Performance Problem > > To: [EMAIL PROTECTED] > > > > I have run into a strance performance problem with > Tomcat that I am at a loss to figure out. In a > nutshell, when I run Tomcat (version 3.2.1, > standalone) on a Solaris Sparc server and hit it > with a Windows client, the minimum response time is > is abount 0.2 seconds. This is for a simple servlet > that just returns some static data. That may not > sound like a lot of time but if a client makes > several requests to the server it can add up fast. > If I run the server on a Linux PC that number is > about 0.01 seconds or less. I also get good > performce if I use a Linux client and hit the > Solaris server. > > > > I have tried using different PC clients (different > PCs, one running NT 4 and one with Windows 2000), > different test programs (one in Java and one in > Visual Basic) and it makes no difference. > > > > I have tried using different Solaris servers, a > 420R and an Ultra 5, neither with any kind of load. > I have tried different JDKs (1.2.2 and 1.3.0). No > difference. > > > > I wrote a quickie standalone Java server for the > Sparcs and their response time was very fast (< 0.01 > secs). The server reads a request, sends a reply, > and closes the socket much like a web server would. > > > > So the problem combination seems to be Solaris > server with Tomcat and a PC client. I know this > sounds nuts but it's totally repeatable and a very > serious problem. Does anyone have an idea what I > can do to get to the bottom of this? > > > > Thanks a lot. > > > > Douglas Hornig > > Dartmouth-Hitchcock Medical Center > > Lebanon, NH > > > > slow response time with Solaris 8 server and > Windows 2000 TCP client as tested with Tomcat and IE > > > Problem description: > > Tomcat Hello World examples > (/examples/servlet/HelloWorldExample) > divide the response into two parts: > > HTTP protocol header > HTML data > > At the Solaris TCP level, the second part of the > response will not be send > till the Windows client acknowledge (ACK) the > first part. > The result: a delay of ~170ms (dependent on > client/server configuration) > > The configuration in problem: > - > Solaris 8 running Tomcat 3.2.1 server > Windows 2000 client machine running a web client > > And the raw data: > - > The output was gathered with: > truss -fdDla -o /tmp/tmp.dat -p
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: > > > > ... > >directoryName="public_html" > userClass="org.apache.catalina.startup.PasswdUserDatabase"/> > > ... > > > >Craig McClanahan
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: [snip] > > #if defined(JK_VERSION) && JK_VERSION >= 1 > > ... newer stuff ... > > #endif > > Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) Yup. > But it makes only sense if someone want to use a new module with a old core > code. > That means a protocol developed in 1.3.x could be used in 1.2.x. > Well could be nice, but difficult to handle. Backport a new protocol to an old > mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. At the moment I'm doing that with switches in a header that's local to the Domino connector, but it would be better if it was part of the jk/common source tree. > > b) People working on the cutting edge j-t-c stuff who will be using the > > latest versions of everything. > > ? That is CVS ? Yes. -- Andy Armstrong, Tagish
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_util.c
andya 01/06/15 04:38:25
Modified:jk/native/common jk_util.c
Log:
Refactored jk_is_path_poperty() and jk_is_cmd_line_poperty() to call a
common helper function.
Revision ChangesPath
1.4 +21 -20jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_util.c 2001/06/07 14:40:50 1.3
+++ jk_util.c 2001/06/15 11:38:23 1.4
@@ -57,7 +57,7 @@
* Description: Utility functions (mainly configuration) *
* Author: Henri Gomez <[EMAIL PROTECTED]> *
* Author: Gal Shachor <[EMAIL PROTECTED]> *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.4 $ *
***/
@@ -566,30 +566,31 @@
}
return JK_FALSE;
}
-
+
+static int jk_is_some_property(const char *prp_name, const char *suffix)
+{
+if (prp_name && suffix) {
+ size_t prp_name_len = strlen(prp_name);
+ size_t suffix_len = strlen(suffix);
+ if (prp_name_len >= suffix_len) {
+ const char *prp_suffix = prp_name + prp_name_len - suffix_len;
+ if(0 == strcmp(suffix, prp_suffix)) {
+ return JK_TRUE;
+ }
+}
+}
+
+return JK_FALSE;
+}
+
int jk_is_path_poperty(const char *prp_name)
-{
-char *path_suffix = "path";
-if(prp_name && (strlen(prp_name) >= strlen(path_suffix))) {
-const char *suffix = prp_name + strlen(prp_name) - strlen(path_suffix);
-if(0 == strcmp(suffix, path_suffix)) {
-return JK_TRUE;
-}
-}
-
-return JK_FALSE;
+{
+ return jk_is_some_property(prp_name, "path");
}
int jk_is_cmd_line_poperty(const char *prp_name)
{
-if(prp_name && (strlen(prp_name) >= strlen(CMD_LINE_OF_WORKER))) {
-const char *suffix = prp_name + strlen(prp_name) -
strlen(CMD_LINE_OF_WORKER);
-if(0 == strcmp(suffix, CMD_LINE_OF_WORKER)) {
-return JK_TRUE;
-}
-}
-
-return JK_FALSE;
+ return jk_is_some_property(prp_name, CMD_LINE_OF_WORKER);
}
int jk_get_worker_stdout(jk_map_t *m,
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote:
>
> GOMEZ Henri wrote:
> >
> > >Ah. So it's really the jk version I need then so people can build the
> > >connector whether they have the latest j-t-c source or something like
> > >the Tomcat 3.2 source distro. It would be useful to have an API version
> > >number somewhere.
> >
> > * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) :
> >
> > we could version it : 1.0.x
> >
> > * mod_jk in TC 3.3 is not frozen but there will be no major feature added :
> >
> > we could version it : 1.1.x
> >
> > * mod_jk in J-T-C will continue its evolution :
> >
> > we could version it : 1.2.x
> >
> > >How about
> > >
> > >#define JK_EXPOSED_VERSION ("mod_jk/1.1a1") <== exists now
> > >#define JK_VERSION 1 <== proposed
> > >
> > >in jk_global.h? There should be some defined mapping between
> > >the version
> > >string and the number too I suppose.
> >
> > May we use something like Apache 2.0 :
> >
> > #define JK_MODULE_BASEPRODUCT "mod_jk"
> > #define JK_MODULE_BASEREVISION "1.2.0-dev"
> > #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT "/"
> > JK_MODULE_BASEREVISION
> >
> > #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION
>
These things should in a version.h.in file and the version.h file should be
included when needed.
That some configure related thing. I have already PACKAGE and VERSION prepare
for that.
> OK, but I was thinking of something numeric so it could easily be tested
> at compile time, for example
>
> #if defined(JK_VERSION) && JK_VERSION >= 1
> ... newer stuff ...
> #endif
Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-)
>
> Strings are fine for user readable versioning, but hard to test at
> compile time.
But it makes only sense if someone want to use a new module with a old core
code.
That means a protocol developed in 1.3.x could be used in 1.2.x.
Well could be nice, but difficult to handle. Backport a new protocol to an old
mod_jk!
>
> > But what do you means by users building from j-t-c or 3.2/3.3 ?
>
> I think the two groups of people who will be interested in the source
> for this (and other) connectors are:
>
> a) People using one of the stable releases and wanting to use it with
> the web server of their choice. They will have downloaded the
> appropriate Tomcat source and may have grabbed the connector source from
> either free.tagish.net or as part of the latest j-t-c release.
>
> b) People working on the cutting edge j-t-c stuff who will be using the
> latest versions of everything.
? That is CVS ?
>
> Ideally I'd like the source for the connector to be the same in either
> case with conditional stuff to include functionality required by later
> jk versions. I assume this would be useful for other connector
> developers too.
>
> As to the mapping between textual versions and numeric one way to do it
> would be to reserve a certain number of digits for each part of the
> version string so you'd have something like this:
>
> 1.0.1 ==> 10001
> 12.3.6 ==> 120306
;-)
>
> which has the advantage that the numerical representation increases
> monotonically and linearly with increases in textual version.
>
> --
> Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote:
>
> >Ah. So it's really the jk version I need then so people can build the
> >connector whether they have the latest j-t-c source or something like
> >the Tomcat 3.2 source distro. It would be useful to have an API version
> >number somewhere.
>
> * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) :
>
> we could version it : 1.0.x
>
> * mod_jk in TC 3.3 is not frozen but there will be no major feature added :
>
> we could version it : 1.1.x
>
> * mod_jk in J-T-C will continue its evolution :
>
> we could version it : 1.2.x
>
> >How about
> >
> >#define JK_EXPOSED_VERSION ("mod_jk/1.1a1") <== exists now
> >#define JK_VERSION 1 <== proposed
> >
> >in jk_global.h? There should be some defined mapping between
> >the version
> >string and the number too I suppose.
>
> May we use something like Apache 2.0 :
>
> #define JK_MODULE_BASEPRODUCT "mod_jk"
> #define JK_MODULE_BASEREVISION "1.2.0-dev"
> #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT "/"
> JK_MODULE_BASEREVISION
>
> #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION
OK, but I was thinking of something numeric so it could easily be tested
at compile time, for example
#if defined(JK_VERSION) && JK_VERSION >= 1
... newer stuff ...
#endif
Strings are fine for user readable versioning, but hard to test at
compile time.
> But what do you means by users building from j-t-c or 3.2/3.3 ?
I think the two groups of people who will be interested in the source
for this (and other) connectors are:
a) People using one of the stable releases and wanting to use it with
the web server of their choice. They will have downloaded the
appropriate Tomcat source and may have grabbed the connector source from
either free.tagish.net or as part of the latest j-t-c release.
b) People working on the cutting edge j-t-c stuff who will be using the
latest versions of everything.
Ideally I'd like the source for the connector to be the same in either
case with conditional stuff to include functionality required by later
jk versions. I assume this would be useful for other connector
developers too.
As to the mapping between textual versions and numeric one way to do it
would be to reserve a certain number of digits for each part of the
version string so you'd have something like this:
1.0.1 ==> 10001
12.3.6 ==> 120306
which has the advantage that the numerical representation increases
monotonically and linearly with increases in textual version.
--
Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
>Ah. So it's really the jk version I need then so people can build the
>connector whether they have the latest j-t-c source or something like
>the Tomcat 3.2 source distro. It would be useful to have an API version
>number somewhere.
* mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) :
we could version it : 1.0.x
* mod_jk in TC 3.3 is not frozen but there will be no major feature added :
we could version it : 1.1.x
* mod_jk in J-T-C will continue its evolution :
we could version it : 1.2.x
>How about
>
>#define JK_EXPOSED_VERSION ("mod_jk/1.1a1") <== exists now
>#define JK_VERSION 1 <== proposed
>
>in jk_global.h? There should be some defined mapping between
>the version
>string and the number too I suppose.
May we use something like Apache 2.0 :
#define JK_MODULE_BASEPRODUCT "mod_jk"
#define JK_MODULE_BASEREVISION "1.2.0-dev"
#define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT "/"
JK_MODULE_BASEREVISION
#define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION
But what do you means by users building from j-t-c or 3.2/3.3 ?
RE: Tomcat Admin Web Interface
Would/could this be implemented as a web context with (possibly) some 'administration' flag set in it's context that way, if you didn't want to have a GUI (security?) you could just remove the context? Just my 2p worth ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, 14 June 2001 23:13 To: '[EMAIL PROTECTED]' Subject: RE: Tomcat Admin Web Interface It would be very good at this stage to go back 1 1/2 years in tomcat archives and re-read the "admin" thread. It was a huge discussion, with many ideas - but nothing happened. As usual, my opinion is that you should start with a prototype and/or existing code - and figure out what is the best way to do it by trying different aproaches. Costin On Thu, 14 Jun 2001, Eric Anderson wrote: > Count me in on working on an admin interface for Tomcat. This along with a > better install/connector config program would go a long way to improve the > overall usability of Tomcat for me. > > Having had experience working on server product GUIs, the plan to decide > what goes into the GUI before starting the project is definitely the best > way to go. Even though there is a considerable amount of planning and > discussion that goes into the GUI requirements sheet, in the end it is > easier to deny unreasonable requests like, "we have this new functionality > two weeks before the release can you incorporate it into the admin > interface?", or "I'd like the GUI to wash and wax my car." A hard and fast > list of GUI features for each release is essential to keeping the GUI > project manageable > > My 2 cents. > > Eric > > > On Thu, 14 Jun 2001, M B wrote: > > > Hello All, > > > > In response to the recent postings regarding Tomcat > > documentation and administration (Re: ~rant~ Docs, > > user list, etc.), I am willing to contribute much > > effort in this area. In addition to documentation, I > > am particularly interested in helping to build an > > administrative web interface for Tomcat 4.0, something > > similar to JRun Management Console, for example. > > > > That would be awesome! > > > Naturally, I want to coordinate my efforts with the > > Tomcat community. Can anyone please point out where I > > should begin, or who I should contact? Is there a > > project for this? The Catalina TODO identifies John > > Shin as volunteer for producing an admin interface, > > but I thought I should email this list before > > contacting him directly. > > > > He volunteered long, long, ago but I haven't heard anything from him > lately. > > As it happens, I've been accumulating a list of functional requirements > for admin capabilities that I'd like to post for discussion. I'll be > finished with what I'm thinking in the next couple of days. > > What I'd like to see us do on issues like this is to discuss and agree on > a functional specs document that is checked in to the CVS repository, and > then start working together on the pieces. It's a little more formal than > the usual :-) open source approach, but I think it will help in the long > run. Does that sound like a useful plan? > > > Thanks, > > Matt > > > > Craig > === 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
