RE: More helpful reporting of exceptions in JSPs
The 'correct' way to do this is to create an enhancement request in bugzilla and attach your patch to it. Mark -Original Message- From: Tim Fennell [mailto:[EMAIL PROTECTED] Sent: Sunday, October 09, 2005 10:50 PM To: tomcat-dev@jakarta.apache.org Subject: More helpful reporting of exceptions in JSPs Hi, I'll apologize in advance if this is the wrong place to post this, or if this has been covered before. I had a good read through the Tomcat docs and faqs, searched the bug database, and googled around on the topic, but could not really find anything. I've been using Tomcat for a while, and in general have found it as good a servlet/JSP container as any I've used. With one exception (no pun intended). A long time ago I started out using WebLogic, and the one thing that I loved about WebLogic, that is missing from Tomcat, is that when an Exception occurred in a JSP it would tell you what line number *in the JSP* generated the exception, and show you a snippet of code around the offending line. For quite a while I'd figured that the way Tomcat was built prevented this from being easy/possible, but I didn't look. Well, I finally got around to looking, and it only took me a couple of hours to implement it. Which makes me wonder if there is some other reason that this isn't done in Tomcat/Jasper? At any rate, I have code that will do this now, and I think it'd be a great productivity boost for anyone else developing JSPs on Tomcat. It amounts to small patches to two files. The first is org.apache.jasper.compiler.Compiler to make it hang on to the parse tree (pageNodes) if in development mode, and a getter to make this accessible. The second is to org.apache.jasper.servlet.JspServletWrapper to do the grunt work of mapping a stack frame from the exception back to the line in the JSP that it came from. It's all coded up to function only when in development mode, and is reasonably well commented. Would any of the committers be interested in taking a look at this if I put together a patch and posted it here? Cheers, -Tim Fennell http://stripes.mc4j.org - 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: New repository org
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache Mark Thomas wrote: Using externals wasn't something I had thought of but if offers a nice way to provide all the source for one version in a single checkout. We now have tomcat/current/5.5.x that uses externals to link in all the various modules. That's actually what I was thinking about, looks great. Now, the big question - where can I add a sandbox/experimental directory? Directly under tomcat. And I would suggest that each project/experiment should have its own subdirectory under /tomcat/sandbox/ Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Costin Manolache wrote: Could we just move all in tomcat5.5 ( and HEAD ) into one repository ( say, tomcat ) ? The ASF has only one SVN repo and we have a top level directory within that. We need to have all our code, including the history, under this directory as CVS will be turned off. The directory strcuture may not be the nicest in the world but I spent some time thinking about it and it is the best I could come up with. There is a better, but longer, explanation on the svn page I put together for the TLP. Take a look at http://people.apache.org/~markt/tomcattlp/svn.html Using externals wasn't something I had thought of but if offers a nice way to provide all the source for one version in a single chekcout. We now have tomcat/current/5.5.x that uses externals to link in all the various modules. Mark Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separate repos. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Remy Maucherat wrote: Hi, Since the previous naming scheme has jakarta everywhere, I propose we change it to (I'll do the updating of the build scripts): http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x - build http://svn.apache.org/repos/asf/tomcat/connectors/trunk - connectors http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x - container http://svn.apache.org/repos/asf/tomcat/jasper/trunk - jasper http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x - servletapi If I misunderstood about how Subversion should be used and this is not a good way to organize things, let me know ;) If by this you mean do a checkout of http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x to a directory called build in the build scripts then +1. If it involves any form of svn move -1 since I don't understand what you are planning to move to where and I have concerns about complications that might be created for checkouts, future branches and future tags. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Schedule
Henri Yandell wrote: On 10/6/05, Remy Maucherat [EMAIL PROTECTED] wrote: Remy Maucherat wrote: There seems to be a problem with those two. http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/ contains what was in jakarta-tomcat-catalina, and jakarta-tomcat-5 appears to be gone. *grin* Ritually disembowelling myself sah! I found jakarta-tomcat-5, which is now at http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x/. Anything I can help with, or is it all good? I think all is OK. I changed the plan for this bit since the original proposal and this caused some temporary confusion. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Remy Maucherat wrote: The Struts trick does what I want. I see magic things in the .svn/dir-props, but obviously I don't know how to set it up properly. Adding a current magic folder doing the same would be good, and I think you can add some release/vX.Y.Z folders as well. I can set this up quite quickly. I'll start setting up the following. If this isn't what we want we can always delete it and start again. /tomcat /current /tc5.5.x /build /container /jasper /connector /servletapi /tc4.1.x /container /jasper /connector /servletapi /tc3.3.x /container /connector /servletapi I'll make sure these link to the right branches I can also add /tomcat /release /tc5.5.12 /build /container /jasper /connector /servletapi /tc5.5.11 /build /container /jasper /connector /servletapi etc although his will take a little bit of time to setup/script. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Yoav Shapira wrote: Hi, When a new release is cut, e.g. v5.5.13, would SVN links need to be updated so current downloads v5.5.13? Is there a script for that? Yoav My intention is that current will point to trunk (HEAD in CVS terms) as it does in struts. The first attempt for 5.5.x is done. A browser view of https://svn.apache.org/repos/asf/tomcat/current/5.5.x will show an empty directory but if you check it out you should get the complete set for the latest 5.5.x code. I should be able to add a target to ant that adds a similar shortcut for a given release. Thinking about it, I should be able to script creating the tags for the release as part of the same target. Just to give everyone a heads up, I will be out of circulation for 3 weeks from this weekend. I am off to Las Vegas to get married and then New England for my honeymoon. I'll do what I can before I go but I need to finish packing ;) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Mark Thomas wrote: https://svn.apache.org/repos/asf/tomcat/current/5.5.x will show an empty That should be https://svn.apache.org/repos/asf/tomcat/current/tc5.5.x tc4.1.x and tc3.3.x are also set up now too. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Web Apps???
This question belongs on the tomcat-user list. Please read http://jakarta.apache.org/site/mail.html mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Schedule
Mark Thomas wrote: Mladen Turk wrote: Can somebody make a firm statement on the timings? 1. Until when (Date:Hour:Minute) commits could be done 2. Wen the CVS will be locked for commit (same format) This is now set for Wednesday 5th October 2005 at 8pm US Eastern time. It should be completed by 11pm US Eastern time. Locking CVS will be the first stage of this process. See the JIRA issue for the full detail (http://issues.apache.org/jira/browse/INFRA-562). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Schedule
Mladen Turk wrote: Hi, Any update on the schedule? I have couple of fixes, commits, etc, but IIUC the transition should happen last weekend, so I've postpone all that, but it seems that CVS is still operational. Can somebody make a firm statement on the timings? 1. Until when (Date:Hour:Minute) commits could be done 2. Wen the CVS will be locked for commit (same format) No, as we are dependent on infrastructure resource to do this. 1 2 will be the same time. The current position is: - we can continue to use CVS - infrastructure will notify us via tomcat-dev when the migration is planned to take place - the first step in the migration will be to lock CVS My advice is to continue to commit to CVS until we find out when the migration will take place. Once we have a time for the migration this gives us our deadline to work to for completing any remaining changes and committing them. Personally, I intend to have any outstanding commits completed well before this time. See the JIRA issue for the full detail (http://issues.apache.org/jira/browse/INFRA-562). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r291334 - /tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
Bill Barker wrote: - Original Message - From: [EMAIL PROTECTED] +[4.1.32] Commons Daemon + Upgrade to 1.0 + I hope you plan to upgrade to 1.0.1, since 1.0 is buggy ;-). Thanks for the heads up. I was going to do a general review of all the library versions at some point. This looks like a good reason to do it now. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help How to implement a valve ??
Ron Kiat wrote: We're thinking of using JSF 1.2 that has the same EL as JSP 2.1. Does Tomcat 5.5 support the incoming JSP 2.1 (with support for the new EL)? Thanks, Ron Kiat No it does not. This will be part of Tomcat 6. Work on Tomcat 6 is unlikely to start until we have complete the transition to a TLP (hopefully in a few weeks time). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migration of TC5 to subversion
The test migration has now been completed and is available to view at: http://svn.apache.org/repos/test/tomcat/build http://svn.apache.org/repos/test/tomcat/container http://svn.apache.org/repos/test/tomcat/jasper http://svn.apache.org/repos/test/tomcat/connectors I made the following changes from my original migration proposal: - j-t-catalina - /tomcat/container - j-t-5- /tomcat/build - added a /tomcat/connectors/tags/jk1.2.x directory The first two changes were because using structure of my original proposal made it very difficult to migrate branches and tags for these modules. The third change just seemed like a good idea. Also, when reviewing the test repository be aware that I made an error in my script (now fixed) and some of the 5.0.x tags are missing for the connector module. They will be present in the final migration. Finally, it looks like we never tagged jasper and the connectors for 4.1.6. I do not plan to do anything about this. We can fix this later if we have to. My intention is to give everyone 96 hours from now to review the repositories. Assuming no complaints and infrastructure availability, the migration will take place some time around 18.00 GMT Tuesday 27 September 2005. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help How to implement a valve ??
You need to extend the SingleSignOn valve as any valve doing single sign on must be an instance of SingleSignOn. Search AuthenticatorBase for SingleSignOn to see why. Mark Bovy, Stephen J wrote: I would like to create a modified version of SingleSignOn valve, I copied it and re-named it ThreadSignOn But when I add the Valve / with my new valve name nothing happens. I had expected the same behaviour as the original, but that does not happen. What are the steps procedures ? What am I missing ? Stephen Bovy Computer Associates 6100 Center Drive Suite 700 Los Angeles, CA 90045 Tel: (310) 957-3930 Fax: (310) 957-3917 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: cvs commit: jakarta-tomcat-5 build.xml
[EMAIL PROTECTED] wrote: remm2005/09/22 03:39:37 Modified:.build.xml Log: - Fix build by excluding tagPlugins.xml. - This file shouldn't be in the standard examples, but rather copied there before precompiling (once it works again, of course). This should be unnecessary. Bill has already removed the file from SVN. For the record, all members of the tomcat pmc have karma for all modules including the specs. This allows us to fix issues with the examples. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.xml
Yoav Shapira wrote: Hi, Will Yoav tag the CVS or SVN for the upcoming release ? I was going to tag both repositories this one time. I am 99% sure that you will not be able to tag the CVS repositories that have already migrated since they will be locked. This will only affect servletapi for TC5. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Remy Maucherat wrote: Do we do a new Tomcat 5.0.12 build (which will be voted on this time) before the migration ? We'll have to change build scripts after that, and I also would have to change the way I work with the repository, which could introduce problems. Based on experience with Tomcat 4, this isn't anywhere near as painful as I first feared. A careful checkout from svn where you use the same directory names as you got with CVS should allow you to do a build without changing any of the scripts. Of course, you will need to manually update each module until we fix the build script to checkout from SVN. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Mladen Turk wrote: Mark Thomas wrote: I know there is a plan to do a JK release this week. If there is a timing clash, JK takes priority. Just shout and I'll delay giving infra the go-ahead to do the final migration. Please don't get limited with that fact. We can easily release from SVN, because when moved to SVN I'll have to change jkrelease.sh script to reflect the changes, so it might be as well a good opportunity for implementing that, cause consecutive release will be coming from SVN repository. Thanks. My current best guess is that the migration will happen this weekend / early next week. I'll post timings when I have them. On the subject of a JK release, could you have a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=35862 and if appropriate include the suggested patch it in the next release. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Final phase of SVN migration - the plan
All, The plan for the last phase is slightly different since these repositories are in pretty much constant use. The CVS repos that will be migrated are: jakarta-tomcat-connectors jakarta-tomcat-catalina jakarta-tomcat-5 jakarta-tomcat-jasper The plan is: - Submit migration request to infrastructure - Once the test migration has been done, I'll write a script to do the necessary restructuring - Run the script on the test repo - Announce that the test repo is ready for review - 48 hours later, assuming that there have been no objections I'll give the go ahead to infrastructure to do the live migration - Shortly after this, CVS will be locked, the live SVN migration will take place (including the restructuring script) and the migration to SVN will be complete I know there is a plan to do a JK release this week. If there is a timing clash, JK takes priority. Just shout and I'll delay giving infra the go-ahead to do the final migration. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Remy Maucherat wrote: Good. The SVN structure you chose to use seems good (although it's not detailed in this email). I left it out for the sake of brevity. It is pretty much as per http://marc.theaimsgroup.com/?l=tomcat-devm=112250656230577w=2 apart from a few naming changes and better separation of branches/tags for each major version. To get an idea, browse svn for the modules already migrated at http://svn.apache.org/repos/asf/tomcat/ Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Yoav Shapira wrote: If possible, it'd be nice to establish a quiet window, say 24 hours, during which we shall not commit anything, and infra will do the real repository move. That will help eliminate the possibility of lost/clashed commits and related wasted time. Good idea. Weekends are usually quiet but it depends on the availability of infrastructure to do the migration. I'll keep the list informed of timings as they become clear. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 3 and Tomcat 4 have moved to subversion
The following CVS modules have been migrated to subversion jakarta-tomcat jakarta-tomcat-4.0 These modules are now read only in CVS. The new SVN locations for the head of these repositories are: http://svn.apache.org/repos/asf/tomcat/container/branches/tc3.3.x/ http://svn.apache.org/repos/asf/tomcat/container/branches/tc4.1.x/ The new SVN locations for key branches are: http://svn.apache.org/repos/asf/tomcat/container/branches/tc3.2.x/ http://svn.apache.org/repos/asf/tomcat/container/branches/tc4.0.x/ NB Committers wishing to make changes to these modules will need to use https as per http://www.apache.org/dev/version-control.html#https-svn The next and final stage of the SVN migration will be to move tomcat5, catalina, jasper and the connectors. A detailed plan for this migration will be published on the dev list. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Costin Manolache wrote: Mark Thomas wrote: I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? I think a clean-up is a very good idea. An archive area already exists and contains jakarta-tomcat-service and jakarta-tools. We should do any clean-up after the svn migration is complete. That way we keep migration issues separate from clean-up issues so it is clear what the cause is if something breaks. I'll start a new thread to gather candidates to move to the archive area. I also think a sandbox is a good idea. Remy will have to do this as he is the only one of us (as PMC chair) with karma at the top of our repo and karma to change the svn authorisation file. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r280906 - in /tomcat/site/trunk: docs/ docs/faq/ xdocs/
The basic content for the TLP site is now done and can be reviewed at http://people.apache.org/~markt/tomcattlp/index.html Whilst I want to tidy it up (remove duplication, fix typos, etc) and someone who knows more about our history than me needs to write something for the heritage page, I don't see why we could not go live with this. I think the remaining steps to move to TLP are: 1. SVN a) Migrate TC3 TC4 - In progress as I type b) Migrate TC5, Connectors and Jasper - will start once a) is done 2. Website a) Need tomcat.apache.org created b) Load content from SVN (trivial) 3. Lists a) [EMAIL PROTECTED] - [EMAIL PROTECTED] b) [EMAIL PROTECTED]- [EMAIL PROTECTED] c) [EMAIL PROTECTED] - [EMAIL PROTECTED] d) Create [EMAIL PROTECTED] (posts from pmc only) 4. Gump a) Change to use SVN 5. Downloads/Archives a) Move from Jakarta to Tomcat 6. Wiki a) Do we want a Tomcat wiki? What have I missed? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r280906 - in /tomcat/site/trunk: docs/ docs/faq/ xdocs/
Bill Barker wrote: 2. Website a) Need tomcat.apache.org created It's been there for a while now :). Thanks - hadn't noticed that. 4. Gump a) Change to use SVN Already done for servletapi/*. (e.g. http://vmgump.apache.org/gump/public/jakarta-servletapi-5/gump_work/update_j akarta-servletapi-5.html). Just waiting on the SVN URLs for the rest. Great. Thanks for doing this (I assume you did it). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
Bugs [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Commits [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mladen Turk wrote: Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r279657 - in /tomcat/site/trunk: docs/findhelp.html docs/whichversion.html xdocs/findhelp.xml xdocs/whichversion.xml
Rahul Akolkar wrote: Looking at this commit, it seems you might want to get some sweeping propset's in on svn:eol-style, and use these as auto-props for future svn additions, if you don't already [ http://www.apache.org/dev/svn-eol-style.txt ]. Thanks for the tip - I hadn't spotted that. I also wonder why the CGI's from last night now bear LFs for eol-style (r279457,r279458). Can those be changed to native? My bad. I'll fix them now. Thanks for all the work. Just trying to save some grief later ;-) Indeed. Your help is appreciated. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
William A. Rowe, Jr. wrote: Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports I would prefer to continue with a single dev list. Reasons are: - Modern e-mail clients allow people to split it any way they like - Many archives are geared to searching one list at a time - Multiple lists raise the barrier (only slightly) to getting involved Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Servlet and JSP APIs have moved to subversion
Remy Maucherat wrote: Mark Thomas wrote: The following CVS modules have been migrated to subversion jakarta-servletapi jakarta-servletapi-4 jakarta-servletapi-5 It seems to work well ! Good. What's the next step ? TC3 TC4. I looked into the website work, and I think it should be enough to simply add a page for mailing lists and downloads (for starters, other pages can be added as needed). For the latter, what are the preferences ? One like jakarta.apache.org, or a much simpler one like httpd.apache.org ? Keeping it simple is good (like httpd). I started to edit the project.xml file and was thinking along the following lines: Apache Tomcat * Home Download * Which version? * Apache Tomcat 5.5 * Apache Tomcat 5.0 * Apache Tomcat 4.1 * Apache Tomcat 3.3 * Archives Problems? * Find help * FAQ * Mailing Lists * Bug Database * IRC Documentation * Apache Tomcat 5.5 * Apache Tomcat 5.0 * Apache Tomcat 4.1 * Apache Tomcat 3.3 * Archives Get Involved * Overview * SVN Repositories * Mailing Lists Misc * Who We Are * Heritage * Apache Home * Resources * Acknowledgements * Contact * Legal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Draft TLP site
I have made a checkout of tomcat/site/trunk available at http://www.apache.org/~markt/tomcattlp/ The downloads don't work (I think because of where this is hosted but I haven't looked at it). I'll update this as work progresses. Any help with the TODOs will be appreciated. Comments on the structure are also welcome. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Remy Maucherat wrote: Synchronizing the writes will also fix problems, since I think the underlying structure of the hashmap went bad due to a concurrency of reads. Try it before whining. Thanks. Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Draft TLP site
Rahul Akolkar wrote: On 9/7/05, Mark Thomas [EMAIL PROTECTED] wrote: The downloads don't work (I think because of where this is hosted but I haven't looked at it). The webserver needs to view the scripts as executable content. chmod'ing the cgi's o+x should do it. Thanks. I spotted that after I posted but changing it doesn't seem to have fixed it. It is getting late - I'll look again with fresh eyes tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Remy Maucherat wrote: Mark Thomas wrote: Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Not in the 5.0.x build he's using. Indeed. But do we need to sync the reads in 5.5.x as well or is it enough just to do the writes? I am confused as you said concurrent reads were the issue but syncing the writes would fix it. Sorry if I am being dense here ;) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cant commit tomcat-dev translation ;(
Henri, How are you connecting to CVS? There was an OS upgrade to people.apache.org aka minotaur.apache.org a little while ago that made ssh stricter in what it would and would not accept. The solution seemed to be use ssh2 rather than ssh1 and use keyboard-interactive authentication rather than password. Of course if you are not going anywhere near minotaur this won't help a bit ;) Mark Henri Gomez wrote: I got error while commiting an update in : /jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/LocalStrings_fr.properties Thanks to commit it :) - 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]
[ANN] Servlet and JSP APIs have moved to subversion
The following CVS modules have been migrated to subversion jakarta-servletapi jakarta-servletapi-4 jakarta-servletapi-5 These modules are now read only in CVS. The new SVN locations are: http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.2-jsp1.1-tc3.x/ http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/ http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/ NB Committers wishing to make changes to these modules will need to use https as per http://www.apache.org/dev/version-control.html#https-svn TC34 will move next (phase 4), followed by TC5, Connectors and Jasper2 (phase 5). A more detailed schedule, particularly for phase 5 since this is the focus of development, will be posted on the tomcat-dev list nearer the time. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN migration Phase 3
It is now the turn of the servletapi repositories. Given the previously expressed views on how these might be better named and my experience of the migration process so far I have modified my plan for servletapi part of the repository. The new version is at the end of this mail. Changes are: - Restructured the 'other' dirs so tags and branches remained separate - Used combination of spec and Tomcat version for dir names - Renamed 'trunk' using the same naming convention I will be placing this request with infra shortly but there is time to modify this structure if needs be. Mark Directory CVS Module(s) CVS Branch/Tag -- -- /tomcat/ /servletapi/ /servlet2.4-jsp2.0-tc5.x/ j-servletapi-5 HEAD /branches/ /servlet2.2-jsp1.1-tc3.x/ j-servletapi HEAD /servlet2.3-jsp1.2-tc4.x/ j-servletapi-4 HEAD /other/ /servlet2.2-jsp1.1-tc3.x/ j-servletapi All other branches /servlet2.3-jsp1.2-tc4.x/ j-servletapi-4 All other branches /servlet2.4-jsp2.0-tc5.x/ j-servletapi-5 All other branches /tags/ /servlet2.2-jsp1.1-tc3.x/ j-servletapi All 4.x tags /servlet2.3-jsp1.2-tc4.x/ j-servletapi-4 All 3.x tags /servlet2.4-jsp2.0-tc5.x/ j-servletapi-5 All 5.x tags /other/ /servlet2.2-jsp1.1-tc3.x/ j-servletapi All other tags /servlet2.3-jsp1.2-tc4.x/ j-servletapi-4 All other tags /servlet2.4-jsp2.0-tc5.x/ j-servletapi-5 All other tags - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site repository cleanup
Any objections to deleting the following? http://svn.apache.org/repos/asf/tomcat/site/branches/TOMCAT_5_0/ http://svn.apache.org/repos/asf/tomcat/site/branches/tomcat-site/ http://svn.apache.org/repos/asf/tomcat/site/tags/start/ http://svn.apache.org/repos/asf/tomcat/site/tags/PRE-ANAKIA-REMOVAL/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_0_26/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_0_27/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_10/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_2/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_8/ I don't see what purpose any of the above might serve. I know copies are cheap. My primary concern isn't space (and deleting things doesn't save space anyway) but making our repository easy for newcomers to navigate. We can get these back easily if we find we need them later. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r264883 - /tomcat/site/branches/pre-tlp/
Remy Maucherat wrote: Add a download page (like this one, maybe: http://httpd.apache.org/download.cgi), end of story ? Or are there plans for something more ambitious ? Rémy Certainly not anything ambitious, but a little bit more than downloads. (archives, SVN, mailing lists, legal, who we are, etc). Basically anything that is currently provided by the Jakarta site that we need our own version of as a TLP. I was planning to use the current Jakarta pages as a starting point and Tomcat-ise them. I also think we should have a heritage page that refers back to Jakarta. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Yoav Shapira wrote: I'd estimate no more than another month to complete the SVN migration, right? Work commitments permitting, certainly within a month and quite possibly less. Side note on this: the name for the CVS (or actually, SVN) area for Servlet API 2.5. I'd prefer servletapi-2.5 for clarity, even though it breaks the pattern of jakarta-servletapi and then jakarta-servletapi-5 that we have used to date. My original svn migration proposal suggested \servletapi\ \trunk\ \branches\ \tc3.x.x\ \tc4.x.x\ \other\ \tags\ \tc3.x.x\ \tc4.x.x\ \other\ I like keeping the directory naming aligned with the rest of the Tomcat repository. It makes it easier for new users to find their way around. As part of the new TLP site, we need to add areas that have previously been handled by Jakarta including version control repositories. I think this is where we make the mapping between Tomcat versions and Servlet/JSP versions clear. Also, similar side note on CVS/SVN location: perhaps we put it in jspapi-2.1 instead of servletapi-6? I think the spec team get to decide this. I had assumed they would do something similar to the servletapi-5 and have jsr154 and jsr245 directories under the root directory (which in svn would be \tomcat\servletapi\trunk - the current trunk having been moved to \tomcat\servletapi\branches\tc5.x.x\). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Remy Maucherat wrote: Mark Thomas wrote: I think the spec team get to decide this. I had assumed they would do something similar to the servletapi-5 and have jsr154 and jsr245 directories under the root directory (which in svn would be \tomcat\servletapi\trunk - the current trunk having been moved to \tomcat\servletapi\branches\tc5.x.x\). I don't know if the spec team is actually still responsible for these repositories, such as if they intend to add the Servlet 2.5 / JSP 2.1 API source there. If the don't, we can switch to a more OSS friendly access and management style. Who do we need to talk at the spec team about this? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Site, service tools have moved to subversion
Phase 2 of the SVN migration is now complete. The main component of this phase is the Tomcat website. jakarta-tomcat-site has moved to http://svn.apache.org/repos/asf/tomcat/site and updated instructions for editing the website may be found at http://svn.apache.org/repos/asf/tomcat/site/trunk/README.txt The following little used modules have also moved: jakarta-tools has moved to http://svn.apache.org/repos/asf/tomcat/archive/tools jakarta-tomcat-service has moved to http://svn.apache.org/repos/asf/tomcat/archive/service - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Convert Tomcat to Subversion Phase 2
The Tomcat team is now ready for phase two of the migration to subversion. For this phase we would like to migrate the following CVS modules. jakarta-tools jakarta-tomcat-site jakarta-tomcat-service Please do a standard (head-trunk, branches-branches tags-tags) conversion for each module. Please grant commit access to the Tomcat PMC (using the existing PMC group) to each module. The resulting repo structure should be: /tomcat/ /archive/ /service/ (j-t-service) /tools/ (j-tools) /site (j-t-site) with trunk, branches and tags directories under each. JIRA issue to follow shortly. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convert Tomcat to Subversion Phase 2
Mark Thomas wrote: The Tomcat team is now ready for phase two of the migration to subversion. For this phase we would like to migrate the following CVS modules. jakarta-tools jakarta-tomcat-site jakarta-tomcat-service Please do a standard (head-trunk, branches-branches tags-tags) conversion for each module. Once the migration is complete I intend to do the following: - Restructure the standard migration to align with my original proposal (http://marc.theaimsgroup.com/?l=tomcat-devm=112250656230577w=2) - Change over the live website to use a svn checkout rather than a cvs one and update the site instructions accordingly - Branch site so 'trunk' becomes our new TLP level website and start work on getting it ready for TLP go-live - Kick off stage 3 of the migration Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Henri Yandell wrote: On 8/17/05, Mark Thomas [EMAIL PROTECTED] wrote: 2. j-t-service, j-t-site 3. j-servletapi, j-servletapi-4, j-servletapi-5 4. j-tomcat, j-tomcat-4.0 5. j-t-catalina, j-t-5, j-t-jasper, j-t-connectors Any other comments/concerns? I have jakarta-tools down as a Tomcat CVS module, though looking at it seems to indicate that it is very dead, not edited for 5 years. Still, the tags are all TOMCAT_3_1 based, so I figure you guys get to decide what to do with it: I'd noticed that watchdog for Tomcat 3.2.x requires this to build. Since nothing else in Jakarta needs it, I'll bring it across with j-t-service and j-t-site and place it in the archive area with j-t-service. Mark * Somehow come over to SVN because Tomcat-3's tags will need it to build(?). * Put into the pot for archiving (http://www.apache.org/dev/drafts/subversion-migration-plan.txt) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Remy Maucherat wrote: Mark Thomas wrote: I am +1 for moving the remaining Tomcat CVS modules to SVN. I'm +10^-60 or something. He he he. Right after that, we'll need new repositories to implement the new Servlet 2.5 / JSP 2.1. Not having been around when we have done this before, do we just branch the previous version? If so, the simplest thing to do would be to create 5.5.x branches for each component and develop 6.0 (assuming we call it that) in trunk. I can do this as soon as we are ready. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r232600 - /tomcat/watchdog/branches/tc3.3.x/WARNING.txt
Larry Isaacs wrote: Hi Mark, I believe the tomcat_32 branch was the last clean build of watchdog for Tomcat 3.2.x and 3.3.x. I always used this branch for testing 3.3.x builds. Some refactoring was begun at HEAD for Tomcat 4.x which was never completed before that work moved to watchdog40. Larry, Thanks for the explanation. I'll move the branches around to reflect this. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Mark Thomas wrote: snip The performance comparison between CVS and SVN is in the early stages and I will post some results once I have a more complete set. Tests performed on WinXP SP2, with Tortoise CVS 1.8.18 and Tortoise SVN 1.2.1 using the Watchdog repository. For tests using a single file I used build.xml. The results are (averages in seconds): Operation CVS SVN checkout 38 51 history 45 blame 47 diff42 revert 71 Also, SVN does not support revision graphs. Some tools can derive the graph but for the ASF repository this will take hours, possibly days. See http://subversion.tigris.org/ for a list of other SVN benefits. I am +1 for moving the remaining Tomcat CVS modules to SVN. Assuming everyone else is happy to move the remaining tomcat modules to SVN I would suggest the following stages (Watchdog was stage 1). I'll give people at least a week to comment on this proposal and assuming no -1's start the phase 2 towards the end of next week. 2. j-t-service, j-t-site 3. j-servletapi, j-servletapi-4, j-servletapi-5 4. j-tomcat, j-tomcat-4.0 5. j-t-catalina, j-t-5, j-t-jasper, j-t-connectors Do we need an OK from the spec team before we do stage 3? Any other comments/concerns? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r232601 - /tomcat/watchdog/branches/tc4.1.x/WARNING.txt
Watchdog has moved but the rest remains with CVS. We have until the end of the year to migrate the rest. Mark Costin Manolache wrote: Did tomcat move to svn already ? Costin [EMAIL PROTECTED] wrote: Author: markt Date: Sun Aug 14 04:48:32 2005 New Revision: 232601 URL: http://svn.apache.org/viewcvs?rev=232601view=rev Log: Remove CVS closure warning from SVN Removed: tomcat/watchdog/branches/tc4.1.x/WARNING.txt - 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: svn commit: r232600 - /tomcat/watchdog/branches/tc3.3.x/WARNING.txt
Bill Barker wrote: As a historical note, this really should be the tc3.2.x branch. This particular watchdog has never worked well with any TC 3.3.x, since it has a lot of bugs related to specific implementation details of TC 3.2.x (and, the Watchdog committers mostly moved on to TC 4.0.x during the Great Flame Wars, so it couldn't be fixed by TC 3.3.x committers :). Thanks for the clarification. I'll change it. That's once of the nice things about subversion - renames (files or directories) are easy and you keep the history. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r232600 - /tomcat/watchdog/branches/tc3.3.x/WARNING.txt
Mark Thomas wrote: Bill Barker wrote: As a historical note, this really should be the tc3.2.x branch. This particular watchdog has never worked well with any TC 3.3.x, since it has a lot of bugs related to specific implementation details of TC 3.2.x (and, the Watchdog committers mostly moved on to TC 4.0.x during the Great Flame Wars, so it couldn't be fixed by TC 3.3.x committers :). Thanks for the clarification. I'll change it. That's once of the nice things about subversion - renames (files or directories) are easy and you keep the history. Bill, I have taken another look at the repository. There is a separate tomcat_32 branch so I assumed that the old HEAD in CVS must have been for 3.3.x (even if not much was done with it). Is this assumption correct? If not, what is the correct interpretation? As part of the migration to a TLP we will need to put together our own version control and download pages (rather than use the Jakarta ones). I plan to include an explanation of the SVN structure in the version control page. I can include additional information such your note above in this explanation. Cheers, mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Watchdog has moved to Subversion
As those of you subscribed to the dev list may have already noticed, the following CVS modules have been migrated to Subversion. jakarta-watchdog jakarta-watchdog-4.0 These modules are now read only in CVS. The new SVN locations are: http://svn.apache.org/repos/asf/tomcat/watchdog/branches/tc3.3.x/ http://svn.apache.org/repos/asf/tomcat/watchdog/branches/tc4.1.x/ NB Committers wishing to make changes to these modules will need to use https as per http://www.apache.org/dev/version-control.html#https-svn I'll update the Tomcat web-site shortly. Apache plans to turn off CVS on 31/12/2005. Therefore, the current plan is that the remainder of the Tomcat modules will be moving to SVN some time between now and the end of the year. Regular updates will be posted to the dev list and announcements made on both lists as each migration goes live. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion migration update
Hi all, Just a quick note to keep you updated with my progress with Subversion. jakarta-watchdog and jakarta-watchdog-4.0 should be migrated shortly. As a result of some questions from Henri, the final structure has been modified slightly to make it clearer which tags and branches belong to which major Tomcat version. The performance comparison between CVS and SVN is in the early stages and I will post some results once I have a more complete set. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Convert jakarta-watchdog and jakarta-watchdog-4.0 to Subversion
The Tomcat project has decided to move to Subversion. Since Tomcat spans a number of CVS repositories, we wish to migrate in a phased manner, starting with the Watchdog repositories. We need to export the following CVS repositories: - jakarta-watchdog - jakarta-watchdog-4.0 Ideally, the resulting structure in SVN should be: SVN Directory CVS Module(s) CVS Branch/Tag -- -- /tomcat/ /watchdog/ /branches/ /tc4.1.x/j-watchdog-4.0 HEAD /other/ j-watchdog, -4.0 All other branches /tags/ /tc4.1.x/j-watchdog-4.0 All 4.1.x tags /other/ j-watchdog, -4.0 All other tags We appreciate that this is non-standard and are happy to move directories around ourselves after a standard migration to: SVN Directory CVS Module(s) CVS Branch/Tag -- -- /tomcat/ /watchdog/ /watchdog/ /trunk/ j-watchdog HEAD /tags/ j-watchdog All tags /branches/ j-watchdog All branches /watchdog-4.0/ /trunk/ j-watchdog-4.0 HEAD /tags/ j-watchdog-4.0 All tags /branches/ j-watchdog-4.0 All branches Finally, commit access should be granted to /tomcat/watchdog/ to the union of: - committers with access to watchdog - committers with access to watchdog-4.0 - members of the new Tomcat PMC JIRA request to follow shortly. Thanks in advance, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to Subversion
Bill Barker wrote: That is fine as long as you build and run on a 1.4+ JDK but when checking for 1.3 compatibility the Coyote/HTTP connector fails. The root cause is the use of the 1.4 regexp API in o.a.coyote.http11.Http11Processor (http://marc.theaimsgroup.com/?l=tomcat-devm=109403344007532w=2). This is true. However in TC 3.3 the Coyote connectors have always been optional. That's why I've kept it using j-t-c HEAD even with the 1.4 dependancy. Of course, it's pretty mote until it's time to do a 3.3.3 release ;-). Ah. Didn't know that. That explains a few things. Unless anyone has a better idea, I'll crack on with 3 over the weekend. I've thought that it should be possible to do this with an Ant filter (so that you don't have to maintain a separate copy of the file). I've always been too lazy to actually sit down and write it however. :). Very cunning. I'll take a look at doing it this way. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to Subversion
Yoav Shapira wrote: Any and all comments appreciated. In particular: a. Should more 3.x.x versions should be included in 4 5 above? b. I have assumed that all releases before 5.5.x will use the 5.0 branch of the connectors. Is this assumption valid? I don't think so. Some Tomcat 3.x versions, for example, already use the latest connectors that are also used by Tomcat 5.5. That is fine as long as you build and run on a 1.4+ JDK but when checking for 1.3 compatibility the Coyote/HTTP connector fails. The root cause is the use of the 1.4 regexp API in o.a.coyote.http11.Http11Processor (http://marc.theaimsgroup.com/?l=tomcat-devm=109403344007532w=2). Possible solutions: 1. Use the 5.0 branch 2. Revert the patch and go back to using jakarta-regexp 3. Introduce an o.a.coyote.http11.tomcat4 package and place a copy of Http11Processor in it that uses jakarta-regexp. Pros/Cons 1. Would mean an awful lot of porting. 2. Quick but adds an unnecessary library to TC5 and leaves TC5 using two different regexp libs 3. Relatively quick but would need some build.xml tweaking for TC5 Unless anyone has a better idea, I'll crack on with 3 over the weekend. On the Subversion front, I have TC4 building with jakarta-tomcat-connectors HEAD and will commit it once I have finished testing the various connector and JVM combinations (I don't plan to provide APR support in TC4). Once I have got this out of the way, I'll work with Henri on the test Watchdog migration. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migration to Subversion
All, Following up on my offer to trial a Subversion migration using Watchdog, I started to think that it would be a good idea to have an idea of what we want our eventual Subversion layout to look like so we could target the Watchdog conversion to that layout and save rework at a later date. My initial thoughts were that default migration (see below) could be improved upon. /tomcat/ /module/ /trunk/ /branches/ /tags/ After several false starts, I came up with a proposed layout based on the following ideas: 1. Modules no longer used (watchdog, service) should be clearly marked as archived 2. Each module should appear directly under /tomcat/ 3. The trunk of each module should always be Tomcat 5.5.x 4. The latest versions of 5.0.x, 4.1.x, 4.0.x 3.3.x should be clearly identified under branches of each module 5. Tags for modules should be grouped by the same versions as in 4 above 6. All the other branches and tags should be preserved but placed under 'other' so they don't clutter up the most frequently used stuff The layout is set out at the end of this mail. Any and all comments appreciated. In particular: a. Should more 3.x.x versions should be included in 4 5 above? b. I have assumed that all releases before 5.5.x will use the 5.0 branch of the connectors. Is this assumption valid? The build scripts are obviously going to need quite a lot of work but I think that will be the case however we do this migration. Once we have agreement on this, I'll put in a request for the Watchdog migration and also kick off a discussion with infra on how best to go about the overall migration. It might be the case that they do a default migration for each module and we (I am happy to do it) move the directories around afterwards. Finally, my intention with the migration of Watchdog is to see what, if any, performance differences there are between CVS and SVN. If there is no major performance hit moving to SVN, great, we can migrate the other modules whenever we choose. If there is a performance hit, we will have some hard evidence on which to base our decision about how to move forward. Mark Directory CVS Module(s) CVS Branch/Tag -- -- /tomcat/ /archive/ /service/ /trunk/ j-tomcat-service HEAD /branches/ j-tomcat-service All branches /tags/ j-tomcat-service All tags /watchdog/ /branches/ /tc4.1.x/j-watchdog-4.0 HEAD /other/ j-watchdog, -4.0 All other branches /tags/ /tc4.1.x/j-watchdog-4.0 All 4.1.x tags /other/ j-watchdog, -4.0 All other tags /connectors/ /trunk/j-tomcat-connectorsHEAD /branches/ /pre5.5.x/ j-tomcat-connectorsTOMCAT_5_0 /other/ j-tomcat-connectorsAll except TOMCAT_5_0 /tags/ /tc3.3.x/j-tomcat-connectorsAll 3.3.x tags /tc4.0.x/j-tomcat-connectorsAll 4.0.x tags /tc4.1.x/j-tomcat-connectorsAll 4.1.x tags /tc5.0.x/j-tomcat-connectorsAll 5.0.x tags /tc5.5.x/j-tomcat-connectorsAll 5.5.x tags /other/ j-tomcat-connectorsAll other tags /container/ /trunk/ /catalina/ j-tomcat-catalina HEAD /core/ j-tomcat-5 HEAD /branches/ /3.3.x/ j-tomcat HEAD /4.0.x/ j-tomcat-4.0 tomcat_40_branch /4.1.x/ j-tomcat-4.0 HEAD /5.0.x/ j-tomcat-catalina TOMCAT_5_0 /other/ j-tomcat, -4.0, -catalina All other branches /tags/ /tc3.3.x/j-tomcat All 3.3.x tags /tc4.0.x/j-tomcat-4.0 All 4.0.x tags /tc4.1.x/j-tomcat-4.0 All 4.1.x tags /tc5.0.x/j-tomcat-catalina All 5.0.x tags /tc5.5.x/j-tomcat-catalina All 5.5.x tags /jasper2/ /trunk/j-tomcat-jasperHEAD /branches/ /tc4.1.x/j-tomcat-jaspertomcat_4_branch /tc5.0.x/j-tomcat-jasperTOMCAT_5_0 /other/ j-tomcat-jasperAll other branches /tags/ /tc4.1.x/j-tomcat-jasperAll 4.1.x tags /tc5.0.x/j-tomcat-jasperAll 5.0.x tags /tc5.5.x/j-tomcat-jasperAll 5.5.x tags /other/ j-tomcat-jasperAll other tags /servletapi/ /trunk/j-servletapi-5 HEAD /branches/ /3.x.x/ j-servletapi HEAD /4.x.x/ j-servletapi-4 HEAD /other/ j-servletapi, -4, -5 All other branches /tags/ /3.x.x/ j-servletapi All 3.x.x tags /4.x.x/ j-servletapi, -4 All 4.x.x tags
Re: How can I build and Debug Tomcat 5.5 source code under Eclipse?
http://jakarta.apache.org/tomcat/faq/development.html Lebing Xie wrote: Thanks Mark, can you give me some links where I can find stuff about such remote debugging. I am a newbie in TC, just finish reading TC 4.1 source and have no experience without IDE as Eclipse (of course I have built TC5 with ANT, 2-3 CVS were down, had to find package with google). I am writing my master thesis about such Application Server and Servlet container. I will program my own Container later, been very interesting in the develop environment. A article about how the TC team program, build and develop TC will help such newbies as me much. Thanx alot for the great work. ur Lebing On Sat, 2005-07-23 at 17:11 +0100, Mark Thomas wrote: The build process is too complex to use the Eclipse builder. I'd recommenced (as this is what I do): - import the source - build with Ant - use remote debugging Works a treat for me with TC4.1.x, TC5.0.x TC5.5.x Mark Lebing Xie wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html I am doing some research on Tomcat and want to build and debug Tomcat5.5 under Eclipse. Originally tomcat is built with ANT, it downloads all components from different CVS and build them together. I'd like to import Tomcat Source code (at first only the core components, such as catalina and Coyota, Jasper) and build them with Eclipse Builder, so I can debug it as a normal JAVA program under DEBUG-View. Who has such experience and can help me? I have built Jetty under Eclipse, but Tomcat is much more complex. - 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: How can I build and Debug Tomcat 5.5 source code under Eclipse?
The build process is too complex to use the Eclipse builder. I'd recommenced (as this is what I do): - import the source - build with Ant - use remote debugging Works a treat for me with TC4.1.x, TC5.0.x TC5.5.x Mark Lebing Xie wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html I am doing some research on Tomcat and want to build and debug Tomcat5.5 under Eclipse. Originally tomcat is built with ANT, it downloads all components from different CVS and build them together. I'd like to import Tomcat Source code (at first only the core components, such as catalina and Coyota, Jasper) and build them with Eclipse Builder, so I can debug it as a normal JAVA program under DEBUG-View. Who has such experience and can help me? I have built Jetty under Eclipse, but Tomcat is much more complex. - 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: New tag ?
Remy Maucherat wrote: It's not really a UI thing for me. One feature I use often are revision lists for a particular file, to be able to tell where a bug has been introduced (I then do diffs between revisions). It seems with SVN I have to retrieve the full revision list for the repository (which will take hours). If someone can offer a workaround for this problem, then I'll support a move to SVN :) I have been doing some quick tests and my totally unscientific, statistically invalid results are that cvs annotate seems to be about 7 to 8 times faster than svn blame (50s compared with 7s) and cvs log seems to be about 2 to 3 times faster than svn log (16s compared to 7s). The svn release notes show a number of modifications to improve the speed of response for a number of commands. The svn team does seem to be moving things in the right direction. I guess the question is can we live with this magnitude performance drop? It is also worth bearing in mind that there is no sign of any scope for negotiation in the CVS switch-off date of 1/1/2006. I would suggest the following way forward: 1. Highlight our performance concerns to infra 2. Request a test migration of something we don't use very much (eg Watchdog) 3. Run some tests so we have some more realistic performance figures 4. Review the results 5. Decide what to do next once we see the performance results If people think this is sensible, I am happy to do 1 to 3 and publish my results so we can do 4 and 5. Thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to do authentication and secure line HTTPS (SSL)
Please post this, and any other requests relating to the usage of Tomcat rather than the development of Tomcat, to the tomcat-user list. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs faq.xml
[EMAIL PROTECTED] wrote: For additional help, the best resource is the Tomcat Users Discussion list. You should start by searching -a href=http://mikal.org/interests/java/tomcat/index.html; +a href=http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED] the mail list archive/a before you post questions to the list. If you are unable to locate the answer to your question in the archive, Eyebrowse has been turned off. The new URL should be: http://mail-archives.apache.org/mod_mbox/jakarta-tomcat-user/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I have some new FormAuthenticator code for Tomcat.
I am -1 for this for the following reasons (in order of importance): 1. Your reference to sending an encrypted user certificate file to the server demonstrates a lack of understanding of PKI that undermines my confidence that you know what you are doing when it comes to security. 2. JAAS provides plug-in authentication. 3. Password hashing is already supported. 4. The implementation is Tomcat specific and hence is non-portable. Mark D M wrote: Hi, I've been working on some code for Form authentication in Tomcat that I think you all might be interested in. In addition to implementing the current J2EE/Servlet spec for authentication (i.e. j_security_check with two keys: j_username, j_password authenticated with the Realm), it also offers some major increases in authentication capabilities with the simple inclusion of an XML file in a web-context's WEB-INF folder. I created this flexible Form authentication with a main concern being that it be as non-intrusive on Catalina code and the Servlet spec as possible. To use this new code, only one line in a properties file needs to be changed: ( Authenticators.properties ) FORM=com.spiralgeneration.formauthentication.FormAuthenticator Obviously, if you are interested in the code, the above class' package would be changed to a Catalina package. While this API implementation does have a number of new classes, there are ZERO changes for any existing Catalina code (save for replacing FormAuthenticator with this new FormAuthenticator). The classes could even be kept in the current jar I've got them in. There is also no impact on the Servlet spec for Form authentication. There are ZERO changes to web.xml or any other deployment or code files of a web context. If a web application wants to use the usual username + password authentication, the Form authentication will act exactly as it does currently in Tomcat. If the web application wants to use the new form authentication, all that's needed is to include WEB-INF/form-authentication.xml. That's it. ALL web.xml configurations remain the same (e.g. securing pages is still done via security-constraint). However, with that XML file included the application gets the following capabilities: 1. Plug in any pre-authentication key manipulators (called KeyPreparer). For example, if a database stores all passwords in a one-way hash, you can register (in the XML) the password key to be prepared by your password-hashing KeyPreparer just prior to sending to an authenticator. (I have created an example of this) This offers a lot of flexibility in terms of storing login keys. If it were necessary to stop hashing passwords, the deployer could simply remove one line in an XML file and the KeyPreparer is unplugged. 2. Plug in any number of custom authenticators (called PluginAuthenticator). Currently, the only authentication possible in the Catalina implementation is a username and password to a Realm. With this implementation a web context could require a username, password and a file. Because this form authentication accepts multipart/form-data POSTs (it converts an uploaded file to java.io.InputStream), the web context could require that users carry a USB key ring (that has an encrypted file for example) so when they login from a remote computer (in a web browser) they can point an input of type=file to that file. The developers could then have two authenticators: 1. The default authentication (All PluginAuthenticators have controlled access to the Realm) which checks the username and password. 2. Their custom authenticator that checks an encrypted file matches the data stored for the username (they register for the username and file in XML). (I have created an example of this) 3. Create as many authentication keys (called SecurityRoleKeys) as needed. In the current authentication model, only a username and password are allowed. Here, a web context could (in XML) require a username, a password, a file, a random number and any other keys they wish. All keys can be given a class type to which they will be converted by the form authentication. For example, the username and password would likely be java.lang.String, the random number java.lang.Long and the file java.io.InputStream. (I have JavaDocs and an example XML file that show all the allowed types) So a KeyPreparer or PluginAuthenticator can expect a key to be a certain type. 4. Accept multipart/form-data POSTs. As mentioned above, this form authentication can handle login forms of enctype=multipart/form-data. As a result, it enables the ability to require file data for logins. For example, an encrypted certificate file installed on an external USB drive or locally on a hard drive. 5. Set a default secure page for logins with no saved request. Currently, if a user goes directly to the login page and logs in, Tomcat will throw an error, No web resource available at /j_security_check (or something like that). With this new
Re: I have some new FormAuthenticator code for Tomcat.
Remy Maucherat wrote: snip I'll be the first to admit, however, that FORM (and the other auth methods from the spec) are insufficient and not flexible enough, and I am not completely against adding additional custom auth-methods. Can you give some use cases where the spec falls short? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I have some new FormAuthenticator code for Tomcat.
David, D M wrote: 1. Local files as authentication tokens OK. I see this as just being a password that is so long that it has to be written down (eg on the USB key) and physically carried around by the user. There is an interesting debate here as to whether this is more or less secure than a 'good' pass-phrase that the user can just carry around in their head. My instinct is that it is about the same but the additional complexity required to implement it makes me lean towards less secure since greater complexity = greater chance to mess things up. Note: since the 'password' will travel over the wire, this is fundamentally different (and less secure) than a PKI style private key on a token which will never be transmitted to the server. 2. Plug-in authentication. Tomcat (and most other web containers) support BASIC, FORM, DIGEST and CLIENT-CERT. Can you give examples (in addition to the 1. above) of authentication types you'd like to see supported? 3. Authentication token manipulation Hashing is the most popular and archives the desired aims of protecting passwords. Can you give examples of other manipulations and the security benefits of performing them? 4. Portability Have a look at http://jcifs.samba.org/. This provides NTLM authentication as a servlet filter. It might give you some ideas about how to make your authentication components more web container neutral. Also there is a Jakarta project starting up (name TBD) that will provide web components such as filters, listeners, etc. If your authentication code can be made container neutral I think this would be a more natural home for it. Have a look at http://marc.theaimsgroup.com/?l=jakarta-generalm=111972374202676w=2, http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons, http://marc.theaimsgroup.com/?t=11194728675r=1w=2 and the related threads. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: website stops answering requests from time to time
This is a question for the tomcat-user list. Mark Ayyanar Inbamohan wrote: This is a production site. We use Tomcat 4.1. website stops answering requests from time to time Our website is under very high daily volume. Several times a week, no requests are answered. Here is the log exception: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.writeObject(HashMap.java:976) at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteObject (ObjectStreamClass.java:809) at java.io.ObjectOutputStream.writeSerialData (ObjectOutputStream.java:1296) at java.io.ObjectOutputStream.writeOrdinaryObject (ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject (StandardSession.java:1429) at org.apache.catalina.session.StandardSession.writeObjectData (StandardSession.java:852) at org.apache.catalina.session.JDBCStore.save (JDBCStore.java:690) at org.apache.catalina.session.PersistentManagerBase.writeSession (PersistentManagerBase.java: 739) at org.apache.catalina.session.PersistentManagerBase.processMaxIdleBackups (PersistentManagerBase.java :1063) at org.apache.catalina.session.PersistentManagerBase.processPersistenceChecks(PersistentManagerBase.ja va:477) at org.apache.catalina.session.PersistentManagerBase.run (PersistentManagerBase.java:1141) at java.lang.Thread.run(Thread.java:534) Thanks in Advance, inr.. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debugging tomcat itself
I debug Tomcat all the time using Eclipse. I can't see any reason why this would work in Eclipse but not NetBeans. It looks like a configuration problem. Mark Hernan Ochoa wrote: Hi all, I'm trying to debug tomcat itself v5.5.9 using netbeans 4.1 without much luck. I'm able to attach to a running instance of tomcat using JPDA, but then my breakpoints are activated erraticaly, and when they actually break the execution of the program, if I trace to trace the code, it usually ends up in the debugged application continuing its execution, I cannot actually debug this way Did someone try this before? These are the things I did: -compiled tomcat 5.5.9 with a build.properties file containing: compile.debug=on compile.deprecation=off compile.optimize=off debuglevel=lines,vars,source (I added the build.properties file in the root directory of the source distribution, and also inside jakarta-tomcat-5) -I added all .java files into a new netbeans project (I created a new project with the option new project with existing java source files or sthg like that) -I run tomcat using the command /bin/catalina.sh jpda start -I attach to the instance of tomcat running with netbeans -I set the breakpoints by toggling them into the .java source files I added on netbeans. Sometimes I do this from the Files window, and sometimes from the Projects windows. Here I'm not sure what's the right way to go. Any help with this would be much appreciated. If anyone has sucessfully debugged tomcat with another debugger, please let me know also. Thanks in advance. bye! - 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: source code for tomcat as a service...
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/daemon/ Mark wrote: Where can I find the source code that builds the Tomcat windows service? I poked around in the jakarta-tomcat-5 CVS repository and there is nothing there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Irene Robatscher/Baldessarini/HUGO_BOSS ist außer Haus.
Just blocked the address. Mark tomcat-dev-owner Joon Kim wrote: Do you have a clue? Can you stop these messages? --- Irene Robatscher [EMAIL PROTECTED] wrote: Ich werde ab 24.05.2005 nicht im Büro sein. Ich kehre zurück am 31.05.2005. I will be out of office from 23.05.05 to 31.05.05. and I will not be able to read your e-mail. For urgent matters pls. get into contact with my colleague Mrs. Anna Franzese: +49-89-306684-16 This e-mail (and/or attachments) is confidential and may be privileged. Use or disclosure of it by anyone other than a designated addressee is unauthorized. If you are not an intended recipient, please delete this e-mail from the computer on which you received it. We thank you for notifying us immediately. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters SavedRequestInputFilter.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Implement request body replay action. New input filter used to insert the request body. This is probably not going to work with the APR protocol, since a subsequent request may be processed by a different processor. All this proves saving POST data is a severly broken concept. I would like to get back to the previous situation, and have this whole thing reverted. As a result, here's my official -1 to all these POST data related changes. The input filter is added to the processor during the processing of the final request in the FORM authentication sequence and the data in it is consumed during the processing of this request. There is no need for this filter, or the data in it, to persist across multiple requests. Data is persisted between requests (of course it has to be so FORM auth can take place) but this is done in the session and therefore it does not matter if the processor that handles the original request is different from the one that handles the FORM auth request or the final redirect to the original URL. At the moment I do see what is so badly broken about this that justifies a -1. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters SavedRequestInputFilter.java
Remy Maucherat wrote: Mark Thomas wrote: If this still goes to the session, then the -1 is not justified. It does still go to the session. The code is not done in a way that is very intuitive to me, so that's the only issue then, and it's not relevant. It wasn't that intuitive to me while I was trying to figure out how to do this either ;) - Bill's assistance was much appreciated for the JK stuff. I still have trouble with the concept of saving any POST data, which tends to be far bigger than parameters (and retrospectively, I have trouble allowing this many parameters). This would kill clustered Tomcats setups. Could the default be a very small value (like 64KB or something) ? I took a particularly paranoid view and set the default to 4k. Mark - 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/authenticator FormAuthenticator.java
Bill,
Thanks for your efforts on this. I have been snowed under with other
things for the last few days but hope to get to doing the implementation
for the action hook later this this week.
Mark
[EMAIL PROTECTED] wrote:
billbarker2005/05/15 22:22:21
Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java
Log:
Oops, missed an indirection
Revision ChangesPath
1.22 +2 -33 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- FormAuthenticator.java 16 May 2005 05:12:50 - 1.21
+++ FormAuthenticator.java 16 May 2005 05:22:21 - 1.22
@@ -388,7 +388,7 @@
if (POST.equalsIgnoreCase(saved.getMethod())) {
ByteChunk body = saved.getBody();
- request.action(ActionCode.ACTION_REQ_SET_BODY_REPLAY, body);
+ request.getCoyoteRequest().action(ActionCode.ACTION_REQ_SET_BODY_REPLAY, body);
// Set content type
MessageBytes contentType = MessageBytes.newInstance();
@@ -485,36 +485,5 @@
}
-protected class SavedRequestInputFilter implements InputFilter {
-
-protected ByteChunk input = null;
-
-public SavedRequestInputFilter(ByteChunk input) {
-this.input = input;
-}
-
-public int doRead(ByteChunk chunk, org.apache.coyote.Request request)
-throws IOException {
-return input.substract(chunk);
-}
-
- public void setRequest(org.apache.coyote.Request request) {
- }
-
- public void recycle() {
-input = null;
- }
-
- public ByteChunk getEncodingName() {
- return null;
- }
-
- public void setBuffer(InputBuffer buffer) {
- }
-
- public long end() throws IOException {
- return 0;
- }
-}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web standards in Tomcat webapps
Bugzilla item with patch for review is the way to go. I suggest starting small in case there is something the committers don't like ;) The other thing to bear in mind is that many of the docs and the Tomcat web-site are actually generated from xml using style sheets. See the CVS repository Jakarta-tomcat-site for details. Mark Rick Beton wrote: Schalk Neethling wrote: Richard If it is decided to move forward with this, I would also be willing to chip in and help the conversion to XHTML + CSS. newbie question: What's the next step? Can I submit a bugzilla bug for upgrading these apps to XHTML + CSS, or is there some other approval process? Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, May 12, 2005 5:28 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. I agree. I'd even be +1 to further restricting the saved body size for CLIENT-CERT auth, and that one is only saved for the time of one request. Since the body in a FORM auth is going to be saved for much longer, it's even more important to restrict it. And this is even more important for mod_jk users, since they will never get a chance to recover the data that they have posted :(. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark Bill Barker wrote: Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. I agree. I'd even be +1 to further restricting the saved body size for CLIENT-CERT auth, and that one is only saved for the time of one request. Since the body in a FORM auth is going to be saved for much longer, it's even more important to restrict it. And this is even more important for mod_jk users, since they will never get a chance to recover the data that they have posted :(. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Bill Barker wrote: From: Mark Thomas [EMAIL PROTECTED] So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) The check on maxPostSize in the Request isn't applied to any 'chunked' POST body, and also not to any 'multipart/form-data'. I don't see any place else that checks it except when CLIENT-CERT auth saves the request body. I stand corrected. This is easy to fix if it is agreed that this, or something similar to it, is the way forward. Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. No. Previously only the Parameters were saved, and limited by maxPostSize. Now you are saving off file-upload posts as well, and these aren't limited anywhere. As above, putting the limit in is easy. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. It should be something like: request.getCoyoteRequest().action(ActionCode.ACTION_SET_BODY_REPLAY, body); but that won't work either unless Jk-Coyote gets cleaned up a bit (the ActionHook implementation is one of those it's ugly but it works things at the moment :). I could do the cleanup if the consensus is that this is the way to go. Any help would be great. It took me a while to figure out how to get this far. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.12 is broken and can not be released as stable
William A. Rowe, Jr. wrote: Truly hope it helps. Sorry for having to route through rowe-clan, it seems tomcat-dev hates my apache.org persona. (tomcat cvs did not complain, but it's forwarded onto tomcat-dev.) This should now be fixed. Let me know if it isn't. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem during authentication
I have just committed a fix for this. Mark Andrey Grebnev wrote: Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - 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: How to redirect all ports to use SSL?
This is a question for tomcat-user, not tomcat-dev Mark Donny R Rota wrote: I want all my Tomcat requests to go through SSL. I want the URLs to look like https://this/ and not https://this:8443 I setup tomcat, and got ssl working on 8443. But I cannot redirect port 80 to 8443. I keep getting 'access denied'. Is there a way in Tomcat to redirect all port 80 requests to SSL(8443)? I know you can do it the other way around 8443 - 80. I'm just running standalone Tomcat, no Apache. advTHANKSance! ...Don... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem during authentication
I have confirmed this behaviour. Your suggestion as to the root cause looks possible. I will investigate further. Mark Andrey Grebnev wrote: Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - 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: ant installer target
This works for me from a clean build with the following process:
1. Build using build.xml as per
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html
2. Then cd jakarta-tomcat-5
3. build dist
4. build installer
You will need to configure build.properties in both ${tomcat-source} and
jakarta-tomcat-5
Mark
Gary Orser wrote:
Not finding any clues in the archives or web...
I've been struggling with trying to get the ant installer target to
work. (tried both 5.5.9 tarball and build.xml cvs checkout). I've tried
this both with cygwin, and cmd.exe (ugh!). Both produce similar results.
In debugging this I've discovered that the installer target should have a
depends=prepare-release. Additionally, the target doesn't copy many
files that it needs from ./build and other places to ./dist.
Is this target supposed to work?
How is the .exe distribution being created that is on the tomcat website?
Has nsis been deprecated?
Is there some reference/howto that describes this process better?
Am I missing something fundamental here?...
PS. I had originally thought that this would be a cool way to have a
point and click installer for our webapp that needs to be installed as a
service. Just include our app in webapps, change filenames,
descriptions,banners, and away we go... I guess nothing is ever that
simple.
Cheers, Gary
--
Gary Orser
Montana State University
Department of Cell Biology and Neuroscience
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml 15 Apr 2005 20:15:17 - 1.290 +++ changelog.xml 22 Apr 2005 20:38:38 - 1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero) + - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Thanks, Mark Peter Rossbach wrote: Hey Mark, I roll it back. Thanks Peter Mark Thomas schrieb: Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml15 Apr 2005 20:15:17 -1.290 +++ changelog.xml22 Apr 2005 20:38:38 -1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero)+ - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - 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: Please help ...
Please read these: http://jakarta.apache.org/site/mail.html http://jakarta.apache.org/tomcat/faq/tomcatuser.html and then post your question to the tomcat-user list. Mark Trung Le Thanh wrote: Dear all, I'm currently writing a web-based application which will be deployed in Tomcat v5.0 and be called when Windows starts. Can anyone show me how to check if the Tomcat server was started or not before starting my application? Thank you very much, Trung Le - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
Please read these: http://jakarta.apache.org/site/mail.html http://jakarta.apache.org/tomcat/faq/tomcatuser.html and then post your question to the tomcat-user list. Mark Mustafa Gulamhusain Makati wrote: Hi, I am working on a Web application which requires me to open a MS-Excel file in the web browser. It was working Ok in Jakarta-tomcat-3.3.1 . But now when I Try to run it on jakarta-tomcat-5.0.9 , the .csv or .xls file opens in the browser with junk characters. Can anybody guide me with the settings that need to be done in the 5.0.9 server for achieving this task. Thank you, With regards, Mustafa Makati. Software Engineer. Infosys Technologies Ltd. Pune. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 13, 2005 2:47 PM To: tomcat-dev@jakarta.apache.org Subject: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 93 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-t omcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-t omcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat -jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/na tive/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-13042005/build/libtoo l --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-13042005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-13042005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-13042005/build/libtoo l: /usr/local/gump/public/workspace/apache-httpd/dest-13042005/build/libtoo l: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/na tive/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-t omcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-t omcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2113042005, brutus:brutus-public:2113042005 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - 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_access allow directive????
Please read these: http://jakarta.apache.org/site/mail.html http://jakarta.apache.org/tomcat/faq/tomcatuser.html and then post your question to the tomcat-user list. Mark Jay Hulslander wrote: I would like to limit access to a directory path that I have in tomcat by domain. I believe I can use the mod_access module with the allow directive to do this. The problem is I don't know what file I need to edit, and I may not have my syntax correct. What I am trying to do is below. Please point me in the right direction. Thanks, Jay\ Directory /Kuali Order Deny,Allow Deny from all Allow from cornell.edu /Directory - 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: Nested tag problem in tomcat 5.0.29
Please DO NOT cross post. The mailing list guidelines are very clear on this issue (http://jakarta.apache.org/site/mail.html) Mark Narayan, Satya wrote: Hi all, I am having problem compiling jsp pages with nested struts tags. Is this a known error ? It says Unable to compile class for JSP Generated servlet error: %CATALINA_HOME%\work\Catalina\localhost\test\org\apache\jsp\ui\Showjsp .java:124: _jspx_meth_logic_equal_0(javax.servlet.jsp.tagext.JspTag,javax.servlet .jsp.PageContext) in org.apache.jsp.ui.ShowPricingConditionPanel_jsp cannot be applied to (org.apache.struts.taglib.html.FormTag,javax.servlet.jsp.PageContext) if (_jspx_meth_logic_equal_0(_jspx_th_html_form_0, _jspx_page_context)) Has anybody got this error. Kindly advise. Thanks and Regards, Satya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: looking for owner of web page
That would be the committers for Tomcat, all of whom are subscribed to this list. I had a quick look at it and it clearly needs to be changed to reflect the move back to JK rather than JK2 (for very good reasons I won't go into see - search the archives if you are interested). It isn't the only page that needs to be updated. See http://issues.apache.org/bugzilla/show_bug.cgi?id=33768 I have added this page to that bug as well as a note to myself to do a general review of the TC4 web pages for any similar issues. Mark Morris, John wrote: Can someone point me to the owner/maintainer of the following web page: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html John Kronos Incorporated 2 Omni Way, Chelmsford, MA 01824 Phone: +1 (978) 947-4492 Fax: +1 (978) 256-5642 Improving the Performance of People and Business(tm) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for TLP?
I was concerned at the additional management overhead such a move would place on us, particularly the PMC chair, and the impact this might have in terms of reduced time for actual development. However, after actually reading what is involved and comparing it to what we have to do now for the Jakarta PMC the change is far less than I had imagined. I believe that the benefits, particularly in terms of greater visbility and clearer branding, more than outweigh the costs. +1 Mark Yoav Shapira wrote: Hi, In light of these recent discussions on [EMAIL PROTECTED]: http://marc.theaimsgroup.com/?t=4256091 http://marc.theaimsgroup.com/?t=4256091r=1w=2 r=1w=2 http://marc.theaimsgroup.com/?l=jakarta-general http://marc.theaimsgroup.com/?l=jakarta-generalm=42733325833w=2 m=42733325833w=2 http://marc.theaimsgroup.com/?t=1753782 http://marc.theaimsgroup.com/?t=1753782r=1w=2 r=1w=2 http://marc.theaimsgroup.com/?t=1753782 http://marc.theaimsgroup.com/?t=1753782r=1w=2 r=1w=2 I think we're ready to move Tomcat to a TLP. There's a lot of support for it in the general Jakarta and ASF ranks. Before we write and vote on a proposal, I wanted to see informally what the opinions are within our own group about this potential move. I'm obviously +1. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] / mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
+1 for the proposal (comment on the scope of the proposed PMC in line) +1 for a annually rotating chair with an option to be reelected Mark Stefan Bodewig wrote: some comments from an outsider, please forgive me 8-) You will also find that if a proposal had problems in the past, it usually has been because of the project scope it described. RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to Servlet and Java Server Pages technologies based on software licensed to the Foundation; and be it further may be a bit broad - I mean, Struts, Tapestry, Turbine and others are related to Servlet and Java Server Pages technologies, aren't they? Implementation of the Servlet and JavaServer Pages JSRs? I'm honestly not sure myself. I assume you mean related to the Implementation of the Servlet and JavaServer Pages JSRs since Implementation of the Servlet and JavaServer Pages JSRs would be very narrow and exclude important parts of Tomcat such as clustering support, AJP support, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Since you went through the previous set of JK bugs for TC4 a few more have emerged. They are: 8541 15314 24628 29777 32519 32696 32998 33248 I suspect that most of them are invalid/already fixed bug would be grateful if you could take a look. Cheers, Mark Mladen Turk wrote: Hi all, My plan is to tag the JK_1_2_9_BETA on March 17th. The beta release will be available for testing from that date. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
Bill Barker wrote: From: Remy Maucherat [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: markt 2005/01/15 12:27:05 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java Log: Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns original url rather than new url as per SRV8.4. Uses same code as CoyoteRequest.getRequestURL() I think the bug report may actually be invalid, because: - getRequestURL is not a path element - the javadoc associated with the method is: Reconstructs the URL the client used to make the request. The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters. I don't know for sure, however. Any comments on that ? I'd tend to go with Remy's interpretation, but it is a grey area in the spec. The javadocs for HttpServletRequest.getRequestURI (which is a path element) say to use the deprecated HttpUtils.getRequestURL to construct a URL, which suggests that HttpUtils.getRequestURL should use the path elements. However the javadocs for HttpUtils.getRequestURL are pretty much the same as for HttpServletRequest.getRequestURL, making the picture a bit grey. On re-reading the spec it is less clear than I first thought. Personally I favour leaving the patch as is but would be happy to revert it pending clarification from the spec team. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector
All, A security issue has come to light where a mal-formed request may result in JSP source code disclosure. This issue only applies if all of the following are true: 1. You are using any Tomcat 4 version = 4.1.15 2. You are using the deprecated HTTP 1.1 connector (org.apache.catalina.connector.http.HttpConnector) 3. You have configured 1 or more contexts served by the connector with a resources element that uses the allowLinking parameter and this parameter is set to true. The fix is to use the Coyote HTTP connector (org.apache.coyote.tomcat4.CoyoteConnector). The on-line Tomcat 4 docs have been updated to include a warning about this configuration combination. The next Tomcat 4 release will include the updated documentation. If you are using Tomcat 4 with the standard Coyote HTTP connector this issue does not apply. Tomcat 5.0.x and 5.5.x are unaffected by this issue. Thanks are due to Glenn Choat who reported this issue to the Tomcat team last week. As a reminder, if you have a verified security bug to report please do not post it to email lists or submit a bug report. Security bugs should be reported privately by email to [EMAIL PROTECTED] Regards, Mark - 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
Mark Thomas wrote: Remy Maucherat wrote: snip I think 32559 was actually invalid. I disagree with this fix (which I fixed once already), as I think no bug existed in the first place: although it is ok to clear the attribute list to be nice for GC (the containing context is discarded, so it shouldn't be very useful), no notification of attribute removals should be sent. Similarly, attributes addition notifications are not done on startup, as the spec seems to imply they are only to be sent for notifying modifications while the application is running. snip I have just re-read the spec and some of the statements in 32559 are certainly wrong. However, I agree with 32559 in that reload and stop/start should have the same effect. I'll put together a simple test case to investigate this. I'll then port this fix back to TC4 plus and further changes the test case throws up. I have looked at this further and the only odd behaviour is that the attribute listeners receive notifications of changes to the welcome files during context stop (and reload). No notifications of changes are received during context start. I don't think this is a major issue but it is inconsistent. I'd like to change it (so no notifications of changes to the welcome files are received on stop) but I couldn't see an easy/obvious way to do this that didn't break something else. Any ideas anyone? Mark - 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
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: markt 2004/12/24 08:50:00 Modified:catalina/src/share/org/apache/catalina/core StandardContext.java Log: Fix bug 32559. add call to context.clearAttributes() I think 32559 was actually invalid. I disagree with this fix (which I fixed once already), as I think no bug existed in the first place: although it is ok to clear the attribute list to be nice for GC (the containing context is discarded, so it shouldn't be very useful), no notification of attribute removals should be sent. Similarly, attributes addition notifications are not done on startup, as the spec seems to imply they are only to be sent for notifying modifications while the application is running. Another issue caused by this change: http://issues.apache.org/bugzilla/show_bug.cgi?id=33463 Rémy I have just re-read the spec and some of the statements in 32559 are certainly wrong. However, I agree with 32559 in that reload and stop/start should have the same effect. I'll put together a simple test case to investigate this. I'll then port this fix back to TC4 plus and further changes the test case throws up. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: P.K. Khandelwal/GRAIN/Noblegroup is out of the office.
Already on the case. Mark Andy Armstrong wrote: On 6 Feb 2005, at 10:49, [EMAIL PROTECTED] wrote: I will be out of the office starting 06-02-2005 and will not return until 14-02-2005. For Urgent work contact. I may be reached on my Singapore mobile +65.96714014 I just left a message on his mobile asking him to have his autoresponder turned off :) Who's in a position to disable his account? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Sandy McArthur wrote: On Feb 4, 2005, at 10:29 AM, Remy Maucherat wrote: Whatever productivity is gained are over CVS will probably get eaten up by less efficient tool integration for me. Right, Ant doesn't have a svn task yet. Isn't that reason enough not to jump ship yet? I do all my CVS stuff from the command line so TortoiseCVS or TortoiseSVN - either works for me. Whilst there is no Ant integration and I am -1 on migration for TC5. When we do start the migration process I would be happy to test the migration of the following as the first batch jakarta-tomcat-4.0 jakarta-servletapi-4 jakarta-watchdog-4.0 (I still use it for testing releases) Running CVS and SVN side by side for a few weeks for Jasper and the connectors isn't too much of a pain. Assuming TC4 all works well, we could then migrate the remaining modules. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
Having raised this in the legal-discuss mailing list, the result was that there is actually no issue to worry about here. See http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/[EMAIL PROTECTED] for details. With this in mind we need to consider what, if anything, to do now. I see the following options: TC5 - Need to populate o.a.c.util.CharsetMapperDefault.properties Options 1. Do nothing. Wait for patches to be submitted. 2. Re-instate the contents of the properties file based on Jason's previous class and include appropriate text in the NOTICE file. Something like: notice o.a.c.util.CharsetMapperDefault.properties is based on code originally written by Jason Hunter [EMAIL PROTECTED] as part of the book Java Servlet Programming (O'Reilly). See a href=http://www.servlets.com/book;http://www.servlets.com/book/a for more information. Used with permission under the Apache 1.1 license. /notice TC4 - Don't need to do anything Options 1. Do nothing 2. Port Remy's enhancements to o.a.c.util.CharsetMapper TC3 - Uses o.a.t.util.http.LocalToCharSetMap which has been deleted Options 1. Re-instate the file. 2. Work around it as suggested in Bill's previous e-mail My own views are: TC 5 - option 2 TC 4 - option 2 TC 3 - option 1 (less effort for us) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
Remy Maucherat wrote: I think we're going nowhere. If the ASF doesn't make it clear that there are no redistribution IP issues because of licensing pollution, snip Isn't this exactly what the posts legal-discuss say? What hasn't been said that needs to be said? quote ...everything we received from Sun for Tomcat is clear of any IP issues until we are notified by the *author* otherwise. /quote seems unambiguous to me. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
