Re: Hi
Please answer quickly! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
NormW wrote:
Good morning All.
The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and
is, for most users I believe, a wrong guess at best, since the majority of
users are probably not using mod_jk2 in load-balancing mode. The 'guess'
means that mod_jk2 creates uri objects assigned to either a load-balancer
that doesn't exist , a load-balancer that is not hooked into anything or a
load-balancer that is not even wanted. For example, the following uri's
are created automatically:
:-)
I agree that lb is a missleading name, as is the whole worker concept.
The real intent is for lb to represent one tomcat cluster ( of one or
many servers ), and for routing to be directed to different clusters
instead of individual machines.
Even if you have a single tomcat - I think it is still better to make the
mapping based on the tomcat instance, and not on the various protocols used
to connect.
The overhead of having lb is very small, and IMO it's well worth it given
the simplification in code and the extra features.
I also think the right direction is to decouple the worker ( as a
particular protcol to connect to a tomcat instance ) from the notion of
routing requests to a particular instance or cluster, which may use multipe
protocols and workers.
nameurigroup context
* null null null
*// lb:lb /
There is no means to determine the existence of the 'lb:lb' worker, but
suffice to say, my setup doesn't want or need it anyway. (As an aside,
perhaps this might be an extension to /jkstatus/ ?)
I think the code created the lb:lb automatically unless one is defined
exeplicitely. The goal was to have each tomcat instance ( or cluster )
associated with an lb, with a reasonable default to minimize trivial
configuration.
Then each lb would have one or multiple protocols pointing at different
tomcat instances.
A more valid approach would be to identify, via the workers2.properties
file, which worker of those configured is to be considered the 'default'.
It would also become the 'default' worker/group for [uri] sections not
having a worker/group entry when created, and a variation of the JkUriSet
parameter could also allow use of the 'default' worker, for example:
JkUriSet worker default
The existing code makes allowance for a defaultWorker property in the
[workerEnv] section of memory, and I would like to submit the attached
[patch
as a step in such an arrangement. If this option isn't used within the
workers2.properties file, then the module reverts to current operation.
The parameter proposed would look as follows and retain the current
default for wEnv-defaultWorker:
I'm not very comfortable with this ( I'm close to -1, but if other people
think it's a good idea I can change it to -0).
It kinds of moves us backwards, to the mess of protocols and load balancers.
I'm ok with any renaming or clarification or defaults - as long as we keep
or increase the current separation between protocols ( i.e. ajp-like
workers ) and clusters/instances - or however you want to call the
lb-like workers.
All mapping should be made between URIs and lb ( clusters/instances ), and
each lb can have multiple protocols ( ajp ) associated. It would be great
if we just create a separate interface to make it clear that those are
distinct.
Costin
[workerEnv]
defaultWorker=workerName
For your consideration and comment,
Norm
--- jk_workerEnv.c.orig Fri Sep 26 07:00:51 2003
+++ jk_workerEnv.c Thu Feb 5 18:36:39 2004
@@ -93,6 +93,8 @@
wEnv-ssl_enable = JK_TRUE;
} else if( strcmp( name, timing )==0 ) {
wEnv-timing= atoi( value );
+} else if( strcmp( name, defaultWorker )==0 ) {
+wEnv-defaultWorker = value ;
} else if( strcmp( name, httpsIndicator )==0 ) {
wEnv-https_indicator = value;
} else if( strcmp( name, certsIndicator )==0 ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX remote and JDK 1.5
Remy Maucherat wrote: Hi, It looks like the new JDK has an easy way to add a connector (and even SNMP) to a VM, without the need for explicit support in the application, using system properties (on the command line) like: - com.sun.management.config.file - com.sun.management.snmp.port - com.sun.management.jmxremote.port I expect other vendors will provide a similar feature :) As a result, there's no need to reinvent the wheel inside Tomcat, and I'm shelving my plans to add a listener to instantiate JMX remote (no need to add complexity), and will unbundle JMX remote (only the JMX RI core will be bundled); instead, I'll add a little chapter about JMX in the docs :) What does it mean ? I saw the 1.5 jmx stuff, but as usual this only works with 1.5 while most people will keep using 1.3 or 1.4 for few years. I hope we're not falling into the forced upgrade trap :-) I agree that tomcat should't reinvent the wheel - but provide some mechanism for 1.4, maybe similar ( or identical ) with what 1.5 provides. This would also allow people with 1.3 or 1.4 to enjoy JMX now. Costin With this JDK, JMX remote powered clients are going to become a standard almost instantly, since the only requirement is that the server is instrumented though JMX. So good job to the J2SE team, this doesn't seem beta (although they didn't test JBoss, it doesn't work right now, as a side effect of bundling JMX :-( ). On the performance side, my (client) VM seems as fast as JDK 1.4.2, but does seem to use a little bit less memory. So unless it turns out to be really unstable (it does seem better than almost all the other Sun JDKs I've tried, so far), final 1.5.0 should be really successful when it's released. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log CommonLogHandler.java Log.java LogHandler.java LogManager.java
What was the reason for removing them from j-t-c ( as oposed to just keeping them - deprecated )? 2-3 kB of saving ? I don't think anybody is using them - but I doubt they hurt anyone. Costin Larry Isaacs wrote: +1 for just adding them back. Since they previously existing in j-t, they may come back with their old history. I'm not enough of a CVS expert to say for sure. I don't know of any trick to merge histories. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 11:23 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log CommonLogHandler.java Log.java LogHandler.java LogManager.java [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] remm2004/02/04 02:28:08 Removed: util/java/org/apache/tomcat/util/log CommonLogHandler.java Log.java LogHandler.java LogManager.java Log: - Removing most of Log. Let me know if there are problems. Ok, you've broken the TC 3.3 build :(. TC 3.3 still needs all of these classes. However, I've got no problem moving them back to j-t. If someone that knows more about CVS than I do knows how to move them with history, let me know :). Otherwise I'll just add them the old-fashioned way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release plan
Henri Gomez wrote: Remy Maucherat a écrit : Bill Barker wrote: committers as binding votes). In the unlikely event that we get enough people to care about 3.3 enough to vote (seeing the trouble that Remy has getting people to vote :) You're torturing me. I thinnk you should be able to get enough +1s, though (you, Henri, JF, Larry; that's four already). And may be Costin also :) :-) I don't have a lot of time - but for a 3.3.2 I'll try to find a weekend to test it with jk2 and update the jmx interceptor if needed. so I can vote +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
Jan Luehe wrote: Bill Barker wrote: Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? This seems a possible use case, but is that really useful ? I would always put the connector at the engine level, personally. Regardless of where you put it, you still have one connector per V-Host IP address. I may be totally off here, but in the most common cases, all your domain names (one for each V-Host) will map to the same IP address, in which case you cannot have more than one Connector listening on the same port (if you do that, you'll get a java.net.BindException when starting the 2nd and so forth Connector). Not quite :-) It is common to have multiple IP addresses - either by using multiple ethernet cards, or by using ifconfig aliases. That's how virtual hosting worked in the old days, and it is still used if you want to support old clients ( or command line / other tools that don't include Host ). For vhost - it is probably valid to have different engines or configs for different vhosts. I think it would be a bad idea to use only the port ( which will be 80 for most hosts anyway ). If mangling the IPv6 address is not a solution, then we'll need some unique name or something. Costin You can only have more than one Connector listening on the same port when they're listening on different IP addresses on the same server. This is the case we need to resolve, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: I proposed a while ago to implement a custom java policy for the SecurityManager which uses XML for configuring permissions for the Java SecurityManager. There were a number of features which made configuring a strict security policy easier. You can look back through the archives for the initial proposal and discussion. It's an open discussion :) However, I'd say this is an uphill battle. I think Costin argued the same earlier, and the standard policy file remained consistent, and now added JMX security rather (which is an important feature since we're now JMX based). So well, I don't know ... Remy From what I recall of the discussion, the issue was not with adding this as a feature, but with how it was implemented using Castor. Castor was clearly a big problem, but not the only one :-) My big concern was about inventing yet-another application-specific DTD. If you want to support an XML format that is in use by 1-2 other applications - great. If you can discuss this issue with any other project and come to an agreement - again, I'm ok. But if this is an XML that only tomcat uses - I would rather stick with the standard policy format. IMO parsing and generating a policy file is a bit more difficult than parsing/generating XML - but not by much, and it's just some code. Documenting and supporting an XML DTD - and getting people to understand and use it is far more difficult. Almost anyone how uses security policies knows the standard format. To force a new syntax on the user just because XML is a bit easier to parse is not a good idea IMO. For those who have to maintain strict java security policies the current policy file format of granting permissions is a pain to use. The XML based policy feature I designed is much easier to use. I disagree - if you mean that XML makes it somehow easier to use because of the . It is usually easier to use what you know or can learn from others. If you mean the extra flexibility you proposed - like ability to define a policy file per app, etc - I agree, but that's unrelated with XML. Costin Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
On Wed, 28 Aug 2002, jean-frederic clere wrote: Are you ok with a change for daemon to use introspection, and remove the dependency from tomcat to daemon plus consolidate all startups ? Sure ;-) Ok, then let me push a bit more: are you ok with merging the C code from daemon into jk2, and continuing the development on the C side in j-t-c/jk/native2 ? There is no point on having 2 codebases that launch the VM from C, or 2 service launchers. And there is a lot to benefits from both sides - I think. That should happen after jk2.0 is released ( eventually we can branch when 4.1 is released - and use the main branch ). ( one nice benefit may be getting back the ability to start and control the java process from apache, like jserv did ). I'm only talking about the C code here. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] Config
After a lot of thinking and searching, I found a solution that I think will work well. If you like it - I'll need some help from Remy to implement it. If you don't like it - I'm waiting for a better one... There are 3 major parts: 1. Config storage. Currently that's server.xml. 2. Configuring various components ( runtime config, init, etc ). That's done using digester/introspection in 4.x ( init ) and JMX ( at runtime ) 3. Saving config. That's done via introspecting life objects and generating server.xml in 4.x What I'm proposing is a pluggable config storage, using JNDI API for storage and JMX ( and introspection ) for runtime changes. For API - my initial approach was to create a clone of 1.4 prefs. I think a much better solution is to use JNDI as API. We already depend on JNDI, and JNDI is available to all VMs - including in GCJ, kaffe. The interface is mature, flexible and well known. In addition it is very easy to create wrappers to jdk1.4 prefs and back - so both 'flavors' can be used. The data will be organized to follow the JMX naming hierarchy ( after reorganizing the naming schema ): each tomcat component that is configurable will have a JMX name and associated attributes, and those will be stored in the directory. An ObjectName will be a jndi Name. We'll automatically gain access to all 'stores' that jndi supports - ldap, directory servers, etc. There are also file providers implementing standard xml formats ( or ldif ?). An additional format to support may be the jboss-style mbean - which may be syntactically closer to the jmx-based runtime. The second layer will be a wrapper that can use either introspection or JMX, possibly an extension of modeler. We'll have a clear distinction between 'persistent' config and 'runtime' config. JMX was not designed for storage ( even if it has the optional load/store methods ), and it is useful to be able to choose between making changes in the running server ( some may be temporary ) and making changes in the persistent store. Using notifications it is possible to propagate any change via JMX to the store - but that should be optional ( i.e. you could choose to not change the store, but only the runtime ). Any operation ( reload, etc ) will be done via JMX - only setting attributes is important for config. It is possible to also use DirContext to represent 'life' objects - and use the same API to set attributes on the persistent and life sub-trees. ( with JMX or introspection underneath ). There are few (major) issues with JMX - I don't know how well it will scale, giving the huge number of objects it involves. One way to solve this is to use mx4j internals - for example to delay some of the introspection, optimize some lookups, etc. Right now the JNDI model seems better suited for a large number of objects ( if we start representing each servlet as an mbean - for example to collect time information ). But overall JMX is the right way to go about configuring and operating on live objects, and JNDI is (IMO) the right way to go about storing hierarchical and config data. What do you think ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
On Mon, 25 Feb 2002, Aaron Smuts wrote: What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. You can probably use tomcat3.3: - it's small - about 1M ( excluding the parser, 800k if you don't include the jasper compiler - you'll still support precompiled jsps ). You can probably cut more if you remove unused modules. - it's fast - IMHO it's one of the fastest servlet containers around - it's simple - as simple as we were able to make it ( but no simpler :-). Almost anything can be replaced, including the servlet implementation ( facade ), loaders, loggers, connectors. In addition it'll run with almost any VM ( including GCJ/native, kaffe, with some changes J2ME ) and it's reasonably easy to embed it. It doesn't have features - except serving servlets as fast as it can. If you want features - probably you need something else. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
On Tue, 12 Feb 2002, Mike Anderson wrote: The problem is that the default cache size is one and in the ajp_init The problem is that I spent too much time writing java code. I didn't see the return statement, the deep if() have confused me. If you ever see any commit (from me) that late in a release cycle - make sure you -1 it, regardless of how usefull it may look. Peer review seems to work well, but it needs more time. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat3. 3.1 release
So far the changes in 3.3 tree were only bug fixes and what I've seen so far was pretty clear and simple - I think the head of 3.3 is as good or better than 3.3.0. We could also take 3.3.0, replace tomcat_utils.jar and label it 3.3.1 - and then in 2-3 weeks release 3.3.2 with te head. But I'm +1 on whatever you choose. Let me know if/how I can help - I don't have time but I could sleep less :-) Costin On Wed, 9 Jan 2002, Larry Isaacs wrote: Hi All, With the amount of spare time I have at the moment, I am not able to put together a Tomcat 3.3.1 release in short order. Doing things quickly is not my forte and the earliest I could do a 3.3.1-beta1 would be the following weekend, i.e. the weekend of the 20th. In addition, I would rather not leave Tomcat 3.3 with the aux.jsp DOS problem for that duration. I propose to add to the site an updated tomcat_util.jar and tomcat_modules.jar that fix the problem based the changes used in Tomcat 3.3.1. The updated source files would be made available as well on the site. Following the patch, I would announce its availability and reason for existence on the usual mailing lists. Since, IMHO, it makes no sense to do any branching on the Tomcat 3.3 track, I propose to add a patches/tomcat33 folder under proposals and use it as the location in CVS in which to keep the 3.3 updated Java files. I'm not a CVS guru, so let me know if there is a better way to deal with files like this. Does anyone have a better suggestion about dealing with the current DOS vunlerability in Tomcat 3.3 (and/or has more time than I do and wants to volunteer to be release manager :-) )? If there are no objections or other suggestions, I'll proceed with the Tomcat 3.3 patch and then start preparing a 3.3.1 release plan. Cheers, Larry Isaacs -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/tomcat UnixSocket.c
I've also wrote the unix socket code, in the jni directory.
I'll check in my version too, and try a merge later ( I've also got the
jkservlet working with both 3.3 and 4.0, things look pretty good )
Costin
On 5 Jan 2002 [EMAIL PROTECTED] wrote:
jfclere 02/01/05 02:03:43
Modified:jk/java/org/apache/jk/server JkMain.java
jk/native2 build.xml
Added: jk/java/org/apache/jk/common ChannelUnixSocket.java
jk/native2/tomcat UnixSocket.c
Log:
Add code for AF_UNIX sockets.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelUnixSocket.java
Index: ChannelUnixSocket.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.jk.common;
import java.io.*;
import java.net.*;
import java.util.*;
import org.apache.tomcat.util.buf.*;
import org.apache.tomcat.util.http.*;
import org.apache.tomcat.util.threads.*;
import org.apache.jk.core.*;
/* XXX Make the 'message type' pluggable
*/
/* A lot of the 'original' behavior is hardcoded - this uses Ajp13 wire protocol,
TCP, Ajp14 API etc.
As we add other protocols/transports/APIs this will change, the current goal
is to get the same level of functionality as in the original jk connector.
*/
/**
* Jk2 can use multiple protocols/transports.
* Various container adapters should load this object ( as a bean ),
* set configurations and use it. Note that the connector will handle
* all incoming protocols - it's not specific to ajp1x. The protocol
* is abstracted by Endpoint/Message/Channel.
*/
/** Accept ( and send ) messages via Unix Socket (AF_UNIX).
* The AF_UNIX is not supported by JAVA so we need a piece of native code.
*
* @author Costin Manolache
* @author Jean-Frederic Clere (Well, I have copied Costin's code and ideas).
*/
public class ChannelUnixSocket extends Channel {
/* XXX do not have port/Address */
// int port;
// InetAddress inet;
Re: [PATCH] about kjc
On Sat, 1 Dec 2001, Jon Stevens wrote: +1 for this patch as it is legal since it uses reflection. Remy I thought that using reflection to work with GPL code was still considered illegal by the FSF. As long ASF/jakarta doesn't have a list of 'accepted licences' that we can include/bundle with our code, and most jakarta projects already depend/bundle lots of proprietary code, I don't see why this patch would be a problem. It doesn't require us to distribute GPL code. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: WG: TC3.3 updating a webapp without killing sessions
Hi Hans, Thanks for your feedback, lb is high on my list as well. I hope to finish the first part of the refactoring next week, and then we can start with new features and good stuff like you mention. I'm also trying to find a way to add/remove webapps without having to restart apache. Costin On Fri, 30 Nov 2001, Hans Schmid wrote: Hi, since Costin is currently refactoring mod_jk in jakarta-tomcat-connectors I want to throw in our usage scenario. We are abusing the loadbalancing feature of mod_jk to switch tomcats on the fly in order to be able to make application updates without killing our curreent user sessions. See discussion below from tomcat-user This feature (graceful restart) was present in jserv and is still missing in mod_jk/Tomcat3.3 as far as I know. Below are references to the archive where Michael Kuz has sent a patch to decouple this feature from the lbfactor (introducing an active flag). So please keep in mind the requirement to be able to update Webapps in a farm of Tomcats without killing active sessions. Thanks, Hans -Ursprüngliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. November 2001 18:21 An: Tomcat Users List Betreff: AW: TC3.3 updating a webapp without killing sessions Thanks Larry, perhaps a lbfactor of 0.1 or so would do the job for us. We could probably live with 1 out of 10 sessions beeing sent to the wrong Tomcat and beeing killed if this instance shuts down. Should this be discussed in tomcat-dev ? I remember a patch from early this year which tried to fix this (check the archives) but did never make it into the release It tried to add a flag called 'active' in the worker.properties file for each worker instead of misusing the lbfactor for this. ajp13-01... lbfactor=1 active=0 and ajb13-02... lbfactor=1 active=1 see http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00102.html and http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00114.html for the patch which might be a little bit outdated -Ursprüngliche Nachricht- Von: Larry Isaacs [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. November 2001 15:00 An: 'Tomcat Users List' Betreff: RE: TC3.3 updating a webapp without killing sessions I assume the value or lbfactor is requested to be 0 because 1/lbfactor is calculated during initialization. Since this is done with doubles, it may generate an internal representation for infinity rather than a division by zero error. I don't have a complete understanding of what mod_jk does internally for loadbalancing, but your approach seems like it should work. A brief scan of the codes shows that some updates to mod_jk would be needed to insure that lbfactor=0 means only use this worker when mandated by session routing. There isn't much logging around the choice of worker. Perhaps adding some logging would help determine why requests are being routed to the lbfactor=0 Tomcat when session routing shouldn't be a factor. Hope this helps. Cheers, Larry -Original Message- From: Hans Schmid [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 4:25 AM To: Tomcat-User Subject: TC3.3 updating a webapp without killing sessions Hi, We try to make a workaround for the following problems: 1.) memory management 2.) application update 3.) do not kill active sessions Perhaps someone can comment on the startegy and answer some questions. Our environment: Tomcat 3.3 final with mod_jk Apache 1.3.19 on Solaris 2.7 Sparc Our problem: ever growing cache until memory runs out (clearly an application problem) plus soft updates to our application without killing actiove sessions The idea: when a certain ammount of memory is reached by the tomcat java process, start up a second Tomcat and route all new requests to the second instance while existing sessions should phase out on the first instance. If no more sessions are active on the original Tomcat, shut it down (currently we just shut it down 30 minutes after the second Tomcat started up) How to do it with mod_jk: We have two versions of a worker.properties. Before we start up our second tomcat, we switch a link to point to the other version. Both versions of the worker.property file have a loadbalancer worker defined: First version: worker.list=loadbalancer worker.ajp13-01.port=11009 worker.ajp13-01.host=tomcathost worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 - important worker.ajp13-02.port=11019 worker.ajp13-02.host=tomcathost worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=0 - important worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=ajp13-01, ajp13-02 Second version: worker.list=loadbalancer worker.ajp13-01.port=11009
mod_jk milestones
Hi, I would like to put some labels on the CVS tree for mod_jk and start taking 'milestone' snapshots. The first 'label' would be retroactive - it should match tomcat4.0.1 release ( for 4.0 users to have something stable/labeled ). This tag is almost identical with what 3.3 uses, the only major diference between j-t-c and 3.3 is the ajp14 protocol that was introduced in j-t-c. I would like to get to a second milestone in mid-december. The major goal is to cleanup the code and allow more extensibility/hooks. This should eventually result in the first release of mod_jk as a separate component. The focus will be on interfaces ( the object-like system used by jk ), and should also be the first step toward APR-based implementation. Please send your vote/opinion/time frame. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jk_handler
mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions: jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jk and APR
This has been discussed many times, and the only conclusion was that we should and will change mod_jk to use APR, but no clear plans were decided. My proposal is quite simple and require minimal code change. Mod_jk consist of a number of interfaces. We already added a channel interface that will abstract the communication ( which is where most of the platform dependent code is ). None of the interfaces is OS-dependent - only the implementations. So for all new code/workers/channels we can use APR. Mod_jk will still work without APR ( at least in the near future ), but not all features will be available. For the build process: we should use apr as a regular library. We'll use whatever is built into apache2.0, without modification. APR is supposed to eliminate the need for OS-specific code and configure - that means we can use a simpler makefile ( and/or the new ant based build). Does it sounds reasonable ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: jakarta-tomcat-connectors build on MSVC6
On Mon, 19 Nov 2001, Remy Maucherat wrote: On Mon, 19 Nov 2001, Michael Smith wrote: Here's a patch for clean builds on MSVC6 - includes a couple of missing headers, and adds JK_METHOD attributes to the neccesary functions (otherwise calling conventions are declared differently, and you get compilation-fatal errors). Thanks Michael ! How about giving Michael commit access ? He already has an account @Jakarta, so he just needs some additional karma. In general, I think all jakarta commiters should have cross-project permissions - maybe with the additional requirement that you need a review-then-commit process when commiting to a project you are not 'regular' commiter. There are many 'integration' bugs ( project X doesn't work with project Y ) that would be solved much quicker this way. But this is something for the PMC to decide. I'll vote +1 for any apache commiter ( i.e. jakarta, xml, httpd... ) who wants to become a commiter on tomcat. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
On Mon, 19 Nov 2001, Bojan Smojver wrote: I propose those are listed in the more natural order, from the newest to the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) Vote to change the order of releases on the Tomcat web page: [X] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Ajp14 and Ajp13
Hi, Right now we treat Ajp13 and 14 as 2 separate workers ( even if most of the code is shared). The problem is that this adds complexity that we could avoid. Given that Ajp14 is not 'official' yet, I would propose to change it to Ajp14 == Ajp13 + extra functions. We should use exactly the same header and encapsulation as in Ajp13 - since this is very well tested. The main difference is in the startup phase, where Ajp14 will login and auto-configure. That can be easily configured and we can have the new Ajp14 clients talking with older Ajp13 servers ( so most fixes will go in the same codebase, without needing to fix both the new 1.4 worker and the old one). If the ajp14 worker will be configured with a login password - then it'll do the extra login and configuration steps. If not - it'll be just our old ajp13 client, capable to speak with tomcat3.2 ... tomcat4.0. On tomcat side, if the connector will be configured to require a login it'll behave as a ajp14 server, and do the autoconfiguration ( and refuse connections from unauthenticated ajp13 clients ). This can be extended in future as more callbacks are added. Instead of having ajp15, 16... we'll keep Ajp13 as the base and configure the calls and callbacks to use. The main reason for this is simplifying the code - which is very important to do before any extension. This would also allow a smooth transition - all new features will be included in mod_jk and the new java connector, but the user will be able to use only what he needs and support multiple server versions. What do you think ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
To clarify: creating a Distributed Session Manager is a good idea, and something that would be great for users. My problem is with designing it at container-level, as an implementation of the servlet session API. Having all objects in a session distributed and no control or feedback is not good. You could have a DSMServlet that would have some init parameters in web.xml. There you can specify what classes/interfaces you want 'distributed', or even what attributes ( by name ). Then you can use the existing listeners and notifications to detect when those objects are saved in the session and do the distribution. You could also define a simple API allowing the user to control this - for example and update() method to be called after the user changes an object. What's different here is that the behavior of servlet sessions doesn't change - most objects can still be stored without an overhead. The user gets to choose what objects to persist/distribute and he has control over the process. And this will work in _any_ container, so the user can assume the objects he marks as persistent/distributable will be this way on any container ( you can't force people to switch to a different container to use your webapp ) You can also define specialized interfaces to be implemented by the objects that will be persisted/distributed. All of this can be done with only standard 2.3 support. A container may provide aditional hooks ( valves, interceptors, etc) of course. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
One question - wouldn't be better if the 'distributed session management' would be first designed and discussed _outside_ of the ServletSession context ? In other words, a SessionManager that would store and provide fail-over, etc for serializable objects. It can have a rich interface, including support for transaction, control sync/async storage, etc. There are many limits in what you can do with a servlet session - all you have is a get/set with Objects ( serializable or not ). No way to guess if the user cares about the object or is just a cache ( in which case it can be a blob that the user just doesn't want to read again from net/disk ). No way to tell the user that his object was stored sucessfully or lost ( you need transactions and exceptions for that ). Designing the SessionManager as a standalone component would make a lot of sense - you can then integrate it with the servlet sessions, or the user could use its richer API. IMHO no sane user should store something in a servlet session and assume the operation will be sucessful - and the session manager can only give a dangerous ilusion that this is possible. Nothing can be guaranteed to allways succeed ( no database or network application can do that ) - and with an API that doesn't provide any feedback there's little you can do. Writing a servlet application assuming the session data will be safe is at least not portable ( assuming it is possible, which I doubt ). At least with a standalone SessionManager you can include the lib in your war and have it working on any container. ( by standalone I mean a user-space util, independent of the servlet container, but with hooks - so it could be hooked into a container as a default session manager or used as an addon ) Costin 1) 10 Tomcat webservers (1-10). Servers 1 and 2 happen to be identifed as 'Session Managers' as well as web servers. Servers 3-10 are just plain web servers, not session managers. In this scenario, Tomcat servers 1 and 2 are burdened by satisfying session requests (queries updates) from the other 9 servers, as well as handling their own web-traffic. They must also initiate communication to the other 9 servers whenever a session is invalidated (due to update, maxAge, or on demand). They must also communicate all session deltas to the 'other' session manager. The best scenario, but tell me if I misunderstand something after you've reviewed case 4. 2) 10 Tomcat webservers, all 10 are identified as 'Session Managers' In this scenario each Tomcat must communicate session deltas to each of the other 9 servers. All servers must perform significant extra work in order to keep their Session store up-to-date. 3) 10 Tomcat webservers, 2 separate Session Managers. Tomcats 1-5 point to SM1, Tomcats 6-10 point to SM 2. In this scenario, each Tomcat only communicates with 1 session manager. Each session manager communicates session deltas with the other SM, and with only the Tomcat servers that it connect themselves to it (5 in this example) on an as-needed basis (e.g. when the Tomcat instance asks for the session data). Each SM must also send tell all it's clients when sessions are invalidated. Fail-over could be handled in a similar manner in all scenarios. Addition of a new SessionManager (or SessionManager capable Tomcat) could be handled in a similar manner in all scenarios. In principle, I completely agree. All I want to express is, that I think we don't need SessionManagers as assigned responsibility and would save traffic. Scenario: 4) 10 Tomcat webservers acting as SessionManagers for Sessions initially created by themselves or being assigned responsibility afterwards for a specific session. In this scenario every Tomcat backs up sessions to a configured number of others (for simple redundancy only with one other tc) The session is primarily held on the TC which created it or most recently used it. The other instance(s) hold a passive copy for fail-savety. a) A dumb load.balancing facility passes a request to a completely different TC which needs control over the connected session. From a regularly updated list or by asking it's peers it get's the (actual) owner of that session and requests to take over ownership. The old owner drop's ownership after the session has been taken over. Alternatively the old owner becomes the backup and the old backup drops. b) A clever load-balancing facility remembers where the last request of this session went and directs the next request to the same TC. The TC has all what it needs to fulfill the request and communicates the changes of the session afterwards. In Scenario a) you have one session copy before the request and one change communication afterwards. in b) only change communication. In your scenario, the TC needs at least the certitude that the session is
Re: Tomcat: Distributed Session Management revisited
On Tue, 13 Nov 2001, Mika Goeckel wrote: I completely agree, that the API lacks proactive support for things in the background that may fail. But given the fact, that we support a reference implementation which has managed to provide really professional services to users (other ref implementations are just for demonstration, nobody would use them in production) and there are (commercial) solutions, that provide session fail-over in the limitations of this API, we **must** try to provide a Well, the cool thing about open source is that we _don't_ need to implement all the bloat that commercial solution have. solution. The API does not specify, how often the container may try to provide that service or what means it utilizes to do that. Nothing is 100% and I think it is better to live with the uncertaincy we discuss here than with the more likely problem that an instance fails and there is no potential replacement. I think it's better to live with the certaincy that everything can ( and will ) fail and tomcat can't change this. The alternative is to give users the impression the data he puts in a session will be safe - and he may rely on that instead of using a transaction and a real API. Databases, EJB, etc are complex - but there's a reason to that. Well, we could argue about how much compexity is actually needed, but one thing is certain ( I hope ) - get/setAttribute is not enough, if you want data integrity you must use a different API ( in particular transactions ). Byte-comparison is not the worst solution. If we think about differential updates, byte comparison is a good candiate for that and surplus one that promises good performance. Byte compare every 5 seconds every object in session ? Let's say you just displayed the confirmation and charged the credit card, but the machine crashed just before you sent the order. ( or reverse - you sent it but didn't charged the credit card ). This should happen in below 5 seconds. If the user wants to place things in a session that she does not need to be replicated, she has the option to declare them transient and write a getter that checks if the Attribute is present, otherwise reconstructs it (in the case of a picture, reloads it from disk). The user has the choice to design for performance or ease. We only need to document the options. So the user should change all his objects to implement some arbitrary pattern just to fit this into our solution ? What if the object is not user defined ( like most are ) ? Well, we have to create wrappers for each objects you store in a session. Try to explain this on tomcat-user ( or tomcat-dev ) ... Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
On Tue, 13 Nov 2001, Paul Speed wrote: I think the idea is that you'd byte compare on commit which ideally would happen at request boundaries. So in this case a single request becomes a transaction... which indeed opens up its own issues, but no bigger than the ones that were always there. Not good enough - when the request is completed the user already has the page confirming his order ( and maybe the card was already charged :-). In fact, that's the same case that fails in _every_ scenario that doesn't involve full EJB-like transaction support. As soon as you access one single piece of data that isn't covered by the transaction support, you lose some amount of failover recovery. And what's worse, far too many people will not realize that, and read the marketing stuff ( 'we support failover, session replication, etc') and believe it is a magic solution. That being said, there may still be a place for a session-based distribution mechanism that can support load balancing, hot-swapping of tomcats, and basic failover. It should definitely be an opt-in sort of thing though, ie: web apps that meet the restrictions can opt to setup tomcat to provide this feature. I agree it would be nice to have a tool that can store objects with fail-over, distribution, etc and using it as a _complement_ to the session ( maybe using the session id, expiration, etc ). I don't think this tool can be used using only the current servlet session API or that it should be used as a servlet session manager. distributed session environment. I think that's a given. Personally, I'm still trying to figure out if there are a large enough number of webapps that could be supported to make it worth the effort. (Heavy emphasis on effort.) I'm more worried about the number of webapps that would be written with the assumption that the session will be magically safe, instead of using transactions/database/EJB/ or whatever storage API. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Tomcat 3.2.4 release
On Fri, 19 Oct 2001, Marc Saegesser wrote: +1 Costin I suppose I should vote for my own proposal. -- Vote: Tomcat 3.2.4 Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- Marc Saegesser
Re: welcome files being forwarded to rather than redirected to?
On Fri, 5 Oct 2001, Jan Grant wrote: On Thu, 4 Oct 2001 [EMAIL PROTECTED] wrote: On Thu, 4 Oct 2001, Remy Maucherat wrote: Also, not doing the redirect would create lots of problems with nested welcome pages (foo/index.html is a valid welcome page). Is it ? Yes. The spec talks about valid partial URIs without leading or trailing '/' characters, however... You are right, my mistake. This is a new feature in 2.3 ( 2.2 doesn't seem to have this ). The good news - at least Apache can deal with that without problems, and for other servers we could implement it in mod_jk. Costin
Re: welcome files being forwarded to rather than redirected to?
On Thu, 4 Oct 2001, Remy Maucherat wrote: Also, not doing the redirect would create lots of problems with nested welcome pages (foo/index.html is a valid welcome page). Is it ? AFAIK no web server accepts this kind of welcome page. It's true the spec doesn't mention what values are valid ( Is ../index.html valid ?), but giving what is common de facto 'standard' I wouldn't interpret it this way. That can be yet another incompatibility between web and servlets ( maybe Jon will read this - now, not after a year :-), and make even more difficult to serve static files with apache. Costin
RE: DO NOT REPLY [Bug 3961] - FactoryConfigurationError on Servlet+JSP+taglib
On Fri, 5 Oct 2001, Ignacio J. Ortega wrote: I'm not sure if the bug is actually in the Jaxp version.. I will try to reproduce it, to see what happens moving around crimson jars.. For me seems it's in Damn ClassLoaders bug type.. :) I also don't think it's related with Jaxp version, and I think it should be fixed now ( well, at least 1/2 ) :-) The problem may be related with the fact that in 3.3RC1, by default we don't provide any parser to the webapp - and from strange reasons jasper will need one. I would like to see more details ( the pages you use, config, etc ) - so we can find out why jasper needs that and why it can't find it using it's own classloader. But in any case, just after 3.3RC1 I added code to make sure all webapps that do not include a parser will get the default one. So the bug should go away ( and wait for j-t-j for a better jasper ). Costin Saludos , Ignacio J. Ortega -Mensaje original- De: Bill Barker [mailto:[EMAIL PROTECTED]] Enviado el: viernes 5 de octubre de 2001 0:26 Para: [EMAIL PROTECTED] Asunto: Re: DO NOT REPLY [Bug 3961] - FactoryConfigurationError on Servlet+JSP+taglib I know that Costin has strong feeling on which Jaxp version we should ship with (I just don't remember what they are:). Does anyone else have an opinion? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 04, 2001 12:51 PM Subject: DO NOT REPLY [Bug 3961] - FactoryConfigurationError on Servlet+JSP+taglib DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3961 FactoryConfigurationError on Servlet+JSP+taglib --- Additional Comments From [EMAIL PROTECTED] 2001-10-04 12:51 --- There seems to be a problem with the Jaxp jar files that ship with RC1. If you download Jaxp 1.1 from java.sun.com and replace the jar files in lib/container with those, your example starts working. ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: DO NOT REPLY [Bug 3961] - FactoryConfigurationError onServlet+JSP+taglib
On Thu, 4 Oct 2001, Bill Barker wrote: I know that Costin has strong feeling on which Jaxp version we should ship with (I just don't remember what they are:). Does anyone else have an opinion? xml-xalan + xml-crimson is my favorite for now ( crimson because it's much smaller), or xalan + xerces2 when will be available. I don't mind xerces1 - nor any other parser. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 04, 2001 12:51 PM Subject: DO NOT REPLY [Bug 3961] - FactoryConfigurationError on Servlet+JSP+taglib DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3961 FactoryConfigurationError on Servlet+JSP+taglib --- Additional Comments From [EMAIL PROTECTED] 2001-10-04 12:51 --- There seems to be a problem with the Jaxp jar files that ship with RC1. If you download Jaxp 1.1 from java.sun.com and replace the jar files in lib/container with those, your example starts working. ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: [PATCH] SingleThreadModel Pool for TC 3.3
Thanks David. I don't like STM, but since it's part of the spec we need to support it. And since you spent the time to write it, I think we have the duty to check it and find a way to check it in:-). Unfortunately, not for 3.3, it's too late. But 3.3.1 can include it. Costin On Thu, 4 Oct 2001, Schreibman, David wrote: I'm submitting this with mixed feelings since the recent discussion has shown strong opinions about the utility of the SingleThreadModel. I was already in the middle of doing the work when all that came about so I went ahead and finished it. After reaping the benefits of Tomcat for a couple of years I've been wanting to give something back. So after a recent post about how to help, I went into bugzilla and found this issue. I don't even use STM, but was somewhat familiar with the ServletHandler and figured I could contribute here. At a minimum, I had fun doing the work and was able to learn a bit more about the code base. Maybe it will be of some use to others. Looking forward to more good stuff from this project!! -David
Re: mod_jk 1.2.0/1.1.0 vs ab
On Fri, 5 Oct 2001, Bojan Smojver wrote: Bojan Smojver wrote: Bojan Smojver wrote: This goes OK on both 1.1.0 and 1.2.0, although some requests aren't served (probably because no more threads are available in ajp13 connector - I run a max of 50). Has probably very little to do with it. I tried more threads, but some requests still fail according to ab. The report claims that 'length' fails. This applies equally to JSP's and VM's. -- Failed requests:650 (Connect: 0, Length: 650, Exceptions: 0) -- I think ( or guess ) that ab is checking the length of the first request, and if following requests have different lengths it assumes it's a failure. Could you check if your page returns the same thing ? Very strange.. Costin
Re: Logging - where?
First, which tomcat ? For 3.3: 1) Where is logging done? Could you give me pointers to specific classes/methods I need to modify? The interface is o.a.t.util.log, o.a.t.modules.config.LogSetter will plug the default implementation. Write a new implementation and replace LogSetter, and you can plug your own logger. 2) Performance - is declaring SQL INSERTs as DELAYED or LOW_PRIORITY enough? Or making static per-db-url buffering and writing many (16-64?) records at once? The 'default' logger is using a queue and does some buffering, you may want to cutpaste. Log4j can do that also - so it may be better to just use log4j. 3) Is it possible to rewrite Tomcat's logging to enable pluggable logging engines? (Standard or Log4j) It should be. Creating a log4j logger module is very high on my todo list, now that Ceki added the posiblity to have separated loggers per webapp and plug a controler. If you want to help ( or just do the whole thing ) - I would be happy to help. 4) I saw suggestion to move to JDK 1.4 logging - _please_ if/when you decide to change logging, move to Log4j instead of this. I don't think we'll change the logging ( at least in 3.3 ), but provide additional logging modules - and people can choose whatever is best for their project. Log4j is my favorite ( since it's apache and used by so many people) , I am also interested in a jdk1.4 logging module - but any other logger should work fine and is welcomed. Costin
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteActionCode.java
On Sun, 30 Sep 2001, Remy Maucherat wrote: Hi Remy, Can you explain a bit what's this ActionCode ? I understant it as a hook mechanism, and I like that - but I'm not sure I like the implementation. Ok. The action thing is not a generic event mechanism. Remember, the name was listener, but you complained about that, and I changed it. The point is just to be able to expose a bit the underlying connection control. The event / hook / handler / valve / interceptor is on the application side, and is something else altogether. Do I need to change the name again ? The problem is not the name, but the fact I don't understand it too well :-) The main need for that is to allow the servlet container to tell the connector that the request has been accepted and is ready to be processed (it's the HTTP/1.1 100 status code). I then added some additional code which mat also be useful. So since it's meant for connection control only, very little, if any, extensibility is needed (there's the custom type if you really need it, though). I see. So we want the container to notify the adapter about certain events and/or actions, for connection control. I'm not sure about 'extensibility' here - this is supposed to work with all kinds of adapters, and we'll need all kind of actions here. Unless I'm missing something, there is one communication between the adapter and the servlet container, and one in reverse. Is the Action this container-adapter interface ? If so, we do need a lot of extensibility and much more power. If not - then maybe we can use whatever mechanism we'll use for container-adapter for Action as well. Note: I don't see why ints would be faster. The reference comparison should be a pointer comparison, which is checking if two ints are equal. Yes, but with int you can also do switch, and it would be simpler - why use an object when all you need is a simple enumeration ? It's all about modularity: here, I'm not trying to replicate all the functionality of, for example, the connector package of Catalina. Coyote and its connectors are supposed to be dumb : parse the request, enforce the protocol on the response, handle the underlying connection. Of course, that's already quite an important responsability. Then, the Adapter is doing the application specific logic (note: I probably still need to remove a few things from the Request and Response). To compare it with the Tomcat 3.3 core, I would say that the Adapter would be some code from Request and Response + the OutputBuffer (which I plan to reuse - although I'll modify it a bit). So we'll have 3 layers - coyote, adapter, container. It's not bad - we just need to spend some more time disucussing it and see how it'll fit with ajp/jni/http11/warp/etc. Costin
Re: Re: Apache/Tomcat Collaboration
On Sun, 30 Sep 2001, Justin Erenkrantz wrote: On Mon, Oct 01, 2001 at 01:49:20AM -0700, [EMAIL PROTECTED] wrote: I think option 2 ( in-process ) is what mod_jk is doing - the code has been written and used quite a bit in the last year. It didn't got all the attention that Ajp got, because it doesn't work with Apache1.3, only with IIS and NES and Apache2 ( and AolServer ). I had a feeling you did this with other servers - just not with httpd. With Apache 2.0? Eh, how? -- justin Well, I had it working for a while, now it crashes with some VMs. It's a tricky thing - usually the signals are the biggest problem, java is very sensitive. Nothing special - just compile jk with support for jni worker, and follow the instructions. You may need to set LD_LIBRARY_PATH to include all the .so from java, and you may have problems with some VMs - JDK1.2.2 seems the easiest to get working, and surprisingly 1.4 worked also fine ( I'm talking about Linux versions here ). It's tricky, but I think it's worth it. Costin
Re: Re: Apache/Tomcat Collaboration
On Mon, 1 Oct 2001, Aaron Bannert wrote: What are the main advantages to using an in-process VM as opposed to an out-of-process VM bridged over some form of IPC (like mod_webapp/mod_jk/mod_jserv)? Well, using in-process VM ( like mod_jk ) has many more benefits than just reduced request/response latency. Think about mod_perl - it's not just about 'faster CGIs'. Right now the 'integration' between tomcat and apache is in a very bad shape, the web server is used mostly as a proxy ( that adds a significant overhead, apache+tomcat can be slower than tomcat standalone), and to servle static files ( that are not password protected ). Authentication can be done only by tomcat, and having apache send messages to tomcat to authenticate for static pages would kill any performance. In general, tomcat can't benefit from most of the features the web server provides, and the web server can't benefit from any feature that tomcat provides. And the difference between a method call ( even via JNI ) and IPC - it's pretty significant. But that's nothing compared with the fact that via JNI you can avoid a lot of memcopy, use existing ( and optimized ) methods, have access to a powerfull API, hook deeply into apache. I would imagine request/response latency is reduced, but how well does it scale, and how does it deal with issues of robustness? It doesn't scale very well in a multi-process model, and it's as robust as the Java VM. The main problem with multi-process model is the sessions. But that can be resolved ( especially if you take advantage of mmap ), and you still gain a lot from the deep integration. Costin
Re: Re: Apache/Tomcat Collaboration
On Mon, 1 Oct 2001, Aaron Bannert wrote: Right now the 'integration' between tomcat and apache is in a very bad shape, the web server is used mostly as a proxy ( that adds a significant overhead, apache+tomcat can be slower than tomcat standalone), and to servle static files ( that are not password protected ). Authentication can be done only by tomcat, and having apache send messages to tomcat to authenticate for static pages would kill any performance. In many cases I've seen, apache isn't even being used to serve static content from the java webapps. OTOH, I think we could come up with a better way to map tomcat's static content to the virtual URI-space of apache to encourage this more. I know - anything that has a security-constraint ( or filter for 2.3 ) has to be sent to tomcat, since authentication is not integrated (and filters are ... well, nightmares ). Even for normal static pages - the apache configuration to do that is quite complex - and I'm not only talking about users, but for us too. Generating the config or sending it via wire does simplify the user's life, but the problem is that we have many unsolved problems. In general, tomcat can't benefit from most of the features the web server provides, and the web server can't benefit from any feature that tomcat provides. I have to disagree with this. In general I think we're all much more comfortable using apache-httpd's HTTP parsing routines, if not merely for the fact that they are tried and tested (not to mention, in many cases implemented by the spec author). Tomcat can and should take advantage of this. In addition, the huge collection of httpd modules can be of huge value to tomcat. The biggest problem I'm seeing here is integration. Well, I was just stating the current reality - of course tomcat should take advantage of this. Integrating with the large collection of modules is one of the big benefits of in-process - and it's a 2-way street. The only problem - it's not yet completed, and there are many problems due to 'impedance mismatch'. And the difference between a method call ( even via JNI ) and IPC - it's pretty significant. But that's nothing compared with the fact that via JNI you can avoid a lot of memcopy, use existing ( and optimized ) methods, have access to a powerfull API, hook deeply into apache. I agree that there is a potential bottleneck in remote IPC that can be avoided with things like JNI. However, I don't think that JNI has better access to the httpd internals than any other apache module. No, the point is that tomcat can use JNI to access the httpd internals _like_ any other apache module. Most of the 'internals' are not designed for remote access ( i.e. low latency, etc ) via IPC. The concern I have with robustness of the VM isn't the VM itself, but the 3rd party jars that are used in most webapps. One of those modules causes a segfault in the multiprocess model and apache/tomcat just keep on chugging. If you have a segfault in one of the multithreaded models, you end up losing all the threads in that process -- even if they are in the middle of a healthy connection. (Apache will have this same problem, so it's not specific to tomcat) No java code should be able to segfault the VM - regardless of what you do inside ( except for calling JNI - but that's not available to users, it's just a small layer in tomcat's internal implementation ). If you get a recent VM - you shouldn't have crashes ( at least it's a long time since I got a crash - and that was in a GUI application ). Of course, everything has a price - and it's important to have multiple choices :-) And you can configure jk for something in the middle - like use JNI for the most accessed pages and IPC for everything else. Or just use IPC for pages - but JNI for integration ( i.e. authentication, etc). Costin
Re: Before I file a bug report...
On Sun, 30 Sep 2001, Jon Stevens wrote: Mmmm, I'm not too sure about all this. The servlet spec seems to imply that the extension mapping is on the end of the path. Section 11.1, item #3 : If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last '.' character. Remy I think the Servlet Spec is wrong then because HTTP says that anything after the extension mapping is PATH_INFO. It Is also inconsistent with the way that servlet path mapping works as well. Well, I agree with Jon, but we had this whole discussion almost a year ago, and the conclusion was that the HTTP spec is wrong and we should follow the Servlet spec. Older versions of tomcat supported path info on extension mapped servlets, that was removed since it was considered a spec compliance bug. Workaround - declare each page with exact mappings in web.xml. Costin
Re: SCRIPT_NAME and PATH_INFO with extension mapping
On Sun, 30 Sep 2001, Jon Stevens wrote: on 9/30/01 5:47 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: the conclusion was that the HTTP spec is wrong and we should follow the Servlet spec. That is complete BS. The servlet spec shouldn't 'override' what is defined in the HTTP spec unless absolutely necessary. This is definitely not a necessary case, but instead an act of stupidity. Workaround - declare each page with exact mappings in web.xml. Making me specify each and every page in my webapp in the web.xml is just plain BS. I bet that a URL like this works: http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar I *know* that this URL works: http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar Essentially, what you are doing by removing this capability is preventing the SCRIPT_NAME from having PATH_INFO and that is not right according to the HTTP spec. I don't think that a Servlet container can override the behavior of the HTTP spec and still claim HTTP compliance. Well, I agree with you - but I feel ofended by the 'you' in this phrase. I didn't removed it - I spent quite a bit of time and arguments to keep it in. BTW, it has nothing to do with the HTTP spec ( which doesn't specify anything like that), but with the way all known web servers operate. And it has nothing to do with JSPs as well - it's true for any extension mapped servlets. Costin
Re: SCRIPT_NAME and PATH_INFO with extension mapping
On Sun, 30 Sep 2001, Jon Stevens wrote: on 9/30/01 3:57 PM, Ignacio J. Ortega [EMAIL PROTECTED] wrote: You lost, this URL does not work in IIS ( 404 ).. Ug. I guess so. JSP == ASP. :-( If you use extension mapping in velocity, it'll be the same, it has nothing to do with JSPs. Costin
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteActionCode.java
Hi Remy, Can you explain a bit what's this ActionCode ? I understant it as a hook mechanism, and I like that - but I'm not sure I like the implementation. For example, any reason not to use a plain 'int' as action code ? At least that would allow switch() which is slightly faster ( when the number of actions will grow ). Also, how do you plan to 'grow' - you can't just add static fields - what about dynamic hook ? If you allow ActionCodes that are not defined as static fields ( so you can use == ), you'll be forced to use .equals(), that would be pretty bad. There are few other things we need to discuss before implementing - but that's one of the most obvious. ( I'm not saying that Hooks are better, just that we need to discuss a bit the details of coyote ) Costin On 1 Oct 2001 [EMAIL PROTECTED] wrote: remm01/09/30 18:09:54 Modified:coyote/src/java/org/apache/coyote ActionCode.java Log: - Add a commit action code. Revision ChangesPath 1.2 +6 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java Index: ActionCode.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ActionCode.java 2001/07/10 02:54:59 1.1 +++ ActionCode.java 2001/10/01 01:09:54 1.2 @@ -70,16 +70,19 @@ // -- Constants -public static final ActionCode ACTION_CUSTOM = new ActionCode(); +public static final ActionCode ACTION_ACK = new ActionCode(); public static final ActionCode ACTION_CLOSE = new ActionCode(); -public static final ActionCode ACTION_RESET = new ActionCode(); +public static final ActionCode ACTION_COMMIT = new ActionCode(); -public static final ActionCode ACTION_ACK = new ActionCode(); +public static final ActionCode ACTION_CUSTOM = new ActionCode(); + + +public static final ActionCode ACTION_RESET = new ActionCode(); // --- Constructors
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Thanks Bill. I'll merge this with my changes and check in. Costin On Sun, 30 Sep 2001, Bill Barker wrote: What I get for trying to do this on a computer without javac installed. Diff file with typos fixed and exceptions handled. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 12:40 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() Actually, my original was a straight java.net.URLEncode after stripping out the session id. However, I'm easy. Attached is using UEncoder (which I initially felt was too expensive). I'm starting to come around to your original idea however. This is better done in the Facade (where there is zero hit for pages that don't ask for RequestURI). Currently, nobody uses unparsedURI, and it is arguably a protocol violation if a servlet serves different pages for equivalent URIs - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 1:23 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain (
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain ( java :-) - important - servlets will get a consistently encoded uri, thus preventing many security problems. With the current code many tricks can be played ( see recent security problems in tomcat ) using encoding - if we were vulnerable to that, I suspect most servlet authors will be as well. Problems: - a bit more work to do. - the 'original' uri will not be preserved in any servers ( the first solution allows that for IIS and standalone ). Your votes please, I'm ok with any of them ( with a slight preference to 2 ) Costin On Thu, 27 Sep 2001, Larry Isaacs wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 3:10 AM To: [EMAIL PROTECTED] Subject: RE: TC 3.3: getRequestURI() Given this is an important change - and something will be broken regardless of what we do - I think we need to coordinate and make sure we're doing it right. - First: Larry - what do you think ? We just had RC1, and we have already a simple patch ( changing SessionId to hide the problem ). My proposal is simple to implement ( just encode the URI on the facade, and use only decoded URIs internally ), but it is braking some of the 2.3 clarifications ( not mandatory for 2.2, of course, but important ) I'm leaning towards your encode in facade solution. I'm curious about the
RE: TC 3.3 Release Plan
On Wed, 26 Sep 2001, Larry Isaacs wrote: Hi David, I had hoped to get Tomcat 3.3 released prior to my up coming house closings and move. I won't be able to make this target, but hope to get Tomcat 3.3 to RC2 not too long after the move, perhaps around October 8. It is RC2 that I plan to propose for release and be voted on. The vote should last a week, and if approved, I will quickly post the final release. That means Oct. 15 should be the target date for the final to be posted officially, and the final code will be frozen on Oct. 8. Costin
Re: TC 3.3 + mod_jk + j_security_check
On Thu, 27 Sep 2001, Bojan Smojver wrote: I was referring to the manual configuration, rather then ApacheConfig one. Some people (me :-) prefer to do things manually. I actually tried with /*.jsp (or /*.vm in my case) only and it (still) doesn't work (which makes sense and I don't consider it a problem) unless you specify: JkMount /login/j_security_check ajp13 or whichever other place j_security_check is under. That's what I wanted to mention in the mod_jk HOWTO. It might save someone considerable amount of time. +1 Manual configuration is the best :-) ( but ApacheConfig is getting very close ) Costin
RE: [PATCH] Potential buffer overflow attach in mod_jk
On Wed, 26 Sep 2001, Ignacio J. Ortega wrote: I think we need Bill Barker Kin-Man Chung aboard already.. if we dont want to have more work that we already have integrating their patches.. Next can change subject and call this a vote about giving them committer access ASAP :) +1 :-) Costin
Re: Tomcat next
On Wed, 26 Sep 2001, Dave Oxley wrote: Hi all, A couple of questions on future Tomcat releases: 1. Will there be a TC3.4 release or is 3.x obsolete after 3.3? AFAIK there is no plan for a 3.4 release after 3.3 - that doesn't mean 3.x will be obsolete, just that the core is now stable and unlikely to change, except bugfixes. Having a stable core is essential for module development and for enhancing the current set of modules. Even if there are many improvements we can add to 3.3, I believe the benefit of keeping 3.3 stable is far bigger. It is not yet decided how we'll release the new modules, but the main idea is to keep the 'base' version as small and clean as possible, and all features to be 'add-ons', outside of the base distribution, and have only bug fixes in 3.3.x-releases. Costin
RE: TC 3.3: getRequestURI()
On Wed, 26 Sep 2001, Keith Wannamaker wrote: 0x3b = ';'. Ignacio is right, SessionID doesn't remove the id because it is not expecting ; to be encoded. So now it shows up in the URI and has the side effect of breaking sessions that depend on url rewriting. But, the spec does say the URL should be encoded, so I'd rather fix SessionID with this patch. However, are there other places where TC is manipulating the URL and assuming it is unencoded? I'm not sure this is the right solution ( but it's a good patch:-). The 'original' URI included a ';' - which is a valid character used in the right way. It shouldn't be encoded by mod_jk - the whole reason for encoding is to try to reproduce the original URI or something equivalent. The only use for %3B is to allow the user to specify some path-info ( or other path components ) that include the ';' character. In a URI ';' is used to pass additional informations about the path ( and it seems it can be attached to any path component ) - I never saw any server to use this feature. Well, we have a big nightmare here - and probably the only way out is to find some consistent ( and implementable ) interpretation of the involved specs and stick with that. The encoded URI is used only to satisfy the servlet spec - and re-encoding the URI is an imperfect workaround. We have few choices: 1. revert to the use of unencoded_uri. Problems: - what about IIS and NES, where this is not available ? - what about integrating with apache, where the decoded uri is used for everything ( that means any attempt to authenticate using apache modules may create huge problems) 2. Use a different encoding function, that doesn't encode ';'. Problems: - encoding/decoding will result in a different URI ( thus the servlet spec will not be happy ) - inconsistency between tomcat standalone and tomcat+server 3. Revert to the use of uri ( i.e. the decoded uri ), and change the getRequestURI ( the facade ) to generated a 'canonical' encoding. Problems: - again it'll not be the 'original' as required by servlet ( but at least this will be consistent across servers) Using 'unencoded' URIs is a huge source of security problems - the server and container _must_ use decoded URIs internally, because otherwise security constraints would be useless. On the other side, servlets that are doing any matching on 'unencoded' URIs are likely to be tricked easily by encoding tricks. So if a user is doing any security check, he'll likely repeat all our bugs. Using a 'canonical' encoding ( where only the chars that are required to be encoded are encoded ) has the benefit that gives a consistent output. My preference would be to do (3). Costin
Re: Tomcat next
On Wed, 26 Sep 2001, Remy Maucherat wrote: What would *you* like to see happen? (And what would *you* like to work on to make it happen? :-). Cleaning up and modularizing the current 4.0 is probably the most important thing to happen before any more features are added, and that's what I would like to see happen. - a Coyote connector (note: Coyote is the name I've chosen to designate half of what is currently the TC 3.3 core) +1 - using a common architecture for the lower-layer is great. - a HTTP/1.1 connector for Coyote +0 ( I'm happy with Apache's implementation of 1.1, but would be a nice module for 3.3 ) Costin
Re: Watchdog-4.0 PB
On Wed, 26 Sep 2001, jean-frederic clere wrote: [java] /home/jakarta/jakarta-watchdog-4.0/dist/conf/servlet-gtest.xml:22: java.lang.NoSuchMethodException [java] Java Result: 1 BUILD SUCCESSFUL Total time: 2 seconds +++ I am using ant-1.4. Yes, something changed in ant-1.4 and now all TaskAdapter-based tasks are failing. I'm looking for a workaround ( if any ). TaskAdapter was used to plug in arbitrary java classes ( that do not extend Task but follow the ant patterns - i.e. bean setters and execute()). However something is now broken. A simple fix is to extend Task ( and add a dependency on the current ant ). Costin
Re: [VOTE] Kin-Man Chung and William Barker for Tomcat CommitterStatus
On Wed, 26 Sep 2001, Craig R. McClanahan wrote: I'd like to follow up on Nacho's (good) suggestion that we add William Barker and Kin-Man Chung as committers on Tomcat. They've both been providing invaluable assistance and patches. I'm +1 on them. I already sent a +1, but since there are 2 new commiters I'll add a seconde one :-) +1 Costin
Re: tomcat hangging problem
Hi Joseph, I assume this is happening only on SMP machines ( i.e. with multiple CPUs). My bet is that this is related with the VM/libraries. It can of course be a bug in tomcat, like a deadlock or something - but then it would fail on all SMP machines. Could you check with the 'latest' 1.3.0 and make sure you have all the patches installed ( pthred.so, etc ). Also, check the version of the libraries between the AIX machines that work and those that don't. If you get a core dump - again, this is a clear sign something is wrong with the VM/libraries. A java program shouldn't be able to coredump regardless of the code inside ( unless JNI is used ), and there's nothing we can do in tomcat ( even if we find a workaround, some user code can crash the server as well ). Is anyone else running SMP machines ? I remember long time ago a problem on linux/smp, but was solved by using a newer VM. Costin Here is the description of current problem I try to solve... I have already mailed to tomcat-user, but since nobody has a beginning of an answer, and since we can't go on production launch anymore, I try here. environment: - AIX 4.3.3 SMP, - JRE 1.2.2 (several builds), then 1.3.0 - tomcat 3.2.1, 3.2.3 then 3.3.b2 (sorry, did not try 3.3.rc1 yet!) problem is: tomcat hangs after some time (may be 3 minutes or some hours). I mean tomcat is running (ps shows it), but no answer is received to requests when tomcat hangs (telnetting it with a http get request results in no response). Even a kill -3 does nothing. Strangely, problem occurs only on _some_ of AIX 4.3.3 machines where I run tomcat. Some machines, with same jre/tomcat/code, run with no problem (well, maybe problem would occur after a much longer time, I don't really know). And I did not met that on winNT4 (with a Sun jdk: I got to try with an ibm jvm). Note that I got a javacore twice, if somebody can interpret it... I wrote a simple servlet which shows tomcat hangging, if that can help: a singleton deals with doGet: first time it launches 'n' threads, each of them will http-request same singleton every 't' seconds and print result to stdout. other request to singleton only prints text/plain string to response's writer. Thanks -- Joseph Vallot This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: [PATCH]: TC 3.3 ReloadInterceptor: Local Interceptors - Feedbackwanted
Hi Bojan, +1 - looks very good, it'll be a great 'first commit'. ( 'normal' case with only global modules is not affected in any way, and for local modules it'll do the right thing, and update the context ). Costin On Tue, 25 Sep 2001, Bojan Smojver wrote: This seems to do the trick. I've tested it with the JDBCRealm interceptor and it behaves normally (ie. JDBCRealm gets hooked back in and it actually works after the application reload). Any feedback before this gets committed is welcome (as in: I'd rather not screw up TC 3.3 RC with my first commit :-) Bojan
Re: TC 3.3: Tabs/Spaces/Indentiation: NOT A CALL FOR DEBATE OR FLAMEWAR!
On Tue, 25 Sep 2001, Bojan Smojver wrote: I've read the thread about tabs/spaces/indentiation in Tomcat code and it seems that at least TC 4 people are going with 4 spaces instead of tabs (judging by comments from Craig). Does that apply to TC 3.3 as well? PS. I've noticed that a lot of TC 3.3 code still uses tabs, so when patching, I might convert into spaces at the same time and comment appropriately. TC3.3 is using tabs, with 4 space indentation and tab==8 spaces. As long as you convert with tab==8 spaces, it'll be fine. AFAIK there is no official rule or vote on this. Costin
Re: [PATCH]: TC 3.3 ReloadInterceptor: Local Interceptors - Feedbackwanted
On Tue, 25 Sep 2001, Bojan Smojver wrote: [EMAIL PROTECTED] wrote: Hi Bojan, +1 - looks very good, it'll be a great 'first commit'. ( 'normal' case with only global modules is not affected in any way, and for local modules it'll do the right thing, and update the context ). Thanks. Wouldn't be able to do any of it without your guidance. Well, you were right in the first place - we need a mechanism to detect changes in the config and reconfigure, taking into account the new app-foo.xml file. And your initial solutions is probably better - and could solve part of the 'reconfigure' issue. Maybe later ( after 3.3 ) we could revisit this issue and improve a bit ContextXmlReader. Costin
Re: TC 3.3: Tabs/Spaces/Indentiation: NOT A CALL FOR DEBATE ORFLAMEWAR!
On Tue, 25 Sep 2001, Bojan Smojver wrote: No probs. I can use tabs + 4 spaces for indentation. No need to overhaul the whole thing if people aren't complaining. Bojan PS. Normally I use spaces in my code and when I produced the last patch, I've noticed that things are a bit 'out of whack'. That's why I asked the question in the first place... Well, you can/should use spaces - and avoid beeing flamed by the space police. But if you preffer using tabs - make sure you use 8 spaces, and don't change files just to replace tabs with spaces. Costin
Re: JK in TC 4.0 ?
On Sat, 22 Sep 2001, Remy Maucherat wrote: ballot [ ] +1. Integrate the mod_jk JARs with the Tomcat 4 distributions. I'll help testing / maintaining it. [ ] +0. Good idea. [ ] -0. Bad idea. [ ] -1. No, because: /ballot My vote: +1 (I'll update the build scripts, tag the j-t-c/util and j-t-c/jk repositories). +1 ( I'll help !). It's a good step toward working togheter. Costin
Re: EmbededTomcat embeded, addContext
Hi Johannes,
Many thanks for your work ! I'll incorporate your fixes - AFAIK Larry
is planning to build RC1 this weekend, I'll make sure everything gets in.
Feel free to propose any additional improvements to
EmbededTomcat. In case you have problems, remember you can at any time
call getContextManager and use it directly.
It is also possible to just ignore EmbededTomcat and create your own
startup program - either something specialized for your needs or a better
version of EmbededTomcat. The current code was 'driven' by the current
common use-cases for tomcat.
The general idea is that everything is ( or should be ) replaceable :-)
Costin
On Fri, 21 Sep 2001, Johannes Brodwall wrote:
I am continuing with my struggle getting tomcat 3.3 to work embedded, and it
seems like I am finally starting to see the light.
I saw that my patch for addEndpoint was added, which is good. However,
addAjpEdpoint contains the same bug. That InetAddress.toString is a
insidious little monster.
More importantly, there is a problem with EmbededTomcat.addContext. Since
the first thing this method does is to call initContextManager, the new
context is added after contextManager.init has been called. This means that
Context.init is never called, and the context is still in STATE_ADDED when
it is supposed to handle requests. This is very hard to debug, as there is
no error message to that effect, only a generic 503.
Here is my suggested patch:
EmbebedTomcat.addContext
347: contextM.addContext( ctx );
+ctx.init();
348: return ctx;
This will happen after contextM.init is called; I am not sure if that will
cause adverse side-effects.
Secondly, in order to more easily spot this kind of problem, I suggest the
following change in ContextManager.
ContextManager.java:949-958
- if( req.getContext() == null ||
- req.getContext().getState() != Context.STATE_READY ) {
- // the context is not fully initialized.
- req.setAttribute(javax.servlet.error.message,
-Application not available);
- // return error code - the caller will handle it
- // handleStatus( req, req.getResponse(), 503 );
- // service unavailable
- return 503;
- }
+ if( req.getContext() == null ) {
+ req.setAttribute(javax.servlet.error.message,
+Context not set in request!);
+return 503;
+ }
+ if( req.getContext().getState() != Context.STATE_READY ) {
+ req.setAttribute(javax.servlet.error.message,
+Context + req.getContext() + is not initialized);
+ return 503;
+ }
Lastly, I would like to warn people that when using
EmbededContext.addContext, the name of the ROOT context is , not ROOT.
The diagnostics for a missing root context are quite confusing
(java.lang.RuntimeException: Assertion failed: container==null at
org.apache.tomcat.modules.mappers.SimpleMapper1.contextMap(SimpleMapper1.jav
a:298))
I hope this can be of use.
Sincerely,
Johannes Brodwall
--
PS. Here is the code I am using - I am executing it using the Beanshell
interpreter (www.beanshell.org) using classpath
lib\tomcat.jar;lib\common\connector_util.jar;
lib\common\core_util.jar;lib\common\etomcat.jar;
lib\common\jasper-runtime.jar;lib\common\servlet.jar;lib\common\tomcat_core.
jar:
tomcatHome = C:\\java\\external\\jakarta-tomcat\\dist\\tomcat;
import org.apache.tomcat.util.IntrospectionUtils;
parentL = IntrospectionUtils.class.getClassLoader();
commonCP = IntrospectionUtils.getClassPath(tomcatHome + \\lib\\common,
null, org.apache.tomcat.common.loader, false);
commonCL = URLClassLoader.newInstance(commonCP, parentL);
containerCP = IntrospectionUtils.getClassPath(tomcatHome +
\\lib\\container, null, org.apache.tomcat.common.loader, false);
containerCL = URLClassLoader.newInstance(containerCP, parentL);
appsCP = IntrospectionUtils.getClassPath(tomcatHome + \\lib\\apps, null,
org.apache.tomcat.common.loader, false);
appsCL = URLClassLoader.newInstance(appsCP, parentL);
tomcat = new org.apache.tomcat.startup.EmbededTomcat();
tomcat.setInstall(tomcatHome);
tomcat.setParentClassLoader(parentL);
tomcat.setContainerClassLoader(containerCL);
tomcat.setCommonClassPath(commonCP);
tomcat.setCommonClassLoader(commonCL);
tomcat.setEstart(true);
rootContextUrl = new URL(file:c:\\java\\projects\\hellotomcat\\);
tomcat.addContext(, rootContextUrl, null);
// using the Accessibility API to set tomcat.initialized = false, and
// then calling tomcat.initContextManager() here will produce the
/ desired behaviour
tomcat.start();
Re: TC 3.3: Form authentication vs. Application reloading
On Fri, 21 Sep 2001, Bojan Smojver wrote: A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). Just to be clear on what you meant here, if there was, for instance this JDBCRealm local interceptor object, you'd just store its reference ,somewhere else while context is being reloaded and then attach the same object back as an interceptor after the reload is done. I was thinking about that but what if that old instance of the interceptor object relied on something in the old context? That would screw things up. But if that's not the case (ie. there can't be any relationship with the context), it should be fine. Still don't know enough to tell. You should call setContext() and reload() on the interceptor to let it know the new context, and the module should be able to handle this - you may need to do additional fixes in the module. In general I think each module should be able to deal with: - dynamic context add/remove - context reloading - module reloading ( in future ) My understanding is that ContextXmlReader actually produces 'fresh' instances every time. True. Do you think it would be better ( or simpler ) to just change ContextXmlReader to create a new set of per/context interceptors ? My thinking was that the interceptors should be 'smart' about reloading, maybe they need to save/restore some state ( like a session interceptor ), or do some other actions. Costin
Re: [PATCH] to get Client Certificates in TC3.3
On Fri, 21 Sep 2001, jean-frederic clere wrote: Regarding CertCompat: I'm not sure we need it, the functions could be added to jdk11Compat. It's not a big deal, I can change this after you commit ( unless you have reasons or a preference to create a compat class for cert-related code - which is ok ). I prefer to have a CertCompat because we could have Java2 and no JSSE. Is JSSE and JDK1.1 possible? Are you using JSSE in CertCompat ? If so - you're absolutely right ( well, maybe we should call it JsseCompat ? ). Even better - we can extend it to support other SSL-toolkits ( I know there is a OpenSSL wrapper around ). Costin ( sorry, I thought you're only using java.security.cert, which is JDK1.2+ but doesn't require JSSE )
Re: Tomcat RPM polls
On Thu, 20 Sep 2001, GOMEZ Henri wrote: I'd like to have the opinion of Tomcat RPMS users about some points since I'm working on enhanced RPMs : 1) Do you want tomcat to be changed to run as nobody instead of root ? Yes, if possible. Or as user 'tomcat' 2) Do you want tomcat to be enabled by default, ie having it active after installation ? No. It may be a security issue ( since the user may not have changed the passwords for admin, etc ). A nice thing would be to not start at all until this is done - but that should be done in the main tomcat (and later ) 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ +1 4) Do you want the webapp stuff moved to /var/www/webapps ? +0 5) Do you want the log stuff moved to /var/log/tomcat ? +1 Costin
Re: Anyone solve the cache problem in Tomcat already ?
On Thu, 20 Sep 2001, Kenny Ma wrote: I need to restart tomcat everytime after i change my servlet program even I added reloadable=true in serevr.xml Anyone solve this problem ? please tell me What version of tomcat ? Reloading works pretty well in 3.3 and reasonably well in 3.2. As long as the servlet/jars are in WEB-INF/lib, classes - and not in the main classpath or something like that. We even detect changes in web.xml. Costin
Re: TC 3.3: Form authentication vs. Application reloading
Hi Bojan, A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). This would deal with other configuration mechanisms as well - ContextXmlReader is not the only way to add contexts, applications embeding tomcat may use API calls as well. Dealing with changes in app.xml is a bit more difficult - and I think the right long-term solution is to consolidate all config modules and create a smart 'deploy tool' module that can take care of all the issues. Costin On Thu, 20 Sep 2001, Bojan Smojver wrote: Bojan Smojver wrote: Is this something that happens by design or am I looking at a possible bug? By following what happens when TC starts and when it reloads the context, it seems that there should be contextInit() method in ContextXmlReader. This interceptor is responsible for calling the ServerXmlReader.loadConfigFile() which in turn (after a series of XML related calls on the stack) calls Context.addInterceptor(), which is responsible for adding all local (to the context) interceptors. If ContextXmlReader had contextInit() method, this would happen every time the context is reloaded and all local interceptors (including my JDBCRealm :-) would be picked up. Swt! Now that's all cool, but I wouldn't have a clue how to write that method. If you guys can point me in the right direction... Thanks, Bojan
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupEmbedded.java
On 19 Sep 2001 [EMAIL PROTECTED] wrote: remm01/09/19 16:53:02 Modified:catalina/src/share/org/apache/catalina/startup Embedded.java Log: - Use reflection to load the SSLServerSocketFactory, which removes the last compilation problem when trying to build with JDK 1.3 + servlet.jar + regexp.jar. - Hopefully, everyone's happy with the build process now :) I'm impressed ! If you check in the 2 jar files ( like all jakarta projects do, while allowing them to be overriden by gump of course ) - the build will be close to perfect. Costin
Re: [PATCH] to get Client Certificates in TC3.3
Hi, Regarding CertCompat: I'm not sure we need it, the functions could be added to jdk11Compat. It's not a big deal, I can change this after you commit ( unless you have reasons or a preference to create a compat class for cert-related code - which is ok ). It seems ok - the only question is if we should put it in before or after RC1. Costin On Thu, 20 Sep 2001, jean-frederic clere wrote: Hi, I have prepared a patch to get the javax.servlet.request.X509Certificate working with the Http10Connector. I will commit it tomorrow (after removing the println() and retesting with JSSE and without JSSE). I have enclosed the patch for Http10Interceptor.java and the 2 new CertCompat files. I have also committed a small patch for PoolTcpConnector.java please check it... Any comments? Cheers Jean-frederic
Re: Using EmbededTomcat embeded in another application - addEndpoint
The classpaths and classloaders in EmbededTomcat are also used somewhat insistantly, especially in the initClassLoader method. For example will initClassLoader try to infer appsCP if it does not exists, but not commonCP. containerCP, appsCP are not used outside this method. commonCP is, but only in the setCommonClassPath method, which does not have any container or apps counterpart. Well, at least we're trying to self-configure/infer as much as possible, the code is not perfect - I added what was needed to improve what I believed to be the common use case. The goal was to minimize the user effort - and if you look at EmbededTomcat.main(), it's close to what you request. ( I suppose we're discussing the curret 3.3 code ). Please send sugestions, I'm very interested in feedback and improvements in this area. Right now the 'Main' works fine ( or at least better than before :-), I was able to use EmbededTomcat standalone ( i.e. using the main() ) and even without server.xml file. Costin All in all, I find the EmbededTomcat class quite tricky to use when not starting it from Main. Are anyone working on the usability aspects of this class? It could be possible to just do: EmbededTomcat tomcat = new EmbededTomcat(); tomcat.setInstall(); // or even tomcat.setTomcatRoot(...), or even let EmbededTomcat do some of the initContext stuff before addModule is called tomcat.addEndpoint(8080); tomcat.addRootContext(); tomcat.start(); Sincerely Johannes Brodwall
Re: [PATCH]: TC 3.3: DependClassLoader
Hi Bojan, First, you're a commiter now, feel free to fix anything you see broken :-) Regarding this particular fix - it will not have a big performance impact ( except for loading .class files, which happen once ). However I would rather keep the old code and add comments - reading a stream byte-by-byte is not a good idea in any case. I'll take a look at ZipFile. Costin On Tue, 18 Sep 2001, Bojan Smojver wrote: After digging some more into the code of it, I've realized that the readFully() method is really hard to understand. So, unless there are some substantial performance gains in the existing approach, maybe we should go with something a bit simpler. And just as a side note, you've probably noticed that I've produced some simple code to replicate (alleged) JDK ZipFile bugs. Any feedback on the validity of that code would be welcome (ie. maybe I'm doing something really stupid in there). Bojan
RE: SSL Attributes
On Tue, 18 Sep 2001, Ignacio J. Ortega wrote: I have found it the 2.2 Spec's (5.7 SSL Attributes). Now I have started to fix Ajp13 in jakarta-tomcat so that it follows the spec's. For the moment I will only return the first certificate. Returning the complete chain is quite a lot of data and it is probably useless for applications. +1 , and a comment on Readme.txt as is a spec compliance issue Until we find a way to cache Client Certificate Chain.. Or we add 2 more messages in ajp13/14 - to get the chain when the user request it. In fact, even the client certificate should be retrieved only on demand, I assume most pages will not deal with certificates ( except maybe some initial page ), and sending even the first cert over the wire would be wasted. Long ago we did some tests and looked into a number of servlets - it's likely 1/2 of what we send by default can be eliminated ( including most of the headers ), very few servlets will do getHeaders(). The impact on performance was visible ( with a small penalty for the requests using getHeaders == one extra roundtrip ). I assume that's something for ajp14/warp ( including customization of what's send and what's not). Costin
RE: SSL Attributes
On Tue, 18 Sep 2001, GOMEZ Henri wrote: That something I've got in mind for ajp14, written on that many times allready, with headers and miscs informations to be asked by tomcat to web-server at getAttributes time for example : +1 ( but not before 3.3 is final ! ) Costin Currently WebServer - Tomcat 1) SEND HEADERS + REQUEST to TC 2) SEND DATA (eventually) to TC 3) WAIT TOMCAT REPLY 4) SEND BACK HEADERS + REPLY TO BROWSER Next in ajp14 WebServer - Tomcat 1) SEND GENERAL HEADERS + REQUEST to TC 2) SEND DATA (eventually) to TC 3) WAIT TOMCAT REPLY OR TOMCAT ENQUIRIES 3a) IF ENQURIES, REPLY TO TC ENQUIRIES ie CERTIFICATE CHAIN which may be more than x certs 4) SEND BACK HEADERS + REPLY TO BROWSER
Re: Compile errors
On Tue, 18 Sep 2001, Craig R. McClanahan wrote: Today, if you download (say) the 3.2 source tree and build it, in an environment that doesn't have JSSE installed, the build script will silently create a incomplete distribution for you, because it will silently exclude building SSLServerSocketFactory. Thus, even though you *think* you just built a complete binary distribution, you didn't -- you cannot take your distribution and deploy it on a machine that does have JSSE installed and run SSL connections, without going back and building from source yet again. Now multiply this same sort of problem by all the options people might want to not require in Tomcat 4. If the build system does not provide at least the option to guarantee a functionally complete build (i.e. fail if something optional is actually missing), I'm going to be -1 on it. Without this, people building distributions (including the release manager building the official ones) has no automated means to validate success. I disagree with this - in tomcat3.x we do the build using only components that are redistributable under apache license - jaxp included ( we use xml.apache.org code for crimson, jaxp and xalan ). The result is functionally complete - it is true it does not include components that depend on other licenses, but I don't think you can require people to download and accept other licenses in order to build tomcat or redistribute. The release manager - on the other side - or people who want to build that functionality - can get the extra code and build the components that would enable it, for the release or for their own use. I believe the build system for 3.x is the right one - and it's consistent with what Apache does - you are not required to download an SSL implementation to build apache httpd. ( as a matter of fact, in some countries it is illegal to use encryption - I think even France has some interesting laws - or used to have, so that would make building tomcat quite difficult ). It may be inconvenient for people - but if a jar is included in an apache product that means ASF gives people who get that package the right to redistribute it without restrictions ( assuming they give credit to apache, etc ). Costin
Re: build problem
Hi Anthony,
AFAIK ( and I just checked the java lang spec ), a class (
CharArrayWriter) can override a method ( write ) and have fewer
throws declarations. It can't have _more_ exceptions.
CharArrayWriter.write() doesn't have any throw() declaration, so the code
seems correct.
We can add a catch(Exception) as a workaround.
Could you try a build with tomcat3.3 ? I assume there are other places
like that, and we should add the workarounds ( or fix what have to be
fixed ) before RC2/final.
We can do that for a 3.2.4 or something - I'm not sure when or if it is
planned, but my main concern now is making sure 3.3 will work.
( I'll try to reproduce the build - I assume you're using gcc3.0 - is
there anything else you need ? )
Costin
On Tue, 18 Sep 2001, Anthony Green wrote:
One of the local changes I had to make to Tomcat in order to build with gcj is
in JspReader.java...
char[] getChars(Mark start, Mark stop) throws ParseException {
Mark oldstart = mark();
reset(start);
CharArrayWriter caw = new CharArrayWriter();
while (!stop.equals(mark()))
caw.write(nextChar());
caw.close();
reset(oldstart);
return caw.toCharArray();
}
Our implementation of CharArrayWriter.write() can throw an IOException, as per
the JDK1.3 docs - resulting in...
upstream/jasper/src/share/org/apache/jasper/compiler/JspReader.java:397:
Exception `java.io.IOException' must be caught, or it must be declared in the
`throws' clause of `getChars'.
caw.write(nextChar());
^
1 error
What's going on here?
Thanks!
AG
Re: [VOTE] New Committer: Bojan Smojver
+1 Costin On Mon, 17 Sep 2001, Larry Isaacs wrote: I would like to propose Bojan Smojver as a committer. He has supplied a number of patches as well as done useful testing. I think he would make good addition to the Jakarta team. Vote, please... Larry Isaacs
Re: Ajp13 change in recent TC 3.3
On Mon, 17 Sep 2001, GOMEZ Henri wrote: Hi to all, The works conducted on ajp13 in TC 3.3 to add chunk support and better handling of the content-length, have broken compatibility with previous mod_jk. I think the only compatibility that matters is 3.2.3 working with the new mod_jk. We should recomend people to upgrade at least mod_jk to 3.3/jk or j-t-c/jk, there are many bug fixes they'll need. Using the old jk with 3.3 is not a good idea. Costin
Re: FW: Tomcat + gcj
Cool... Could we try to link the generated .so with mod_jk and apache :-) ? Costin On Mon, 17 Sep 2001, GOMEZ Henri wrote: -Original Message- From: Anthony Green [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 9:51 AM To: [EMAIL PROTECTED] Subject: Tomcat + gcj This is just an FYI... I recently got Tomcat working on Linux with gcj (a free native code compiler and runtime for the java programming language). Tomcat, and all of the support libraries (xalan, servletapi) are compiled to native executables and shared libraries which run without any supplementary JRE. Servlets are compiled to native shared libraries like so.. $ gcj -shared -o lib-HelloWorldExample.so -O2 HelloWorldExample.java ..and they get loaded and executed as expected. I'm able to run most of the example servlets, as well as some servlet's using xalan - but there are still a few bugs that need to be ironed out. JSP doesn't work out of the box. I haven't looked into it yet. I've placed everything up for cvs access here: http://sources.redhat.com/rhug It will take a bit of debugging to get it all working perfectly. I'd appreciate help if anyone is inclined... just subscribe to the mailing list and have at it. Thanks! AG
Ant1.4 requirement for tc3.3 ?
Ant1.4 is the current release of jakarta-ant, and our build works fine except 2 warnings ( deprecation in fixcrlf ). However, if we update the task it'll fail on ant1.3 - so my proposal is to keep it compatible with both ant1.3 and ant1.4, and accept the warnings if 1.4 is used. Other opinions ? Larry ? Costin
RE: Remaining Tomcat 3.3 Issues
On Mon, 17 Sep 2001, Craig R. McClanahan wrote: If you go this way, you would definitely want to make a note someplace that apps cannot use a security constraint with a /* pattern, because there is no other directory in which the login and error pages can be put. Because /* is a legal URL pattern, IMHO that means there *is* an implicit spec requirement to support this. However, it's not a regession, because 3.2 is broken here as well, so it can't really be called a showstopper. (This feature is supported in 4.0, which took some pretty interesting code gymnastics.) I'm not sure this is an implicit requirement - /* works fine with basic authentication, and the rules for mapping URI constraints are _very_ explicit ( well, too explicit I would say ). There is no exception mentioned in the prefix mapping ( /* mapps everything but the uri's used for form-auth and maybe some error pages - since implicitely they are supposed to work ). IMHO explicit text takes precedence over implicit. But this could also be resolved by adding ALLOWs for the login page. ( == more specific uri constraints that would match it ) Costin
Re: SSL Attributes
On Mon, 17 Sep 2001, jean-frederic clere wrote: Hi, I have patched mod_jk for TC4.0 so that the SSL Attributes follow the spec's (SRV.4.7). I have not found anything in the 2.2 spec's about it. I have noted that the javax.servlet.cert.X509Certificate of TC3.3 is a String not an array of java.servlet.request.X509Certificate. What should we do?: 1 - Update TC3.3 code so that is compatible with 2.3 spec's. 2 - Document in tomcat-ssl-howto.html that in TC3.3 javax.servlet.cert.X509Certificate is a String and add an example how to use it. 1 - if possible. The spec is clear even for 2.2 ( the type is a X509Certificate[] ), and having different from 4.0 would mean trubles for anyone who uses it. AFAIK 3.2 returned a string (or nothing ?), but this is clearly a bug. Costin
RE: Remaining Tomcat 3.3 Issues
On Mon, 17 Sep 2001, Larry Isaacs wrote: Hi Costin, See below for my proposal for Item #2. I think this is the only one remaining that matters for RC1 at this point. Let me know if you think this will work. I think we can postpone this for RC2. You are right - syncronization in init() should have no impact on performance. I want to look into how 4.0 is doing that too. I'll make a pass through be bugs in the last Tomcat3 Bugzilla report and see if I'm missing any. I'll update the plan this afternoon and anticipate building RC1 tonight. +1 Costin
Re: Remaining Tomcat 3.3 Issues
Larry, I tried to fix as much as possible, could you post an update with what remains open for RC1 ? On Wed, 12 Sep 2001, Larry Isaacs wrote: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. Done ( well, I hope - I tried to avoid sync() on the 'typical' case ). 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. I don't know - it seems very difficult to fix, maybe leave it for later? I don't think this is a very frequent case. 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. +1 to postpone, there is a workaround ( to put them in a different dir ). 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. Henri, Nacho - is this resolved ? 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. Done. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? I don't think this is important - it's not required by the spec, and we can add it as a replacement module ( or in 3.3.1 ). I can do a merge if you want - shouldn't be difficult. 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Done. 177 Race condition during servlet initialization BugRat Report#2 I would make this LATER. 182 JSP error-page doesn't work with virtual hosts BugRat Report I think this is fixed ( long ago ) in 3.3. 274 request.getUserPrincipal() doesn't work when user is authent It seems Larry noted it is fixed in 3.3, we might have few problems with cert auth ( since this is done by Apache, and I'm not sure it's very well tested ) 437 req.getParameter(name) Ignores charset. always assumes ISO88 This is resolved ( as much as possible - we can't cover all browser bugs ) 461 Use setCharacterEncoding(UTF8) does not change the way get Seems to be closed. 463 Ctx( /examples ): IOException in: R( /examples + + null) No This should be fixed in 3.3, 1253 Frequent Connection reset by peer errors Seems like a difficult bug, we should postpone it to RC2. 1482 Ignored session ids in encoded URLs This is marked as fixed. 1663 Tomcat -SSL problem Nothing we can fix in tomcat about this, but if we find a good way to sign certificates - it would be a good addition to the docs. For testing I do add the cert to the cacerts, I never signed a cert - it should be a way ( but it's not a tomcat bug ) 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after It seems Henri can't reproduce it - we should leave it open maybe we get more info. 3233 exception handling wrt errorpages seems to be incorrect Done. 3486 Session problem (with case insensitive context matching on windows) I believe this is invalid, and if it's valid we shouldn't try to fix it as it may brake something else and affect the security. Costin
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/bufDateTool.java MessageBytes.java
On Sun, 16 Sep 2001, Remy Maucherat wrote: costin 01/09/16 21:56:02 Modified:src/share/org/apache/tomcat/util/buf DateTool.java MessageBytes.java Do you plan to keep the version of the buffers which is in j-t-c/util in sync ? I'll sync them after 3.3 is out, but long term I don't think they'll be in sync. There are many improvements and simplifications we can do in j-t-c, and if mod_jk is going to APR-land, I think it's a good idea to do some nice things with the java side as well. Too much 'maintainance' mode, need some action :-) Costin
Re: Weird Classloaders
On Sat, 15 Sep 2001, Bojan Smojver wrote: Could you file a bug in bugzilla and attach a very simple servlet and instructions on how to reproduce ? It would help a lot. Costin
Re: IIS Connector for TC4.0
On Fri, 14 Sep 2001, jean-frederic clere wrote: Maybe to you, but buddy Costin doesn't like it... :) No I'm sure Costin like the merge, and I like you all comment the following timing : I like the merge, I don't like the idea of moving all jk features over to webapp ( and not on the argument that APR is so difficult that it makes more sense to do that then using APR in jk and adding webapp's features ). 1) Release TC 3.3/4.0 2) Start to think on how to merge AJP14/WARP 3) APRise mod_jk (Adding in a sense you can have a code with/without it via configure would be a lot more work). 4) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation) +1 - that seems a good plan, and we should do it anyway. The result would be some common code we can share. 5) Add the worker concept to mod_webapp +0 on this - with some changes mod_webapp could support all jk workers, but I'm not sure what would be the use to duplicate. We can call the result mod_jk_webapp - and will certainly include all mod_webapp features, but I believe it's much easier ( and better ) to add warp to apr to jk ( rather then add workers, connectors, etc to webapp ). And we can do that with minimal impact on jk stability. Costin
Re: [J-T-C] Apache 2.0 code review required
On Fri, 14 Sep 2001, Justin Erenkrantz wrote: Since you have a common infrastructure via callbacks, I don't think you can take advantage of a lot of the new features in Apache 2.0. Oh, well. -- justin Well, we should be able to. We can just add more callbacks - and make sure the code that is using them checks if the callback is implemented and degrades gracefully. I don't think keeping everything as dumb as the dumbest server is a good idea - but the big problem is making sure those features don't interfere too much with the servlet spec ( see the mod_rewrite discussion ). Costin
Re: Weird Classloaders
On Sat, 15 Sep 2001, Bojan Smojver wrote: - if the jar file is changed, the application will reload (due to some recent fixes there in DependClassLoader), but some resources might not get loaded properly (for instance a properties file from within that jar) What do you mean ( i.e. how do you load the properties ) ? We create a new loader, and getting resources with the new loader should return the new stuff ( I'm not sure for Bundles, maybe they're caching something - need to check ). - if old version of the jar file, or a new jar file with the same binary of the class is returned back to WEB-INF/lib, sometimes the app will come back to normal after an automatic reload (not always though) - if you keep replacing jar file long enough with different versions, it will eventually fail even when loading class files from it and the whole app will stop working (ClassNotFoundException) Again, need more details. I've checked the code in DependClassLoader and (unfortunately) it calls the parent's equivalent methods for getResourceAsStream() and getResource(), where parent is java.net.FactoryURLClassLoader. parent2 is the same as class as parent, but different object (ie. another instance of the same thing). I'm guessing those things are part of the JDK. DependClassLoader is a wrapper around the real webapp loader - it's role is to record dependencies. Parent is the real loader, parent2 is the grand-parent ( the parent of all webapps ). If a resource can be loaded by parent2, it is loaded ( to respect the delegation rules ). If not, we get the resource from parent ( i.e. from the application WEB-INF ). The class is created by DependClassLoader so class deps will also go to DCL ( and we can record them ). URLClassLoader is the standard JDK1.2+ loader. It has some important features besides loading classes - it checks sealing, load the right security context, and many other things that are imporant. You can of course replace it with anything you want - including SimpleClassLoader or replacement. All you need to do is replace LoaderInterceptor with your custom-made one. So, my real question here is, do any of you Sun guys (or any of you with better knowledge of JDK) know what this java.net.FactoryURLClassLoader actually does? Is it kind of 'caching' stuff and then it gets seriously confused when there are changes? Or maybe I'm doing something I'm not supposed to do... If you can provide more details, I can take a look. Reloading seems to work fine for me ( but I'll try again ). And finally, do we just write a replacement for this (probably buggy) method, or is there are known workaround or fix for this? We must first find out which of the buggy methods we need to replace :-) Costin
Re: Weird Classloaders
On Sat, 15 Sep 2001, Bojan Smojver wrote: Remy Maucherat wrote: TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs directly (using JarFile objects). I'm really careful about properly closing these objects when the CL is dumped when reloading. However, there are still problems, at least under Windows (the symptoms are roughly what you describe). So it looks like the problems are with the java.util.jar package. After playing a bit more with the whole thing, it turns out that there is an IOException thrown when bytes are read from java.util.zip.ZipFile$1 (I'm guessing 1 is an internal class in ZipFile which is actually an InputStream - do I see JDK people giving a nod?). The ZipFile object is brand new after jar gets refreshed and yet it seems to be reading something totally bogus data. One other somewhat interesting observation: if the jar grows, the class file cannot be found. If it shrinks, class is found but properties files packed in there are not. Really amusing... Seems like a bug in JDK, if ZipFile is new it shouldn't use the old stuff. It seems the ZipFile uses a native implementation... Can you try with a different VM ? Maybe IBM 1.3 ( well, it can be identical ) ? I think Ant has a good replacement for the whole zip, and we can certainly take a look. Creating a class loader using the different zip is also possilbe, and plugging it in is also easy. However, I would mark this as LATER. The whole thing can take time, and I don't think we can/should put this into 3.3 ( because it'll be new untested code ). Costin
Re: IIS Connector for TC4.0
On Thu, 13 Sep 2001, Pier Fumagalli wrote: Regarding a long-term plan, I heard Costin and Henri talking about refactorying the JK connector APIs, and using APR, but that actually nothing is ready yet (correct me if I'm wrong)... My alleged thought right now goes to a big input in terms of API design from the JK guys, I believe (but that's my personal feeling) that if a major redesign needs to be done in JK land, we can use some of the bases put in place by WebApp and especially APR, to come out with maybe a new/revised improved APR-based module... My view: It should happen only after 3.3 (and 4.0) is released, switching to APR is reasonably easy ( IMHO ), adding warp protocol is doable ( but require some changes in the request representation to use the same struct as the other jk modules ). Integrating WARP and AJP14 seems easy ( technically - there are many common things ), but it'll require some 'negotiation' - and I hope some real community involvment. Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. And of course, I'm happy to see both Pier and Henri are open. Costin
Re: Remaining Tomcat 3.3 Issues
On Thu, 13 Sep 2001, Bill Barker wrote: Re. 7) Since there is only one facade per Request and only one Request per thread, you could avoid synchronized all together by having an instance of SimpleDateFormat in either the Request or the facade. That would just leave ServerCookie using DateTool, where the hit would be minimal. Just me $0.02. +1 Costin - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: RE: Remaining Tomcat 3.3 Issues -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds
Re: IIS Connector for TC4.0
On Fri, 14 Sep 2001, Pier Fumagalli wrote: Anyway, switching to APR is not that easy (IMO), if you want to take advantage of ALL which is provided by APR (I'm deprecating ANSI-C here). This is an incremental process, and can only increase the stability of jk. Refactoring/cleaning of jk - one part will be done by the move to APR ( of course ), there are some optimizations and improvements in the jni connector I am planning ( also after APR is in ), and some of the webapp API ( and docs :-) could also help a lot. DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6 months I got to know APR quite well, on the other hand, you guys have more experience on the different web-servers... We have a working APR-based implementation, let's just put it together in a nice way so that it fits BOTH needs... It doesn't make too much sense. You're saying we should use WebApp because it already uses APR, and port back all the protocols and modules to it. I don't know - if using APR is so difficult that it's easier to port all the modules to webapp rather than replace the C functions with the APR equivalent in jk - then maybe we should thing again about using APR. But my impression so far is that APR is quite easy to use and very close to the current abstractions used in jk. Costin
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Any news on this one James ? Do you have any patch that could add jar:
support to SimpleClassLoader ? We could implement a workaround, but if
possible I would fix this by supporing jar URLs where not available.
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
I'm using IBM's JDK 1.1.8
I feel almost certain that it does not have a jar protocol handler.
I tried your suggestion but I still get the exception:
java.net.MalformedURLException: unknown protocol: jar
at java.lang.Throwable.init(Throwable.java:74)
at java.lang.Exception.init(Exception.java:38)
at java.io.IOException.init(IOException.java:38)
at
java.net.MalformedURLException.init(MalformedURLException.java:38)
at java.net.URL.init(URL.java:201)
at java.net.URL.init(URL.java:222)
Looking at JDK 1.1.8 javadoc it seems that a URL Handler for the protocol
is created:
If this is the first URL object being created with the specified
protocol, a stream protocol handler object, an instance of class
URLStreamHandler, is created for that protocol:
James
==
==
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real problem is not in DependClassLoader, but SimpleClassLoader, where
getResource() is implemented. Even if we 'hack' DCL to not call
getResource(), I think it would be better, as you sugest, to add code to
support the jar protocol.
The problem is in SCL.getResource(), the code is:
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
if( r.zipEntry != null ) {
try {
return new URL(jar:file: +
r.repository.getPath() + !/ +
name);
} catch(java.net.MalformedURLException badurl) {
One thing you can try ( and may work ) is to replace this with
new URL(jar, null, r.repository.getPath() + !/ + name );
This will avoid calling the handlers ( which are used to parse the local
part ).
I agree the right solution is to add the dummy handler ( or a 'real' jar
handler ! ) in the compat package. It must at least parse the URL,
otherwise it'll brake reloading ( since getFile() is used to add the jar
location to the list of files that are checked for modifications ).
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar
protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing,
parent2
was always able to load the class requested. Thus, the resource (i.e.
URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the
parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2
class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Well, I would have prefered to not have this subject opened up... My understanding of the Apache License is that a product/build distributed by ASF should contain only code and libraries that have Apache license or something that is compatible. I agree with most of Craig's argument, as long as we are sure we can indeed distribute those files in the first place ( somone more familiar with apache licensing can answer this ). And I'm not sure I agree with having compile-time dependencies on code that we can't distribute - that's the reason 3.x doesn't depend on JSSE nor J2EE ( even if it includes modules that would enable this functionality ). Also, I believe pieces of code that depend on non-distributable code should be optional - the release should be built to include them, but the code should work fine if they are not present. Costin On Thu, 13 Sep 2001, Remy Maucherat wrote: Craig R. McClanahan wrote: I am not talking about what API's/jar files are required to build Tomcat 4. The only place my tests were used was to determine if the jar file should get copied into $CATALINA_HOME/common/lib when I do a build. The official distribution you build will still contain all the jar files you want. And if someone is building Tomcat 4 from source and follow your directions for building they to will get those jar files copied into common/lib. If they fail to follow your directions for configuring the build.properties file either the build will break or the required jars will not be available at runtime. Hopefully someone building from source is clueful enough to figure that out. This doesn't affect the binary distribution, which is where the support questions come from. I don't see anything wrong with making the _build_ a bit flexible instead of forcing all who build Tomcat 4 into a one size fits all mode. I think that it's very good for big projects, because it will force you to test everything (instead of leaving out parts of the code which may be broken). Example: There was a bug in Catalina with JDK 1.3 and JNDI which was caused by having 'jndi.jar' loaded in the commonCL, which was causing a conflict with the JNDI classes loaded by the system CL. Now, if you allow developers to not have jndi.jar with JDK 1.3, that pretty much guarantees that the bug will be found out much later. Of course, there are a extreme cases, like IMO the JAF and JavaMail. I say it's time to create that 'modules' repository and put these factories there (but that can wait for the next release) :) Remy
RE: Bug in TC 3.3 DependClassLoader
Sorry, I had a lot on my had in the last days.
Bojan - if you want to send a patch, it would be great. If not - I can fix
the bug ( but I would prefer you to send a patch - who knows, maybe later
you'll send another one, the first is allways harder :-)
Costin
On Wed, 12 Sep 2001, Larry Isaacs wrote:
Hi Bojan,
Costin is the expert on this section of code. I need to become
more familiar with it, so I'm willing to take a look. If you can
submit a patch, that would be helpful. If you need to wait for
Costin's advice, I understand. On occasion, I have had to do
the same.
Cheers,
Larry
-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 8:10 AM
To: Tomcat Dev List
Subject: Bug in TC 3.3 DependClassLoader
Since I was playing with distributing all my apps in jars...
In method dependency() of that class, there is a section for jars. It
goes something like this:
if( jar.equals( res.getProtocol() )) {
String fileN=res.getFile();
int idx=fileN.indexOf( ! );
if( idx=0 )
fileN=fileN.substring( 0, idx) ;
f=new File( fileN );
if( debug 0 ) log( Jar dep +f );
if( ! f.exists()) f=null;
}
if( f==null ) return;
Dependency dep=new Dependency();
dep.setLastModified( f.lastModified() );
dep.setTarget( c );
dep.setOrigin( f );
dependM.addDependency( dep );
So if the res is:
jar:file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com
/binarix/wpm/ParseXML.class
then fileN after res.getFile() is:
file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com/bin
arix/wpm/ParseXML.class
and after tossing everything after the bang, it becomes:
file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar
which is NOT a file (a URL maybe?), so f.exists() returns false and f
becomes null. The method dependency() returns without adding the jar in
question to the list of dependencies. Aie!
Maybe there should be another 'file' section inside the 'jar' section to
resolve that URL?
If you guys think that'd work OK, I can write a little patch...
Bojan
RE: Remaining Tomcat 3.3 Issues
My current 'preference' is to use r-uri, as in the main branch ( and how it used to be ). That keeps rewrite working and is consistent with most apache modules. The downside is that we're on the edge of the spec, which require the 'original' URI. However, since HTTP seem to allow proxies to alter (normalize) the URI, on some server the 'original' URI is not available, and the servlet spec covers only the servlet container, not the web server - and we'll keep whatever enter the servlet container unchanged - I believe using r-uri is a decent solution. If the servlet spec would be interpreted to mean 'the URI that the user typed' - then I believe that's impossible to implement anyway ( at least on browser alters that ). I'm not very sure - but beeing consistent across the servers and consistent with what other modules and server-side programs are doing seems a good argument. Costin On Wed, 12 Sep 2001, Larry Isaacs wrote: One of the main aspects of this issue is for me to become informed as to the state of Tomcat 3.3's mod_jk with respect to this. Tomcat 3.3's mod_jk.c has: s-req_uri = r-uri; which, by the statement below, appears to be rewrite enabled. This might explain why it works for Bill. I recall there being a discussion on tomcat-dev a while back about this, but I don't recall the final resolution, or if there was one. Formally establishing this resolution for Tomcat 3.3 was my reason for including item 11. Thanks, Larry -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 3:11 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues mod_jk uses (used?) r-unparsed_uri to preserve encoding. Therefore, any mod_rewrite munging of r-uri is invisible to mod_jk. This is the issue to which Larry is referring, not Apache module ordering. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 2:30 PM | To: [EMAIL PROTECTED] | Subject: Re: Remaining Tomcat 3.3 Issues | | | Re. 11) I use mod_rewrite + mod_jk regularly without problems. The problem | is that the out-of-the-box model order puts mod_jk ahead of mod_rewrite. | The trick to make them play happily together is to simply re-order them in | httpd.conf. Of course, this has the downside that you can't use the file | generated by ApacheConfig verbatim. But if you want advanced functionality, | you have to expect to fiddle with the configuration.
RE: Remaining Tomcat 3.3 Issues
On Wed, 12 Sep 2001, Keith Wannamaker wrote: Then we need to be sure to encode r-uri in the main branch and to change r-unparsed_uri to encode(r-uri) in the 3.2 branch. I am swamped now and will put it on a long todo list.. if anyone beats me to it. Well, I said that would be my preference, but it's a very delicate issue - maybe we should have a vote or discuss it more. The code change is easy, deciding one way or another is the real problem. Costin | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 6:10 PM | To: '[EMAIL PROTECTED]' | Subject: RE: Remaining Tomcat 3.3 Issues | | | | My current 'preference' is to use r-uri, as in the main branch ( and how | it used to be ). That keeps rewrite working and is consistent with most | apache modules.
RE: Remaining Tomcat 3.3 Issues
On Thu, 13 Sep 2001, Ignacio J. Ortega wrote: Please give me some info.. It's possible to use no cookies sessions without using mod_rewrite in apache? I don't know what you mean - mod_jk is taking care of decuding the sessionId, and it support both cookie and URL decoding. I didn't even know that people are using mod_rewrite for that. Maybe to integrate with other session schemes ( used for non-servlet applications ) Costin
Re: [VOTE] Bug Notification E-Mails
+1, Jon has a point. ( I was among those bad guys who sugested the current behavior, mea culpa ) Costin On Mon, 10 Sep 2001, Christopher Cain wrote: I'm going to go ahead and call this, in the name of peace and brotherhood :) - Whenever a bug is entered or modified on Nagoya Bugzilla, should Tomcat-Dev receive a copy of the automatic e-mail notification sent to the assigned developer? [] +1 Tomcat-Dev should definitely be CC'ed a copy of the notifications [] +0 Sure, why not [] -0 I don't really care to see them, but I won't complain if I do :) [] -1 Leave it alone (explain) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: [VOTE] New commiter Ryan Bloom
+1 Costin On Mon, 10 Sep 2001, GOMEZ Henri wrote: I would like to propose Ryan Bloom as commiter in Tomcat, and particulary on jakarta-tomcat-connector. Ryan is one of the dev leader in Apache 2.0 and contributed many patch for both mod_jk and mod_webapp, showing us that connectors avoid politics :) Vote, please - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3
I spent some quality time with emacs and merge, comparing j-t-c and j-t versions of jk. So far things look very good, all fixes in j-t seems to be already in j-t-c. The only big difference ( that makes difficult to comapare ) is ajp13, but it seems we are ok there. Henri - could we undo the ajp13.c changes, for example by copying the current ajp13 from j-t and re-doing the autoconf changes ? Having ajp_common is nice, but I think we would be better if we keep ajp13 unchanged and let ajp14 evolve without having common code with ajp13. The protocols are not backward compatible, and they shouldn't anyway. Only major fixes should be merged back into j-t, the code there is stable and it's far better to keep it that way as it reduces the pressure on j-t-c. You can treat this as a branch - because if we drop j-t/src/native and use j-t-c, then we'll have to create a branch for the stable release. Of course, the nice thing is that most changes in j-t-c/jk will happen in ajp14 and probably a new jni connector ( that I'm planning ), so releasing a j-t-c should be much easier ( it'll have the same stable code as j-t, plus extra features ). BTW, since j-t-c/jk works for both 3.3 and 4.0, it would be nice if we could plan a release of the jk connector ( or at least milestone/alpha or beta ) sometime shortly after 3.3 and 4.0 are out ( so it can rely on the stable environment and be tested with it ) Costin On Mon, 10 Sep 2001, Larry Isaacs wrote: Hi Henri, I appreciate your efforts concerning the connectors. My position is that Tomcat 3.3 needs to have stable Ajp13 connectors for Apache 1.3, IIS, and to the extent we can, Netscape. A connector for Apache 2.0 should come out of jakarta-tomcat-connectors instead of jakarta-tomcat. Given that connectors were part of 3.2.x releases, I'm very reluctant to remove all of them from 3.3. Since we are approaching an attempt to release, I need to impose the restriction on the connectors that no features be added and only safe fixes be applied. I believe this restriction is best imposed on the jakarta-tomcat tree at this time and not jakarta-tomcat-connectors where Apache 2.0 is ongoing. If there are bug fixes in J-T-C that would benefit the J-T connectors, and they are safe and easy to apply, then they are worth considering to port. If one is needed, but may not be safe, please let me know of the issue. Otherwise, don't bother back porting J-T-C changes to J-T. I plan to go ahead and delete the J-T Apache 2.0 support once we know there isn't anything there that we need to port to J-T-C. You may be the best judge as to when the deletion can occur. If you could let me know, or suggest how I might check, I would appreciate it. I don't anticipate doing much, if any, maintenance on the connectors after the Tomcat 3.3 release. So hopefully, this should be a temporary pain, and shouldn't be that painful since the J-T connectors should be stable already (given there is some recent work on input chunking that we hope to have debugged soon, perhaps already. Thanks Keith). If there are issues where I shouldn't consider them stable, please let me know so we can address them. Thanks, Larry -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 4:39 AM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3 +1 Let me comment at little. I'm currently working in porting changes in JT to JTC and from JTC to JT. For example, recent change in AJP13 chunk support in JT are not in JTC and latest stuff for Apache 2.0.26-dev not in JT. Let me say that it's just a nightmare to work on two branches (but that's allready a known problem :) Could we go a step farther and concentrate on just J-T-C. My question is, why not working today only in JTC and make use regular snapshot of JT instead of trying to maintain 2 sets of code ? Pier is allready doing that for mod_webapp and have removed (correct Pier ?) all the connector part from Tomcat 4.0 tree, and is using JTC snapshot of WA at each TC 4.0 release ... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for T omcat 3.3
On Mon, 10 Sep 2001, Keith Wannamaker wrote: I just finished merging all the chunked encoding support for ajp13 into j-t-c and was about to checkin. I'll hold off until we decide about this: | Henri - could we undo the ajp13.c changes, for example by copying the | current ajp13 from j-t and re-doing the autoconf changes ? Having If you have them, just check in. If we do this, the changes will get in anyway ( since we have them in j-t ). Yes, I hate duplication ... Costin
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3
On Mon, 10 Sep 2001, Pier Fumagalli wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: Ryan to became more than just a contributer : This is the third time we agree on something in less than 24 hours. This implies that either I'm getting old, or just plain silly... Now, if you could agree on merging mod_webapp and mod_jk, that would be something... Costin
Re: [VOTE] Bug Notification E-Mails
On Mon, 10 Sep 2001, Pier Fumagalli wrote: Ok, so since I need to try to be the nice guy over here, let's do it this way... It seems apparent that the mailing list want to be notified of bugs (lots of +1 and no -1), so this is a simple one [ ] +1 - I want all messages to a new tomcat-bugs mailing list [X] -1 - I want all messages to tomcat-dev Costin
