Re: mod_jk 1.2.14.1 Released?
Where are the zip/tar balls of the sources for those wishing to jump the gun? [I assume they're not changing at this point...] Jean-frederic Clere wrote: Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.14.1 Released?
Was 1.2.14.1 ever officially released? If not, will it be soon? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk 1.2.14 source
NormW wrote: Good evening, AFAIK there is no 1.2.14 source 'bundle', but rather it exists in 'head', which is still with CVS rather than SVN. Check out the Jakarta Tomcat pages for the CVS CLI commands to get the latest mod_jk source. Should look similar to the following: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co jakarta-tomcat-connectors cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic logout Ah... I thought this had moved to SVN like Apache itself. CVS is still better supported by IDEs than SVN, so this should actually make Josh's task easier. -- Jess Holle Jess Holle wrote: Fenlason, Josh wrote: Where could I find the 1.2.14-dev source bundle? Thanks. , Josh. I'm betting you have to snag it with an SVN client. Am I right? If so, is it just a simple/default "latest" setting to get this? -- Jess Holle - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_jk 1.2.14 source
Fenlason, Josh wrote: Where could I find the 1.2.14-dev source bundle? Thanks. , Josh. I'm betting you have to snag it with an SVN client. Am I right? If so, is it just a simple/default "latest" setting to get this? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of code
Out of curiosity, is a mod_jk 1.2.14 vote set to occur at some point? Or are there known issues with 1.2.13 at this point? [My understanding is that the odd-even release # model is now being followed -- correct?] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/APR benchmark results
Would we expect anything markedly different with Apache 2 worker rather than prefork? This would seem a bit more of an apples-to-apples comparison (i.e. comparing multi-threaded low-process count servers). Also how many simultaneous workers (threads/processes/whatever) were allowewd in each case? [I stopped using prefork on all platforms when moving to Apache 2.] -- Jess Holle Mladen Turk wrote: Hi, Here are the brief results for Tomcat HEAD: Server Threads Pause (ms) Error(%) Rate (req/sec) Apache2.0.49500 1000 1.74 124.2 Http11Protocol 500 1000 0.20 139.5 Http11AprProtocol 500 1000 0.00 266.9 Tests has been run on SLES9/64-Bit/Java-1.5.0_02-b09 Client was WINXP/SP2 running JMeter and Peter Lin's test plans. Those tests simulate 500 concurrent users connecting to a 150 maxClient server. The connection is keep-alive with 1 second delay between the requests. So our JNI/APR http connectors is almost twice faster then both Tomcat standard http connector and Apache2/prefork. What is more important is that the error number is zero, meaning there were no refused connections, because of keepalive connection poller. Regards, Mladen. - 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: Tomcat and APR
Overall this seems well and good as long as this is not the default in 5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a good JVM without native code). To play devil's advocate for a moment, however, would use of Java NIO potentially make more sense for Tomcat, i.e. to take a step forward in terms of performance, etc, without requiring native code? [I'm not saying NIO covers all the bases APR would or is as fast. Rather wondering whether performance efforts should not remain in the pure Java space until that is truly exhausted.] -- Jess Holle Remy Maucherat wrote: Hi, This has been hinted for a while ;) The purpose of this email is to propose using APR (Apache Portable Runtime) as the network IO used by Tomcat, instead of the JVM's IO. This will provide the following benefits (some small, others more significant): - zero GC IO API (APR is not object based) - flexible handling of socket reads/writes using pollers and non blocking IO - sendfile support Which will allow: - better scalability when using HTTP/1.1 keepalive, by eliminating the need for tying a thread blocked on an IO read (one or more (one on Unix, plenty on Windows) pollers will be used instead); this will allow certain single machine servers which couldn't use keealive in order to limit the amount of threads (to be able to have more simultaneous users) to benefit from the (large) performance benefits of keepalive - better performance and easier configuration when using AJP: one of the issues of AJP at the moment is that the number of AJP processors in Tomcat must be equal to the number of processors on the front end native servers, or keepalive has to be disabled (resulting in performance degradation); the benefit for AJP seems to actually be greater than for HTTP (special thanks to Mladen who explained to me the situation in detail) - efficient static file serving (not done yet) - (likely) better performance and reliability on free JVMs - probably slightly better performance (over NIO, Mladen measured 10%, while I measured 0%; as classic IO is a bit slower generally, I expect a small improvement); unfortunately, maximum throughput suffers (maximum throughput is measured by ab with keeplive enabled on localhost), as we cannot just block on the read until the next request comes; the benchmarks I use usually suck anyway ;) - SSL support through OpenSSL (not done right now) - access to certain useful native functions (detailed system status information, random data generation, etc) This would effectively make Tomcat more appealing to the lower end servers and, hopefully, web hosting companies (due to lower resource usage). Large sites would likely also benefit a little from the AJP improvements. The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do). Now the tricky points: - is it appropriate for 5.5 ? I'd say yes, as it will be a separate independent implementation - will require APR, and a small JNI friendly wrapper library tentatively named libtcnative by Mladen (Windows binaries - and likely others - will be provided); portability should be good - we'll need to improve performance (and especially fix the kludge that is currently used to decide if a socket should be put inside a poller) Comments ? Rémy - 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: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JDTCompiler.java
Despite advancements in speed, etc, the notion of Eclipse or Tomcat or anything else using it until it is both faster *and* as robust as javac is a bit strange. The notion that Eclipse depends upon it to the point that it's Java 5 support is held up by JDT development is particularly strange to me. javac is not a panacea but it support Java 5 quite nicely right now. [I'm using NetBeans 4, so I'm unaffected by Eclipse's move -- it just baffles me.] -- Jess Holle Remy Maucherat wrote: Tim Funk wrote: Is there a reason _jspx_dependants is a Vector - why not an ArrayList? This would remove the syncs inside of Vector. I don't know. It probably wouldn't hurt. It won't help me with my ECJ bug, however ;) Rémy - 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: [ANN] JK 1.2.10 Released
Mladen Turk wrote: Günter Knauf wrote: Hi Mladen, Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it H Metrowerks used to be good back when I used it (early PowerPC Mac days). It was stricter than most compilers -- perhaps even causing some warnings to be errors. I understand how this can cause issues building open source software, but for my own development I always appreciated the compiler being stricter than others -- it made porting a lot easier. [I now use Java and am dismayed at what C compilers let you get away with.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Remy Maucherat wrote: Linux is such a mess in large part because people who write software treat it as second-class - 'let someone else deal with compiling binaries for linux, I'll only do it for windows and mac'. As a result linux distributions have the freedom to mess up and 'personalize' each package to their own taste ( we all know how painful it is to switch from one distro to another or use/support 2 distros - each file is in a different place - this is called lock in ). On windows - you can get nice binaries, with installer and everything else you would expect - distributed by the package authors. Even if we produce binaries, distributions will use their own. People also tend to use what their distribution provides. I wish there was a way to convince distros not to do their own disparate things -- with Tomcat, Apache, etc, etc. It fragments documentation, support, and automation of configuration, etc, and really is a pity. It would be nice if everything was consistently installed in a standard layout and then symbolic links created into the standard layout from other locations as the distros saw fit -- especially if there was a "repair" script to fix these if needed. Having the location of the original copies of things vary is highly annoying for anyone trying to communicate with those on disparate distros and platforms. On the other hand, it seems that distros tend to feel some need to do things that seemingly should be common/standard differently (they're almost Microsoft like in that respect...) -- and people obviously use the path of least resistance, i.e. whatever their distro provides. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav Shapira wrote: Hola, If a patch was submitted and committed, I think the name of the submitter should be mentioned. I usually put the name of the committer only in the changelog. That seems to be consistent with past practice. The bugzilla issue (linked from the changelog when possible) has the name of the submitter(s). If they add themselves as @authors in the code, I also leave that in. However, if we want to put submitter names in the changelog, I'm fine with that and will start doing so from now on. The standard practice for the Apache httpd project is to mention both the patch submitter and committer in the change log. As a sometime patch submitter, I appreciate this. -- Jess Holle
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspFactoryImpl.java HttpJspBase.java
[EMAIL PROTECTED] wrote: remm2005/03/21 07:38:13 Modified:jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java TldLocationsCache.java JspConfig.java JspRuntimeContext.java SmapUtil.java JspReader.java Compiler.java jasper2/src/share/org/apache/jasper EmbeddedServletOptions.java jasper2/src/share/org/apache/jasper/servlet JspServlet.java JspServletWrapper.java jasper2/src/share/org/apache/jasper/xmlparser UCSReader.java ParserUtils.java UTF8Reader.java jasper2/src/share/org/apache/jasper/runtime JspFactoryImpl.java HttpJspBase.java Log: - Per instance loggers in Jasper. Thanks, Remmy. I'll have to give this a try once 5.5.9 is out. [Yes, I'm lazy and won't be building/patching my own before this given that I'm on vacation with the family.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
[EMAIL PROTECTED] wrote: +Changes in JK 1.2.8 +* cachesize has changed from unlimited to limited, so it's basically a pool of connections + with recycle timeout like in mod_proxy for Apache 2.2. Is the cachesize setting for a per-worker-process pool, so the real pool size is (# of worker processes)*(cachesize)? This is important to understanding how to set cachesize. Also, I assume that one should keep the number of worker processes low then. Why? If one's Tomcat is throttling connections more than Apache, then one could end up with a very small pool in each Apache process -- possibly leading to this pool being exhausted far before the Apache worker process' threads are exhausted. The desire is to throttle to a maximum number of Tomcat threads -- not throttle as a percentage of the first one or two Apache worker process' threads... Am I misunderstanding something here? [For now I have been configuring to have only 2 worker processes on UNIX for a little redundancy but each with a cachesize of 1/2 my Tomcat max threads setting.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Here, I suppose modifying all the loggers to be like this: private Log log = LogFactory.getLog(JspServlet.class); would fix the issue without further problems. Hmm... Any chance of such a fix in the next few months. I can search out such and suggest patches, but I'm quite sure you have a far greater degree of familiarity with the details -- I just saw the "configuration nightmare" as you aptly put it. It's not the official J2EE way (there's no official J2EE way, as the default java.util.logging implementation is one global namespace unsuitable for containers), but it's similar to JNDI handling. Understood. I've already got reasonable JNDI-based approach -- assuming the static loggers are to be cleaned up any time in the near future. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: I also added fixes recently so that loggers are not accessed too early, which was a similar issue (some loggers would be have be improperly associated with the container classloader). There's lots of tweaking needed with logging overall, it's sort of to be expected. I'll have to check out the latest 5.5 as that's basically the other problem I was seeing. Tomcat using my log4j and my log4j.properties, but was doing so before my first ServletContextListener was called, so I had not had a chance to install my LoggerRepositorySelector. Thus these loggers were in my web app but not using the LoggerRepository I designated for my web app... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Jess Holle wrote: Jess Holle wrote: Okay, I did a bit more digging. *If*: * Your web app contains log4j.jar *and* commons-logging.jar. * You do not have log4j installed in any of Tomcat's own lib directories. * You use a JNDI or other contextual classloader based LogRepositorySelector. *Then*: * The first Tomcat web application will "steal" loggers from the Tomcat base, i.e. any that happen to be obtained while the first web app's contextual classloader is active. o In a brief, simple test, whichever web app receives the first JSP page request will "steal" the following Tomcat loggers: + org.apache.jasper.compiler.Compiler + org.apache.jasper.compiler.JspReader + org.apache.jasper.runtime.PageContextImpl + org.apache.jasper.servlet.JspServletWrapper + org.apache.jasper.xmlparser.ParserUtils * By "steal", I mean that these loggers end up in the LoggerRepository of the given web app. Their configuration is thus controlled by it. Also, they use the log4j library from the given web app. There's nothing unexpected here: Jasper is a regular servlet, and thus all of its classes will be loaded with the webapp's classloader. It's basically like if you had the Jasper JARs inside /WEB-INF/lib. The problem then is that Jasper uses static logger instances, while it should either log to the servlet context or have per instance loggers, as it resides in a classloader shared across webapps. Regardless of what happens, we will need to cleanup Jasper's logging behavior. What's unexpected here is as you say that these loggers are static -- or in any event not per-web-app. Otherwise, this behavior would be fine and good! Another completely different strategy for acquiring loggers is to use the CL which loaded the class (ie, to use straight delegation). There's the problem that it could cause classcast exceptions, however, and it's more annoying to configure. Both solutions behave differently, but they have their own merits. I happen to prefer the context classloader oriented one in a J2EE environment (so it was used for the java.util.logging implementation I added recently based on some user submitted code that I heavily modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143). Yes, I now have both approaches coded and as you say both have their merits. If the instances wherein Tomcat loggers configured/obtained from one web app are used across web apps are eliminated in Tomcat 5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's own loggers for each web app would use that web app's configuration. Otherwise I really have to go with the straight delegation approach to prevent cross-web-app logger effects. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Jess Holle wrote: Remy Maucherat wrote: BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat level but having it in your web app. This leads to: * whole crop of loggers using java.util.logging (fine, to be expected, and there are Java 5 MBeans -- albeit limited -- to interact with these) * a few core Tomcat loggers that are *not* by nature per web app loggers using the log4j jar and configuration of the first web app that uses the class enclosing them (e.g. the first web app to get a request!) * the web app's own classes using whatever you specify It is the 2nd of these 3 bullet that is so disturbing to me. I'd like to see these either have separate loggers for each web app, or behave like the rest the Tomcat loggers and cause a leak of data and references between web apps. This -- and a reasonable set of MBeans to control/expose loggers seems quite doable with the approach Yoav and Bill laid out. It's just unfortunate that the out-of-the-box behavior with web apps using log4j is so onerous. The core loggers you talk about are probably the ones used for reporting your servlets/filters/etc loading errors. This seems webapp related to me. Considering the classes containing these loggers are not per web app as best I can tell I don't believe the loggers are, but I guess more thorough debugging on my part is in order. Perhaps I am mistaken and these are Tomcat loggers, but are specific to my web app. Okay, I did a bit more digging. *If*: * Your web app contains log4j.jar *and* commons-logging.jar. * You do not have log4j installed in any of Tomcat's own lib directories. * You use a JNDI or other contextual classloader based LogRepositorySelector. *Then*: * The first Tomcat web application will "steal" loggers from the Tomcat base, i.e. any that happen to be obtained while the first web app's contextual classloader is active. o In a brief, simple test, whichever web app receives the first JSP page request will "steal" the following Tomcat loggers: + org.apache.jasper.compiler.Compiler + org.apache.jasper.compiler.JspReader + org.apache.jasper.runtime.PageContextImpl + org.apache.jasper.servlet.JspServletWrapper + org.apache.jasper.xmlparser.ParserUtils * By "steal", I mean that these loggers end up in the LoggerRepository of the given web app. Their configuration is thus controlled by it. Also, they use the log4j library from the given web app. I could always be mistaken, but my examination of the LoggerRepository's involved seems pretty conclusive. If one has to have log4j and commons-logging in one's web app, then the only solution appears to be to put log4j in Tomcat and use a non-contextual classloader based LogRepositorySelector. Avoiding the contextual classloader based LogRepositorySelector only keeps Tomcats loggers from sharing the web app's intended LoggerRepository -- they still use the web app's log4j and its default LoggerRepository. -- Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat level but having it in your web app. This leads to: * whole crop of loggers using java.util.logging (fine, to be expected, and there are Java 5 MBeans -- albeit limited -- to interact with these) * a few core Tomcat loggers that are *not* by nature per web app loggers using the log4j jar and configuration of the first web app that uses the class enclosing them (e.g. the first web app to get a request!) * the web app's own classes using whatever you specify It is the 2nd of these 3 bullet that is so disturbing to me. I'd like to see these either have separate loggers for each web app, or behave like the rest the Tomcat loggers and cause a leak of data and references between web apps. This -- and a reasonable set of MBeans to control/expose loggers seems quite doable with the approach Yoav and Bill laid out. It's just unfortunate that the out-of-the-box behavior with web apps using log4j is so onerous. The core loggers you talk about are probably the ones used for reporting your servlets/filters/etc loading errors. This seems webapp related to me. Considering the classes containing these loggers are not per web app as best I can tell I don't believe the loggers are, but I guess more thorough debugging on my part is in order. Perhaps I am mistaken and these are Tomcat loggers, but are specific to my web app. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Bill Barker wrote: You just need to provide the methods (if you wanted to code against Catalina, you'd just create a LifecycleListener :). This is a hook into commons-modeler, so you technically could use a plain old JavaBean. Otherwise, DynamicMBeans probably work best (or, at least give you the most control). I have gotten used to using my own subclasses to StandardMBean. This allows me to lay out the "static" portion of my MBean with an interface and extend it as necessary -- adding dynamic and open MBean behaviors as necessary in my own classes. Java 1.5's APT turns out to make automated generation of MBean descriptions, operation parameter names, impacts, etc, from MBean interface Javadoc, formal parmeter names, annotations, etc, quite simple. A little more elbow grease and the descriptions are localized (based on the server's locale). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Jess Holle wrote: Why out of curiosity? I don't have a pro-UGLI ax to grind here, but Commons-Logging's behavior in Tomcat is really undesirable as is. It would be the same anyway: the loading configuration and the logger instances will be tied to the webapp classloader. It has to work this way. As I understand it, the thing that does not work for you right now is that Tomcat uses your webapp's logger namespace before your callbacks are called. Yes. The issue is really that Tomcat uses log4j out of my web app for loggers that are to be used outside my web app. Not only is the library used out of my web app but so is the configuration -- meaning web app A gets core Tomcat log output from web apps B and C... Yoav confirmed that the solution is to move log4j and a default configuration higher in the stack so that everything uses it. This together with a per-web-app ClassLoader (but not contextual classloader!) based LoggerRepository will ensure each web app gets its own loggers and configuration files and Tomcat core gets its own. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of the issue. I don't see any real difference. There should be plenty of container listeners and stuff available to configure this. (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue what it is) The nice thing about this as I understand it is that it would allow me to set up my own MBeans for a Tomcat-level / app-wide log4j LoggerRepository. You're right, though, as far as per-web-app MBeans and LoggerRepository's -- there are more than enough servlet listeners, etc, in the servlet spec to handle this. BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat level but having it in your web app. This leads to: * whole crop of loggers using java.util.logging (fine, to be expected, and there are Java 5 MBeans -- albeit limited -- to interact with these) * a few core Tomcat loggers that are *not* by nature per web app loggers using the log4j jar and configuration of the first web app that uses the class enclosing them (e.g. the first web app to get a request!) * the web app's own classes using whatever you specify It is the 2nd of these 3 bullet that is so disturbing to me. I'd like to see these either have separate loggers for each web app, or behave like the rest the Tomcat loggers and cause a leak of data and references between web apps. This -- and a reasonable set of MBeans to control/expose loggers seems quite doable with the approach Yoav and Bill laid out. It's just unfortunate that the out-of-the-box behavior with web apps using log4j is so onerous. -- Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Bill Barker wrote: - Original Message - From: "Jess Holle" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans at the corresponding points of the Engine's Lifecycle, as well as handling JMX registration and un-registration. Cool! Thanks! Do I have to actually implement Lifecycle or just provide these methods? Will a standard/dynamic MBean do or does it have to be a model MBean? [Mine extend StandardMBean and implement MBeanRegistration at the moment.] -- Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Just one more stupid question: How/where would I register/deregister (start/stop) MBeans at the Tomcat level for the Tomcat-level log4j LoggerRepository -- rather than in my ServletContextListener? For per-web-app MBeans, I can use ServletContextListener, of course, but given that log4j loggers are not JMX-exposed, I'd like to put some MBeans to do this up at the Tomcat application level. I do this in my web app, but I'd like to have the Tomcat-level MBeans installed even without any of my web apps installed. -- Jess Holle Yoav Shapira wrote: Hola, Your approach is right and should work. You basically have to move everything up the classloader hierarchy into Tomcat's section, and have a copy of the MBean stuff in each webapp classloader repository that you want to manage. And I agree that it sucks... Yoav -Original Message----- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:30 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to "fix" this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more "dev" follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Remy Maucherat wrote: Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. I already voted on that: -1. Why out of curiosity? I don't have a pro-UGLI ax to grind here, but Commons-Logging's behavior in Tomcat is really undesirable as is. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of the issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to "fix" this is to deploy log4j in Tomcat's own lib directories -- and deploy my log4j controller MBeans there for the default LoggeRepository and again in each web app for each web app's LoggerRepository. If that's what I need to do, I'll get on with doing it, but I'd like to know I'm not just overlooking the obvious... -- Jess Holle Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:17 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more "dev" follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - 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: Web apps vs. Logging vs. Tomcat
P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more "dev" follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
I had e-mailed this to users mailing list, but I have what I believe is a more "dev" follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assuming I end up having to move log4j up into Tomcat's classloaders -- at which point I'll want to install my LoggerRepository controlling MBeans up at this level as well -- as log4j's MBeans have issues and using log4j loggers means you don't get the (admittedly sparse) java.util.logging MBean coverage. -- Jess Holle Jess Holle wrote: I have been trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) without giving my web app a chance to initialize it in any way as best I can tell. My web app has a ServletContextListener which initializes log4j by setting up its own LoggerRepository, configuration file and watcher (since log4j's won't shutdown), etc. Of course, every Tomcat logger created within my web app up until this point is now using log4j from my web app (!) and using the basic log4j.properties [if present] from my web app -- for loggers that apply to all web apps! How is one supposed to work this? I am currently using a static LoggerRepository reference within my web app so that a log4j loaded higher in the classloader tree won't cause LoggerRepository sharing. I was using a JNDI-based LoggerRepositorySelector as per log4j author recommendations, but this goes a step further than above -- it puts all the Tomcat loggers that are errantly using my log4j into my LoggerRepository -- which would be fine if these loggers were not shared with other web apps. What's the solution here? Do I have to put log4j into Tomcat's lib directories to force it to use its own centralized log4j? Is that the best solution? -- Jess Holle
Re: [PATCH] Re: StandardSession activate()/passivate() are broken
Also I notice that when PersistentManager is used that my sessionDestroyed() method is called multiple times (twice actually) whenever a session is being expired from store (i.e. upon removal of old passivated session data). I am patching (crudely) around this for now, but I thought I'd bring this to everyone else's attention. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Re: StandardSession activate()/passivate() are broken
Attached is a patch (against the latest 5.5.x source) that addresses
this issue.
--
Jess Holle
Jess Holle wrote:
It appears that the activate() and passivate() routines of
StandardSession are not functioning properly. [I've only tested
5.0.30, but 5.5.x seem to have identical erroneous code.]
These methods are called, but do not fire appropriate
HttpSessionEvent events. A comparison of these routines to tellNew()
and expire() is rather telling.
I plan to rework this code along the lines of tellNew() and expire() to
get proper functionality
--
Jess Holle
--- StandardSession.java-1.49 2005-02-24 10:58:20.184415700 -0600
+++ StandardSession.java2005-02-24 10:59:08.0 -0600
@@ -729,19 +729,20 @@
public void passivate() {
// Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i < keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i < listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
.sessionWillPassivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
-(sm.getString("standardSession.attributeEvent"), t);
+(sm.getString("standardSession.sessionEvent"), t);
}
}
}
@@ -756,19 +757,20 @@
public void activate() {
// Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i < keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i < listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
.sessionDidActivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
-(sm.getString("standardSession.attributeEvent"), t);
+(sm.getString("standardSession.sessionEvent"), t);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
StandardSession activate()/passivate() are broken
It appears that the activate() and passivate() routines of StandardSession are not functioning properly. [I've only tested 5.0.30, but 5.5.x seem to have identical erroneous code.] These methods /are /called, but do not fire appropriate HttpSessionEvent events. A comparison of these routines to tellNew() and expire() is rather telling. I plan to rework this code along the lines of tellNew() and expire() to get proper functionality -- Jess Holle
5.5 support for Java 5 language features in JSPs
Is there any realistic ETA for Java 5 language feature support in Tomcat 5.5 JSPs? Tomcat 5.0.30 has a simple web.xml flag to note the target language version. 5.5 does too -- if you force it to use javac rather than JDT. This is sounding better and better the longer Tomcat 5.5 does not bundle a JDT that fully supports Java 5. I realize this is not a Tomcat issue as much as a JDT issue -- except that Tomcat 5.5 uses JDT by default. I also realize scriptlets are considered evil -- but they, and hard requirements for Java 5 *now*, are a fact of life for some of us. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat roadmap
A related question would be when will the JDT embedded in Tomcat 5.5 support Java 5 language compilation. -- Jess Holle Yoav Shapira wrote: Hi, Tomcat is not a full J2EE container, "only" a Servlet and JSP container. Accordingly, J2EE spec releases don't matter per-se. They only matter if they contain new Servlet or JSP spec releases in them. Tomcat 6 will implement the next version of the JSP and Servlet specs, whenever those come out. Yoav -Original Message- From: Sam Ewing [mailto:[EMAIL PROTECTED] Sent: Thursday, February 17, 2005 7:46 PM To: tomcat-dev@jakarta.apache.org Subject: Tomcat roadmap J2EE 5.0 releases in the second half of 2005. Will this be implemented by Tomcat 5.5 too, or will this result ina new version - say Tomcat 6 (for Servlet 2.4/JSP 2.1?). I was writing an article on this area, and was curious about the roadmap.. Thanks, Sam __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - 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: Current Connector Development
Günter Knauf wrote: Hi Mladen, appologies that I couldnt closely follow the connector development in the past year, so I'm somewhat suprised about all the recent directions; and cant really understand them; so I would greatly appreciate if you could do a summarize why you are currently again developing to mod_jk... well, what I see is this: after more than one year stagnation on the mod_jk2 connector we started again, made it comilable on all platforms, and improved it a lot, cleaned up the code cause we made APR mandatory, and did a release. Many users where happy with it, and a lot of new users came and saw 'hey, thats the new connector' and tried it; others migrated and found mod_jk2 faster over mod_jk. Few time later you are not lucky with mod_jk2, and you just want to start another conenctor; and after some discussion you agreed to create mod_proy_ajp. Then suddenly, just after mod_proy_ajp is just born - and I cant believe that it is only cause I couldnt follow up with development - I see that you state that mod_jk2 has come to its end cause of no developers and no users interest really suprised of this all I get mail from Novell asking for help since mod_jk is now broken. we have just fixed it so we could folow up with the 1.2.8 release, and you continue to break it .. If I recall correctly we commonly agreed with last time's discussion that we stay with mod_jk _as_is_ and dont move to APR or such, and that mod_jk should mainly remain for our Apache 1.3.x users while Apache 2.x users should use mod_jk2 or also now mod_proxy_ajp - so what has changed this direction now?? Mladen, if you continue with the mod_jk development I fear that we end up the same as with mod_jk2: you will certainly break Apache 1.3.x support - at least on NetWare, and that's _very_ bad cause it's a shipping product of NetWare 6. I don't see mod_jk ending up the same as mod_jk2 in that: 1) The configuration is relatively sane as compared to that of mod_jk2 2) There are many reasonably stable mod_jk versions, so even *if* Mladen screws up a release there are plenty of alternative mod_jk versions. * On the other hand, there never really was a stable mod_jk2 release -- every release tested continued to exhibit serious corner case issues. It would be great if everyone could move to mod_proxy_ajp, but I believe that still requires Apache 2.1/2.2 -- which means it has not yet arrived for the majority of us. I personally applaud Mladen for his efforts to fix/improve/maintain mod_jk given that that is the reality for most of us. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ServletRequest to MBean Mapping
Is there any way to map from a javax.servlet.ServletRequest (from within a filter or whatever) to the JMX data registered on this request by Tomcat? I am trying to produce some servlet-engine independent MBeans to garner a certain level of data in an independent fashion but would like to be able to pluck out certain things from the corresponding Tomcat MBeans where appropriate, e.g. to jump from ServletRequest to the request processor to determine how many bytes are read and written by the request without having to try to redo all of this myself (without direct access to the buffers). Ideas? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 5.5.7 Stability
You can and have fixed CLASSPATH in the past. Use of the JRE's lib/ext or lib/endorsed is different -- and not reasonably solvable, though. -- Jess Holle Remy Maucherat wrote: Tim Funk wrote: I'm going to abstain from voting since I am unable to adequately test. But I did find one item which could be a PITA for the folks on tomcat-user. In setclasspath.sh - the CLASSPATH isn't always overridden. If the user tries to start tomcat with an existing CLASSPATH - that is appended to the bootstrap classpath. You can only guess that wacky errors I saw after startup with my legacy 3+ year old CLASSPATH. I committed the change to setclasspath.sh to fix this. While this issue is definitely not a blocker, it might cause a lot of frustration for the many users who keep their CLASSPATH enironment variable set. Well, JARs in system extensions is an equally common and very similar issue, from what I've seen (where the user has an old servlet.jar in the booclasspath, for example). We can't fix that one. Rémy - 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: [VOTE] JK 1.2.8 Stability
I'm not a commiter, but... I tried with our app on Windows (didn't get time for Solaris and AIX yet) and it worked just fine. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat monitoring
I'd like to be able to monitor the maximum requests active (within a connector thread pool) that are used at any time (and reset this maximum). I'd like to be able to monitor the backlog (ala acceptCount) at a given point in time and the maximum to date (and reset this maximum). [I already noticed the ability to monitor the currentThreadsBusy in ThreadPool.] Am I (hopefully) overlooking this in the existing MBean stack? Or are these candidates for addition? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.8 Stability
For those of us lurking waiting for the outcome of this vote, it would seem to be extraordinarily slow That's not to say I don't appreciate the freely given time of those involved or the time they're taking to evaluate 1.2.8. On the other hand, it would be very good to bring this to some closure. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCStore Downgrade (Tomcat4 vs. Tomcat 5)
Tom Anderson wrote: TOMCAT 5 I have discovered that the checkInterval values are no longer used (despite what the documentation says) and are instead replaced by the backgroundProcessorDelay value in the Container class. This means that I now only have one value to set for the equivalent of the 2 checkInterval values we had in Tomcat 4. I suspect that this was done to decrease the number of threads necessary which seems like a noble goal. But the downside is that I now am forced to run my JDBCStore.processExpires() much more often than I'd like (15 times more often in my case) which is a hardship on the database. This seems like something to look into -- at least in 5.5.x where this has changed yet again, but the controlling parameters are less clear there. Furthermore, in Tomcat 4 JDBCStore overrode StoreBase.processExpires() to only select older sessions from the database something like this: SELECT id FROM tomcat_sessions WHERE app = '/Standalone/localhost/acme' AND 1104288671296 > (lastaccess + maxinactive*1000))) Please see my recent (rejected) patches in this regard. The final versions (after some discussion) were against 5.5.x, but previous versions were against 5.0.30. I could send you 5.0.30 patches as well. Remy was unmoved in the end -- and I don't blame him entirely as my patches have not yet undergone the stress testing they need due to a backlog in the group responsible for such things. Also my patches were on 3 fronts (and thus one might say were all over the map...) -- eliminating possible race conditions, passivating sessions on an LRU basis, and improving JDBCStore and FileStore behavior in processExpires(). Thus in the end my patches did not go in. This was a good thing because each session is loaded into memory before deciding whether or not to expire it, so you don't want to load every Stored session if possible. In my case we often have tens of thousands of sessions in Store so loading all those older sessions every 60 seconds is quite a hardship, especially when combined with the fact that it is running 15 times as often! Agreed! I think the 5.0.30 FileStore and JDBCStore implementations are extraordinarily silly in this regard! Please see my patches to StoreBase, FileStore, and JDBCStore in this regard. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
Remy Maucherat wrote:
Jess Holle wrote:
[Yes, the Request change would still be necessary to prevent the
chance of requests randomly getting their sessions passivated and
recycle after they findSession() but before access().]
A session can be passivated at any (bad) time (which will screw up
requests), and we already do plenty of on access checks. I don't see
what it adds.
A session must not be passivated at just *any* bad time -- that's part
of what I'm fixing.
For the case where one has many valid sessions, many of which are
passivated due to a maximum active sessions constraint, there is likely
to be some level of thrashing such that it is entirely too likely that a
session which has only been idle for a short while is getting passivated
between the findSession() and the access() call. This will result in an
otherwise fine request going horribly wrong from a user's perspective
(assuming the state data in the session was at all critical).
If Request is left as is, then it user's will inappropriately get new
sessions in such cases. If it is changed without the preAccess()
addition, the user will get an invalidated session instead.
As I said, the patch ideas look fine, but I do have questions:
- Why do you really need methods named preAccess and access on the
manager ? The first one seems to be designed to do swap ins while the
second one keeps usage stats, so maybe this could be more elegant. Or
maybe not.
The attached patch has some clarifying comments.
preAccess() is intended to fix the race condition case. It should
rarely do more than check isValid and return, but without it user
requests can go awry for no reason as they see it.
access() move the accessed session to the front of the LinkedHashMap
thereby maintaining sorting. The attached patch also uses this sorting
to reduce the overhead of processMaxIdleSwaps() by breaking from the
loop as newer sessions are encountered. [Yes, I know this may mean some
old sessions are not passivated when a session access on a very old
session occurs between findSessions() and this check, but that's better
than running through all sessions every processing interval.
processMaxIdleSwaps() should be a best reasonable effort.]
- Keeping session skeletons around will eat resources. I understand
this will improve performance, but is that really a good idea ? I'm
asking for your experience after the change here (is memory usage much
higher, etc).
I am working all of this on 2 fronts here: trying to get an acceptable
patch together, incorporate any feedback, etc, and get this tested
against real world scenarios where we're having issues.
Our issue involves various web apps that keep large amounts of session
data for all users -- and a corresponding inability to scale beyond a
few users. I am certain all of these changes put together will not
suffice to totally fix this problem -- and efforts to improve the web
apps are therefore also planned.
I'll certainly provide feedback (and further patches if/where
appropriate) as I gain more real world experience with this approach.
--
Jess Holle
Index: PersistentManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.25
diff -u -r1.25 PersistentManagerBase.java
--- PersistentManagerBase.java 22 Nov 2004 16:35:18 - 1.25
+++ PersistentManagerBase.java 17 Dec 2004 15:41:30 -
@@ -20,6 +20,11 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
@@ -204,17 +209,44 @@
protected long processingTime = 0;
-// - Properties
+/**
+ * Whether session should be synchronously swapped out immediately upon
+ * exceeding maxActiveSessions. Defaults to 'false'.
+ */
+protected boolean immediateSwapOnMaxActiveExceeded = false;
+
+
+// -
Constructors
+
+
+public PersistentManagerBase() {
+sessions = new LinkedHashMap() {
+protected boolean removeEldestEntry(Map.Entry eldest) {
+if ( immediateSwapOnMaxActiveExceeded ) {
+ int maxActiveSessions = getMaxActiveSessions();
+ if ( maxActiveSessions >= 0 )
+ if ( size() > maxActiveSessions )
+ if ( isStarted() )
+ // try to swap out oldest entry; if entry i
Re: PersistentManagerBase (etc) Patches
Attached are a new PersistentManagerBase patch and a new
PersistentSession class. Together these eliminate the need for the
changes to ManagerBase and StandardSession (but not to Request, but this
change is an innocuous reordering of a couple of lines of code).
I've not had a chance to test these, but this would appear to keep
almost all substantive effects out of the base classes and limit them to
the session passivation classes which need these changes. I also
managed to eliminate the need for the endAccess() override (which was
really a workaround for the unbalanced endAccess() call in swapIn() --
though other unbalanced calls might benefit from some debug code in
endAccess() as well...).
--
Jess Holle
Jess Holle wrote:
On further analysis it seems that StandardSession is only constructed
by ManagerBase and indirectly from SimpleTcpReplicationManager via the
ReplicatedSession subclass.
Given that SimpleTcpReplicationManager is mutually exclusive of
PersistentManager, it would appear I should move my StandardSession
changes into a new PersistentSession class and move my ManagerBase
changes into PersistentManagerBase.
Which portions of my changes woulud be objectionable in this case?
[Yes, the Request change would still be necessary to prevent the
chance of requests randomly getting their sessions passivated and
recycle after they findSession() but before access().]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: PersistentManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.25
diff -u -r1.25 PersistentManagerBase.java
--- PersistentManagerBase.java 22 Nov 2004 16:35:18 - 1.25
+++ PersistentManagerBase.java 17 Dec 2004 05:53:42 -
@@ -20,6 +20,11 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
@@ -204,17 +209,44 @@
protected long processingTime = 0;
-// - Properties
+/**
+ * Whether session should be synchronously swapped out immediately upon
+ * exceeding maxActiveSessions. Defaults to 'false'.
+ */
+protected boolean immediateSwapOnMaxActiveExceeded = false;
+
+
+// -
Constructors
+
+
+public PersistentManagerBase() {
+sessions = new LinkedHashMap() {
+protected boolean removeEldestEntry(Map.Entry eldest) {
+if ( immediateSwapOnMaxActiveExceeded ) {
+ int maxActiveSessions = getMaxActiveSessions();
+ if ( maxActiveSessions >= 0 )
+ if ( size() > maxActiveSessions )
+ if ( isStarted() )
+ // try to swap out oldest entry; if entry is
still too fresh then processMaxActiveSwaps() will swap out sessions when
possible in the background
+ swapOutSessionIfOldEnough( (StandardSession)
eldest.getValue(), System.currentTimeMillis(), minIdleSwap,
"persistentManager.swapTooManyActive" );
+}
+return ( false );
+}
+};
+}
-
+// - Properties
+
+
+
/**
-* Indicates how many seconds old a session can get, after its last use
in a
-* request, before it should be backed up to the store. -1 means
sessions
-* are not backed up.
-*/
+ * Indicates how many seconds old a session can get, after its last use in
a
+ * request, before it should be backed up to the store. -1 means sessions
+ * are not backed up.
+ */
public int getMaxIdleBackup() {
return maxIdleBackup;
@@ -314,13 +346,13 @@
/**
-* Set the Container with which this Manager has been associated. If it
is a
-* Context (the usual case), listen for changes to the session timeout
-* property.
-*
-* @param container
-*The associated Container
-*/
+ * Set the Container with which this Manager has been associated. If it is
a
+ * Context (the usual case), listen for changes to the session timeout
+ * property.
+ *
+ * @param container
+ *The associated Container
+ */
public void s
Re: PersistentManagerBase (etc) Patches
On further analysis it seems that StandardSession is only constructed by ManagerBase and indirectly from SimpleTcpReplicationManager via the ReplicatedSession subclass. Given that SimpleTcpReplicationManager is mutually exclusive of PersistentManager, it would appear I should move my StandardSession changes into a new PersistentSession class and move my ManagerBase changes into PersistentManagerBase. Which portions of my changes woulud be objectionable in this case? [Yes, the Request change would still be necessary to prevent the chance of requests randomly getting their sessions passivated and recycle after they findSession() but before access().] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
Remy Maucherat wrote: Jess Holle wrote: Where have I "faked" robustness? I will not claim I actually achieve it, but I certainly tried, fixed real race condition cases, and don't know of ones I missed. The only race condition that I can possibly imagine is on accessCount, which I think is something quite unimportant (if you think it is, add volatile which will solve the problem). We don't care about the exactitude of lastAccessedTime in this case (or you need to tell me why we care). The only race condition after my fix or before it? I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this! Right, and next time there's an issue, we'll add postAccess, I suppose. This is not workable. I'll put code correctness over code maintainability any day -- but that's just me. Clearly you try to balance both. [The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.] You need to relax a little about this kind of issues. The rest of your patch seems like a good start overall :) So you're proposing excising the preAccess() stuff? Or what exactly? I'd happily put most of the patch into the standard distribution and maintain the rest on my own if appropriate. That would lessen the maintenance burden on me and hopefully provide some benefit to everyone else. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
Remy Maucherat wrote: Jess Holle wrote: It is not useful without the rest of the changes as without the rest of the changes there are intolerable race conditions. Right. I suppose that's the end of the discussion then, it would be a waste of time to continue. -1 for your patch. If you really feel insecure, then you could try adding volatile to the accessCount field, but it's really useless. Volatility of accessCount is a minor (though perhaps additionally necessary) part. The bigger issues are that: * During a request, between getSession(sessionId) and session.access() the session could be passivated and recycled -- thus lousing up that request. * A truly long request (e.g. a streaming dynamic content response) can be ongoing and have its session passivated and recycled while it is still ongoing -- recycling the session object it already has access to. As I recall there were other race condition possibilities, but these by themselves were too problematic to let alone. If anyone is actually able to get any robust value out of PersistentManager as it is, then I believe my changes to the passivated session expiration algorithm are a good thing. I just don't see how the whole thing is supposed to really hold water with known race conditions (including a "FIXME" noting them...) -- Jess Holle
Re: PersistentManagerBase (etc) Patches
Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: I'd appreciate comments as to what's wrong with the patch :-) I am clearly new to this area of Tomcat, but there were clear issues in this area of the code that I cannot ignore if I am to depend on PersistentManager. * Extremely inefficient behavior when trying to expire passivated sessions. o All passivated sessions were fully deserialized back into memory to check if they were stale upon each and every processExpires() execution. For large numbers of large sessions (the whole reason you'd bother with passivation!), this will be a large drain on performance. o My changes make the modification time more accessible in FileStore and make more efficient staleness checks in both FileStore and JDBCStore. This seems useful. It is not useful without the rest of the changes as without the rest of the changes there are intolerable race conditions. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
Jess Holle wrote: Remy Maucherat wrote: Jess Holle wrote: And finally, here are the patches against 5.5.6 (same as HEAD at this moment in this case). Ok, but I still dislike the patch ;) I'd appreciate comments as to what's wrong with the patch :-) Sorry I missed your previous comments somehow. I've included them below: I don't like the foundation on which the patch stands, unfortunately. I did not get a warm fuzzy "this is rock solid stuff" feeling about this myself... That said, if there are problems with the foundation, then let's rework it. In the end, I did not see too much glaringly awful about the approach. I unfortunately need session passivation, so if necessary I'll have just keep this in my own distribution if that's what it takes. I am guessing I'm not the *only* one in this boat, so it would be good to work this out... I also don't quite see the real-world usefulness of some of the new features, for example the date usage sorting. If you have a limit on the maximum active sessions and many more sessions than this (when non-expired, passivated sessions are included) then it makes sense to have a fairly aggressive minimum idle time prior to passivation but to ensure that the oldest non-passivated session will be passivated first so as to avoid thrashing between active and passive states where it is not necessary. In particular, all the proposed changes to the base classes (std session, manager base, request), which seem to be designed to add fake robustness to the mix, and add more complexity. I don't think any of these changes bring anything useful, but they do decrease performance and maintainability. Where have I "faked" robustness? I will not claim I actually achieve it, but I certainly tried, fixed real race condition cases, and don't know of ones I missed. I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this! All the same the changes to the base classes are fairly minimally obtrusive. If they cannot be avoided, then they seem worth living with for some of us to have session passivation... [The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
Remy Maucherat wrote: Jess Holle wrote: And finally, here are the patches against 5.5.6 (same as HEAD at this moment in this case). Ok, but I still dislike the patch ;) I'd appreciate comments as to what's wrong with the patch :-) I am clearly new to this area of Tomcat, but there were clear issues in this area of the code that I cannot ignore if I am to depend on PersistentManager. Primary issues encountered were: * Race condition previous noted by "FIXME". o There were no guarantees that a session would not be serialized to disk, passivated, and recyled while it was being used. o There were variations on this. I fixed the more obvious ones by the admittedly unfortunately synchronization on access() and around use of swapOut() in conjunction with checks on accessCount. The less obvious case required a change access(), Request, etc, to allow an already referenced (but not accessed) session which has been swapped out (and thus recycled) to be swapped back in within access() as necessary/appropriate. * Lack of any sort of LRU prioritization to what is passivated when the maximum number of active sessions has been exceeded. o I replaced usage of HashMap with LinkedHashMap in PersistentManagerBase (only). * Extremely inefficient behavior when trying to expire passivated sessions. o All passivated sessions were fully deserialized back into memory to check if they were stale upon each and every processExpires() execution. For large numbers of large sessions (the whole reason you'd bother with passivation!), this will be a large drain on performance. o My changes make the modification time more accessible in FileStore and make more efficient staleness checks in both FileStore and JDBCStore. Additionally there was a discrepancy between lastAccessedTime and thisAccessedTime usage in normal isValid(), etc, and the behavior of PersistentManagerBase, etc In all of these cases I may have misunderstood something or overlooked more optimal solutions. I would like to see all of these issues addressed in the best fashion possible -- and if possible in the standard distribution of Tomcat rather than just in ours. I am thus more than open to suggestions for improvement. The issue is that right now there are clear, unaddressed issues which I believe I have at least improved upon though certainly not perfected. -- Jess Holle P.S. I assumed Manager, etc, interfaces should not be extended, hence my introduction of some new methods at ManagerBase and my instanceof checks. This may have been a bad assumption, but this can easily be amended as needed.
Re: PersistentManagerBase (etc) Patches
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
--
Jess Holle
Jess Holle wrote:
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that
they did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were donoe with a proper CVS tool).
I have reworked this for 5.5.4 as well, but there are a number of
changes between 5.5.4 and 5.5.6 in these same files. I thus plan to
merge up to 5.5.6 before passing these patches along. If anyone is
desparately interested in the 5.5.4 stuff now, let me know.
Overall, I do believe these are a substantial improvement over the
current code, so I'd appreciate it if someone reviewed them a bit --
especially the 5.5.6 versions as it would be good to see this merged
in to 5.5.x at least.
--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase -- and also noticed its experimental
status.
Looking at the sources I found "FIXME" comments regarding: (1) a
race condition between session passivation and session usage and (2)
a lack of LRU sorting to passivate oldest sessions first. I also
discovered that all passivated sessions are regularly (every minuted
by default) read back into memory in their entirety to check if they
should be expired.
The attached set of patches is intended to address all of these
issues -- and seems to do so to the best of my (admittedly limited)
testing.
There are additional fixes that should be made to JDBCStore (i.e. in
general it seems to a trip to the database for every row in many
cases where 1 per 'n' would suffice), but this was of less interest
to me for the time being than FileStore, so I have not pursued
these. Also, I introduced a new attribute to PersistentManagerBase,
but have not yet exposed it via JMX. This is intentional at this
point as I am uncertain as to the merits of the non-default value of
this operation as of yet.
Comments and questions are welcome. All of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
Index: Request.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.18
diff -u -r1.18 Request.java
--- Request.java20 Nov 2004 21:10:47 - 1.18
+++ Request.java16 Dec 2004 17:47:20 -
@@ -2178,11 +2178,11 @@
} catch (IOException e) {
session = null;
}
-if ((session != null) && !session.isValid())
-session = null;
if (session != null) {
session.access();
-return (session);
+if (session.isValid()) // check isValid() *after* access()!
+return (session);
+session = null;
}
}
Index: JDBCStore.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.12
diff -u -r1.12 JDBCStore.java
--- JDBCStore.java 2 Nov 2004 20:05:12 - 1.12
+++ JDBCStore.java 16 Dec 2004 17:47:20 -
@@ -151,6 +151,11 @@
protected PreparedStatement preparedKeysSql = null;
/**
+ * Variable to hold the keysThatMayBeExpired() prepared
statement.
+ */
+protected PreparedStatement preparedKeysThatMayBeExpiredSql = null;
+
+/**
* Variable to hold the save() prepared statement.
*/
protected PreparedStatement preparedSaveSql = null;
@@ -456,7 +461,7 @@
+ sessionTable + " WHERE " + sessionAppCol
+ " = ?";
preparedKeysSql = _conn.prepareStatement(keysSql);
- }
+}
preparedKeysSql.setString(1, getName());
rst = preparedKeysSql.executeQuery();
@@ -491,6 +496,66 @@
return (keys);
}
+protected String[] keysThatMayBeExpired()
+throws IOException
+{
+int maxInactiveInterval = ((ManagerBase)manager).maxInactiveInterval;
+if ( maxInactiveInterval < 0 )
+return new String[0];
+
+ResultSet rst = null;
+String keys[] = null;
+synchronized (this) {
+int numberOfTries = 2;
+while (numberOfTries > 0) {
+
+Connection _conn = getConnection();
+
Re: PersistentManagerBase (etc) Patches
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that they
did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were donoe with a proper CVS tool).
I have reworked this for 5.5.4 as well, but there are a number of
changes between 5.5.4 and 5.5.6 in these same files. I thus plan to
merge up to 5.5.6 before passing these patches along. If anyone is
desparately interested in the 5.5.4 stuff now, let me know.
Overall, I do believe these are a substantial improvement over the
current code, so I'd appreciate it if someone reviewed them a bit --
especially the 5.5.6 versions as it would be good to see this merged
in to 5.5.x at least.
--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase -- and also noticed its experimental
status.
Looking at the sources I found "FIXME" comments regarding: (1) a race
condition between session passivation and session usage and (2) a
lack of LRU sorting to passivate oldest sessions first. I also
discovered that all passivated sessions are regularly (every minuted
by default) read back into memory in their entirety to check if they
should be expired.
The attached set of patches is intended to address all of these
issues -- and seems to do so to the best of my (admittedly limited)
testing.
There are additional fixes that should be made to JDBCStore (i.e. in
general it seems to a trip to the database for every row in many
cases where 1 per 'n' would suffice), but this was of less interest
to me for the time being than FileStore, so I have not pursued
these. Also, I introduced a new attribute to PersistentManagerBase,
but have not yet exposed it via JMX. This is intentional at this
point as I am uncertain as to the merits of the non-default value of
this operation as of yet.
Comments and questions are welcome. All of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
Index: Request.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.16
diff -u -r1.16 Request.java
--- Request.java26 Oct 2004 15:42:05 - 1.16
+++ Request.java15 Dec 2004 20:26:16 -
@@ -2173,11 +2173,11 @@
} catch (IOException e) {
session = null;
}
-if ((session != null) && !session.isValid())
-session = null;
if (session != null) {
session.access();
-return (session);
+if (session.isValid()) // check isValid() *after* access()!
+return (session);
+session = null;
}
}
Index: FileStore.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/FileStore.java,v
retrieving revision 1.5
diff -u -r1.5 FileStore.java
--- FileStore.java 23 Jun 2004 13:51:36 - 1.5
+++ FileStore.java 15 Dec 2004 20:26:48 -
@@ -209,8 +209,14 @@
if (file == null) {
return (new String[0]);
}
+
String files[] = file.list();
+// Bugzilla 32130
+if((files == null) || (files.length < 1)) {
+return (new String[0]);
+}
+
// Build and return the list of session identifiers
ArrayList list = new ArrayList();
int n = FILE_EXT.length();
@@ -367,8 +373,31 @@
oos.close();
}
+// give file modification date to match last session access time
+if ( !file.setLastModified(
((StandardSession)session).thisAccessedTime ) )
+ if (manager.getContainer().getLogger().isDebugEnabled())
+ manager.getContainer().getLogger().debug("Could not set
last modified date on file store for " + session.getId() );
+
}
+// use file modification date to check if we should bother loading session
+protected StandardSession loadSessionIfShouldBeExpired( String sessionId )
+{
+File file = file(sessionId);
+if (file != null) {
+long sessionAccessTime = file.lastModified();
+if ( sessionAccessTime > 0 ) {
+int maxInactiveInterval =
((ManagerBase)manager).maxInactiveInterval;
+if ( maxInactiveInterval >= 0 ) {
+long timeNow = System.currentTimeMillis();
+int timeIdle = (int) ((timeNo
Re: PersistentManagerBase (etc) Patches
For those who tried finding through the patches only to find that they
did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were donoe with a proper CVS tool).
I have reworked this for 5.5.4 as well, but there are a number of
changes between 5.5.4 and 5.5.6 in these same files. I thus plan to
merge up to 5.5.6 before passing these patches along. If anyone is
desparately interested in the 5.5.4 stuff now, let me know.
Overall, I do believe these are a substantial improvement over the
current code, so I'd appreciate it if someone reviewed them a bit --
especially the 5.5.6 versions as it would be good to see this merged in
to 5.5.x at least.
--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase -- and also noticed its experimental
status.
Looking at the sources I found "FIXME" comments regarding: (1) a race
condition between session passivation and session usage and (2) a lack
of LRU sorting to passivate oldest sessions first. I also discovered
that all passivated sessions are regularly (every minuted by default)
read back into memory in their entirety to check if they should be
expired.
The attached set of patches is intended to address all of these issues
-- and seems to do so to the best of my (admittedly limited) testing.
There are additional fixes that should be made to JDBCStore (i.e. in
general it seems to a trip to the database for every row in many cases
where 1 per 'n' would suffice), but this was of less interest to me
for the time being than FileStore, so I have not pursued these. Also,
I introduced a new attribute to PersistentManagerBase, but have not
yet exposed it via JMX. This is intentional at this point as I am
uncertain as to the merits of the non-default value of this operation
as of yet.
Comments and questions are welcome. All of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
Index: StoreBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StoreBase.java,v
retrieving revision 1.8
diff -b -u -r1.8 StoreBase.java
--- StoreBase.java 22 May 2004 23:23:23 - 1.8
+++ StoreBase.java 15 Dec 2004 18:35:35 -
@@ -204,7 +204,7 @@
}
try {
-keys = keys();
+keys = keysThatMayBeExpired();
} catch (IOException e) {
log (e.toString());
e.printStackTrace();
@@ -213,13 +213,10 @@
for (int i = 0; i < keys.length; i++) {
try {
-StandardSession session = (StandardSession) load(keys[i]);
+StandardSession session = (StandardSession)
loadSessionIfShouldBeExpired(keys[i]);
if (session == null) {
continue;
}
-if (session.isValid()) {
-continue;
-}
if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
// recycle old backup session
session.recycle();
@@ -240,6 +237,33 @@
}
}
+protected String[] keysThatMayBeExpired()
+throws IOException
+{
+return ( keys() );
+}
+
+protected StandardSession loadSessionIfShouldBeExpired( String sessionId )
+{
+StandardSession session;
+try
+{
+session = (StandardSession) load(sessionId);
+}
+catch ( ClassNotFoundException e )
+{
+session = null;
+}
+catch ( IOException e )
+{
+session = null;
+}
+if ( session != null )
+if (session.isValid())
+return ( null );
+return ( session );
+}
+
/**
* Log a message on the Logger associated with our Container (if any).
*
Index: PersistentManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.19.2.1
diff -b -u -r1.19.2.1 PersistentManagerBase.java
--- PersistentManagerBase.java 18 Nov 2004 22:13:36 - 1.19.2.1
+++ PersistentManagerBase.java 15 Dec 2004 18:35:36 -
@@ -20,6 +20,11 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
import j
PersistentManagerBase (etc) Patches
A week or two ago I found I had need of the persistent session manager,
PersistentManagerBase -- and also noticed its experimental status.
Looking at the sources I found "FIXME" comments regarding: (1) a race
condition between session passivation and session usage and (2) a lack
of LRU sorting to passivate oldest sessions first. I also discovered
that all passivated sessions are regularly (every minuted by default)
read back into memory in their entirety to check if they should be expired.
The attached set of patches is intended to address all of these issues
-- and seems to do so to the best of my (admittedly limited) testing.
There are additional fixes that should be made to JDBCStore (i.e. in
general it seems to a trip to the database for every row in many cases
where 1 per 'n' would suffice), but this was of less interest to me for
the time being than FileStore, so I have not pursued these. Also, I
introduced a new attribute to PersistentManagerBase, but have not yet
exposed it via JMX. This is intentional at this point as I am uncertain
as to the merits of the non-default value of this operation as of yet.
Comments and questions are welcome. All of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
--- StandardSession-5.0.30.java 2004-12-13 21:28:06.0 -0600
+++ StandardSession.java2004-12-13 21:28:04.0 -0600
@@ -593,7 +593,14 @@
* should be called by the context when a request comes in for a particular
* session, even if the application does not reference it.
*/
-public void access() {
+public synchronized void access() {
+
+ManagerBase managerBase = ( ( manager instanceof ManagerBase ) ?
(ManagerBase) manager : null );
+if ( managerBase != null )
+managerBase.preAccess( this );
+
+if ( !isValid || expiring )
+ return;
this.lastAccessedTime = this.thisAccessedTime;
this.thisAccessedTime = System.currentTimeMillis();
@@ -601,7 +608,10 @@
evaluateIfValid();
accessCount++;
-
+
+if ( isValid )
+if ( managerBase != null )
+managerBase.access( this );
}
@@ -611,11 +621,12 @@
public void endAccess() {
isNew = false;
-accessCount--;
-
+if ( accessCount > 0 )
+--accessCount;
+else if ( debug > 0 )
+log( "Session " + getId() + " accessCount [" + ( accessCount - 1 )
+ "] < 0 " ); // show access count as it would be if we had decremented
}
-
/**
* Add a session event listener to this component.
*/
@@ -790,6 +801,20 @@
}
+/**
+ * Copy all non-transient fields other than id from 'otherSession' to
+ * this session.
+ */
+protected void copyFieldsOf( StandardSession otherSession )
+{
+ this.attributes = (HashMap) otherSession.attributes.clone();
+ this.creationTime = otherSession.creationTime ;
+ this.lastAccessedTime = otherSession.lastAccessedTime;
+ this.maxInactiveInterval = otherSession.maxInactiveInterval;
+ this.isNew = otherSession.isNew;
+ this.isValid = otherSession.isValid;
+ this.thisAccessedTime = otherSession.thisAccessedTime;
+}
/**
* Release all object references, and initialize instance variables, in
@@ -802,7 +827,7 @@
setAuthType(null);
creationTime = 0L;
expiring = false;
-id = null;
+// id = null;
lastAccessedTime = 0L;
maxInactiveInterval = -1;
accessCount = 0;
@@ -810,7 +835,7 @@
setPrincipal(null);
isNew = false;
isValid = false;
-manager = null;
+// manager = null;
}
--- StoreBase-5.0.30.java 2004-12-13 21:29:12.0 -0600
+++ StoreBase.java 2004-12-13 21:29:08.0 -0600
@@ -204,7 +204,7 @@
}
try {
-keys = keys();
+keys = keysThatMayBeExpired();
} catch (IOException e) {
log (e.toString());
e.printStackTrace();
@@ -213,13 +213,10 @@
for (int i = 0; i < keys.length; i++) {
try {
-StandardSession session = (StandardSession) load(keys[i]);
+StandardSession session = (StandardSession)
loadSessionIfShouldBeExpired(keys[i]);
if (session == null) {
continue;
}
-if (session.isValid()) {
-continue;
-}
if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
// recycle old backup session
session.recycle();
@@ -239,7 +236,34 @@
}
}
Re: FIXMEs in PersistentManagerBase
Just a shot in the dark here, but what if:
1. We synchronize on 'session' for the bulk of the 'for' loop.
2. We make StandardSession.access() synchronized
* I'd really like to avoid (2), but I don't see a really good
alternative.
3. We fix the other FIXME regarding LRU by creating a treemap sorting
by access time and then just walk over values().
* I'd really like to actually just keep a doubly linked list
in the manager and bump sessions to the front of this in
StandardSession, but I'm not sure if doing this in access()
would suffice.
Suggestion would be appreciated!
--
Jess Holle
Jess Holle wrote:
I have dire need to use PersistentManager, which is experimental at
this time.
Looking in the source, I note 2 "FIXME" comments -- one of which seems
to clearly indicate a race condition. It actually occurs twice
(though the comment only occurs once) but the code in both cases looks
similar to:
// Swap out all sessions idle longer than maxIdleSwap
// FIXME: What's preventing us from mangling a session during
// a request?
if (maxIdleSwap >= 0) {
for (int i = 0; i < sessions.length; i++) {
StandardSession session = (StandardSession)
sessions[i];
if (!session.isValid())
continue;
int timeIdle = // Truncate, do not round up
(int) ((timeNow -
session.getLastAccessedTime()) / 1000L);
if (timeIdle > maxIdleSwap && timeIdle >
minIdleSwap) {
if (log.isDebugEnabled())
log.debug(sm.getString
("persistentManager.swapMaxIdle",
session.getId(), new Integer(timeIdle)));
try {
swapOut(session);
} catch (IOException e) {
; // This is logged in writeSession()
}
}
}
}
Does anyone have any brilliant ideas/suggestions on how this condition
should be resolved? I'm digging around, but my experience with all of
the pieces involved is rather limited.
--
Jess Holle
FIXMEs in PersistentManagerBase
I have dire need to use PersistentManager, which is experimental at this
time.
Looking in the source, I note 2 "FIXME" comments -- one of which seems
to clearly indicate a race condition. It actually occurs twice (though
the comment only occurs once) but the code in both cases looks similar to:
// Swap out all sessions idle longer than maxIdleSwap
// FIXME: What's preventing us from mangling a session during
// a request?
if (maxIdleSwap >= 0) {
for (int i = 0; i < sessions.length; i++) {
StandardSession session = (StandardSession) sessions[i];
if (!session.isValid())
continue;
int timeIdle = // Truncate, do not round up
(int) ((timeNow - session.getLastAccessedTime())
/ 1000L);
if (timeIdle > maxIdleSwap && timeIdle > minIdleSwap) {
if (log.isDebugEnabled())
log.debug(sm.getString
("persistentManager.swapMaxIdle",
session.getId(), new Integer(timeIdle)));
try {
swapOut(session);
} catch (IOException e) {
; // This is logged in writeSession()
}
}
}
}
Does anyone have any brilliant ideas/suggestions on how this condition
should be resolved? I'm digging around, but my experience with all of
the pieces involved is rather limited.
--
Jess Holle
Re: Tagging JK1_2_27_BETA_2 today 18:00 GMT
After no more betas are in order is the plan to release a stable 1.2.7 or to bump the version up to 1.2.8 at that point? [Sorry for the question but I seem to recall both possibilities being uttered previously.] -- Jess Holle P.S. Thanks to all for all the hard work on JK 1.2.7, especially Mladen :-) Mladen Turk wrote: Hi, I'll tag JK1_2_27_BETA_2 later today and release as beta 2. IMO this will be the latest beta release for 1.2.7. if no serious bugs found. Regards, Mladen. - 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: Custom HttpSession passivation?
Jess Holle wrote: Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: It's called persistent manager, and it's the same place as the standard manager, in the session package. There's even docs: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html Thanks for the pointer! It appears to have what I need/want except for one feature, though I'd like to confirm this. Is maxActiveSessions the maximum number of sessions at one time? Or is it rather the maximum number which have not been passivated allowed at one time? If maxActiveSessions is reached, it will (at the moment) refuse the creation of a new one (like for the StandardManager). To be really clear does "is reached" mean there are 'maxActiveSessions' *active* (non-passivated) sessions? Or does it mean there are 'maxActiveSessions' sessions which have not been invalidated and/or destroyed? Sorry for the dumb question. The docs are ambiguous but the code is not. [The meaning is the former -- and I so happy, assuming this works.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom HttpSession passivation?
Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: It's called persistent manager, and it's the same place as the standard manager, in the session package. There's even docs: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html Thanks for the pointer! It appears to have what I need/want except for one feature, though I'd like to confirm this. Is maxActiveSessions the maximum number of sessions at one time? Or is it rather the maximum number which have not been passivated allowed at one time? If maxActiveSessions is reached, it will (at the moment) refuse the creation of a new one (like for the StandardManager). To be really clear does "is reached" mean there are 'maxActiveSessions' *active* (non-passivated) sessions? Or does it mean there are 'maxActiveSessions' sessions which have not been invalidated and/or destroyed? [We need the former -- badly enough to add it ourselves if necessary.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom HttpSession passivation?
Remy Maucherat wrote: It's called persistent manager, and it's the same place as the standard manager, in the session package. There's even docs: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html Thanks for the pointer! It appears to have what I need/want except for one feature, though I'd like to confirm this. Is maxActiveSessions the maximum number of sessions at one time? Or is it rather the maximum number which have not been passivated allowed at one time? If it is the latter, then I don't see any gaps between what I need and what is already there! [Unless you see any from the brief description I've given...] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom HttpSession passivation?
Remy Maucherat wrote: Jess Holle wrote: I have a need to passivate HttpSessions on a more aggressive basis than that of timing them out. Default behavior is to time out a sessions after 30 minutes of inactivity -- which is fine. Rather I need to be able to passivate sessions to disk after say 10-15 minutes or rather passivate all but the last 'n' (e.g. 200) to disk -- re-activating these if/when necessary (i.e. when a request comes in for the given session). Am I missing a configuration option for such behavior in Tomcat? [Is this something SunONE or WebSphere add on top of the base code they share with Tomcat?] If not, do APIs exist for: * Passivation of individual sessions, i.e. serializing them to disk, calling the right listeners, etc? * Activation of individual sessions, i.e. re-storing them from disk, cleaning files from disk as appropriate, calling the right listeners, etc? o Is this done automatically on attempts to access the session in question? I'm using Tomcat 5.0.30 and 4.1.24, though I could limit things to 5.0.30 if that helps. [I could /possibly/ even pursue 5.5.x if that helps enough, but there are significant obstacles to us pursuing this direction at this time.] This is the purpose of the persistent manager, which supports a number of backends (JDBC and file, at the moment). Can you give me a brief summary of what is and is not there? For instance, I assume from your answer that there is no simple configuration of "passivate after 15 minutes and auto-reactivate as needed", true? Is the auto-reactivate there? These may be stupid questions -- can you give a little more detailed pointer, i.e. full class names and/or important method and pointers any existing docs beyond Javadoc? I can root around given the info given so far as well -- but a brief high-level overview as to what's there already and where to begin would be very helpful. Note: We won't be accepting any contributions in this area for 4.1, and for 5.0, it is unlikely too. Thanks for the note. Did this area change much between 4.1 and 5.0? If not, then I could consider doing something against 5.0 and porting to 5.5 as a contribution. If this area changed significantly, then I may need to consider whether I can just do this once against 5.5 rather having to do this against 5.0 and then rework it for 5.5. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom HttpSession passivation?
I have a need to passivate HttpSessions on a more aggressive basis than that of timing them out. Default behavior is to time out a sessions after 30 minutes of inactivity -- which is fine. Rather I need to be able to passivate sessions to disk after say 10-15 minutes or rather passivate all but the last 'n' (e.g. 200) to disk -- re-activating these if/when necessary (i.e. when a request comes in for the given session). Am I missing a configuration option for such behavior in Tomcat? [Is this something SunONE or WebSphere add on top of the base code they share with Tomcat?] If not, do APIs exist for: * Passivation of individual sessions, i.e. serializing them to disk, calling the right listeners, etc? * Activation of individual sessions, i.e. re-storing them from disk, cleaning files from disk as appropriate, calling the right listeners, etc? o Is this done automatically on attempts to access the session in question? I'm using Tomcat 5.0.30 and 4.1.24, though I could limit things to 5.0.30 if that helps. [I could /possibly/ even pursue 5.5.x if that helps enough, but there are significant obstacles to us pursuing this direction at this time.] Any/all pointers in this regard would be appreciated. Thanks for your time. -- Jess Holle [EMAIL PROTECTED]
Questions on mod_jk, session affinity, etc
For cases where the session data is too large and/or volatile to replicate without a performance penalty and where session affinity is thus required, is there any hope/possibility/interest of trying to balance the number of active sessions per Tomcat instance (i.e. sending new requests to the instance with the fewest active sessions)? Or is there any possibility of "transfering" a session from one Tomcat instance to another when one gets overloaded -- rather than continually replicating every change to the session across all instances? [This would seem to require changes to Tomcat and mod_jk/mod_proxy_ajp, right?] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple Tomcat Instance Question
I have been experimenting with embedding Tomcat except embedding the full normal distribution via Bootstrap rather than fiddling with the embedded distribution. A few questions arise from this: 1. When using multiple Tomcats, e.g. with CATALINA_BASE, etc, does one always need separate 'work' directories? * With a huge web app with 1000's of JSPs, it is a bit obnoxious to have 'n' copies of all of this. Yes, I could pre-populate this via precompilation and copying, but this still consumes a lot of disk. * If I could share one 'work' directory across all instances, would I then have to disable all further JSP compilation to avoid multi-process race conditions, or is this all handled? 2. Are there any guides out there on how to do this sort of embedding? * I'm pretty familiar with server.xml, web.xml, etc, etc, and the CATALINA_BASE approach with a full deployment seems simple enough -- but I'm unsure what I well known/documented alternatives I might be missing. One note on CATALINA_BASE: Without a $CATALINA_BASEE/webapps directory any XML files defining web apps in conf/** seem to be silently ignored. I don't have anything I want to place in the webapps directory, though. This may be a side-effect of me continuing to use the out-of-the-box server.xml to this point, which references 'webapps', but it took me some time to discover. Related note on 5.5.x and bearing .xml files: These now have to have the same name as the web app (at least in 5.5.3), whereas one used to be able to name them anything at all and just change the web app name in the element. Not a big deal, but a surprising change. [I actually ended up using jconsole to visually diff between a working Tomcat instance of an older version and 5.5.3.] -- Jess Holle
Re: Newest JK commits
Mladen Turk wrote: Jess Holle wrote: Mladen Turk wrote: I've done some JK commits that I've been testing for a long time. Have you updated the docs for the lb_factor and socket_timeout changes? That's the thing I'm planing for the all next week. I would like to rewrite the entire JK docs using Tomcat's style and build process. Also we should make clear what we are going to support (making JK2 as unsupported), advertising new mod_proxy and proxy_ajp, etc. Style is well and good, but the clarity around JK2, etc, is priceless! -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newest JK commits
Mladen Turk wrote: Hi all, I've done some JK commits that I've been testing for a long time. The major addition is socket timeout that was missing, causing couple of minutes delays on some platforms if tomcat was down. Also I've back ported the load balance algorithm from proxy_balancer, that actually does what it should. For example the A:lb_factor=5 and B:lb_factor=1 will now give five times more requests to host A. I have also changed one very misleading directive (socket_timeout) to recycle_timeout. The socket_timeout directive is now what it should be (the timeout for the socket), while the recycle_timeout is the inactive socket timeout. Have you updated the docs for the lb_factor and socket_timeout changes? I have also revert Jean-Frederic's latest map_free changes (by mistake). Further more IMO we should prefix all public functions using jk_. That's about it. I have tested all patches on unix and win32. What I'd like to see is if I broke something on AIX (Henry ?) and Netware (Norm, Guenter?) Cheers, MLaden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
Remy Maucherat wrote: Martin Grotzke wrote: The Filter includes one statement: System.setProperty( "javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl" ); the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class. but the part that's not a tomcat-"internals" issue does not have to be discussed here, probably the tomcat-user-list is a better place for this... Without a security manager, any application can set system properties, which are global. So here the JAXP settings will be changed for the whole system, which will produce random results (since only your webapp has visibility on the Xerces class) :( There are clearly better ways to influence JAXP than this... If there are no other META-INF services entries for document builders in the class loader prior to the web app's (which I believe is the case in 5.5), then just having your Xerces (which should have such a META-INF entry) in your web app should suffice. But honestly, Xerces 1.4.4!?! That's positively ancient. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.29 JSP compilation fails when using JDK 1.5.0
I accidentally got Windows end-of-line sequences in the last set of
patches. Here's a better set.
--
Jess Holle
Jess Holle wrote:
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to
1.3 but leaving the source release unspecified -- resulting in the JDK
1.5 javac default source release, 1.5 -- and javac won't allow this
mixture.
I am attaching a set of patches that (1) defaults the source release
to 1.3 as well and (2) allows this to be controlled in a completely
independent and analogous manner to target release.
I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle
--- Options.java-5.0.29 2004-10-19 09:56:58.0 -0500
+++ Options.java2004-10-19 09:57:00.0 -0500
@@ -117,11 +117,16 @@
public String getCompiler();
/**
- * Compiler target VM, e.g. 1.1,1.2,1.3, or 1.4.
+ * Compiler target VM, e.g. 1.1, 1.2, 1.3, 1.4, or 1.5.
*/
public String getCompilerTargetVM();
/**
+ * Compiler source VM, e.g. 1.3, 1.4, or 1.5.
+ */
+public String getCompilerSourceVM();
+
+/**
* The cache for the location of the TLD's
* for the various tag libraries 'exposed'
* by the web application.
--- Compiler.java-5.0.292004-10-19 09:56:54.0 -0500
+++ Compiler.java 2004-10-19 09:57:08.0 -0500
@@ -386,6 +386,11 @@
info.append(" compilerTargetVM=" + options.getCompilerTargetVM() +
"\n");
}
+if (options.getCompilerSourceVM() != null) {
+javac.setSource(options.getCompilerSourceVM());
+info.append(" compilerSourceVM=" + options.getCompilerSourceVM() +
"\n");
+}
+
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
--- EmbeddedServletOptions.java-5.0.29 2004-10-19 09:57:12.0 -0500
+++ EmbeddedServletOptions.java 2004-10-19 09:57:06.0 -0500
@@ -144,6 +144,11 @@
private String compilerTargetVM = "1.3";
/**
+ * The compiler source VM ("1.3" by default).
+ */
+private String compilerSourceVM = "1.3";
+
+/**
* Cache for the TLD locations
*/
private TldLocationsCache tldLocationsCache = null;
@@ -303,6 +308,14 @@
return compilerTargetVM;
}
+/**
+ * @see Options#getCompilerSourceVM
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
public boolean getErrorOnUseBeanInvalidClassAttribute() {
return errorOnUseBeanInvalidClassAttribute;
}
@@ -571,6 +584,11 @@
this.compilerTargetVM = compilerTargetVM;
}
+String compilerSourceVM = config.getInitParameter("compilerSourceVM");
+if(compilerSourceVM != null) {
+this.compilerSourceVM = compilerSourceVM;
+}
+
String javaEncoding = config.getInitParameter("javaEncoding");
if (javaEncoding != null) {
this.javaEncoding = javaEncoding;
--- JspC.java-5.0.292004-10-19 09:57:10.0 -0500
+++ JspC.java 2004-10-19 09:57:02.0 -0500
@@ -98,6 +98,8 @@
private static final String SWITCH_CLASS_NAME = "-c";
private static final String SWITCH_FULL_STOP = "--";
private static final String SWITCH_COMPILE = "-compile";
+private static final String SWITCH_SOURCE = "-source";
+private static final String SWITCH_TARGET = "-target";
private static final String SWITCH_URI_BASE = "-uribase";
private static final String SWITCH_URI_ROOT = "-uriroot";
private static final String SWITCH_FILE_WEBAPP = "-webapp";
@@ -145,6 +147,7 @@
private String compiler = null;
private String compilerTargetVM = "1.3";
+private String compilerSourceVM = "1.3";
private boolean classDebugInfo = true;
private Vector extensions;
@@ -276,6 +279,10 @@
}
} else if (tok.equals(SWITCH_ENCODING)) {
setJavaEncoding(nextArg());
+} else if (tok.equals(SWITCH_SOURCE)) {
+setCompilerSourceVM(nextArg());
+} else if (tok.equals(SWITCH_TARGET)) {
+setCompilerTargetVM(nextArg());
} else {
if (tok.startsWith("-")) {
throw new JasperException("Unrecognized option: " + tok +
@@ -479,6 +486,22 @@
compilerTargetVM = vm;
}
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public void setC
Re: 5.0.29 JSP compilation fails when using JDK 1.5.0
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to
1.3 but leaving the source release unspecified -- resulting in the JDK
1.5 javac default source release, 1.5 -- and javac won't allow this mixture.
I am attaching a set of patches that (1) defaults the source release to
1.3 as well and (2) allows this to be controlled in a completely
independent and analogous manner to target release.
I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle
--- JspC.java 2004-10-05 13:30:36.0 -0500
+++ JspC.java-new 2004-10-18 15:11:30.851472700 -0500
@@ -98,6 +98,8 @@
private static final String SWITCH_CLASS_NAME = "-c";
private static final String SWITCH_FULL_STOP = "--";
private static final String SWITCH_COMPILE = "-compile";
+private static final String SWITCH_SOURCE = "-source";
+private static final String SWITCH_TARGET = "-target";
private static final String SWITCH_URI_BASE = "-uribase";
private static final String SWITCH_URI_ROOT = "-uriroot";
private static final String SWITCH_FILE_WEBAPP = "-webapp";
@@ -145,6 +147,7 @@
private String compiler = null;
private String compilerTargetVM = "1.3";
+private String compilerSourceVM = "1.3";
private boolean classDebugInfo = true;
private Vector extensions;
@@ -276,6 +279,10 @@
}
} else if (tok.equals(SWITCH_ENCODING)) {
setJavaEncoding(nextArg());
+} else if (tok.equals(SWITCH_SOURCE)) {
+setCompilerSourceVM(nextArg());
+} else if (tok.equals(SWITCH_TARGET)) {
+setCompilerTargetVM(nextArg());
} else {
if (tok.startsWith("-")) {
throw new JasperException("Unrecognized option: " + tok +
@@ -479,6 +486,22 @@
compilerTargetVM = vm;
}
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public void setCompilerSourceVM( String vm )
+{
+ compilerSourceVM = vm;
+}
+
public TldLocationsCache getTldLocationsCache() {
return tldLocationsCache;
}
@@ -1156,5 +1179,4 @@
// pass straight through
}
}
-
}
--- Options.java2004-10-05 13:30:36.0 -0500
+++ Options.java-new2004-10-18 14:46:30.631270600 -0500
@@ -117,11 +117,16 @@
public String getCompiler();
/**
- * Compiler target VM, e.g. 1.1,1.2,1.3, or 1.4.
+ * Compiler target VM, e.g. 1.1, 1.2, 1.3, 1.4, or 1.5.
*/
public String getCompilerTargetVM();
/**
+ * Compiler source VM, e.g. 1.3, 1.4, or 1.5.
+ */
+public String getCompilerSourceVM();
+
+/**
* The cache for the location of the TLD's
* for the various tag libraries 'exposed'
* by the web application.
--- Compiler.java 2004-10-05 13:30:36.0 -0500
+++ Compiler.java-new 2004-10-18 14:44:05.863104200 -0500
@@ -386,6 +386,11 @@
info.append(" compilerTargetVM=" + options.getCompilerTargetVM() +
"\n");
}
+if (options.getCompilerSourceVM() != null) {
+javac.setSource(options.getCompilerSourceVM());
+info.append(" compilerSourceVM=" + options.getCompilerSourceVM() +
"\n");
+}
+
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
--- EmbeddedServletOptions.java 2004-10-05 13:30:36.0 -0500
+++ EmbeddedServletOptions.java-new 2004-10-18 14:42:33.480264200 -0500
@@ -144,6 +144,11 @@
private String compilerTargetVM = "1.3";
/**
+ * The compiler source VM ("1.3" by default).
+ */
+private String compilerSourceVM = "1.3";
+
+/**
* Cache for the TLD locations
*/
private TldLocationsCache tldLocationsCache = null;
@@ -303,6 +308,14 @@
return compilerTargetVM;
}
+/**
+ * @see Options#getCompilerSourceVM
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
public boolean getErrorOnUseBeanInvalidClassAttribute() {
return errorOnUseBeanInvalidClassAttribute;
}
@@ -571,6 +584,11 @@
this.compilerTargetVM = compilerTargetVM;
}
+String compilerSourceVM = config.getInitParameter("compilerSourceVM");
+if(compilerSourceVM != null) {
+this.compilerSourceVM = compilerSourceVM;
+}
+
String javaEncoding = config.getInitParameter("javaEncoding");
if (javaEncoding != null) {
this.javaEncoding = javaEncoding;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.29 JSP compilation fails when using JDK 1.5.0
Any chance of a 5.0.30 with this resolved in the near future? [I take it you're back from vacation, Yoav, as I see CVS commit notices with your name on them.] -- Jess Holle Shapira, Yoav wrote: Hi, Thanks for spotting and reporting this issue. While Tomcat 5.0.x doesn't officially support J2SE 5.0, we don't want to make things worse with new releases ;) So my apologize for this issue. I'm really busy today and tomorrow at work, and then I'm traveling this weekend [it's a long holiday weekend in the US]. If someone could at least post a .diff patch to fix this, I'd be grateful and I'll try to commit it quickly. If we wait for me, this issue might have to wait a few days ;) Thanks, Yoav Shapira Millennium Research Informatics -----Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 3:55 PM To: Tomcat Developers List Subject: 5.0.29 JSP compilation fails when using JDK 1.5.0 Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine (out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in general. Tomcat 5.0.29 can no longer compile JSP pages when running under JDK 1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I believe this is a serious regression in 5.0.29 that should by itself prevent it from getting a "stable" rating -- though I'd love to quickly see a 5.0.30 including a fix for this :-) [Tomcat 5.0.29 does seem to work alright under 1.5.0 if you pre-compile all JSP pages via an Ant project...] Note that the startup environment, JSP pages, etc, are identical in both cases. In both cases I use "catalina.50.bat start". Also note that the JSP pages use no 1.5 features whatsoever -- I'm just trying to run with JDK 1.5.0. Also, both results hold both for "development" Jasper settings (fork=false, development=true, reloading=true) and "production Jasper settings (fork=true, development=false, reloading=false). The symptom when this fails is the following console message: javac: target release 1.3 conflicts with default source release 1.5 I am *guessing* this may have something to do with the following change log entry: 30984 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984>: Added compilerTargetVM option to Jasper. (yoavs) -- Jess Holle This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Costin Manolache wrote: Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. Sorry. Windows, Solaris, and Linux do, and HPUX will soon. AIX and Mac OS X will lag as always, though if recent history is any guide AIX will lag further than Mac OS X. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: For those interested in not wasting their time the way I just did, I just found this: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html *Limitation*: On Windows, for security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports persistent access control lists (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls. I obviously use FAT32, and I have to add that this limitation is quite stupid. No multi user setup would run FAT and expect security, so you are fine allowing anything you want on FAT (at least, I can't see how it makes stuff more secure). Ah... All my file systems are NTFS... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.0.29 JSP compilation fails when using JDK 1.5.0
Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine (out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in general. Tomcat 5.0.29 can no longer compile JSP pages when running under JDK 1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I believe this is a serious regression in 5.0.29 that should by itself prevent it from getting a "stable" rating -- though I'd love to quickly see a 5.0.30 including a fix for this :-) [Tomcat 5.0.29 does seem to work alright under 1.5.0 if you pre-compile all JSP pages via an Ant project...] Note that the startup environment, JSP pages, etc, are identical in both cases. In both cases I use "catalina.50.bat start". Also note that the JSP pages use no 1.5 features whatsoever -- I'm just trying to run with JDK 1.5.0. Also, both results hold both for "development" Jasper settings (fork=false, development=true, reloading=true) and "production Jasper settings (fork=true, development=false, reloading=false). The symptom when this fails is the following console message: javac: target release 1.3 conflicts with default source release 1.5 I am *guessing* this may have something to do with the following change log entry: 30984 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984>: Added compilerTargetVM option to Jasper. (yoavs) -- Jess Holle
Re: [5.5] Packaging
Costin Manolache wrote: Shapira, Yoav wrote: It depends how you define support, right? Does "support" mean by default everything is configured for JDK 1.3, and Tomcat is built with target="1.3" ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3? What is the cost of having "target=1.3" by default ? It means the class files and the release will work with jdk1.3 - and it will also run on 1.4 or 1.5. What is the benefit of having target=1.4 and forcing people who use 1.3 to recompile the entire tomcat ? Despite my own feeling that 1.3 has gone the way of the dodo bird, this is a good question. The only thing I know of offhand is that 1.4 gives you assert(). Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think. That's a question for Sun :-), who is forcing people to jump through the hoops by bundling all features with the VM. Most of the features that are interesting in 1.5 have to be to be done right... Tomcat core already works with 1.3 - and you can have optional connectors/valves/etc that only work with 1.5 or 1.6 - with just a simple conditional compilation. I understand why MSFT is forcing people to upgrade windows - they make a lot of money from that, and don't care how much the users will suffer to upgrade. But we don't gain that much by forcing people to upgrade the VM to use the latest version of tomcat. I wish Sun would sell and make money on the VM - so at least someone would gets some benefit from this forced upgrade cycle :-) The reasons to force upgrades are: 1. Ability to fully leverage compelling runtime features for end-user benefit (e.g. in the case of 1.5, better concurrency utilities, built-in JMX, etc; in the case of 1.4 this might possibly include NIO stuff for loading static files or some such) 2. Ability to use compelling development features (e.g. generics in the case of dropping releases prior to 1.5, improved/easier-to-use APIs in cases, etc) 3. Narrower platform mix to mess with supporting / answering questions on, etc. -- Jess Holle
Re: [5.5] Packaging
Jeanfrancois Arcand wrote: +1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at Sun so I might have a couple of bad habits ;-) ) Is the vote to be only on whether to continue to support 1.3? Or the same for 1.4? Also, is it just a commiters vote? Every platform of *any* note has a stable 1.4.2 now and there is precious little excuse to keep using it. On the other hand, if history is any indicator it will be up to 1 full year before 1.5 is available *and* stable on all platforms.(including various versions of UNIX, etc). Perhaps this will somehow only be 6 months, but I'd guess that though 1.5 could be the default, 1.4 support will be needed for up to 12 months after Sun's initial 1.5.0 release. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
I would *guess* that those not bothering to move from 1.3 (for whatever reason) are mostly the same folk who won't upgrade to a more recent Tomcat version anyway. -- Jess Holle Shapira, Yoav wrote: Hola, "Write once, run anywhere" - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? I don't think the number is significant. It's very subjective, and I have no empirical data, just opinion from the tomcat-user list. If someone could show, for example, that more than a tenth of Tomcat users run with JDK 1.3 in production, I'd be convinced me JDK 1.3 is still significant. I completely agree WORA is essential, possibly the biggest advantage of the Java language/platform. But then why aren't we coding/building to JDK 1.1 or J2ME? It's a question of tradeoffs. Maybe we should have a vote on whether Tomcat 5.5 should require JDK 1.5? This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: endorsed directory (WAS: 5.0.28 next week?)
Agreed. Isn't the issue that the JAXP in Tomcat's endorsed is incompatible with 1.5? Joseph Shraibman wrote: I don't know why you want to get rid of endorsed. Sure java 5.0 will have an up to date xerces, but it will get out of date in the future, so you might as well keep the endorsed directory. Amy Roh wrote: +1 I'd like to add startup scripts that don't use endorsed so that tomcat 5.0.28 can be run on JDK 5.0 if needed to be. People can test it out by switching the scripts. I'm running TCKs to see if there're any problems but will commit soon. Let me know if anyone has issues with this. - 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: Where's 4.1.31?
Cox, Charlie wrote: I really hate comments like this. I'm glad you have plenty of free time to upgrade to 5.x. Sorry to rankle you, but let's be honest -- if you want to be able to move forward you have to keep looking ahead. Either your app is so portable (and likely thus rather simple) that feel you can just snag the latest servlet engine du jour and use it -- or you keep an eye to (and some testing time slated for) future versions of servlet engines (and other components) you use. If your app is in pure maintenance mode and you're not moving it forward, then by all means pull back 1 patch at a time as appropriate. So right now from a business perspective, upgrading because it's there is not a reason to upgrade. If I perceive that 4.x is slow for my application, then I have a reason to upgrade. If I need the new listeners, status monitor, or other enhancements, then I will consider an upgrade. Getting all the bug fixes that would be in a hypothetical 4.1.31 (and setting yourself up to get those that would be in a hypothetical 4.1.32 and those that are already in 5.0.27 for that matter) are quite possibly ample reasons for one to upgrade -- and are a lot more than "because it is there". -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
I've said too much on this already, but if you really need 4.1.x and bug fixes thereto, then why not take Tomcat 4.1.30 and patch it as necessary to address bugs of sufficient concern and deliver that to your customer/user base? That seems like a better solution for all than a 4.1.31 release. -- Jess Holle Shapira, Yoav wrote: Hi, I agree with Jess, this is the wrong direction in principle. We're encouraging users to stick with 4.1.x if we do this release. Normally we have just an informal "if everyone is OK with this, I'd like to push out release X on this day" and then a vote on labeling it as stable. The latter being the only official vote. But in this case, I'd want to have a more general vote of should we have 4.1.x maintenance releases, given the reasons stated earlier in this thread. If we have such a vote, and if it passes, and if you decide to go ahead with this release, then you will probably assume responsibility for bugs filed against 4.1.x. This is of course unofficial, but nonetheless this type of arrangement exists with Tomcat 3.3.x. None of us care much for the 4.1.x issues now, except that Mark moved the relevant Connector-related issues from 4.1.x to 5.0.x so that they don't get dropped. This type of move, which I didn't like originally, should definitely be stopped if 4.1.x is still in active development as indicated by regular releases. Man this is a bummer going into the weekend ;) Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Cox, Charlie wrote: Because a 4.1.x upgrade is not an api change. There is much more testing involved in upgrading to a new major version than a point release. The problem is finding the time to review the (possible)effects of 5.x on your installation and all your applications when you could roll out a point release with much less effort. Unless your app is not moving into the future this should have already been done with 5.x by this point (just possibly not yet deployed) -- right? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Keith Wannamaker wrote: Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. Hmmm... As someone who distributes Tomcat 4.1.x and 5.0.x to a broad customer base I see Tomcat 5.0.x certification as a 100% necessity for the future/present and see the incremental effort of verifying a new 4.1.x release as wasted when it could be focused on a 5.0.x verification against past and current releases of our own product. Then again I believe I have a pretty good record of all changes that were required to our product for Tomcat 5 for future releases that could be backed into previous ones... I'm sure different people have different reasons. Yes, I echo Yoav's sentiment, though that the community needs to focus on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x releases. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
The offer to do this is great, but I am more than a little curious: Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is faster, more stable, etc, at this point as best I can tell. -- Jess Holle Keith Wannamaker wrote: Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - 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: common/endorsed & classLoader
Jeanfrancois Arcand wrote: Jess Holle wrote: Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what "endorsed" really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? Yes, because in 1.4, Crimson is used and doesn't support XML schema. That's the only good reason we have to use Xerces when validating a web.xml. Note thatn in 1.5, Xerces packages have been renamed to com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: you should be able to bundle any xerces version in your war). I didn't test it yet Xerces does not have to be endorsed or even be *the* endorsed JAXP XML implementation to be used for purposes like validating XML schema. One can simply directly use the given JAXP factory class -- or better yet use a loader that first tries for the 1.5 repackaged JAXP factory and then reverts to the standard Xerces class naming or some such. If this is not feasible (e.g. if the digester, etc, code involved simply grabs the currently defined JAXP implementation), one could always just have a given classloader force Xerces to be the JAXP implementation for everything within it (by redirecting request for the given meta-inf/services entries to define Xerces as the XML implementation). Such a classloader could also have the smarts not to do this in Java 1.5 Now if the 1.5 JAXP interfaces themselves render the current Xerces inoperable that is a bigger issue -- and one which I would have to chalk up as a serious design flaw in JAXP, i.e. one should not grow interfaces in such a way as to break all existing implementations -- rather one should add a sub-interface and provide APIs to request the sub-interface, etc. I sincerely hope Sun has not mis-stepped in such a major way with something as central as JAXP... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed & classLoader
Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what "endorsed" really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? -- Jess Holle
Re: Tomcat 5.0.28 release
Jeanfrancois Arcand wrote: [back from vacation :-)] Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) Couldn't the use of XML be forced in a manner that is completely independent of JAXP? This could try for the 1.5 Xerces (once at startup) and then fail over to the 1.4 Xerces which it would always deliver, etc. Just a thought -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Overall, JAXP is a very painful thing to those deploying any intensive XML or XSLT that might care what implementation is used and not having the luxury of dictating this implementation to everything else in the JVM. For instance, JAXP requires a separate classloader to change the XML or XSLT implementation used (i.e. to override the meta-inf/services entries as needed) -- yet one can't just create one's own classloader with a rigid security manager in place (e.g. in an applet). Even for per-JVM manipulation, JAXP requires fairly intrusive screwing with one's jars (to remove unwanted meta-inf entries) or command lines or creation of endorsed directories. In the end, I've resorted to using my own static factories to look up and instantiate JAXP implementation. From there on out, the JAXP APIs are fairly nice and easy to use, so the result is having only a single non-standard line of code per XML or XSLT factory. -- Jess Holle Shapira, Yoav wrote: Hola, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. JDK 1.4 was the first one to include JAXP and an XML parser implementation (Crimson) in the JDK itself. This presented difficulties to all container writers, including Tomcat, because they had to jump through special hoops to allow user web applications to override the parser and JAXP interfaces that shipped with the JDK. The typical use-case is a user wishing to use Xerces version X, which provides new features not available in Crimson and not accessible via the JAXP APIs, but relying on new DOM or SAX classes. The user needs both the xml-apis.jar and the xercesImpl.jar from his WAR file to be loaded, overriding those in the JDK itself (old JAXP and old Crimson parser). The endorsed classloading mechanism is the approach suggested by Sun and adopted by Tomcat. "Endorsed" means that classes from that repository can override those classes with the same name that ship with the JDK. The XML parsers are the classic example, but there are others. Our classloader how-to (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html ) and Sun's documentation on the mechanism in general (http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain additional explanations. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
I would have to agree with the gentlemen from Sun and NetBeans that it is preferable to have a standard stable version bundled with other products as opposed to some other file set which one cannot independently reproduce. Why? Users of NetBeans, etc, would like to know that they can reproduce the same behavior outside the IDE by grabbing the same version label from Jakarta. If NetBeans uses its own set of source versions, then users never know what might differ between the NetBeans Tomcat behavior and standard Tomcat releases. I happen to be responsible for the redistribution of a modified Tomcat and have come to noting each and every deviation (change or addition) from the standard Tomcat release upon which I'm based for this reason. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
I suspect isapi_redirect will continue working for some time (though it's URI pattern mapping really did not work for quite some time until 1.2.6). mod_auth_sspi seems to solve the NTLM issue fairly nicely. The political reasons are, however, without any technical basis and thus cannot realistically be addressed save through placation Having just spent over a week getting IIS 6 and isapi_redirect working for a complex system, I've got mixed feelings here. I'd like this to keep working (ideally without any "IIS 5 isolation mode" workarounds) and placating customers, but overall I think Apache 2 is better solution and a better use of the community's time. Now if someone could take over ownership/maintenance for mod_auth_sspi, I'd feel better about IIS support slowly withering away -- Jess Holle Ari Suutari wrote: Hi, I think we do have agreement on droping IIS/iPlanet. Does this mean that in the future there won't be a way to integrate tomcat to IIS ? We have some customers that require use of IIS as frontend (for either political reasons or they want to use integrated windows authentication feature of IIS). Of course there are commercial products for this, but tomcat has just been a very good companion to IIS in our systems. So I hope that someone maintains some kind of solution for IIS integration. Ari S. -- Ari Suutari, Syncron Tech Oy, Finland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS-Tomcat connector bugs
I have been pounding my head into the wall trying to get
isapi_redirect.dll working on IIS 6.0.
There are 3 bugs here with isapi_redirect and its docs as they stand
today -- only one directly of Microsoft's making, it appears:
*1) The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always
contains the host and port screwing up virtual host-independent
URI-to-worker mappings.*
I did a little digging and discovered that this has apparently been
broken since revision 1.19 (i.e. 1.18 worked). The apparent fix is as
follows:
--- jk_isapi_plugin.orig.c 2004-02-24 01:45:50.0 -0600
+++ jk_isapi_plugin.c 2004-07-21 12:11:50.0 -0500
@@ -718,14 +718,13 @@
jk_log(logger, JK_LOG_DEBUG,
"In HttpFilterProc Virtual Host redirection
of %s\n",
snuri);
-} else {
- strncpy(snuri, uri, sizeof(snuri));
- }
+worker = map_uri_to_worker(uw_map, snuri, logger);
+}
if (!worker) {
jk_log(logger, JK_LOG_DEBUG,
"In HttpFilterProc test Default redirection
of %s\n",
uri);
-worker = map_uri_to_worker(uw_map, snuri, logger);
+worker = map_uri_to_worker(uw_map, uri, logger);
}
if (worker) {
I have filed this as bug 30236
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30236>.
Just to add an example:
/examples/*=ajp13
will no longer work with the current code but
/fullhostname/examples/*=ajp13
does.
*2) isapi_install.vbs has hard-wired references throughout to
"isapi_redirector.dll". Unfortunately, the default name of the DLL and
that used throughout all the documentation bundled and otherwise is
"isapi_redirect.dll".*
This leads to *very* confusing failures to load the connector into IIS.
Once this apparent typo is corrected, this script works great.
I have filed this as bug 30238
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30238>.
*3) Connector documentation is not up-to-date for IIS 6 Changes*
The IIS portion of the Tomcat connector documentation makes no mention
of the extra steps required to get the connectors working with IIS 6.
These are clearly documented elsewhere on the web
(http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomcat-iis6-howto.html
<http://www.rit.edu/%7Eack5504/tomcat-iis6-howto/tomcat-iis6-howto.html>
amongst other places), so there is little reason not to incorporate this
information. Not bundling this information leaves most people
attempting this configuration completely lost -- and they just give up.
I have filed this as bug 30239
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30239>.
That's it for the moment
--
Jess Holle
Re: WebappClassLoader.getURLs Bug!
Okay, I'll just change getURL() to be identical to getURI() and all should be well for me. Shapira, Yoav wrote: Hi, And wait for a 5.1 release, which may not be long in the making. Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 12:40 PM To: Tomcat Developers List Subject: Re: WebappClassLoader.getURLs Bug! Remy Maucherat wrote: Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. So you'd recommend that I just patch my own distribution, then? [Changing getURL() to convert to a URI first worked fine in 4.1.24...] -- Jess Holle - 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: WebappClassLoader.getURLs Bug!
Remy Maucherat wrote: Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. So you'd recommend that I just patch my own distribution, then? [Changing getURL() to convert to a URI first worked fine in 4.1.24...] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Jess Holle wrote: One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation. Certainly things function in a reverse proxy environment and so the more complex situation is handled. The issue is that individual developers *can* do bad things by assuming that the request protocol is that they should use in tags, etc. Overall, that would just be life, though and is insufficient reason not to leverage mod_proxy. 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the "picky" code is *too* picky, but it isn't mine :-)] I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications. Actually it is rather portable and does not break any spec to the best of my knowledge. It just assumes it can get at the original content body stream, request string, etc, as an alternative to getParameter() without missing anything. Why this is the case is a long story. I also miss forget exactly where things fall down, but Apache, iPlanet (with embedded servlet engine), and IIS (with Tomcat) all work (except config issues with IIS 6...) This appears to be far removed from most folks' experience, so I guess Tomcat's httpd is good enough for most. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. The keep alive stuff turns out to be a hard requirement for many deployments. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The "httpd serves the static content" feature can be implemented through extending ProxyPass to support regular expressions, for example: That would be a hard requirement for our usage as well. A huge reason for using Apache is to serve the static content at that level. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Graham Leggett wrote: In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the "get Apache to server static content" feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. There is a bit more - we want to be able to have Apache authenticate and pass this info to tomcat for example. I don't know if this can be done with mod_proxy ( maybe have it add an extra header - but that may have security problems ). That is a hard requirement for us as well. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case MX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. Agreed. It sounds like a great project, but a *separate* project and module. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the "picky" code is *too* picky, but it isn't mine :-)] -- Jess Holle
Re: WebappClassLoader.getURLs Bug!
Remy Maucherat wrote: Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. I agree: you really should be complaining about Sun (who wrote the bad URL handling in the first place). Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappClassLoader.getURLs Bug!
Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. So getURI is essentially doing a file.toURI().toURL() anyway? If so, can we just switch getURLs() to call getURI() rather than getURL()? Or should we switch getURL() to call getURI after attempting to get the canonical file object (which is all it does apart from toURL(), whose results are broken as far as the RMI runtime is concerned)? If need be, I can keep either of these patches in my own distribution, but I always like to see a single, consistent fix for everyone. -- Jess Holle
WebappClassLoader.getURLs Bug!
In Tomcat 4.1.x, I discovered that RMI calls from Tomcat failed when the
any of the full file paths of the web app jars contained a space (' ')
character.
At the time, I was told this would be fixed in Tomcat 5 and to work
around it in Tomcat 4.1.x, which I did.
Unfortunately, now that I've moved to Tomcat 5, I discover that the bug
is still quite present. There is now a nice getURI() method along with
the previous getURL() method. Unfortunately, getURLs() does not use
getURI( file ).toURL() or any such as it would need to for the RMI
runtime's sake (as it calls getURLs()).
I can clearly patch WebappClassLoader.getURLs() to make such calls
myself, but:
1. I'm left wondering about the broader implications of doing just this.
* In Tomcat 4.1.x, I changed getURL() to do
canonicalFile.toURI().toURL() under Java 1.4 and a hand
coded equivalent in previous JVMs.
* This works quite robustly in my experience, but I'm left
wondering what the overall best, safest, and most performant
fix is.
2. I don't want to keep having to maintain my own fix. An overall
optimal fix should be integrated into Tomcat 5 so that this issue
ceases to be an issue for everyone using Tomcat.
--
Jess Holle
Re: Some JK2 ideas
I actually built this yesterday upon rediscovering it -- and it seems to work fine. Unfortunately: 1. The licensing is unclear. 2. There appears to be no active maintenance or support of this module. I'm thus more than a little reluctant to put too many eggs in this basket. -- Jess Holle Günter Knauf wrote: Hi, A good number desparately want NTLM-based authentication. [They like the single-sign on for Windows clients, but they love the notion of better security than clear-text name/password, etc, without having to buy a server certificate or use HTTPS on their intranet.] If Apache 2 had a stable module for this (whether or not it was from the ASF itself), I would think this would be a good step to get these folk to shift to Apache. then shift them - this module is available since first Apache2 days: http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip and also for Apache 2.1: http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Costin Manolache wrote: Jess Holle wrote: Henri Gomez wrote: It's better then having people struggle with mod_jk config and feeling it's tomcat developer's job to support IIS. You could also suggest IIS users to switch to Apache 2.0.50 for Windows :) I'd love to -- and have. Unfortunately, some have drank too much Microsoft Kool-Aid. A good number desparately want NTLM-based authentication. [They like the single-sign on for Windows clients, but they love the notion of better security than clear-text name/password, etc, without having to buy a server certificate or use HTTPS on their intranet.] If Apache 2 had a stable module for this (whether or not it was from the ASF itself), I would think this would be a good step to get these folk to shift to Apache. Then it may be better to spend the time implementing an NTLM auth for Tomcat and Apache instead of spending the time supporting IIS :-) Quite possibly... Though there is also a sizable contingent of "we've got to have someone to sue" folk, i.e. they're down on open source software due to a lack of people to throw lawsuits at rather than due to a lack of support. Sad but true -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Costin Manolache wrote: Jess Holle wrote: Maybe the best response to this would be to update the docs and say "tomcat IIS 6 is not supported, plese contact microsoft and ask them to do it". They have plenty of developers and money - they could send a check to Andy and Henri, or do it themself :-) I'm quite certain that they're ecstatic that it is problematic to make these things work together. Personally, I despise IIS. However, when customers insist on using IIS for all HTTP(S) traffic and your product relies on a servlet engine, what are you supposed to do? Tell them to contact Microsoft. Unfortunately some customers have IIS support (with no extra help from Microsoft) as a requirement for the whole solution. They'll not buy or buy non-Java before bothering to pave this ground themselves with Microsoft. Customers are probably paying money to use IIS ( plus the OS, support, etc ). Why should Apache tomcat solve their problems with IIS ? I don't think any tomcat developer received any free IIS + development tools + os licence + support from msft. We should obviously provide all the APIs and protocols to allow such a thing to work, but I don't think we should maintain it ( unless someone really has fun doing it ). I can understand that. It is unfortunate for those caught trying to get Java into Microsoft shops, but it is certainly an easily understood position. Do quality commercial offering exist that integrate with IIS *well*? JRun is completely untenable. Most of the big guys have their own web server, app server, etc, etc, to push -- causing still more problems. Moreover, we don't want still more engines to test everything with I just think the problem of running IIS with app servers should be handled by Microsoft. They get the money from the IIS users, they should support IIS and implement what their customers need. We should just focus on Apache. It's better then having people struggle with mod_jk config and feeling it's tomcat developer's job to support IIS. In a way I agree, Microsoft is happily creating an unworkable environment. Unfortunately, either Java as a whole backs out of this arena or it fights for it. If Tomcat backs out, then it seems unlikely that many using IIS will even bother trying Java servlets and/or JSP pages (as they'll have no free way to do so). If they try using servlets with IIS - they'll have a bad experience and blame us. So it may be much better to just tell them to open a feature request on microsoft support site, or if they want to try servlets - download apache for free. All that makes sense for ASF. It just leaves me SOL :-) Perhaps IIS serving as a proxy for Apache would be a more tenable position -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Henri Gomez wrote: It's better then having people struggle with mod_jk config and feeling it's tomcat developer's job to support IIS. You could also suggest IIS users to switch to Apache 2.0.50 for Windows :) I'd love to -- and have. Unfortunately, some have drank too much Microsoft Kool-Aid. A good number desparately want NTLM-based authentication. [They like the single-sign on for Windows clients, but they love the notion of better security than clear-text name/password, etc, without having to buy a server certificate or use HTTPS on their intranet.] If Apache 2 had a stable module for this (whether or not it was from the ASF itself), I would think this would be a good step to get these folk to shift to Apache. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
