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
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 v.2
Both approaches have their advantages Just don't loose the multi-file configuration flexibility given by JkUriSet. Also, having either XML-based configuration *or* pure .conf configuration would be more easily understood than the current workers2.properties details. Mladen Turk wrote: -Original Message- From: Henri Gomez Of course all that sounds like JK3, but ... Did you see my post about a simpler module specific for now to Apache 2.x (2.0/2.1), may be something which could be included in standard Apache 2.x distribution which will save us hours on explaining how to build mod_jk/mod_jk2 Yes, I did. I read all the replys wery carefully. Did you understand mine? What I propose is: 'imagine a TC as a virtual file system' So, you can 'apr_vfopen(TC/sever, )' like opening a file. You could for examle: Jk3Mount /*.jsp and have smewhere something like: mapping *.jsp server name=1.2.3.1 factor=10% / /mapping or: mapping *.jsp balance server name=1.2.3.1 factor=10% / server name=1.2.3.2 factor=20% / server name=1.2.3.3 factor=auto / server name=1.2.3.4 factor=failover / /balance /mapping
Re: Some JK2 ideas
Angus Mezick wrote: -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Mladen Turk wrote: -Original Message- From: Bill Barker Having the option to do per-host and even per-context configs makes life much easier for admins of servers that support it. Otherwise, you end up with a file that looks like: jk-config host1; host2; host3; /jk-config which is fine for xml-hackers, but not very helpful for server-admins. Yes, that's true, but that same layz admin still has to make the Tomcat running, or not? It still has to learn that server.xml stuff, and even make it working :) Who ever asked the poor apache admin about the TC's config ater all? It really does not matter who the admin is. Even a sophisticated admin is going to want to have file modification dates they can trust on various aspects of the configuration so they can answer did I change this part? questions. Using a modular multi-XML-file approach does not pollute the result with any additional server-specific or Tomcat-specific baggage. It just makes management and automated configuration/installation much more workable. Really off topic, but a sophisticated admin should have all of there configs versioned in CVS and have a script (ant?) that stops the server, deploys the config, starts the sever. Should, but most admins don't go that far, unfortunately. [Selfishly I want the modification dates to remain faithful so that I can look over such administrator's shoulders and say look you touched the following 3 .conf files since things were working as desired -- focus on those.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.2
Jess Holle wrote: Both approaches have their advantages Just don't loose the multi-file configuration flexibility given by JkUriSet. Gack, I meant lose. I did one of my own pet-peeve typos Also, having either XML-based configuration *or* pure .conf configuration would be more easily understood than the current workers2.properties details. Mladen Turk wrote: -Original Message- From: Henri Gomez Of course all that sounds like JK3, but ... Did you see my post about a simpler module specific for now to Apache 2.x (2.0/2.1), may be something which could be included in standard Apache 2.x distribution which will save us hours on explaining how to build mod_jk/mod_jk2 Yes, I did. I read all the replys wery carefully. Did you understand mine? What I propose is: 'imagine a TC as a virtual file system' So, you can 'apr_vfopen(TC/sever, )' like opening a file. You could for examle: Jk3Mount /*.jsp and have smewhere something like: mapping *.jsp server name=1.2.3.1 factor=10% / /mapping or: mapping *.jsp balance server name=1.2.3.1 factor=10% / server name=1.2.3.2 factor=20% / server name=1.2.3.3 factor=auto / server name=1.2.3.4 factor=failover //balance /mapping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: My updated TODO. So I'll do the deployer next, followed by trying to optimize startup time. Then, there's tweaking. Filip, do you have time to refactor the clustering soon ? I think we should tweak your farming feature as well, as it should likely be done the way the manager servlet is (rather, will be) doing its stuff. The idea is to have only one big entry point for deployments, rather than have 20 different components calling various deploy methods (which is impossible to maintain). I need to write some code and experiment, and then I'll have a clearer view of what this refactoring will look like (sorry, it's just a little too messy right now for me to enumerate the list of changes). - Attempt to redo a bit the deployer: * remove the CL code which is there to avoid JAR locking (or at least allow disabling this feature for non-Windows OSes); when enabling anti locking code, move everything to a temp deploy folder where everything will be referenced from; controlled by a development flag on the Context to allow disabling this on Windows Just a note: Please allow the anti-locking stuff to be skipped on Windows as well. [Some of us value performance over deployment convenience.] * move processing of context.xml to StandardContext (at the expense of being able to specify the context class, which will move to an attribute on the Host), as I realize it is important to get context level configurability without adding too much complexity in the embedding application; this could also go in ContextConfig, but this should be done in another event (START occurs too late) - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - Resolve DBCP - Pool - Collections dependency, using package renaming - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) It would be good to get many of the changes listed above this last point available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and do 1.5-specific goodies. - Externalize configuration saving out of StandardServer - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: Just a note: Please allow the anti-locking stuff to be skipped on Windows as well. [Some of us value performance over deployment convenience.] Yes, of course. In production, many people don't use hot deployment (it doesn't give good enough QoS right now, IMO). - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) It would be good to get many of the changes listed above this last point available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and do 1.5-specific goodies. No for 5.0.x, as nearly everything in my list requires API breakage :( That includes the anti-locking stuff? That's unfortunate as I was hoping to see that in 5.0.x Oh well. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.27 as Stable
I have no vote -- but I'd say YES to stable if I had one Shapira, Yoav wrote: Hi, 5.0.27-beta has been out for a few weeks, the TCKs pass, the tester and watchdog tests pass, and there has been positive feedback for it on the user list without any show stopper bug reports. This change is simply a label change and minor website update, no code change or new binaries. Changelog: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/changelog.html ballot Release 5.0.27 as Stable: [ ] Yes [ ] No /ballot I vote Yes ;) Yoav 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Mladen Turk wrote: 3. Get rid of Jk2* from Apache module and use only 'Jk2On' That will register the JK2 in the same way as filter on IIS (for each virtual server). All this imply that the workers2.xml is the main config point, meaning that the same workers2.xml is operable either on IIS or Apache or any other web server. Also there are no other 'per-server' directives rather then 'on or off'. If you're proposing getting rid of JkUriSet, DON'T! It is *very* helpful to be able to mount URI's for a specific web app in an Apache .conf file that contains all the other settings for that web app. This is doubly true when you want that single conf file to cover mod_jk and mod_jk2 bases so you can quickly and easily toggle between the two in case of issues. Having to merge per-web-app configurations into a single XML file would be a mess by comparison for such use cases -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Mladen Turk wrote: -Original Message- From: Jess Holle If you're proposing getting rid of JkUriSet, DON'T! That's exactly what I whish to do. It is *very* helpful to be able to mount URI's for a specific web app in an Apache .conf file that contains all the other settings for that web app. I'm driving the Peugeot 406, and it would be very helpull that I can get a spare part from 'Yugo' :) So, will I adapt my Peugot, or just try to find a cheaper part? Also as I stated the workers2.xml should be the main config, for _all_ platorms. No exceptions. Like there is no exceptions in Java itself. I can see eliminating all web-server-specific configuration options in the long-term -- though keeping the existing options around for a while as deprecated alternatives would be nice, i.e. to give everyone a conversion grace period. I cannot, however, see pushing everything into a single XML file. This is insufficiently modular for a web server that may have dozens of web apps with their own specific settings. Rather what I'd suggest is something like: workers2.xml * contains all mod_jk2 settings that are not web-app specific * /can/ contain all mod_jk2 settings for the given server one or more directories containing web-app specific settings (again specified as XML) * each worker defined in workers2.xml could have its own sub-directory and each web app could thus be mounted by each placing an XML file containing any settings for it in the appropriate sub-directory * other alternatives are possible (e.g. each web-app's XML file could explicitly call out the worker instead and all the XML files could be in one location, though I like the mapping-by-placement arrangement) This suggestion is essentially how Tomcat 5.0.x handles web-app Context elements -- down to my shameless pilfering of the mapping-by-placement idea. It was painful to add Context elements directly to server.xml when this was required, i.e. when such modularity was not supported, the Tomcat group realized this and an easy to use modular configuration approach was provided. I'd wholeheartedly support this sort of an approach (and would be grateful to have XML rather the current workers2.properties format). Killing off JkUriSet without such an improved modular alternative (especially without a grace period) would *not* be appreciated -- by me and a number of others I know who don't follow this list. It would essentially push me towards sticking my customers with mod_jk indefinitely. A final suggestion: A utility to produce the new XML file format from the old formats (not part of the mod_jk2 binary, of course) would be helpful. -- Jess Holle
Re: Some JK2 ideas
Mladen Turk wrote: From: Jess Holle I can see eliminating all web-server-specific configuration options in the long-term -- though keeping the existing options around for a while as deprecated alternatives would be nice, i.e. to give everyone a conversion grace period. Well, you have a JK or that. Point taken. I cannot, however, see pushing everything into a single XML file. This is insufficiently modular for a web server that may have dozens of web apps with their own specific settings. Rather what I'd suggest is something like: Did you try to set up the JK2 on some other server then Apache? No, though on this basis I can understand and concur with your general idea. I just firmly believe forcing an entire server's jk2 configuration including all web-apps' configurations into a single XML file lacks sufficient modularity. Did you try to use your server.xml from TC on other platforms? Huh? server.xml is Tomcat-specific -- as are the Context elements. That's like saying did you ever try to use mod_jk2 config files with JRun. Now if what you mean is have I tried it with Tomcat on various OS and web server platforms, then the answer is, yes. Until Tomcat allowed Context elements to be placed outside its server.xml into separate, per-web-app files, configuring (non-WAR) web apps led to ugly to a merging and general maintenance issue with server.xml. Once per-web-app XML config files were allowed things became 1000 times more manageable from a tooling and maintenance perspective. [Now if your question is shouldn't everything be done via WAR files, then you're one of the lucky few for whom unexpanded WAR files actually fulfill your requirements.] Having things Apache specific AFAICT was the major reason why so many project has failed. Nothing about modular XML files should be Apache specific. I'm just suggesting we learn from Tomcat's experiences and not require every web-app's configuration be merged into a single XML file. It was not workable there and it won't be here. -- Jess Holle
Re: Some JK2 ideas
Mladen Turk wrote: -Original Message- From: Bill Barker Having the option to do per-host and even per-context configs makes life much easier for admins of servers that support it. Otherwise, you end up with a file that looks like: jk-config host1; host2; host3; /jk-config which is fine for xml-hackers, but not very helpful for server-admins. Yes, that's true, but that same layz admin still has to make the Tomcat running, or not? It still has to learn that server.xml stuff, and even make it working :) Who ever asked the poor apache admin about the TC's config ater all? It really does not matter who the admin is. Even a sophisticated admin is going to want to have file modification dates they can trust on various aspects of the configuration so they can answer did I change this part? questions. Using a modular multi-XML-file approach does not pollute the result with any additional server-specific or Tomcat-specific baggage. It just makes management and automated configuration/installation much more workable. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Mladen Turk wrote: -Original Message- From: Jess Holle Who ever asked the poor apache admin about the TC's config ater all? It really does not matter who the admin is. Even a sophisticated admin is going to want to have file modification dates they can trust on various aspects of the configuration so they can answer did I change this part? questions. Don't think that the current config provides that either. It does if you use JkUriSet. I have a separate (auto-generated) .conf file for every web app containing mod_jk, jk2, etc, etc, configuration and another auto-generated .conf file for each web app (included by the first) containing any/all Apache-side authentication configuration for the web app. I can have (and auto-generate) more files per web app, but I (and others I know) won't move to anything that regresses from this level of modularity. Using a modular multi-XML-file approach does not pollute the result with any additional server-specific or Tomcat-specific baggage. It just makes management and automated configuration/installation much more workable. In contrary, it makes it simpler, cause you have a common denominator, and that is 'well documented' config file, usable on any container. What I'm saying here is that I want modular per-web-app config-file support. I don't care if any/all server-specific and Tomcat-specific stuff is removed from them -- actually that is laudable in the long term even if a bit painful in the short term. I just don't want to be forced into shoving the whole configuration into a single file (or using XML entity reference hacks which are beyond ugly -- and require the main file to be modified to add extra entity references which is highly undesirable). JkUriSet can be used only on the Apache server. So, the question is, are we adapting the apache module to other servers, or we have a container independent module. I think you are missing my point: Go ahead and remove JkUriSet, just add equivalent functionality to do per-web-app configuration files. Just do it in a server-independent, XML-based way this time around. If you wish to have a few virtual hosts, you will need to apply two completely different configurations for each side anyhow (httpd.conf or click-clik and server.xml). Having specific directives for each container makes that even more complicated thought. I'm just looking for things like: * Web app X: o jk-mount /x/*, /y/*, and *.jsp o map these all to worker X * Web app Y o jk-mount /m/* and *.jsp o map these all to worker Y and so on With the information above (and any other things which are justifiably per-web-app *and* per-web-app support already exists for) be specifiable in separate files, one for Web app X, one for Web app Y, and so on. -- Jess Holle
Re: Ready for mod_jk 1.2.6 release?
Ditto. I started just using CVS-latest for mod_jk and mod_jk2 some time back as the gap between new, stable feature/fix content and release labels was just too great. Overall CVS-latest has been more stable than the last labels for some time now David Rees wrote: Rainer Jung wrote: the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. I would like to see one. I am already using CVS to get the new features and bug fixes, but an official release would be nice. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this Unfortunately, I'm against useless code in this branch. JSR 160 being brand new, you're going to need new software pretty much everywhere, but of course upgrading the JDK is not an option. Given the new branch changes the API rather significantly, I think it's not going to be a release people will be upgrading to. If it still doesn't make sense, then you can probably manage to cut paste a few lines of code from the JMX docs, right ? ;) sin I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? -- Jess Holle
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? It's the exact opposite. With JDK 1.5, we need no pluggable something, no nothing. So this is why I really want to do that instead of bothering with more dead code. In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm ok with a special JDK 1.4 package full of optional components being put together (assuming none of the new syntax gets used, of course), which could contain your listener and other JARs (like Xerces). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Yep. I'm just anxious to see JMX RMI remoting support in Tomcat soon, i.e. in a stable shipping version that supports a stable, shipping JRE (i.e. 1.4.2). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
- Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP and Pool 1.2
Is there a timeframe for moving to Commons DBCP and Pool 1.2? Just curious -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS branching
Shapira, Yoav wrote: Hi, OK, if we already have an established practice to continue development on HEAD, that's OK. I'll branch TOMCAT_5_0 when I tag 5.0.27 then. Wouldn't you branch it now prior to any non-5.0 work being done on HEAD? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the possibility of / interest in a 4.1.31 release?
Parallel question: How many think that the public messaging should be that more along the lines of Tomcat 5 is now at least as stable/mature as Tomcat 4.1.30 and that folk should upgrade to it? Having asked, I still believe a 4.1.31 for such an issue as that brought up here would be appropriate. I ask the question in terms of messaging to users, OEMs, etc, that 4.1.x has been superseded by 5.0.x in terms of the best version for production -- if/when the community feels this is reality. Personally, I feel that 5.0.22 is at least as stable as the latest 4.1.x, is faster, and overall is preferable. -- Jess Holle Jeff Tulley wrote: For a third time, we have had a defect logged on the fact that I introduced a bug into JNDIRealm while adding a new filtering feature. The fix was very simple and has been made, but post-release of 4.1.30. That, and the admin application largely does not work due to an unfortunate tagging problem. What is the possibility that there will be a 4.1.31 release? Is there any interest in that? I am not a committer and so cannot bring this about, but I wanted to suggest that it seems to me to be a very good idea. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - 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: What is the possibility of / interest in a 4.1.31 release?
Glad to hear it. Perhaps I'm dense, but this stance is not readily apparent from the Tomcat web page. Contrast: *Tomcat 4.0.x*. Tomcat 4.0.6 is the old production quality release... with *Tomcat 4.1.x*. Tomcat 4.1 is a refactoring of Tomcat 4.0.x, and contains significant enhancements, including... Perhaps Tomcat 4.1.x's verbage should be more like Tomcat 4.0.x's, i.e. state that it is an old production quality release... -- Jess Holle Shapira, Yoav wrote: Hi, It's unlikely you'll see a 4.1.x release for any one feature, unless it's a critical security fix. 4.1.x will have bundle releases with several features, less frequency. We've been giving the message for a while now that 5.x is the way to go, not least because less resources (including release manager resources) are spent on 4.x. Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 4:36 PM To: Tomcat Developers List Subject: Re: What is the possibility of / interest in a 4.1.31 release? Parallel question: How many think that the public messaging should be that more along the lines of Tomcat 5 is now at least as stable/mature as Tomcat 4.1.30 and that folk should upgrade to it? Having asked, I still believe a 4.1.31 for such an issue as that brought up here would be appropriate. I ask the question in terms of messaging to users, OEMs, etc, that 4.1.x has been superseded by 5.0.x in terms of the best version for production -- if/when the community feels this is reality. Personally, I feel that 5.0.22 is at least as stable as the latest 4.1.x, is faster, and overall is preferable. -- Jess Holle Jeff Tulley wrote: For a third time, we have had a defect logged on the fact that I introduced a bug into JNDIRealm while adding a new filtering feature. The fix was very simple and has been made, but post-release of 4.1.30. That, and the admin application largely does not work due to an unfortunate tagging problem. What is the possibility that there will be a 4.1.31 release? Is there any interest in that? I am not a committer and so cannot bring this about, but I wanted to suggest that it seems to me to be a very good idea. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - 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] 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java
Glenn Nielsen wrote: On Wed, Apr 14, 2004 at 03:04:51PM -0500, Jess Holle wrote: Jan Luehe wrote: Sandy McArthur wrote: Does this mean J2SE 1.3 support is no more? On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: \ Log: Added support for exception chaining. +iae.initCause(e); If there is a strong desire to maintain BC with J2SE 1.3, I'll resort to the JdkCompat mechanism, but both Remy and Jess voiced (strongly in the case of Jess) opinions that there was no need for it. Though I strongly feel Java 2 v1.3.1 is too old to bother with it (and that those who are still stuck back on it for some strange reason can stick with older versions of Tomcat as well), I do believe a statement that this and future versions of Tomcat shall require Java 2 v1.4 or higher should accompany the first public release after any change requiring Java 2 v1.4 for basic functionality. I don't think the minimum JVM requirement should be changed between minor releases. What about those who for whatever reason can't move to java 1.4 yet but need a Tomcat upgrade path for bug fixes, etc.? You're right that this should likely have been stated on the first public release of 5 and not changed until 5.1 or some such -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java StandardDefaultContext.java
Remy Maucherat wrote: (personally, I don't care about JDK 1.3 support anymore) I'll strongly ditto that -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java
Jan Luehe wrote: Sandy McArthur wrote: Does this mean J2SE 1.3 support is no more? On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: \ Log: Added support for exception chaining. +iae.initCause(e); If there is a strong desire to maintain BC with J2SE 1.3, I'll resort to the JdkCompat mechanism, but both Remy and Jess voiced (strongly in the case of Jess) opinions that there was no need for it. Though I strongly feel Java 2 v1.3.1 is too old to bother with it (and that those who are still stuck back on it for some strange reason can stick with older versions of Tomcat as well), I do believe a statement that this and future versions of Tomcat shall require Java 2 v1.4 or higher should accompany the first public release after any change requiring Java 2 v1.4 for basic functionality. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 18479] - HttpSessionBindingListener.valueUnbound() not called
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18479. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18479 HttpSessionBindingListener.valueUnbound() not called --- Additional Comments From [EMAIL PROTECTED] 2004-04-13 09:44 --- The sessionDestroyed timing problem is what the 2.3 specification mandated (this was a mistake obviously), so you cannot have something portable between 2.3 and 2.4 here. [Replying on mailing list as Bugzilla is down.] Actually you can -- but you have to check the servlet engine spec version and have different logic branches for each version. It's ugly, but it is doable. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 28350] - Tomcat with mod_jk does not serve up files with names containing % character
Thanks! It works great. -- Jess Holle NormW wrote: Good morning. Add the _keyword only_ (forwardURIEscaped) in the workerEnv section in workers2.properties. (ie, it is _not_ used in an 'zzz = xxx' format statement. Norm DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28350. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28350 Tomcat with mod_jk does not serve up files with names containing % character --- Additional Comments From [EMAIL PROTECTED] 2004-04-12 22:02 --- Okay, JkOptions +ForwardURIEscaped works great, but how do you accomplish the same thing with mod_jk2? My servlets get called with uri's with path-infos containing %'s when I use mod_jk and this option, but they don't get called with mod_jk2 and I can find no such setting noted in the mod_jk2 docs. Is this a gap in mod_jk2? - 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: [5.0.22] Release vote
I'm not a committer, but... Given the number of did you get _ important fix xyz _? mails, it seems to make sense to re-tag. It has been a while since a public release and it would be nice to have a public release with this latest flurry of fixes (i.e. so maybe the public release is considered as good as CVS head for a little while...) -- Jess Holle Henri Gomez wrote: Remy Maucherat wrote: ballot Release 5.0.22 as Stable: [ ] Yes [ ] No /ballot I've tested the new Windows wrapper, and it did work for me (and it looks as if we did hire some M$ guy to do its UI). However, some more testing is needed (note: it's not suppoed to work on Win9x for now). Another risky change is the upgrade to Xerces 1.6.2. I didn't put the latest docs bundle on the website (AFAIK, the changelog will be the only update, so I think I'll only upload this file). I didn't run the CTS yet with that build. Did the 5.0.22 will include my patch in jk/java/org/apache/jk/common JkMX.java to set correctly the RMI port ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.22] Release vote
Remy Maucherat wrote: Shapira, Yoav wrote: Hi, I don't think we should relase a stable with a few bugs we can fix easily, a lot of people don't read the release notes, and might start filing bugs against them, so we will lose the time later anyway. There were several check ins after the tag, from different committers, so I think it would benefit us to cut a new tag. If I am the only one that feels like this, then I will redraw my vote. You're not the only one, I agree. Oki, no release then. I don't care at all, and don't expect a new tag for weeks. I'm really really tired of the wait, you tagged five minutes ago, and you forgot my all important patch attitude. Given all the time and energy you put into this Remy, I can completely understand. On the flip side, the overall community would be best served by getting as solid of a point release as possible out sooner rather than later. If the current 5.0.22 tag is the best you/we have time/energy for, then that seems better than 5.0.19. If the plan was to release furiously every couple of weeks or something than I believe everyone's release criteria would be simply better than the last public release. Given that you don't expect to tag for weeks, which I would assume means more like 4-5 than 2 (and would completely understand and concur with this decision as no one can keep up with releases happening every week or two anyway and this sponges up too much time doing release management), then there is a desire to try to get as many of the fixes in process into each public release -- rather than having to refer the masses to CVS for weeks... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.22] Release vote
Remy Maucherat wrote: Jess Holle wrote: I'm not a committer, but... Given the number of did you get _ important fix xyz _? mails, it seems to make sense to re-tag. It has been a while since a public release and it would be nice to have a public release with this latest flurry of fixes (i.e. so maybe the public release is considered as good as CVS head for a little while...) We already knew you were a whiner, you know ;) Guilty as charged :-) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
I also tried this and everything worked nicely.
NormW wrote:
Good morning All.
Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet
now registers correctly the same as a [uri] section, and can access /admin
with only a Location in the httpd.conf. I did note there were duplicate
uri objects created (based on their name) if the same uri spec was in both
files, but in any case this is a lot closer to theory than in the past.
Thanks Jean.
Norm
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:22 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2
mod_jk2.c
jfclere 2004/03/31 06:22:04
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Fix handling of id added in jk2_create_dir_config().
I do not see why we need this id... May because jk2_merge_dir_config()
was buggy.
That fixes PR 18472 and 28916.
Revision ChangesPath
1.82 +33 -16
jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- mod_jk2.c 21 Mar 2004 09:44:30 - 1.81
+++ mod_jk2.c 31 Mar 2004 14:22:04 - 1.82
@@ -221,14 +221,25 @@
strcpy(tmp_full_url, s-server_hostname);
strcat(tmp_full_url, uriEnv-uri);
}
+
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
uri, tmp_full_url);
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
path, cmd-path);
+
uriEnv-name = tmp_virtual;
uriEnv-virtual = tmp_virtual;
+} else {
+/*
+ * The jk2_create_dir_config added an id to uri and path
+ * we have to correct it here.
+ */
+
+uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
+uri, cmd-path);
}
+
/* now lets actually add the parameter set in the Location block
*/
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
(char *)name, (void *)val);
@@ -293,40 +304,46 @@
jk_uriEnv_t *child = (jk_uriEnv_t *)childv;
jk_uriEnv_t *parent = (jk_uriEnv_t *)parentv;
jk_uriEnv_t *winner = NULL;
-jk_uriEnv_t *loser = NULL;
+char *hostchild;
+char *hostparent;
if (child == NULL || child-uri == NULL || child-workerName ==
NULL) {
winner = parent;
-loser = child;
}
else if (parent == NULL || parent-uri == NULL
|| parent-workerName == NULL) {
winner = child;
-loser = parent;
/* interresting bit... so far they are equal ... */
}
else if (strlen(parent-uri) strlen(child-uri)) {
winner = parent;
-loser = child;
+}
+else if (strlen(parent-uri) == strlen(child-uri)) {
+/* Try the virtual host to decide */
+hostchild = child-mbean-getAttribute(workerEnv-globalEnv,
child-mbean,host);
+hostparent = parent-mbean-getAttribute(workerEnv-globalEnv,
parent-mbean,host);
+if (hostchild == NULL)
+winner = parent;
+if (hostparent == NULL)
+winner = child;
+if (winner == NULL) {
+if (strlen(hostchild) strlen(hostparent))
+winner = child;
+else
+winner = parent;
+}
}
else {
winner = child;
-loser = parent;
}
/* Do we merge loser into winner - i.e. inherit properties ? */
-/*if ( winner == child )
- fprintf(stderr, Going with the child\n);
- else if ( winner == parent )
- fprintf(stderr, Going with the parent\n);
- else
- fprintf(stderr, Going with NULL\n);
- */
-fprintf(stderr, Merging %s %s %s\n,
-(winner == NULL || winner-uri == NULL) ? : winner-uri,
+ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+ mod_jk2 Merging %s %s winner: %s\n,
(child == NULL || child-uri == NULL) ? : child-uri,
-(parent == NULL || parent-uri == NULL) ? :
parent-uri);
+(parent == NULL || parent-uri == NULL) ? : parent-uri,
+(winner == child) ? parent : child );
return (void *)winner;
-
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 5.0.20 Issue
Kin-Man Chung wrote:
I think your only valid point is the one about the need to make
errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
but we are not bundling jspc scripts anymore, so I didn't feel there
is a need for it. Anyway, its value can be set with an ant task.
Otherwise, Jasper behaves the same as before when
errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it
take more time to compile, but that's a compile-time vs. runt-time
tradeoff that all compilers make.
The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time. For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem. For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.
I'm not arguing with the overall intent of your change. Rather I
believe that calling the constructor during compilation is wasteful and
improper as the environment *can* differ between compilation and
runtime. Also, the fact that a failure to compile in this fashion
generates a partial Java source means that once a compilation fails due
to an environmental issue it will continue to fail even when the
environment is corrected (e.g. when another server comes back up).
That's certainly not appropriate.
If you have ideas about how to modify Generator that works better, please
submit a patch, and I'll see if it can be incorporated.
I must profess ignorance as to how to submit an official patch (e.g. how
to generate one), but here's a diff with Generator.java version 1.230
from CVS of what I'm suggesting:
22a23
*import java.lang.reflect.Constructor;*
1224c1225,1226
bean.newInstance();
---
// Next line will throw exception if
public no-args constructor cannot be found
*Constructor constructor =
bean.getConstructor( new Class[] {} );
*
Essentially, I'm suggesting we check for the existence of the default
constructor, but don't call it. That takes the same amount of real code
(2 more lines thanks to my import and gratuitous comment) and avoids (1)
actually constructing the bean during compilation and (2) making any
unnecessary assumptions about compilation vs. runtime environmental
conditions.
Applying this diff to Generator.java addresses my issue and I believe is
an overall improvement and better aligned with the JSP specification. I
would greatly appreciate it if this could be incorporated into the
Jasper/Tomcat source stream.
--
Jess Holle
[EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Sorry, I should have said mod_alias, not mod_dir... -- Jess Holle Jess Holle wrote: mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x releases had with mod_dir. Specifically something like: Alias /MyWebApp D:\my_app_view\Myapp/codebase Directory D:\my_app_view\Myapp/codebase Options Indexes FollowSymLinks /Directory Directory D:\my_app_view\Myapp/codebase/WEB-INF AllowOverride None deny from all /Directory IfModule mod_jk2.c Location /MyWebApp/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location /IfModule Does not successfully map /MyWebApp/servlet/* to MyWebApp's servlets. Rather I get 404's. Once I comment out the Alias and Directory lines, the JkUriSet directive works as expected (but the overall app does not work properly, of course). This worked fine with mod_jk2 2.0.2. This sort of configuration is *very* helpful in that it allows configuration of additional web apps by Including one conf file per web app and containing everything necessary for that web app for both mod_jk and mod_jk2 -- thus allowing the LoadModule line to determine everything and keeping web app configurations nicely separated. A fix (patch now, 2.0.5 later?) for this would be greatly appreciated as there are important fixes and enhancements in mod_jk2 2.0.4. Without this working, however, 2.0.4 is a non-starter for me. -- Jess Holle P.S. I can certainly give more details, file a bugzilla bug, etc, as necessary. I just got back from vacation, tried out mod_jk2 2.0.4 and wanted to get the ball rolling on this issue before I trudged through my e-mail backlog.
Re: Bug: jk2 2.0.4 vs. mod_dir
Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
I certainly know what a JavaBean is, Remy. First, *any* constructor can fail and throw an exception due to any number of factors -- including a JavaBean constructor. Second, I did not write the beans in question. I'm simply seeking to maintain reasonable resiliency in their handling. My proposed change does that and is in better keeping with the intent of the spec than testing if the bean constructor actually succeeds at a given time. Finally, though I strongly feel this patch is an overall improvement (and have received off-list mail to that effect), I will patch my own Tomcat as necessary if the Tomcat group is not flexible in this matter. -- Jess Holle Remy Maucherat wrote: Jess Holle wrote: I'm not arguing with the overall intent of your change. Rather I believe that calling the constructor during compilation is wasteful and improper as the environment *can* differ between compilation and runtime. Also, the fact that a failure to compile in this fashion generates a partial Java source means that once a compilation fails due to an environmental issue it will continue to fail even when the environment is corrected (e.g. when another server comes back up). That's certainly not appropriate. At the heart of the problem is that you do not seem to know what a JavaBean is. 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: Bug: jk2 2.0.4 vs. mod_alias
jean-frederic clere wrote: Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. I have also managed to reproduce this more succinctly than previously in almost the same fashion with: Alias /servlets-examples D:\Tomcats\Tomcat5020\webapps\servlets-examples Location /servlets-examples/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location The Tomcat servlet examples are not accessible with these settings. They are, however, (apart from static content like images, etc) once you remove the Alias line. This example is clearly contrived as it is simplified down to the bare essentials. There are larger reasons for me needing to take this sort of approach... -- Jess Holle P.S. I see warnings that worker is deprecated and that I should use group in the logs. Is this just a change in terminology? Where does it all apply?
Re: Bug: jk2 2.0.4 vs. mod_alias
Jess Holle wrote: jean-frederic clere wrote: Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. I have also managed to reproduce this more succinctly than previously in almost the same fashion with: Alias /servlets-examples D:\Tomcats\Tomcat5020\webapps\servlets-examples Location /servlets-examples/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location The Tomcat servlet examples are not accessible with these settings. They are, however, (apart from static content like images, etc) once you remove the Alias line. P.S. Let me know if I should file a Bugzilla bug for this -- Jess Holle
Re: Bug: jk2 2.0.4 vs. mod_dir
jean-frederic clere wrote: I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. And using a VirtualHost works around the problem... (That is why I have not dectected it before). And to re-iterate 2.0.2 does not have this issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Kin-Man Chung wrote: Your test for bad beans is much weaker than what it is now. For instance, you do not catch the case where the bean class is abstract. Ah, yes, you are correct. That can also be easily checked with an additional line of code, of course. However, I am sympathetic to your view on this. If I can be convinced that we have covered all checks that we can do without too much trouble, I'll fix Jasper. I don't know of any other issues that I'm overlooking besides the possibility of the constructor failing -- which is, of course, what I'm trying to overlook :-) getConstructor() will only return public constructors (as per Javadoc and the Java sources), so that's handled already. I'll add and test the missing line (or possibly 2) shortly. Thanks for the help. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Jess Holle wrote:
Kin-Man Chung wrote:
Your test for bad beans is much weaker than what it is now. For
instance,
you do not catch the case where the bean class is abstract.
Ah, yes, you are correct. That can also be easily checked with an
additional line of code, of course.
However, I am sympathetic to your view on this. If I can be
convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.
I don't know of any other issues that I'm overlooking besides the
possibility of the constructor failing -- which is, of course, what
I'm trying to overlook :-)
getConstructor() will only return public constructors (as per Javadoc
and the Java sources), so that's handled already.
I'll add and test the missing line (or possibly 2) shortly.
Actually I was also missing a check to see if the class was public :-(
Here's my new proposed diff:
22a23
import java.lang.reflect.Constructor;
23a25
import java.lang.reflect.Modifier;
1224c1226,1231
bean.newInstance();
---
int beanModifiers = bean.getModifiers();
if ( !Modifier.isPublic( beanModifiers ) )
throw new IllegalAccessException( Bean
class is not public );
if ( Modifier.isAbstract( beanModifiers )
|| Modifier.isInterface( beanModifiers ) )
throw new InstantiationException( Bean
class is abstract );
Constructor constructor =
bean.getConstructor( new Class[] {} );
--
Jess Holle
Bug: jk2 2.0.4 vs. mod_dir
mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x releases had with mod_dir. Specifically something like: Alias /MyWebApp D:\my_app_view\Myapp/codebase Directory D:\my_app_view\Myapp/codebase Options Indexes FollowSymLinks /Directory Directory D:\my_app_view\Myapp/codebase/WEB-INF AllowOverride None deny from all /Directory IfModule mod_jk2.c Location /MyWebApp/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location /IfModule Does not successfully map /MyWebApp/servlet/* to MyWebApp's servlets. Rather I get 404's. Once I comment out the Alias and Directory lines, the JkUriSet directive works as expected (but the overall app does not work properly, of course). This worked fine with mod_jk2 2.0.2. This sort of configuration is *very* helpful in that it allows configuration of additional web apps by Including one conf file per web app and containing everything necessary for that web app for both mod_jk and mod_jk2 -- thus allowing the LoadModule line to determine everything and keeping web app configurations nicely separated. A fix (patch now, 2.0.5 later?) for this would be greatly appreciated as there are important fixes and enhancements in mod_jk2 2.0.4. Without this working, however, 2.0.4 is a non-starter for me. -- Jess Holle P.S. I can certainly give more details, file a bugzilla bug, etc, as necessary. I just got back from vacation, tried out mod_jk2 2.0.4 and wanted to get the ball rolling on this issue before I trudged through my e-mail backlog.
Tomcat 5.0.20 Issue
Jess Holle wrote: Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) There are several issues with this change: 1. The new logic assumes that the bean can be directly instantiated /at compile time/ and throws a page compilation error when this is not the case. * There are beans that can be directly instantiated at run time but not at compile time (e.g. upon precompilation). This was the case in all 6 of our failures. [Examples as to when this might occur include requirements for databases being accessible, other servers running, etc, etc, for successful bean instantiation.] * The error occurs in such a way that a partial Java source file is written, so later attempts to recompile the page (when the runtime environment is duplicated) also fail unless the partial Java source file is first deleted. 2. I note the errorOnUseBeanInvalidClassAttribute setting but there are issues here as well: * The default value, true, breaks existing code. * If errorOnUseBeanInvalidClassAttribute is set to false: o Instantiation of some (e.g. session or application scope) beans can be time and/or resource consuming. Besides being an invalid test as to whether a bean can be directly instantiated, instantiating such beans during compilation can be costly. [The combined time for precompiling all pages was longer in 5.0.20 with this behavior in place than when I removed it.] o The new behavior will cause beans to be instantiated via Beans.instantiate() rather than directly instantiated when compile time direct instantiation fails. This leads to a performance degradation whenever a bean has a runtime instantiation dependency. * As best I can tell, errorOnUseBeanInvalidClassAttribute is not accessible from / exposed via JspC main -- which I use from my pre-compilation scripts for various reasons. Due to these issues I have reverted this change in Generator to the 5.0.19 state (leaving the other valuable changes in this class intact). Once I did so all 985 JSP pages compiled -- including the 6 that had previously failed. I would urge that this change be reverted -- either in this release (or an immediate 5.0.21 release) or immediately changed in HEAD for the next release. -- Jess Holle
Re: Tomcat 5.0.20 Issue
Remy Maucherat wrote: Well, your pages are invalid. Really, I don't see what's so mysterious: anything used in useBean must be a JavaBean. This will not be fixed. Did I miss something? Are JavaBean default constructors required to succeed in any/all environments? Specifically are they required to succeed at compile time when none of the runtime requirements they have are met? This seems somewhat odd to say the least. That said, I did not author any of the beans in question and could certainly give the authors of said beans hell for their transgressions *IF* I have sufficient proof that what they're doing is completely wrong. Overall, however, the change in 5.0.20 still seems questionable -- at least with respect to the many other details (e.g. that the default causes new failures, that the compiler flag is not accessible via JspC.main(), etc...) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Based on the given bug id, I would propose a different implementation than that found in 5.0.20. Specifically I would suggest that Generator: 1. Try to load the given class. 2. Look up its default (no-args) constructor via reflection. [This is the key part, look up the constructor but don't call it!] 3. If a public no-args constructor IS found, then code should be generated to use it to directly instantiate the bean. 4. If a public no-args constructor is NOT found, then a page error should be generated and Beans.instantiate() should be used if errorOnUseBeanInvalidClassAttribute is set to false. This should be more efficient, avoid breaking pages using beans with non-trivial environmental constraints for successful construction, and follow the letter of the spec better as I see it. -- Jess Holle Tim Funk wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444 -Tim Jess Holle wrote: Jess Holle wrote: Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
P.S. Nothing in the quoted spec segments implies that the JSP compiler should attempt to actually *instantiate* beans at compile time or expect that that should work. -- Jess Holle Jess Holle wrote: Based on the given bug id, I would propose a different implementation than that found in 5.0.20. Specifically I would suggest that Generator: 1. Try to load the given class. 2. Look up its default (no-args) constructor via reflection. [This is the key part, look up the constructor but don't call it!] 3. If a public no-args constructor IS found, then code should be generated to use it to directly instantiate the bean. 4. If a public no-args constructor is NOT found, then a page error should be generated and Beans.instantiate() should be used if errorOnUseBeanInvalidClassAttribute is set to false. This should be more efficient, avoid breaking pages using beans with non-trivial environmental constraints for successful construction, and follow the letter of the spec better as I see it. -- Jess Holle Tim Funk wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444 -Tim Jess Holle wrote: Jess Holle wrote: Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5's service.bat, etc.
The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I see it: 1. The new tomcat.exe (aka procrun) does not seem to reliably route stdout and stderr to the specified files. * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout and stderr treatment to procrun's. JavaService captures all the startup stdout as well as System.out.println's, etc. procrun does not. 2. Tomcat 5 does not include any documentation on how to use procrun (or even that tomcat.exe is procrun). 3. I have not managed to get procrun to target the server JVM (as opposed to the client) in any reliable fashion. * With JavaService this was achieved by targeting the appropriate jvm.dll. The procrun docs say the same thing is possible, but this does not work. 4. service.bat does not route as many arguments to procrun as what I for one route to JavaService -- and thus it provides less flexibility (especially with no documentation). * For JavaService I provide heap sizing, etc, parameters, as this is critical to any real use of Tomcat. * Having built in support for passing JPDA debug args to the JVM is also a must. 5. service.bat does not provide any default handling of tools.jar. * By default the resulting service can't compile JSP pages. Overall, service.bat and procrun feel like they're not ready for production use -- which is fine as long as that's understood by the user community. Personally, JavaService and an Ant script to produce the right (enormous) command line for seem to do the trick nicely -- with Tomcat 4.1.x and 5.0.x. -- Jess Holle
Re: jk2 2.0.4 tagged
Is there a source tarball for 2.0.4 available for download somewhere yet? -- Jess Holle Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev - 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 5's service.bat, etc.
Bill Barker wrote: The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I see it: 1. The new tomcat.exe (aka procrun) does not seem to reliably route stdout and stderr to the specified files. * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout and stderr treatment to procrun's. JavaService captures all the startup stdout as well as System.out.println's, etc. procrun does not. Procrun works fine with --Java=java. Yes, it needs work for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :). Hmmm --Java=pathToJvmDll did not work at all for me -- service failed to install and other errors. [W2K with latest service packs and Java 2 v1.4.2_04.] --Java=java worked but lost most of the stdout and stderr output -- including all the startup output. It did seem to start up faster than JavaService... 2. Tomcat 5 does not include any documentation on how to use procrun (or even that tomcat.exe is procrun). 3. I have not managed to get procrun to target the server JVM (as opposed to the client) in any reliable fashion. * With JavaService this was achieved by targeting the appropriate jvm.dll. The procrun docs say the same thing is possible, but this does not work. This works fine for me with either --Java=java -JavaOptions=-server#... or with --Java=c:\path\to\server\jvm.dll. I was actually referring to the latter approach, which as I said did not work for me. I did not honestly trust the first approach -- I guess I should have 4. service.bat does not route as many arguments to procrun as what I for one route to JavaService -- and thus it provides less flexibility (especially with no documentation). * For JavaService I provide heap sizing, etc, parameters, as this is critical to any real use of Tomcat. * Having built in support for passing JPDA debug args to the JVM is also a must. So edit the service.bat file :). As usual, patches are always welcome ;-). The fact that you have to replace all spaces with #'s and shovel all JAVA_OPTS or CATALINA_OPTS into a single argument makes it more difficult to just pass in and concatenate portions of the command line. With JavaService, one can do: set javaMemArgs=... set debugArgs=... set javaPropArgs=... set javaArgs=%javaMemArgs% %debugArgs% %javaPropArgs% JavaService.exe -install %serviceName% %jvmDllArg% %javaArgs% %startArgs% %stopArgs% %stdioArgs% %currDirArgs% In other words, one can flexibly and easily insert additional arguments. With procrun, I have to worry about replacing some spaces with #'s, properly escaping quotes, etc, within the aggregate argument containing all the Java arguments, etc. Essentially this makes it harder to have a one-size fits (most) all script. 5. service.bat does not provide any default handling of tools.jar. * By default the resulting service can't compile JSP pages. Overall, service.bat and procrun feel like they're not ready for production use -- which is fine as long as that's understood by the user community. I should clarify that another reason for this was a number of crashes I had just installing and removing my service with procrun. -- Jess Holle
Re: [5.0.20] New build
Remy Maucherat wrote: The new build is now available (a bit late, but with additional fixes). Thanks for the help with the license transition and the bugfixing. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/ This has no JMX and no Windows installer. The build may not be very useful except for basic regression testing, despite a number of good fixes :( Can you elaborate on may not be very useful? I care nothing for the Windows installer as we produce our own installer for our Tomcat distributions. So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what else is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19 but with more bug fixes? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.20] New build
Remy Maucherat wrote: Jess Holle wrote: Can you elaborate on may not be very useful? Generally, people expect to be able to run a binary out of the box. I concur that this is the normal expectation and that the Tomcat group should pressure the board to ease up. If they don't I might suggest: * A simple Ant-based configuration tool. o That grabs jmx.jar from the web as part of the configuration. I use Ant to configure Apache and Tomcat, but I must admit all components are bundled -- I don't assume a network connection over which to fetch them. So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what else is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19 but with more bug fixes? Nothing. Other than the not ready to run effect, this should be a good release (assuming there are no regressions). Thanks for the info. Once I get a chance I'll check this out. One area of immediate concern: Is jmx.jar an additional top-level jar that must be added to CLASSPATH or java command lines to run Tomcat? Or is it automatically picked up by Bootstrap, etc, as before? [This will clearly affect a number automated configurations if this has indeed changed.] -- Jess Holle
ETA for mod_jk 1.2.6 and mod_jk2 2.0.4
It is my understanding mod_jk2 2.0.4 is due this week and that the plan is to release mod_jk 1.2.6 shortly thereafter. Is this still accurate? Any further light that can be shed on this (e.g. how long to expect to wait for 1.2.6) would be appreciated. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.20] New build
Remy Maucherat wrote: Jess Holle wrote: One area of immediate concern: Is jmx.jar an additional top-level jar that must be added to CLASSPATH or java command lines to run Tomcat? Or is it automatically picked up by Bootstrap, etc, as before? [This will clearly affect a number automated configurations if this has indeed changed.] It's in the manifest of the bootstrap.jar. The change is because the bootstrap needs to register the classloaders so that Tomcat is fully configurable and remotely embeddable through JMX. Ah. So this part of the change is not due to the licensing snafus. That's good to know. Of course, Tomcat will run out of the box on JDK 1.5. As is this. Thanks again. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.20] New build
As these are part of a shipping commercial product, I do not believe I can do so without traversing a significant legal morasse. At a high level they started as simple enough ventures which replace configuration files with tokenized (e.g. @@varName@@) versions and then do replace operations and set permissions appropriately on UNIX. At that level they directly mimic the Apache web server's binary distribution install scripts, but work on UNIX and Windows alike. As time has passed these have grown to allow automated installation of somewhat sophisticated web app configurations in Apache with authenticated and anonymous sub-regions of the web apps and configuration update/regeneration when a new option is added to the configuration. The scripts also support installation as Windows services, creation and installation of self-signed certificates, etc. All of this has been just enough for our application's needs, but none of it is specific to them. -- Jess Holle Tim Stewart wrote: Hey Jess, I would be interested in seeing your ant scripts to configure tomcat and apache. Would you mind posting a URL or sending them to me? Thanks, Tim - Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 9:10 AM Subject: Re: [5.0.20] New build Remy Maucherat wrote: Jess Holle wrote: One area of immediate concern: Is jmx.jar an additional top-level jar that must be added to CLASSPATH or java command lines to run Tomcat? Or is it automatically picked up by Bootstrap, etc, as before? [This will clearly affect a number automated configurations if this has indeed changed.] It's in the manifest of the bootstrap.jar. The change is because the bootstrap needs to register the classloaders so that Tomcat is fully configurable and remotely embeddable through JMX. Ah. So this part of the change is not due to the licensing snafus. That's good to know. Of course, Tomcat will run out of the box on JDK 1.5. As is this. Thanks again. -- 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: [5.0.20] New build
Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). -- Jess Holle Remy Maucherat wrote: The new build is now available (a bit late, but with additional fixes). Thanks for the help with the license transition and the bugfixing. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/ This has no JMX and no Windows installer. The build may not be very useful except for basic regression testing, despite a number of good fixes :( 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]
mod_jk cachesize vs. processes
I've been trying hard to verify something: Is the cachesize configured with mod_jk per process in a multi-child Apache? I'd *assume* so, but I know where assuming tends to get me -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.19] Release vote
Bill Barker wrote: It looked like it should work, but I couldn't free up a machine to test it on (until now :). You can get rid of the messages by adding: request.registerRequests=false to your jk2.properties file. Thanks. What are the other effects of taking this action (and not taking this action)? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.19] Release vote
Tomcat 5.0.19 seems to work well enough. One question, though. I'm now seeing the following messages as I test my application: *Feb 17, 2004 4:59:34 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request* Feb 17, 2004 4:59:38 PM org.apache.jk.server.JkCoyoteHandler action INFO: Response already commited Feb 17, 2004 4:59:38 PM org.apache.jk.server.JkCoyoteHandler action INFO: Response already commited *Feb 17, 2004 5:01:39 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request* *Feb 17, 2004 5:02:02 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0* I'm used to the Response already commited INFOs, but not the other (bolded) stuff. What does it mean? [Apache 2.0.48+, mod_jk 1.2.5, Tomcat 5.0.19, 2.3 web.xml including servlet-sesssion listeners and filters] -- Jess Holle
Re: [5.0.19] Tag tomorrow
Remy Maucherat wrote: As discussed previously. What's the status of the JK 2 release ? Also, I've been seeing mutterings of a JK 1.2.6 release -- any status on that? [Ping and pong, etc, would be nice to have in a released, citable version!] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release plan
Dave Oxley wrote: Henri, What is the current state of JK2. Is it alpha, beta or GA. If this is going to be an alpha release, what is the plan for a GA release. I would like to migrate from JK when it is stable. This is a *very* good question. Last time I dared to ask the consensus was mod_jk was a better idea for a production system -- but there was a good deal of dissent on this question... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Collections 3.0?
Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Collections 3.0?
Remy Maucherat wrote: Jess Holle wrote: Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? It would have been better if either: - 3.0 was backwards compatible with 2.0 :) - it was using different package names Note that you should be able to override and use collections 2.1 inside a webapp even if collections 3.0 is in common/lib, and hopefully it'll work. If it doesn't, there will be a huge mess, and lots of hate mail ;) Or vice versa presumably? If this *should* work, then I can give it a wing, though I've not really sanity checked 3.0 myself -- as we use 2.1 very little and my immediate concern was Tomcat compatibility. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: WebDAV and TC5
George MATKOVITS wrote: Please, PLEASE add it! There is no demand because MOST users do not know any compatible clients! Thank you - George WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Julian Reschke wrote: Jess Holle wrote: WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. I absolutely disagree. Windows comes with two clients (an explorer extension and a filesystem driver), How does the user use the filesystem driver? The end-user certainly cannot achieve anything meaningful via web folders. I did a lot of testing in this regard. Now if there is a better level of usability/functionality achievable with Windows without significant additional client side programming, I'd love to hear more about it -- i.e. I'd love to discover I'm simply ignorant here and find a silver bullet for this issue! MacOSX comes with a drriver, and there's also a Linux FS. Agreed on these counts, but these are 10% of the market. Many major applications (for instance Adobe or OpenOffice) support it as well. WebDAV is robust and interoperability is actually quite good. OpenOffice is very small in terms of market share, though I certainly wish it all the best! Adobe is also fairly small in terms of market share. What is really necessary is an across-the-board file-system and desktop GUI level integration such that all applications on the OS get some level of functionality with WebDAV (including open and save as a minimum!) and those that are DAV-aware may get more. App-by-app DAV awareness is *much* less interesting as it is guaranteed to be inconsistent between apps and as a server-vendor one can't depend on it being present in the client apps. I've not seen any means to achieve this across-the-board functionality with Windows (and again, *please* prove me ignorant here). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Shapira, Yoav wrote: Howdy, I don't think small market shares or lack of clients is a reason for exclude a server feature. They are separate. If the WebDAV app added some negative impact to the tomcat server, then take it out, but if not, then lets add it back in. Even if WebDAV is useful in the general sense (I tend to agree with Senor Holle that it's not, I don't feel strongly either way), I think it's telling that no one complained when we removed it. Anything we add that's not used is bloat by definition, and more for us to maintain. Of course, we already do have a WebDAV servlet shipping with tomcat5, and that's the main part. What else did you (Mark T.) think of adding to the distribution? This gets me thinking again of the idea of a minimal build: no webdav, no CGI, no examples, no docs, no balancer, minimal server.xml as the default, etc, so as to minimize download size and cater to those users who know what they're doing and just want to drop their webapp into tomcat. Jakarta could have a minimal Tomcat binary + a set of standard Jakarta add-on web-apps. Add a standard web app catalog viewer to Tomcat and you're set. Right? [At that point Tomcat would be kind of like what NetBeans tries to be in this regard, which is pretty nice -- all other aspects of NetBeans aside.] -- Jess Holle
Re: [OT] Re: WebDAV and TC5
Remy Maucherat wrote: Yes, but soon you're going to pitch a HTTP-server-in-100k, complete with its own proprietary API ;) The embedded distribution is IMO good for a minimal distribution. I for one wasn't about to :-) Rather I think that the module-catalog approach broadens the exposure of the user-community to these modules (rather than them just getting overlooked since they're in there somewhere) and allows separate release points -- which is a dual-edged sword... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
Remy Maucherat wrote: Jess Holle wrote: Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their SunONE is better performed / more scalable than Apache 2 + Tomcat benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). I realize that the extra inter-process hop and marshalling incurred by mod_jk[2] are bound to cause some reduction in throughput. I was actually more concerned by the (lower) scalability plateaus they are showing for Tomcat than the performance per se. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
In general, I agree that general benchmarks are useless and can be slanted towards any alternative you choose. Also I agree that Tomcat generally seems to perform quite well and reliably. -- Jess Holle Peter Lin wrote: As usual, these types of comparisons aren't really useful or even desirable. I remember there used to be a benchmark JSR, but it was with drawn. one of these days, a standard set of web and ejb benchmark apps should be created. that way, instead of the usual simple jsp tests, the performance measurements would be more indicative of how a webapp might perform. from my own experience with coyote connector, it is equal to SunOne, orion, resin, and weblogic. this is based on real applications benchmarked on several servlet containers. Compared to Tomcat 3.2 and older, TC5 has made great strides and remy has worked his butt off. I won't bother pointing out flaws in other servlet containers, since it leads to flame wars. you can google for that information yourself. peter lin Remy Maucherat [EMAIL PROTECTED] wrote: Jess Holle wrote: Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their SunONE is better performed / more scalable than Apache 2 + Tomcat benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
Re: [5.0] Three proposals
Remy Maucherat wrote: Here are some new proposals. 1) Optimization of the session implementation. The session is not a thread safe object. In Tomcat, the session implementation is partially thread safe for some reason (this has been like that since Tomcat 4.0, AFAIK). As a result, we can remove some synchronization. The code should also be simplified (fewer HashMap lookups - ex: remove will return the removed object if there was one, so removeAttribute should be a lot simpler), and avoid event object allocations when it is not useful. As a result of this, setAttribute will become much faster. In addition to this, I will experiment with fixing bug 26051, and will need to add a new endAccess method to the Session interface to do this. All this are rather high risk changes, and should not be ported to 4.1.x. Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their SunONE is better performed / more scalable than Apache 2 + Tomcat benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.18] Release vote
Jeanfrancois Arcand wrote: ballot Release 5.0.18 as Stable: [X ] Yes [ ] No /ballot I don't actually have a vote (not being a commiter or any such), but I'd ditto the stable rating for 5.0.18. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of JTA integration
Remy Maucherat wrote: Jeff Tulley wrote: Last I checked (a while ago, admittedly), JBoss was architected such that you can deploy only the pieces you need - VERY modular. So, you can make it not a monster, but rather just Tomcat + JTA, if I am not mistaken. It seemed at the time (early JBoss 3.0 days) that such a thing was not that hard either. That's the idea, and it didn't change with JBoss 3.2.x. I think it would have been a terrible idea to change this ;-) As a reminder, I work for Jboss Group. My goal is to: - be more responsive, and sync as fast as possible JBoss with Tomcat - improve the quality of the Tomcat integration (in progress) - offer a seamless upgrade path from Tomcat standalone should some J2EE features become needed Cool. Along the lines of the original thread -- I believe it is truly a shame that one must generally drag in an entire app server in order to get JTA / transaction management support. [Sheesh -- you'd think you needed an entire app server to do anything from the current state of affairs, when the reality is that Tomcat is all you need for a lot of things.] I understand JBoss is architected to be modular, separable, etc. It would be great if someone could go one step further and produce a seamlessly Tomcat pluggable, JTA-only sub-distribution of JBoss -- or just an Ant script to produce that from a normal JBoss distro or CVS label. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
This sort of memory leak can't be left unaddressed -- i.e. you shouldn't have to change the settings to avoid an intolerable memory leak. Is this issue new to 5.0.17 or was it in 5.0.16 as well? In either case, it would be good to see this fixed in 5.0.17 -- but it is all the more critical if it was initially broken in 5.0.17! -- Jess Holle Filip Hanik wrote: I dont think setting maxSpareThreads==maxThreads is a good solution to a problem as this memory leak. I still have to verify that that would actually solve the problem if we don't want to remove request info, lets fix it. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:24 AM To: Tomcat Developers List Subject: Re: Found it - WAS: Memory leak Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. 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]
5.0.17 Feedback
5.0.17 seemed to work fine overall [though I'm anxiously awaiting the memory leak resolution] -- including the new useBodyEncodingForURI flag :-) I did notice that out of 992 JSP pages Tomcat 5.0.16 has successfully compiled (via an Ant precompilation using Tomcat's jspc) only 899 were successfully compiled by 5.0.17. I looked into this further and discovered that 5.0.16 misreported 3 failures as successes as the jspc task failed but did not signal such. Thus Tomcat 5.0.17 is a nice improvement in this regard! -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.17 Feedback
Shapira, Yoav wrote: Howdy, I did notice that out of 992 JSP pages Tomcat 5.0.16 has successfully compiled (via an Ant precompilation using Tomcat's jspc) only 899 were successfully compiled by 5.0.17. I looked into this further and discovered that 5.0.16 misreported 3 failures as successes as the jspc task failed but did not signal such. Thus Tomcat 5.0.17 is a nice improvement in this regard! I hope you meant 902 and not 992? Good catch. I actually mean 992 and 989 respectively. I transposed the 8 and 9 in the latter statistic -- i.e. only 3 JSPs out of 992 failed to compile with 5.0.16 but were not noted as failures only to be noted as such by 5.0.17. Which means that neither our JSPs nor 5.0.16 was that far amiss -- but 5.0.17 is a definite improvement in this regard. -- Jess Holle
Re: DO NOT REPLY [Bug 25958] New: - Request.setCharacterEncoding doesn't work properly if you send form via get method and if you go to another page via link
Note that Sun suggests use setCharacterEncoding() for exactly this purpose in their new how-to article at http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/. Amongst other things they say (under the heading Handling Request Parameter Encodings and after having described request.setCharacterEncoding()): If the application always sends pages in UTF-8, it can simply specify this encoding as the request encoding. So Sun is clearly messaging that this is a good, standard means for web-app developers to address the problem. I'd suggest that the out-of-the-box default settings be for the suggested Sun techniques to work... -- Jess Holle
Re: Bug 23929: ServletRequest.setCharacterEncoding()
From a developers point of view however, applying the above two points a) brakes expected behaviour (setCharacterEncoding() method does not work the same as before) b) does not give an acceptable alternative (if all parameter passing could be solved with POST method, then the GET method would not be needed, would it?) c) a lot of web apps stopped working when an upgrade of the tomcat version was performed So I think it is legitimate to be upset when first confronted with this change of behaviour. I will not claim that I was reasonable when originally confronted with the change. I will say that: 1. Our existing (4.1.x) usage of setCharacterEncoding() works across all recent servlet engines tested [including 2 commercial servlet engines] -- and is thus some indication of a de facto standard. 2. It would seem from examples provided with setCharacterEncoding() by Sun that the intent is to include request parameters and that thus this should be the default operation of this API rather than requiring additional configuration to obtain this behavior. As for how easy it is to NOT file duplicate bugs on this issue, having followed this debate, I have collected the following list of somehow related bugs I did searches again after being scolded by Remy. I must admit that I must have crossed wires when doing searches and filing bugs and somehow managed to miss this search (which it is my habit to do). Speaking for myself and having reread these messages: Assuming I 've been working for some time with the old behaviour and experienced the new one, I would not be able to understand why this change was made, EVEN if someone gave me the above list of bugs. Agreed. Without a short summary attached to the bugs I would still have filed a new bug and argued to high hell... -- Jess Holle
Bug 23929: ServletRequest.setCharacterEncoding()
Remmy, et al: The API is *not* optional. It is a required part of the servlet spec. It works just great in Tomcat 4.1 and is not an acceptable regression in Tomcat 5. I am thus one step away from re-opening this bug (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929) I cannot use the encoding setting on the connector as the standard handling of servlet parameters is ISO-8859-1 decoding unless setCharacterEncoding() is used to specify something else. All of our other code thus follows this standard carefully (and works across all servlet engines tested). [This includes handling multi-byte data in servlet parameters.] This does require some careful shuffling to workaround the fact that the wrong encoding was used by the servlet engine and to use the correct one (UTF-8 in most, but not all, cases). We do, however, have some code which leverages this new API to setCharacterEncoding(UTF-8) -- which is, in fact, very nice to have. I can see that it can be obnoxious for implementation -- but users of the API do not and should not care. Tomcat 5 has a lot of promising things over Tomcat 4.1 -- don't let spec non-compliance force those who are forced to care about rigorous i18n to tell our customers to use Tomcat 4.1 or pay for a commercial servlet engine if they want later spec compliance. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 23929: ServletRequest.setCharacterEncoding()
Remy Maucherat wrote: Jess Holle wrote: Remmy, et al: The API is *not* optional. It is a required part of the servlet spec. Great. I didn't know that ;-) How about: - Not CCing me. I'm subscribed to tomcat-dev already. thanks. Sorry. - There's big threads, commit messages (incl recent ones), and bugs on this issue. How about reading that before writing an email about how bad things are. I did search the archives for such threads before even filing my duplicate bug, so apparently my searching is inept. I'll look again, but pointers would be appreciated. BTW, there's no bug. It would be nice if the bug comments described why it is not a bug. I understand Bugzilla is not a discussion forum, but it would really help future reporters of an issue not to resurrect old issues if the bug comments contained a final summary as to why the bug was closed as INVALID. Did I and the other reporter mis-use the API? The API presumably must work, so how are we misuing it so that it does not? If it does not work, then how does this meet the spec? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 23929: ServletRequest.setCharacterEncoding()
Remy Maucherat wrote: Jess Holle wrote: - There's big threads, commit messages (incl recent ones), and bugs on this issue. How about reading that before writing an email about how bad things are. I did search the archives for such threads before even filing my duplicate bug, so apparently my searching is inept. I'll look again, but pointers would be appreciated. For example: remm2003/12/10 14:26:28 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java mbeans-descriptors.xml Log: - Add a flag to allow using the encoding specified in the contentType for the URI paramters. This is disabled by default, not compliant with the standards, but present for compatibility. But as per my previous message I /cannot /change this on a connector basis. I /must /make this determination on a per-request basis -- /and the servlet spec specifically allows me to do this via the setCharacterEncoding() API as I read it/. There's a query page in BZ, also, and as I said, many threads on tomcat-dev (use the archives). I queried both at some length -- especially BZ. I'll query the tomcat-dev archives further, but again a simple synopsis of how Tomcat's behavior satisfies the spec and is thus not a bug attached to the bug would save everyone a lot of trouble in cases like this. In other words, where a bug that from all indications appears to be a spec violation is closed as INVALID an explanation attached to the bug itself would be a *very* good idea. -- Jess Holle
Re: Bug 23929: ServletRequest.setCharacterEncoding()
Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: For example: remm2003/12/10 14:26:28 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java mbeans-descriptors.xml Log: - Add a flag to allow using the encoding specified in the contentType for the URI paramters. This is disabled by default, not compliant with the standards, but present for compatibility. But as per my previous message I /cannot /change this on a connector basis. I /must /make this determination on a per-request basis -- /and the servlet spec specifically allows me to do this via the setCharacterEncoding() API as I read it/. The content-type header and your setCharacterEncoding call both control the request entity body character encoding. So if using the entity body encoding *also* for URI parameters, what would you think it would do ? This is a good question -- but one which only applies to POST. My bug case was explictly with GET. If there is an entity body encoding specified in the request, then I am not sure which should override. If there is not, then I would presume setCharacterEncoding() should win out. If the only issue is when these differ, then I believe that site designers should simply ensure they don't. There's a query page in BZ, also, and as I said, many threads on tomcat-dev (use the archives). I queried both at some length -- especially BZ. I'll query the tomcat-dev archives further, but again a simple synopsis of how Tomcat's behavior satisfies the spec and is thus not a bug attached to the bug would save everyone a lot of trouble in cases like this. In other words, where a bug that from all indications appears to be a spec violation is closed as INVALID an explanation attached to the bug itself would be a *very* good idea. Sorry, I'm not a broken record, and I will not go on repeating the same stuff over and over 20 times. Just once on the one of the bug reports in the duplicate chain would suffice. [At least in my handling of our internal bug system it is common place to copy/paste the final status from e-mail threads and/or lists into the bugs attachments when closing the bug.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
Remy Maucherat wrote: Jan-Henrik Haukeland wrote: Remy Maucherat [EMAIL PROTECTED] writes: My opinion is that NIO is going to be really useless. Eh, hello!? Oh, okay if it's not important that Tomcat scale and perform well it may be useless. But, really, before NIO it was hopeless to try and write a scalable and fast tcp server application in Java. Tomcat's current connection handling with blocing all over the place and thundering herd problem doesn't scale or work very well under heavy load. You apparently have a very strong opinion on this, and that's fine. You also obviously don't know what you are talking about. The purpose of Tomcat is to make the web tier of an application server (Tomcat is actually a mini application server), not some kind of non blocking I/O toolkit to be used to build fixed function servers. Non blocking I/O has great applications, and is a very useful technology, but it does not apply to the application server world. I think you should find a servlet container which has NIO, compare with Tomcat 5.0.16, and come back to report your findings about how much scalability or speed NIO brings (note: doing the non blocking socket handling in a native layer doesn't really count, since it's not a fair comparison with Java's NIO; you might as well use Apache). Bring facts, not useless rants. I've lost the reference but did anyone else see the non-blocking NIO plug-in that was supposed to fit right into Java things like Tomcat and solve all their performance/scalability issues? I saw this touted somewhere recently. It sounded *way* too good to be true, but was interesting. I'm thinking it was called something like JEngine or something equally vague... What little I could make out from the info at the time seemed to suggest that it might be nice (assuming it worked) if you wanted to allow Apache to keep loads of connections open to a non-blocking IO layer in Tomcat without burdening it as much as this would normally imply. Of course the next layer of Tomcat needs to wait on the thread pool anyway, so I'm not sure what the real benefit over a reasonably sized mod_jk[2] connection pool really is... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Dan Johnsson wrote: Jess Holle wrote: Tim Funk wrote: Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: /.../ * The amount of content specified in the setContentLength method of the response has been written to the response. * That's what I figured. I'm just a bit uncertain about the corner/end case where nothing is to be written to the response, i.e. for a content-length of 0. \ It becomes clearer to me if I rephrase The amount /.../ has been written /.../ to the in this context supposedly equivalent At least the amount /.../ has been written /.../. Then the special case of 0 becomes: At least zero bytes have been written to the response. which is indisputably true, and thus the response object is to be closed. I am absolutely in agreement that Tomcat is in line with the letter of the spec here. I just think that the a few more letter should really present as it seems inappropriate for a setContentLength(0) to commit a response. -- Jess Holle
Tomcat 5 Issue (not 5.0.16 specific!)
First, I'd like to say that we should *not* consider the following issue as one to prevent a stable label for Tomcat 5.0.16. That said, I've noted that if you do: response.setContentLength( 0 ); All subsequent setHeader(), etc, calls are ignored -- Tomcat considers the response commited. Is this as per the spec? Or is this an odd corner case? [The fact that we have code that does a setContentLength(0) seems to be an odd corner case in and of itself... I've worked around this in our code by ensuring that this call is always made after all other headers are assigned.] -- Jess Holle
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Tim Funk wrote: Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: The termination of the service method of the servlet. * The amount of content specified in the setContentLength method of the response has been written to the response. * That's what I figured. I'm just a bit uncertain about the corner/end case where nothing is to be written to the response, i.e. for a content-length of 0. The sendError method is called. The sendRedirect method is called. Looks like the behavior is OK. I was kind of guessing this was to the letter of the spec -- I'm fine with my changes (which would not have been necessary but for some old mechanisms which produce a hash of headers and toss them at code which simply spits them at the response in hash order -- with a few special cases to use more specific methods where possible). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.16
I don't have a vote, i.e. I'm not a committer, but for what it's worth: Remy Maucherat wrote: ballot Release 5.0.16 as Stable ? [*X*] Yes [ ] No /ballot I saw no issues (other than an issue with javac, not Tomcat) with 5.0.15 and have not seen any with 5.0.16 either. -- Jess Holle
Pre-compiling one JSP page at a time?!?
I look at the Tomcat 5 documentation for pre-compiling JSP pages and at the 5.0.15 source for JspC -- and as best I can tell there is absolutely no way to specify a particular set of JSP pages to compile at a given time. Nested include elements don't work (as they are documented to in Ant's optional JspC task). There is a setArgs(), but it takes an array of Strings -- which I don't believe will automatically be coerced out of any normal Ant property. What am I missing? I need to be able to compile one JSP page at a time for validation purposes in a large-team environment. I need to know exactly which JSP pages pass and fail. To complicate things there are a lot of JSP fragments that have .jsp suffixes, so we know a number will fail and would like to exclude them. Is there some way I should be using Ant's JspC in conjunction with Tomcat 5 to get the right result or... what? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ETA for Tomcat 5.0 Stable?
J2EE 1.4 has been released! As I understand (from personal use as well as that from lurking here), Tomcat 5.0 should be ready to be tagged any day as 5.0.15 and to achieve a stable rating. -- Jess Holle Jess Holle wrote: Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: Jess Holle wrote: Now that J2EE 1.4 is going final this week, what is the ETA for a stable Tomcat 5.0.x release? It was my understanding that some Tomcat 5.0.x releases *might* have been considered stable, but this label was not considered since J2EE 1.4 was not yet final. We did fix bugs since, so that means the initial 5.0.x should be a lot more polished than previous .0.0 Tomcat releases. So where are we at now? Is 5.0.14 likely to be considered stable once J2EE 1.4 is? Or is a 5.0.15 coming down the pipe shortly? I see no specs here: http://www.jcp.org/en/jsr/detail?id=151 No specs = no 5.0.15. Understood. I'm by no means saying the Tomcat crew is not on the ball! Rather the press statements by Sun, etc, are that all this stuff is going final this week. The J2EE 1.4 was approved by vote as a final spec and Sun is supposed to releasing the spec itself and a new SunONE version supporting it as well -- both this week. The rumors say today, so if it's early enough for me (I'm in Europe) I'll tag Tomcat CVS at the same time. Otherwise, I'll tag it tomorrow. As for uploading the 5.0.15 build, it will likely happen tomorrow. Counting the vote, we're looking at the end of the week if there are no problems. Unless someone is blowing smoke here, I am thus assuming that 5.0.14 or a quick 5.0.15 will be up for a stable vote shortly *after* that occurs. I'm just trying to get an understanding as to whether this assumption is presumptuous -- and how things are likely to play out at that point. Specifically, I'm trying to determine how quickly/agressively to test Tomcat 5.0.x and whether 5.0.14 is a good target for this activity. With the exception of the charset issue, TC 5.0.14 seems like a decent build. Or you can get a nightly build, since the last one will be mostly equivalent to 5.0.15. Thanks for the info. That's exactly what I wanted to hear. -- 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: [5.0.15] Test build available
Tomcat 5's tomcat.exe and tomcatw.exe do not work in the manner then used to in Tomcat 4.1.29. Can someone please point me to information on the changes? Or is the intent that tomcat.exe should work as it did in 4.1.29? [In which case, it clearly does not.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ETA for Tomcat 5.0 Stable?
Rather the press statements by Sun, etc, are that all this stuff is going final this week. The J2EE 1.4 was approved by vote as a final spec and Sun is supposed to releasing the spec itself and a new SunONE version supporting it as well -- both this week. The rumors say today, so if it's early enough for me (I'm in Europe) I'll tag Tomcat CVS at the same time. Otherwise, I'll tag it tomorrow. As for uploading the 5.0.15 build, it will likely happen tomorrow. Counting the vote, we're looking at the end of the week if there are no problems. FYI: As you may well have already seen/heard, the official press statements are now saying that the 24th, i.e. next Monday, is now the official spec, etc, release date. Looking forward to 5.0.15 stable :-) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ETA for Tomcat 5.0 Stable?
Now that J2EE 1.4 is going final this week, what is the ETA for a stable Tomcat 5.0.x release? It was my understanding that some Tomcat 5.0.x releases *might* have been considered stable, but this label was not considered since J2EE 1.4 was not yet final. So where are we at now? Is 5.0.14 likely to be considered stable once J2EE 1.4 is? Or is a 5.0.15 coming down the pipe shortly? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ETA for Tomcat 5.0 Stable?
Remy Maucherat wrote: Jess Holle wrote: Now that J2EE 1.4 is going final this week, what is the ETA for a stable Tomcat 5.0.x release? It was my understanding that some Tomcat 5.0.x releases *might* have been considered stable, but this label was not considered since J2EE 1.4 was not yet final. We did fix bugs since, so that means the initial 5.0.x should be a lot more polished than previous .0.0 Tomcat releases. So where are we at now? Is 5.0.14 likely to be considered stable once J2EE 1.4 is? Or is a 5.0.15 coming down the pipe shortly? I see no specs here: http://www.jcp.org/en/jsr/detail?id=151 No specs = no 5.0.15. Understood. I'm by no means saying the Tomcat crew is not on the ball! Rather the press statements by Sun, etc, are that all this stuff is going final this week. The J2EE 1.4 was approved by vote as a final spec and Sun is supposed to releasing the spec itself and a new SunONE version supporting it as well -- both this week. Unless someone is blowing smoke here, I am thus assuming that 5.0.14 or a quick 5.0.15 will be up for a stable vote shortly *after* that occurs. I'm just trying to get an understanding as to whether this assumption is presumptuous -- and how things are likely to play out at that point. Specifically, I'm trying to determine how quickly/agressively to test Tomcat 5.0.x and whether 5.0.14 is a good target for this activity. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ETA for Tomcat 5.0 Stable?
Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: Jess Holle wrote: Now that J2EE 1.4 is going final this week, what is the ETA for a stable Tomcat 5.0.x release? It was my understanding that some Tomcat 5.0.x releases *might* have been considered stable, but this label was not considered since J2EE 1.4 was not yet final. We did fix bugs since, so that means the initial 5.0.x should be a lot more polished than previous .0.0 Tomcat releases. So where are we at now? Is 5.0.14 likely to be considered stable once J2EE 1.4 is? Or is a 5.0.15 coming down the pipe shortly? I see no specs here: http://www.jcp.org/en/jsr/detail?id=151 No specs = no 5.0.15. Understood. I'm by no means saying the Tomcat crew is not on the ball! Rather the press statements by Sun, etc, are that all this stuff is going final this week. The J2EE 1.4 was approved by vote as a final spec and Sun is supposed to releasing the spec itself and a new SunONE version supporting it as well -- both this week. The rumors say today, so if it's early enough for me (I'm in Europe) I'll tag Tomcat CVS at the same time. Otherwise, I'll tag it tomorrow. As for uploading the 5.0.15 build, it will likely happen tomorrow. Counting the vote, we're looking at the end of the week if there are no problems. Unless someone is blowing smoke here, I am thus assuming that 5.0.14 or a quick 5.0.15 will be up for a stable vote shortly *after* that occurs. I'm just trying to get an understanding as to whether this assumption is presumptuous -- and how things are likely to play out at that point. Specifically, I'm trying to determine how quickly/agressively to test Tomcat 5.0.x and whether 5.0.14 is a good target for this activity. With the exception of the charset issue, TC 5.0.14 seems like a decent build. Or you can get a nightly build, since the last one will be mostly equivalent to 5.0.15. Thanks for the info. That's exactly what I wanted to hear. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org
jean-frederic clere wrote: Glenn Nielsen wrote: Joseph Shraibman wrote: ./configure -with-apxs=/usr/local/apache2/bin/apxsGlenn Nielsen wrote: As part of the mod_jk 1.2.5 release I promised to move the JTC download to BTW you forgot to generate a configure file for the release, users will have to run buildconf.sh Running buildconf.sh is in the building mod_jk from source instructions. That is not what the other products are doing and that will bring complex questions about autoconf/automake. I think we have to deliver a configure not a configure.in Agreed! When you hop onto an unfamiliar system with almost no gnu tools (e.g. you're lucky to have gcc) and have to build mod_jk needing autoconf, m4, libtool, etc, etc, becomes a real hassle! Enough of one that I've been using makefiles from previous mod_jk releases instead. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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.5 test release source distribution
Actually from my reading of jk_version.h this change was already made in the test release. [And the version string shows up as 1.2.5 on Windows.] Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Glenn Nielsen wrote: I have generated a test release source distribution for mod_jk 1.2.5, you can find it at: http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test on as many OS/web servers as possible. I have already tested on Solaris7/8 Sparc. If there are no problems with this source release I will call for a release vote Friday 9/12 and release Monday 9/15 if the vote passes. I note that this date has come and gone. Is there an ETA for this release. Sorry not to have gotten back to anyone with the info, but the test source worked fine in reasonably extensive use with Apache 2.0.47 on Windows and some quick tests on Solaris 9 and AIX 4.3.3 with Apache 1.3.28. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 3.3 Estimated Release Date
Is there a new estimate for the Tomcat 3.3 release date? The classloader separation and performance improvements are really attractive, but I really need to know when to expect their availability or they're of no use (until well after their release). -- Jess Holle -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 01, 2001 6:36 PM To: [EMAIL PROTECTED] Subject: RE: PATCH: jk_nt_service enhancements - TC3.3 Hope this is better. By the way the new features are: Allow adding of service dependancies Allow adding of service with different user name Allow adding of service as Automatic startup New functions to start and stop services on remote machines Going to add a Bugzilla entry now... Dave [EMAIL PROTECTED] From: Ignacio J. Ortega [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: PATCH: jk_nt_service enhancements - TC3.3 Date: Sat, 1 Sep 2001 20:16:58 +0200 Hola David: Could you send the patch as a diff -u? Better if you fill a bug report as a request for enhancements, and attaches the patch to it, so we can follow the issue more closely.. Thanks for the feedback and the patch.. Saludos , Ignacio J. Ortega -Mensaje original- De: Dave Oxley [mailto:[EMAIL PROTECTED]] Enviado el: sábado 1 de septiembre de 2001 14:15 Para: [EMAIL PROTECTED] Asunto: PATCH: jk_nt_service enhancements - TC3.3 I've made a couple of enhancements to jk_nt_service. Attached is a patch for jk_nt_service.c and the documentation. This change was made against HEAD of jakarta-tomcat. Can someone check it over for possible check in. Dave [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
