[mod_webapp.dsp & mod_webapp.mak] cvs commit
mod_webapp.dsp: add ws2_32.lib define "APR_DECLARE_STATIC" add pr_warp_config.c, pr_warp_network.c, pr_warp_packet.c to source files add mod_webapp.mak mod_webapp.zip
Re: Cert Lockdown - 3.3 Integration
Costin:
You told me in the beginning that if I needed any additional callbacks to let
you know. I think I do, and I'll explain why. If you think I'm on the wrong
track, let me know.
Any arbitrary number of http interceptors can be defined (I think, right?),
each with the ability to bind to a specific external interface (IP addresss).
Any number of these can be secure, since the only real SSL limitation is the
old "one cert per external address" rule. I therefore have only three options
that I see:
1) Create some kind of new attribute for the Http connectors
("promptForKeyPass" or something) and add the appropriate set() method to
Http10Interceptor. This would basically negate the need for a separate module,
but fiddling with Http10Interceptor == not at all tempting.
2) Create a new customer interceptor which loads at a higher level (server or
context) and acts as a kind of "Http Connector Listener". Using the
addInterceptor() callback, it would scan each interceptor loaded and check for
secure Http10Interceptors (or, more specifically, for any secure instances of
PoolTcpConnector), and call the prompt if necessary.
3) Create some kind of new child tag for the Http interceptors. I have no
absolutely no idea how to implement this in the current architecture.
I already pretty much discounted #1 (unless for some reason you like it). #2,
which I think would make sense as a child of , has the benefit of a
little cleaner config file and significantly cleaner code, at a slight cost to
runtime performance. My implementation, which I had already started before #3
occurred to me, would check each interceptor being loaded for "instanceof
PoolTcpConnector.getClass()". If true, then it would check to see it if is
secure. If, it would use the Feliner utility to prompt for the keystore
password, then call the setKeysPass() method with the specified value. I'm not
sure exactly what the performace hit would be for this design in a typical
environment, but it probably wouldn't be that noticable.
If I go with #2, I will need a new callback. The addInterceptor() comments says
that it is called before the new interceptor is initialized, which obviously
wouldn't work for this scenerio. I'll need one that gives me a callback for
_after_ the new interceptor is initialized, so that I can check to see if it is
secure. There are therefore two remaining issues if I go with the second
approach:
1) I need the new callback.
2) I need a new mechanism for checking whether or not the keystorePass was
explicitly specified in the tag, since I will want to skip the prompt for those
particular interceptors. I was thinking of simply adding a boolean field to the
socket factory, isKeypassSet (or whatever), which would get toggled to true in
the setKeysPass() method.
Thoughts?
- Christopher
Re: Cert Lockdown - 3.3 Integration
P.S. What's the difference between engineInit() and engineStart()? They both say "Called when the ContextManger is started", so when in the loading process does each get called? - Christopher
RE: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? ++
-Message d'origine- De : Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Envoyé : lundi 6 août 2001 18:45 À : Tomcat Dev Objet : RE: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? > On Mon, 6 Aug 2001, Loïc Lefèvre wrote: > > > Would/Must the RewriteValve do that? > > > > Well, you can certainly use Valves if you don't mind being tied to Tomcat > 4. But, to implement a controller type mechanism that uses request > dispatchers, a Filter is a much better answer (the only way a Valve can do > the dispatch is to change the Request URI to select the appropriate > servlet). Indeed, I think a filter is better. > > Doing the pattern matching yourself (say, with the jakarta-regexp > package) inside a Filter still avoids all the "thousands of if > statements" you are worried about. (But talking about how to implement > this is straying into TOMCAT-USER topics -- this list is for Tomcat > development related questions). 2nd Indeed ;), but if I've send this mail here (the DEV mailing list), it's because of the catalina/docs/dev/todo.html file and because of the before the end paragraph: Valve Provided Functionality PriorityAction Item Volunteers ... LOW Design and implement a valve that provides functional rt - similar to the Apache server Rewrite family of directives that support transformations on the request URI. [org.apache.catalina.valves.RewriteValve] ... Does this answer (your mail) means this action item has been recently deleted? :( Second question: Will Tomcat allow sharing cookies (I mean path="/")? I think it could be interesting and thus the server.xml don't have a DTD, this could be done like this: < :))) (would be great!) How about it? Third question: Does the servlet specification (2.2 or 2.3) tell all that Tomcat have to do or such idea can become true? :) :) :) :) note: Does this mail stands in the "PROPOSALS FOR TOMCAT" category or is it a best way to do it? :) > > > Loïc Lefèvre > > > > Craig Loïc Lefèvre > note : thanks Pier ;) > note 2: it worked before, I mean the e-mail address > > -Message d'origine- > De : Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Envoyé : samedi 4 août 2001 04:08 > À : '[EMAIL PROTECTED]' > Cc : '[EMAIL PROTECTED]' > Objet : Re: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? > > > > > > On Thu, 2 Aug 2001, Ru, Simon wrote: > > > I wonder if Servlet 2.3's Filter allow partial URLPatternMatching. > Something > > like: > > > > > > timerFilter > > /Controller?action=timer* > > > > If it can, then we can use the Filtering mechanism as a controller to do > > request dispatching. We can avoid having thousands if statements in the > > Controller and we can easily modify the dispatching route without > recompile. > > > > If it can't, is it something worth enhancing? What needs to add to have > that > > capability? Thanks in advance. > > > > While what you propose might be quite nice, Tomcat needs to conform to the > servlet spec's rules for what a legal can contain -- it's > the same for both filter mappings and servlet mappings -- and this pattern > is not legal. > > One strategy would be to match for "/Controller/*" and let the filter look > at the query parameters to decide whether or not to do anything > special. Otherwise, it can just pass the request on unmolested. > > > Simon Ru > > Software Engineer > > (510) 897-5331 > > http://www.worldchain.com > > > > Craig McClanahan > >
Tomcat 4.0b6 Audit
Hi, Would you be interested in the audit report of Tomcat 4.0b6 sources? Loïc Lefèvre note: It's made with Together v4.2.
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers SimpleMapper1.java
larryi 01/08/07 05:08:26
Modified:src/share/org/apache/tomcat/modules/mappers
SimpleMapper1.java
Log:
Added support for Context virtual host aliases. Added a warning to log
if '/' is prepended to the path for a mapping.
Committed a modified version of a patch to add wildcard support for virtual
host names that begin with '*'. The beginning '*' should only be used with
virtual host aliases.
Submitted by: Chris Bryden
Revision ChangesPath
1.9 +74 -12
jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/SimpleMapper1.java
Index: SimpleMapper1.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/SimpleMapper1.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SimpleMapper1.java2001/08/03 02:50:20 1.8
+++ SimpleMapper1.java2001/08/07 12:08:26 1.9
@@ -148,6 +148,7 @@
throws TomcatException
{
map.addMapping( ctx.getHost(), ctx.getPath(), ctx.getContainer());
+map.addMappings( ctx.getHostAliases(), ctx.getPath(), ctx.getContainer());
}
/** Called when a context is removed from a CM - we must ask the mapper to
@@ -158,6 +159,11 @@
{
if(debug>0) log( "Removed from maps ");
map.removeAllMappings( ctx.getHost(), ctx);
+
+Enumeration vhostAliases=ctx.getHostAliases();
+while( vhostAliases.hasMoreElements() )
+map.removeAllMappings( (String)vhostAliases.nextElement(), ctx );
+
// extension mappings are local to ctx, no need to do something
// about that
}
@@ -179,6 +185,7 @@
{
Context ctx=ct.getContext();
String vhost=ctx.getHost();
+Enumeration vhostAliases=ctx.getHostAliases();
String path=ct.getPath();
String ctxP=ctx.getPath();
@@ -195,9 +202,15 @@
case Container.PREFIX_MAP:
// cut /* ( no need to do a string concat for every match )
// workaround for frequent bug in web.xml ( backw. compat )
- if( ! path.startsWith( "/" ) ) path="/" + path;
- map.addMapping( vhost,
- ctxP + path.substring( 0, path.length()-2 ), ct);
+if( ! path.startsWith( "/" ) ) {
+log("WARNING: Correcting error in web.xml for context \"" + ctxP +
+"\". Mapping for path \"" + path + "\" is missing a leading
'/'.");
+path="/" + path;
+}
+String prefixPath=ctxP + path.substring( 0, path.length()-2 );
+ map.addMapping( vhost, prefixPath, ct);
+ map.addMappings( vhostAliases, prefixPath, ct);
+
if( debug>0 )
log("SM: prefix map " + vhost + ":" + ctxP +
path + " -> " + ct + " " );
@@ -236,8 +249,13 @@
break;
case Container.PATH_MAP:
// workaround for frequent bug in web.xml
- if( ! path.startsWith( "/" ) ) path="/" + path;
+if( ! path.startsWith( "/" ) ) {
+log("WARNING: Correcting error in web.xml for context \"" + ctxP +
+"\". Mapping for path \"" + path + "\" is missing a leading
'/'.");
+path="/" + path;
+}
map.addExactMapping( vhost, ctxP + path, ct);
+ map.addExactMappings( vhostAliases, ctxP + path, ct);
if( debug>0 )
log("SM: exact map " + vhost + ":" + ctxP +
path + " -> " + ct + " " );
@@ -261,7 +279,7 @@
/* Request mapping */
-/** First step of request porcessing is finding the Context.
+/** First step of request processing is finding the Context.
*/
public int contextMap( Request req ) {
MessageBytes pathMB = req.requestURI();
@@ -460,7 +478,9 @@
// host -> PrefixMapper for virtual hosts
// hosts are stored in lower case ( the "common" case )
SimpleHashtable vhostMaps=new SimpleHashtable();
-
+// host -> PrefixMapper for virtual hosts with leading '*'
+// host key has '*' removed
+SimpleHashtable vhostMapsWC=new SimpleHashtable();
SimpleHashtable prefixMappedServlets;
SimpleHashtable exactMappedServlets;
@@ -503,7 +523,10 @@
PrefixMapper vmap=this;
if( host!=null ) {
host=host.toLowerCase();
- vmap=(PrefixMapper)vhostMaps.get(host);
+if( host.startsWith( "*" ) )
+vmap=(PrefixMapper)vhostMapsWC.get(host.substring( 1 ));
+else
+vmap=(PrefixMapper)vhostMaps.get(host);
}
// remove all paths starting with path
@@ -555,11 +578,18 @@
prefixMappedServlets.p
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml
larryi 01/08/07 05:14:20
Modified:src/tests/webpages/WEB-INF test-tomcat.xml
Log:
Added a "colonPort" property that includes the colon with the port number,
and updated response matches to use it to in place of ":${port}". This allows
you to avoid false failures when using the default port 80.
Revision ChangesPath
1.41 +10 -9 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- test-tomcat.xml 2001/08/03 02:57:08 1.40
+++ test-tomcat.xml 2001/08/07 12:14:20 1.41
@@ -16,9 +16,10 @@
early tests.
-->
-
+
+
@@ -458,13 +459,13 @@
http://${host}:${port}/index.html";
+expectHeaders="Location:http://${host}${colonPort}/index.html";
returnCode="${http.protocol} 302"
/>
http://${host}:${port}/test/servlet/index.html";
+
expectHeaders="Location:http://${host}${colonPort}/test/servlet/index.html";
returnCode="${http.protocol} 302"
/>
@@ -1338,7 +1339,7 @@
Test for required authorization redirection response
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
@@ -1346,31 +1347,31 @@
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
- http://${host}:${port}/test/aaa/login.jsp"; />
+ http://${host}${colonPort}/test/aaa/login.jsp"; />
cvs commit: jakarta-tomcat/src/admin/test test.jsp
larryi 01/08/07 05:17:45
Modified:src/admin/test test.jsp
Log:
Updated to set the colonPort property to "" if port 80 is used. Avoids
false failures when default handling would expect "http://localhost:80/...";
instead of "http://localhost/...";.
Revision ChangesPath
1.15 +12 -0 jakarta-tomcat/src/admin/test/test.jsp
Index: test.jsp
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/test/test.jsp,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- test.jsp 2001/07/19 06:19:57 1.14
+++ test.jsp 2001/08/07 12:17:44 1.15
@@ -17,6 +17,17 @@
%>
<% out.flush();
if( request.getParameter("target") == null ) return;
+
+ String port = request.getParameter("port");
+ String colonPort;
+ try {
+ colonPort = ":" + port;
+ if ( Integer.parseInt(port) == 80 )
+ colonPort = "";
+ } catch (Exception e) {
+ out.println("ERROR: Invalid port number!");
+ return;
+ }
%>
@@ -33,6 +44,7 @@
+
RE: SimpleMapper1.java
Chris, I have committed my attempt at updating SimpleMapper1. I tried to make it a little more efficient by storing "*hosts" in a separate map. Let me know if it works properly in your situation. Note that the format for adding aliases is (from Costin's update): <... > For it to work, the entries must come before the entries. Cheers, Larry > -Original Message- > From: Chris Bryden [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 06, 2001 10:52 AM > To: [EMAIL PROTECTED] > Subject: RE: SimpleMapper1.java > > > At 10:23 06/08/01 -0400, you wrote: > >Hi Chris, > > > >I've looked at committing your patch. However, in reviewing > >who uses Context.getHost(), I a little nervous about having > >Context.getHost() contain a wildcard. (I think this is what > >your patch implies.) Though I don't think anything bad > >happens currently, Context.getHost() is used in a number > >of locations which would seem as though they aren't expecting > >a wildcard. ContextManager.createRequest() is the one that > >make me the most nervous. > > > >Context does have a vhostAliases field. This would seem > >a more appropriate location for your wildcard string. > >Unfortunately, I don't think vhostAliases can be specified > >in server.xml or apps-xxx.xml yet. You are welcome to look > >into adding that. I'll try to find time if you can't. > > I agree, that patch was really just a bit of a hack to get me > out of a > tight spot. I did see a few references to vhostAliases as I > was looking > through and thought that It would probably be the better > place for this > sort of thing. > > I'll try to make some time this week to have a look at adding alias > specifications to server.xml or apps-whatever.xml this week > if you like... > > > >Once that is done, your patch and a simple update to > >SimpleMapper1.addContext() should get the behavior you desire > >without putting a wildcard in Context.getHost(). > > sounds good to me. I'll let you know how I get on > > Regards, > > Chris > > > > > > -Original Message- > > > From: Chris Bryden [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, July 31, 2001 10:07 PM > > > To: [EMAIL PROTECTED] > > > Subject: SimpleMapper1.java > > > > > > > > > > > > Hi, > > > > > > I didn't get a response from the last mail I sent on this > > > subject, but I > > > hope I could borrow a few minutes of your time to at least > > > point me in the > > > direction of the relevant documentation on virtual hosts > in tomcat... > > > > > > I am using > > > > > > Apache 1.3.20 and Tomcat 3.3 on Linux 2.4.5 > > > > > > We use a large number of virtual hosts in apache of the form > > > xyz.subdomain.ourdomain.com. They all point to the same > > > context, with the > > > xyz art of the name being used by the webapp to determine > how it was > > > accessed and set content accordingly... > > > > > > In the apache configuration, the virtual host is defined using the > > > ServerAlias directive and a wildcard, however, tomcat seems > > > to need the > > > Host tags in server.xml to exactly match the host header.. > > > > > > I was under a lot of pressure to get this working at the > > > time, so hacked > > > SimpleMapper1.java so that I could put a wildcard in my > Host tag in > > > server.xml according to the attached patch... > > > > > > The question I have is, what is the future for defining > > > wildcard hosts in > > > the Host tags in server.xml..? I would be more than happy to > > > help with any > > > development in this area, but I need to know what the plans > > > are for virtual > > > host definitions in server.xml > > > > > > If the reason that I didn't get a reply to my earlier mail is > > > that I am > > > being a complete muppet, please could you direct me to the > > > relevent docs so > > > I can demuppetize :-) > > > > > > Kind Regards, > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Cert Lockdown - 3.3 Integration
On Tue, 7 Aug 2001, Christopher Cain wrote: > P.S. > > What's the difference between engineInit() and engineStart()? They both > say "Called when the ContextManger is started", so when in the loading process > does each get called? EngineInit is called after you add all the initial modules. The startup sequence is: 1. new ContextManager() 2. add all the modules you need ( you can add modules later, but you need a basic set to get something stable ) 3. call cm.init(). At this stage engineInit() is called. Before init() the modules are notified on addInterceptor(), contextState() ( if a context is added to the server before init ). 4. The server is in a "stable" state, ready to opreate. It now starts setting up contexts. 5. For each context, addContext() and contextInit() are called 6. cm.start() 7. engineStart() hooks is called, announcing the server is ready to take requests ( because all contexts are now in stable state ). 8. Engine moves to running state, everything is operational. Costin
Re: Catalina Startup Hook (actually, both camps should read this:-)
on 8/6/01 10:31 PM, "Christopher Cain" <[EMAIL PROTECTED]> wrote: > But I have to say, from > someone without a great deal of personal investment in either tree in > particular, ALL of you people should be damn proud. Wouldn't it be amazing if they had just worked together though? All that great talent working on two different (yet the same!) things seems like such a shame to me! :-) -jon
Tomcat-Users mailing list...
Folks... We need someone from the Tomcat 3.x developers to monitor and answer questions on the tomcat-user mailing list. There are tons of questions related to mod_jk, tons of questions related to bugs that seem to be fixed in bugzilla but are constantly reappearing in later builds. I and Craig (thank god he exists) are answering some of them, but at least in my case I don't have enough knowledge of the codebase to see whether some of them are real bugs or just something that users are doing wrong... Just a FYI... Pier
Re: Tomcat 4.0b6 Audit
On Tue, 7 Aug 2001, Loïc Lefèvre wrote: > Hi, > Would you be interested in the audit report of Tomcat 4.0b6 sources? > > Loïc Lefèvre > > note: It's made with Together v4.2. > > Very much so! Craig
Re: Tomcat-Users mailing list...
I've become pretty knowledgable on the whole startup process over the past week or so, with some help from Costin and in examining the source. While I don't have the broad overall container knowledge that the core developers have, I'll try and help out with any of the startup/loading related questions. I'm not currently subscribed to the user list, but I'll so now and do what I can. - Christopher Quoting "Pier P. Fumagalli" <[EMAIL PROTECTED]>: > Folks... We need someone from the Tomcat 3.x developers to monitor and > answer questions on the tomcat-user mailing list. > > There are tons of questions related to mod_jk, tons of questions related > to bugs that seem to be fixed in bugzilla but are constantly reappearing > in later builds. > > I and Craig (thank god he exists) are answering some of them, but at > least in my case I don't have enough knowledge of the codebase to see whether > some of them are real bugs or just something that users are doing wrong... > > Just a FYI... > > Pier
RE: Tomcat-Users mailing list...
I subscribed, and will try to answer what I can with the time available. Cheers, Larry > -Original Message- > From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 07, 2001 1:01 PM > To: tomcat dev jakarta.apache.org > Subject: Tomcat-Users mailing list... > > > Folks... We need someone from the Tomcat 3.x developers to monitor and > answer questions on the tomcat-user mailing list. > > There are tons of questions related to mod_jk, tons of > questions related to > bugs that seem to be fixed in bugzilla but are constantly > reappearing in > later builds. > > I and Craig (thank god he exists) are answering some of them, > but at least > in my case I don't have enough knowledge of the codebase to > see whether some > of them are real bugs or just something that users are doing wrong... > > Just a FYI... > > Pier >
Problem in JasperLoader ?
Hi all,
I am using a RequestDispatcher to do a cross context include to a JSP. The
problem is there seems to be a problem in the JasperLoader implementation.
Let me explain quickly the configuration :
contextA :
- does a
getContext("/contextB").getRequestDispatcher("path/file.jsp").include(request,
response) call
contextB :
- contains the path/file.jsp file that contains an @page
import="com.xo3.MyClass" and of course uses the MyClass class...
- contains the WEB-INF/classes/com/xo3/MyClass
When the dispatch occurs, the JSP file is compiled and executed, but it
complains that it can't load the MyClass class. I suspect the following
lines in src\jasper\src\share\org\apache\jasper\servlet\JasperLoader.java :
// Class is in a package, delegate to thread context class loader
if( !name.startsWith(Constants.JSP_PACKAGE_NAME) ) {
ClassLoader classLoader = null;
if (System.getSecurityManager() != null) {
classLoader =
(ClassLoader)AccessController.doPrivileged(privLoadClass);
} else {
classLoader =
Thread.currentThread().getContextClassLoader();
<
}
clazz = classLoader.loadClass(name);
if( resolve )
resolveClass(clazz);
return clazz;
}
The problem here is that from what I understand from the source the current
thread context class loader is never changed from contextA to contextB. So
that when JasperLoader executes in contextB, it actually tries to load
classes using the class loader of contextA.
Did I miss something in configuration or is this a bug ?
Best greetings,
Serge Huber.
[EMAIL PROTECTED]
RE: Velocity and JSP speed testing...
Sorry man, I can't make a really good flame war when I agree with Jon. But there is still hope: we still flame each other from time to time (even if on other lists). Nothing as blazing than that one you remember, but still... =:o) Have fun, Paulo > -Original Message- > From: Christopher Cain [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 07, 2001 6:24 AM > To: [EMAIL PROTECTED] > Subject: Re: Velocity and JSP speed testing... > > > Totally OT, bandwidth-wasting, irrelevant musings P.S. ... > > Where did that Paulo Gaspar cat go? That guy was always > interesting in a flame > war, especially with Jon involved. Man ... dude did NOT like Jon, > but he sure > loved Velocity. I wonder he went ... I really miss those days, > back when we > were all so young and innocent ... it was a simpler time ;-) > > Anyway, Jon, I always thought that you should have used some of > those flame > posts from Gaspar for some really sweet Velocity advocacy, maybe > in your mag > articles and web site and stuff. I can hardly think of a more compelling > advertisement for Velocity than one of those, "Jon is in > insufferable ass, but > I wouldn't use any other solution than Velocity." That speaks volumes. > > I really do miss that Gaspar guy though ... we liked him :-) > > - Christopher >
Re: Tomcat-Users mailing list...
Unfortunately my yahoo account has a space limit, so I can't subscribe. If someone can tell me how to tell list server to subscribe in "write only mode" ( many list servers allow this option ) - I could help a bit. ( I suppose you may have 4-5 mails from [EMAIL PROTECTED] in your "spam" list, I tried to answer few mails but they never arrived to the list ). Now that 3.3 is almost done I'll have a bit more free time to work on docs and help users - most of us have day jobs, so prioritizing things is important... Costin On Tue, 7 Aug 2001, Pier P. Fumagalli wrote: > Folks... We need someone from the Tomcat 3.x developers to monitor and > answer questions on the tomcat-user mailing list. > > There are tons of questions related to mod_jk, tons of questions related to > bugs that seem to be fixed in bugzilla but are constantly reappearing in > later builds. > > I and Craig (thank god he exists) are answering some of them, but at least > in my case I don't have enough knowledge of the codebase to see whether some > of them are real bugs or just something that users are doing wrong... > > Just a FYI... > > Pier >
RE: Tomcat-Users mailing list...
I'll subscribe again too and also answer when time permits.. > -Original Message- > From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 07, 2001 7:01 PM > To: tomcat dev jakarta.apache.org > Subject: Tomcat-Users mailing list... > > > Folks... We need someone from the Tomcat 3.x developers to monitor and > answer questions on the tomcat-user mailing list. > > There are tons of questions related to mod_jk, tons of questions > related to > bugs that seem to be fixed in bugzilla but are constantly reappearing in > later builds. > > I and Craig (thank god he exists) are answering some of them, but at least > in my case I don't have enough knowledge of the codebase to see > whether some > of them are real bugs or just something that users are doing wrong... > > Just a FYI... > > Pier > >
Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT
Title: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT .-. | Steven Velez oo| | Software Engineer /`'\ | alventive (\_;/) | 678-202-2226 querystring.patch
Re: Problem in JasperLoader ?
Quoting Serge Huber <[EMAIL PROTECTED]>:
> Hi all,
>
> I am using a RequestDispatcher to do a cross context include to a JSP.
> The
> problem is there seems to be a problem in the JasperLoader
> implementation.
> Let me explain quickly the configuration :
>
> contextA :
> - does a
> getContext("/contextB").getRequestDispatcher("path/file.jsp").include(request,
>
> response) call
I just checked and cross-context includes and forwards have a problem.
You can use a redirect as a workaround with b6.
Remy
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
craigmcc01/08/07 13:53:06
Modified:jasper/src/share/org/apache/jasper/logging
DefaultLogger.java
jasper/src/share/org/apache/jasper/servlet JspServlet.java
Log:
The current implementation of logging in Jasper (using JasperLogger)
causes a background thread to be created per declaration,
instead of once per web app, due to the changes needed to deal with
sealing violation problems. Change this to use DefaultLogger instead,
which uses the request processing thread. Messages continue to be logged
to the servlet context log, so there will be no visible behavior
difference (other than elimination of useless daemon threads).
PR: BugTraq #4488877
Submitted By: Tony Ng <[EMAIL PROTECTED]>
Revision ChangesPath
1.2 +38 -0
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/logging/DefaultLogger.java
Index: DefaultLogger.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/logging/DefaultLogger.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DefaultLogger.java2000/08/12 00:52:11 1.1
+++ DefaultLogger.java2001/08/07 20:53:06 1.2
@@ -58,6 +58,7 @@
import java.io.Writer;
import java.io.IOException;
+import javax.servlet.ServletContext;
/**
* Trivial logger that sends all messages to the default sink. To
@@ -74,12 +75,45 @@
newline = separator.toCharArray();
}
+
+/**
+ * Default constructor leaves the debug output going to the
+ * default sink.
+ */
+public DefaultLogger() {
+super();
+}
+
+
+/**
+ * The servlet context we are associated with.
+ */
+protected ServletContext servletContext;
+
+
+/**
+ * Construct a logger that writes output to the servlet context log
+ * for the current web application.
+ *
+ * @param servletContext The servlet context for our web application
+ */
+public DefaultLogger(ServletContext servletContext) {
+super();
+this.servletContext = servletContext;
+}
+
+
+
/**
* Prints log message to default sink
*
* @parammessage the message to log.
*/
protected void realLog(String message) {
+if (servletContext != null) {
+servletContext.log(message);
+return;
+}
try {
defaultSink.write(message);
defaultSink.write(newline);
@@ -97,6 +131,10 @@
* @paramt the exception that was thrown.
*/
protected void realLog(String message, Throwable t) {
+if (servletContext != null) {
+servletContext.log(message, t);
+return;
+}
try {
defaultSink.write(message);
defaultSink.write(newline);
1.20 +3 -1
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- JspServlet.java 2001/07/17 04:21:14 1.19
+++ JspServlet.java 2001/08/07 20:53:06 1.20
@@ -96,6 +96,7 @@
import org.apache.jasper.compiler.TldLocationsCache;
import org.apache.jasper.logging.Logger;
+import org.apache.jasper.logging.DefaultLogger;
import org.apache.jasper.logging.JasperLogger;
/**
@@ -253,7 +254,8 @@
this.serverInfo = context.getServerInfo();
// Setup logging
-Constants.jasperLog = new JasperLogger(this.context);
+//Constants.jasperLog = new JasperLogger(this.context);
+Constants.jasperLog = new DefaultLogger(this.context);
Constants.jasperLog.setName("JASPER_LOG");
Constants.jasperLog.setTimestamp("false");
Constants.jasperLog.setVerbosityLevel(
RE: Velocity and JSP speed testing...
> He is over on the Velocity lists being a pain in the ass still. :-) > > I just love him. I love you too Jon. > Our last flame war was about me wanting to get rid of the dynamic > logging in > Velocity and just make a dependency on Log4J. Eventually, I think he just > gave up. Now that Ceki has the 25k .jar file, it is no contest. Yes, after a few servings of Jon's usual "delicate" approach, Jason van Zyl made a single post where he made sense of it all. Sometimes Jon is right - he just has some trouble explaining it. (He tends to explode something in the process.) =;o) Have fun, Paulo > -Original Message- > From: Jon Stevens [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 07, 2001 6:31 AM > > > on 8/6/01 9:24 PM, "Christopher Cain" <[EMAIL PROTECTED]> wrote: > > > Totally OT, bandwidth-wasting, irrelevant musings P.S. ... > > > > Where did that Paulo Gaspar cat go? That guy was always > interesting in a flame > > war, especially with Jon involved. Man ... dude did NOT like > Jon, but he sure > > loved Velocity. I wonder he went ... I really miss those days, > back when we > > were all so young and innocent ... it was a simpler time ;-) > > > > Anyway, Jon, I always thought that you should have used some of > those flame > > posts from Gaspar for some really sweet Velocity advocacy, > maybe in your mag > > articles and web site and stuff. I can hardly think of a more compelling > > advertisement for Velocity than one of those, "Jon is in > insufferable ass, but > > I wouldn't use any other solution than Velocity." That speaks volumes. > > > > I really do miss that Gaspar guy though ... we liked him :-) > > > > - Christopher > > He is over on the Velocity lists being a pain in the ass still. :-) > > I just love him. > > Our last flame war was about me wanting to get rid of the dynamic > logging in > Velocity and just make a dependency on Log4J. Eventually, I think he just > gave up. Now that Ceki has the 25k .jar file, it is no contest. > > :-) > > p.s. Below is a recent privately sent email that I got about the > JDJ article > I wrote...name/company removed to protect this fine enlightened > individual. > :-) > > -jon >
Addition of 'dirty' field to Session interface
Hi, In order to support persistent failover, we have written our own Store class that writes session data to DB of our choice. We decided to use maxIdleBackups as that will save the data periodically to disk without getting rid of it in memory. PersistentManagerBase.processMaxIdleBackups() writes the session data to DB at periodical intervals irrespective of session has changed or not. I think it will be very valuable addition to add getDirty() and setDirty(boolean) methods to the Session interface. When PersistentManagerBase saves the session contents, it can set dirty bit to false and from then onwards save the session only if the bit is set to true. Selected setXXX methods in StandardSession will set the dirty bit to true indicating that Session data has changed and it needs to be saved in the next save cycle by PersistentManager. Let me know what you guys think of this useful optimization. I can contribute the code if necessary. -- Cheers!
Re: Addition of 'dirty' field to Session interface
--- Vishy Kasar <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In order to support persistent failover, we have written our own
> Store
> class that writes session data to DB of our choice. We decided to use
> maxIdleBackups as that will save the data periodically to disk
> without
> getting rid of it in memory.
> PersistentManagerBase.processMaxIdleBackups() writes the session data
> to
> DB at periodical intervals irrespective of session has changed or
> not.
> I think it will be very valuable addition to add getDirty() and
> setDirty(boolean) methods to the Session interface. When
Wouldn't this require a change to the Servlet API? This is probably
not the right list for that :)
> PersistentManagerBase saves the session contents, it can set dirty
> bit
> to false and from then onwards save the session only if the bit is
> set
> to true.
>
> Selected setXXX methods in StandardSession will set the dirty bit to
> true indicating that Session data has changed and it needs to be
> saved
> in the next save cycle by PersistentManager.
But what happens if in one servlet you put an object in the session,
then later, after the session has been saved, another request is
handled by a different servlet that get's the object from the session
and changes its state.
In this case, you have to have the cooperation of the application
developer to call setDirty(true) so you know something has changed.
If you are going to rely on developers following some kind of
convention, it could probably be done without changes to the spec.
What about asking them to call setAttribute("Dirty","True") whenever
they make a change? Your PersistentManager could then remove the
attribute after a save. (not that I believe they would do this
consistently any more than they will call setDirty(true) )
Is there something I am missing?
Jim
>
> Let me know what you guys think of this useful optimization. I can
> contribute the code if necessary.
>
> --
> Cheers!
>
>
>
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
TC3.2: TCPPoolConnector leaks in thread pool (bug #3033)
Hi, I have just posted bug #3033 to nagoya, about a bug in the TCPPoolConnector. When running TomCat in standalone mode, after some time I notice the message ThreadPool: Pool exhausted with 100 threads. over and over again in the error log file. In practice this causes TomCat to be out of order. The problem can be demonstrated with the attached simple servlet. The servlet has a main() method, so that it can call itself from the command line. It spawns 10 threads, which keep calling the servlet in a never ending loop. Exceptions in both client and server are forced. After some minutes you will notice the "Pool exhausted" message in a default TomCat configuration, although the number of clients is 10 and the number of threads is 100. Any suggestions welcome, Jochen LoadServlet.java
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java
remm01/08/07 17:32:02
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
Log:
- Cross contexts include and forwards were broken because the context
class loader wasn't appropriately set. Now, check if the current context class
loader is the same as the one in the Catalina Context's loader. If it's not, the
old context class loader value is saved, the Catalina Context class loader is
set as the context class loader, and after the wrapper has been allocated
and invoked, the old context class loader value is restored.
Bug reported by Serge Huber .
Revision ChangesPath
1.25 +20 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ApplicationDispatcher.java2001/08/01 03:04:04 1.24
+++ ApplicationDispatcher.java2001/08/08 00:31:54 1.25
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.24 2001/08/01 03:04:04 craigmcc Exp $
- * $Revision: 1.24 $
- * $Date: 2001/08/01 03:04:04 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.25 2001/08/08 00:31:54 remm Exp $
+ * $Revision: 1.25 $
+ * $Date: 2001/08/08 00:31:54 $
*
*
*
@@ -108,7 +108,7 @@
* javax.servlet.ServletResponseWrapper.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.24 $ $Date: 2001/08/01 03:04:04 $
+ * @version $Revision: 1.25 $ $Date: 2001/08/08 00:31:54 $
*/
final class ApplicationDispatcher
@@ -337,7 +337,6 @@
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet exception occurs
*/
-
public void forward(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
@@ -591,6 +590,18 @@
private void invoke(ServletRequest request, ServletResponse response)
throws IOException, ServletException {
+// Checking to see if the context classloader is the current context
+// classloader. If it's not, we're saving it, and setting the context
+// classloader to the Context classloader
+ClassLoader oldCCL = Thread.currentThread().getContextClassLoader();
+ClassLoader contextClassLoader = context.getLoader().getClassLoader();
+
+if (oldCCL != contextClassLoader) {
+Thread.currentThread().setContextClassLoader(contextClassLoader);
+} else {
+oldCCL = null;
+}
+
// Initialize local variables we may need
HttpServletRequest hrequest = null;
if (request instanceof HttpServletRequest)
@@ -716,6 +727,10 @@
(sm.getString("applicationDispatcher.deallocateException",
wrapper.getName()), e);
}
+
+// Reset the old context class loader
+if (oldCCL != null)
+Thread.currentThread().setContextClassLoader(oldCCL);
// Rethrow an exception if one was thrown by the invoked servlet
if (ioException != null)
javascript won't work in tomcat
Hello, I have very simple html page have JavaScript, it works find if load from file system, buy the java script won't work if I load it from tomcat, does anyone know the reason or have similar problem? Thanks a lot David Cao - Energizing by Thinking -Original Message- From: Roytman, Alex [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 07, 2001 1:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Catalina: How to specify factory class name for a Resource in server.xml Hello, I am writing several jndi factories for catalina's JNDI implementation and I am trying to figure out how to specify factory class for a resource. The only sample I found was and factory class for type="javax.sql.DataSource" is hard coded. How do I specify factory class for my resource? Thank you very much Alex Roytman
Re: TC3.2: TCPPoolConnector leaks in thread pool (bug #3033)
One solution would be to update to 3.2.3 - if I remember corectly this has been fixed. Costin On Wed, 8 Aug 2001, Wiedmann, Jochen wrote: > > Hi, > > I have just posted bug #3033 to nagoya, about a bug in the > TCPPoolConnector. When running TomCat in standalone mode, > after some time I notice the message > > ThreadPool: Pool exhausted with 100 threads. > > over and over again in the error log file. In practice > this causes TomCat to be out of order. > > The problem can be demonstrated with the attached simple > servlet. The servlet has a main() method, so that it can > call itself from the command line. It spawns 10 threads, > which keep calling the servlet in a never ending loop. > Exceptions in both client and server are forced. After > some minutes you will notice the "Pool exhausted" message > in a default TomCat configuration, although the number > of clients is 10 and the number of threads is 100. > > Any suggestions welcome, > > > Jochen > >
RE: Velocity and JSP speed testing...
Quoting Paulo Gaspar <[EMAIL PROTECTED]>: > Sorry man, I can't make a really good flame war when I agree > with Jon. That's okay, buddy. You're back, and that's the important thing. We missed you is all ;-) - Christopher
Re: Tomcat-Users mailing list...
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > > If someone can tell me how to tell list server to subscribe in "write only > mode" ( many list servers allow this option ) - I could help a bit. > > ( I suppose you may have 4-5 mails from [EMAIL PROTECTED] in your > "spam" list, I tried to answer few mails but they never arrived to the > list ). You are... Already. Pier
Service code...
Just a FYI... For the next beta of TC4, I'd rather improve the WebApp connector than the Service code... Does it collide with some priority/ schedules of someone, I'd really shoot for WebApp first and Service then... Pier
[tomcat 4] using jikes to compile jsp's
has anybody tried using jikes to compile jsp's with tomcat 4 on windows recently? i have. it barfed :) basically what's happening is the classpath is getting messed up. more specifically, the entry in the classpath that points at WEB-INF/classes/ is getting messed up. the classpath ends up looking like this: ...;/c:/tomcat/webapps/myWebapp/WEB-INF/classes/;... it's the beginning "/" that appears to be screwing jikes up. apparently javac can handle this kind of path, but jikes can't. it looks like the classpath for jsp's is being set in WebappLoader.setClasspath(), which get's respositories (which are URL's) from an instance of WebappClassLoader. then, for URL's that are of the "file" scheme, it pulls of the file part and adds this to the classpath. in the case of the above example, one of these URL's will be "file:/c:/tomcat/webapps/myWebapp/WEB-INF/classes/". i can think of some potential hacks... but i was hoping someone who knows this code better would have some ideas on how this might be fixed or worked around :) or, is this a problem with jikes itself? tia, -kevin.
