DO NOT REPLY [Bug 32002] New: - null page in deploy
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32002 null page in deploy Summary: null page in deploy Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I didnt placed any path inside WAR file to deploy and started to deploying it forwards me to null page (blank). I think it would be better to check that option and generate approperiate info. I now this is trivial.. but Tomcat should run best:) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 5.5.4 does not start when a single webapp fails
dear tomcat-developers, i installed the latest tomcat-5.5.4. when i try to start a webapp that runs without problems on tomcat 5.5.3, i get the following error: INFO: Starting Servlet Engine: Apache Tomcat/5.5.4 Nov 1, 2004 10:24:46 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled - Initializing log4j with '/path/to/webapp/WEB-INF/log/log4j.mescalin.xml'. Nov 1, 2004 10:24:50 AM org.apache.catalina.core.StandardPipeline registerValve INFO: Can't register valve ErrorReportValve[localhost] javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl could not be instantiated: java.lang.NullPointerException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104) at org.apache.commons.modeler.util.DomUtil.readXml(DomUtil.java:284) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.execute(MbeansDescriptorsDOMSource.java:130) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.loadDescriptors(MbeansDescriptorsDOMSource.java:120) starting tomcat stops with this error, and tomcat will not respond to any request, neither for the context that caused the error, nor for other contexts like the default one. the start procedure stops with the stack trace, there's no message like INFO: Server startup in ms... nmap shows the port 8080 to be open, but netstat does not list the request made from the browser kill -3 shows the following output: - Full thread dump Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode, sharing): DestroyJavaVM prio=1 tid=0x0805bff0 nid=0x1ff7 waiting on condition [0x..0xfeffd040] Thread-2 prio=1 tid=0x082b5910 nid=0x2007 waiting on condition [0x0570c000..0x0570c480] at java.lang.Thread.sleep(Native Method) at com.freiheit.vps.schnittstellen.urllogin.LoginFilter$1.run(LoginFilter.java:83) at java.lang.Thread.run(Thread.java:595) Thread-1 daemon prio=1 tid=0x085e9d18 nid=0x2006 waiting on condition [0x063cc000..0x063cc800] at java.lang.Thread.sleep(Native Method) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95) Low Memory Detector daemon prio=1 tid=0x080a0de8 nid=0x2002 runnable [0x..0x] CompilerThread0 daemon prio=1 tid=0x0809f898 nid=0x2001 waiting on condition [0x..0x02f34068] Signal Dispatcher daemon prio=1 tid=0x0809e9c0 nid=0x2000 runnable [0x..0x] Finalizer daemon prio=1 tid=0x08099c60 nid=0x1fff in Object.wait() [0x02eb3000..0x02eb3580] at java.lang.Object.wait(Native Method) - waiting on 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08098f70 nid=0x1ffe in Object.wait() [0x076d5000..0x076d5500] at java.lang.Object.wait(Native Method) - waiting on 0xb73c6958 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0xb73c6958 (a java.lang.ref.Reference$Lock) VM Thread prio=1 tid=0x080964a0 nid=0x1ffd runnable VM Periodic Task Thread prio=1 tid=0x080a2278 nid=0x2003 waiting on condition - one note about the LoginFilter u see in this list: - when i remove the filter mapping, this filter get's started, and the error is the same as described above - when i remove both filter mapping and filter definition, i get the stack trace as described above, but the tomcat process terminates with the error (the filter's not loaded). i don't know if this are different problems, or if there's some relation. one problem is that the webapp does not start, but another problem is that tomcat fails to start if one context is not starting correctly. my system: fedora core 2 sun jdk 1.5 (jpackage.org) tomcat 5.5.4 alpha log4j 1.2.7 (the same with 1.2.8) do you need some more information? for now, i'll step back to tomcat 5.5.3. thanx for your help, martin signature.asc Description: This is a digitally signed message part
RE: contrib directory
Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
hello, that was only half of the story. what i forgot to mention: the web.xml contains a listener-entry for a class, that initializes log4j with a specified log4j.xml (here log4j.mescalin.xml). when i remove the entry for the listener in the web.xml, tomcat starts without any error... regards, martin On Mon, 2004-11-01 at 11:02, Martin Grotzke wrote: dear tomcat-developers, i installed the latest tomcat-5.5.4. when i try to start a webapp that runs without problems on tomcat 5.5.3, i get the following error: INFO: Starting Servlet Engine: Apache Tomcat/5.5.4 Nov 1, 2004 10:24:46 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled - Initializing log4j with '/path/to/webapp/WEB-INF/log/log4j.mescalin.xml'. Nov 1, 2004 10:24:50 AM org.apache.catalina.core.StandardPipeline registerValve INFO: Can't register valve ErrorReportValve[localhost] javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl could not be instantiated: java.lang.NullPointerException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104) at org.apache.commons.modeler.util.DomUtil.readXml(DomUtil.java:284) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.execute(MbeansDescriptorsDOMSource.java:130) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.loadDescriptors(MbeansDescriptorsDOMSource.java:120) starting tomcat stops with this error, and tomcat will not respond to any request, neither for the context that caused the error, nor for other contexts like the default one. the start procedure stops with the stack trace, there's no message like INFO: Server startup in ms... nmap shows the port 8080 to be open, but netstat does not list the request made from the browser kill -3 shows the following output: - Full thread dump Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode, sharing): DestroyJavaVM prio=1 tid=0x0805bff0 nid=0x1ff7 waiting on condition [0x..0xfeffd040] Thread-2 prio=1 tid=0x082b5910 nid=0x2007 waiting on condition [0x0570c000..0x0570c480] at java.lang.Thread.sleep(Native Method) at com.freiheit.vps.schnittstellen.urllogin.LoginFilter$1.run(LoginFilter.java:83) at java.lang.Thread.run(Thread.java:595) Thread-1 daemon prio=1 tid=0x085e9d18 nid=0x2006 waiting on condition [0x063cc000..0x063cc800] at java.lang.Thread.sleep(Native Method) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95) Low Memory Detector daemon prio=1 tid=0x080a0de8 nid=0x2002 runnable [0x..0x] CompilerThread0 daemon prio=1 tid=0x0809f898 nid=0x2001 waiting on condition [0x..0x02f34068] Signal Dispatcher daemon prio=1 tid=0x0809e9c0 nid=0x2000 runnable [0x..0x] Finalizer daemon prio=1 tid=0x08099c60 nid=0x1fff in Object.wait() [0x02eb3000..0x02eb3580] at java.lang.Object.wait(Native Method) - waiting on 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08098f70 nid=0x1ffe in Object.wait() [0x076d5000..0x076d5500] at java.lang.Object.wait(Native Method) - waiting on 0xb73c6958 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0xb73c6958 (a java.lang.ref.Reference$Lock) VM Thread prio=1 tid=0x080964a0 nid=0x1ffd runnable VM Periodic Task Thread prio=1 tid=0x080a2278 nid=0x2003 waiting on condition - one note about the LoginFilter u see in this list: - when i remove the filter mapping, this filter get's started, and the error is the same as described above - when i remove both filter mapping and filter definition, i get the stack trace as described above, but the tomcat process terminates with the error (the filter's not loaded). i don't know if this are different problems, or if there's some relation. one problem is that the webapp does not start, but another problem is that tomcat fails to start if one context is not starting correctly. my system: fedora core 2 sun jdk 1.5 (jpackage.org) tomcat 5.5.4 alpha log4j 1.2.7 (the same with 1.2.8) do you need some more information? for now, i'll step back to tomcat 5.5.3. thanx for your help, martin signature.asc Description: This is a digitally signed message part
Re: tomcat 5.5.4 does not start when a single webapp fails
Martin Grotzke wrote: dear tomcat-developers, i installed the latest tomcat-5.5.4. when i try to start a webapp that runs without problems on tomcat 5.5.3, i get the following error: It works for me. I d/led the distribution, as packaging problems are always a possibility. INFO: Starting Servlet Engine: Apache Tomcat/5.5.4 Nov 1, 2004 10:24:46 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled - Initializing log4j with '/path/to/webapp/WEB-INF/log/log4j.mescalin.xml'. Nov 1, 2004 10:24:50 AM org.apache.catalina.core.StandardPipeline registerValve INFO: Can't register valve ErrorReportValve[localhost] javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl could not be instantiated: java.lang.NullPointerException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104) at org.apache.commons.modeler.util.DomUtil.readXml(DomUtil.java:284) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.execute(MbeansDescriptorsDOMSource.java:130) at org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.loadDescriptors(MbeansDescriptorsDOMSource.java:120) For some reason modeler tries to use Xerces without the right Java 5 package name. Your system configuration seems bad. starting tomcat stops with this error, and tomcat will not respond to any request, neither for the context that caused the error, nor for other contexts like the default one. the start procedure stops with the stack trace, there's no message like INFO: Server startup in ms... nmap shows the port 8080 to be open, but netstat does not list the request made from the browser kill -3 shows the following output: - Full thread dump Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode, sharing): DestroyJavaVM prio=1 tid=0x0805bff0 nid=0x1ff7 waiting on condition [0x..0xfeffd040] Thread-2 prio=1 tid=0x082b5910 nid=0x2007 waiting on condition [0x0570c000..0x0570c480] at java.lang.Thread.sleep(Native Method) at com.freiheit.vps.schnittstellen.urllogin.LoginFilter$1.run(LoginFilter.java:83) at java.lang.Thread.run(Thread.java:595) Thread-1 daemon prio=1 tid=0x085e9d18 nid=0x2006 waiting on condition [0x063cc000..0x063cc800] at java.lang.Thread.sleep(Native Method) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95) Low Memory Detector daemon prio=1 tid=0x080a0de8 nid=0x2002 runnable [0x..0x] CompilerThread0 daemon prio=1 tid=0x0809f898 nid=0x2001 waiting on condition [0x..0x02f34068] Signal Dispatcher daemon prio=1 tid=0x0809e9c0 nid=0x2000 runnable [0x..0x] Finalizer daemon prio=1 tid=0x08099c60 nid=0x1fff in Object.wait() [0x02eb3000..0x02eb3580] at java.lang.Object.wait(Native Method) - waiting on 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked 0xb73c68d8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08098f70 nid=0x1ffe in Object.wait() [0x076d5000..0x076d5500] at java.lang.Object.wait(Native Method) - waiting on 0xb73c6958 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0xb73c6958 (a java.lang.ref.Reference$Lock) VM Thread prio=1 tid=0x080964a0 nid=0x1ffd runnable VM Periodic Task Thread prio=1 tid=0x080a2278 nid=0x2003 waiting on condition - I'd like to understand why you think a thread dump is useful to debug a JAXP configuration issue. Funny :) one note about the LoginFilter u see in this list: - when i remove the filter mapping, this filter get's started, and the error is the same as described above - when i remove both filter mapping and filter definition, i get the stack trace as described above, but the tomcat process terminates with the error (the filter's not loaded). i don't know if this are different problems, or if there's some relation. one problem is that the webapp does not start, but another problem is that tomcat fails to start if one context is not starting correctly. my system: fedora core 2 sun jdk 1.5 (jpackage.org) tomcat 5.5.4 alpha log4j 1.2.7 (the same with 1.2.8) do you need some more information? for now, i'll step back to tomcat 5.5.3. Your report is bogus, so step back all you want, but there won't be any fix. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
Martin Grotzke wrote: hello, that was only half of the story. what i forgot to mention: the web.xml contains a listener-entry for a class, that initializes log4j with a specified log4j.xml (here log4j.mescalin.xml). when i remove the entry for the listener in the web.xml, tomcat starts without any error... Your listener might mess up JAXP's configuration: download the compatibility package which includes Xerces with the regular package names. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
On Mon, 2004-11-01 at 13:26, Remy Maucherat wrote: Martin Grotzke wrote: one problem is that the webapp does not start, but another problem is that tomcat fails to start if one context is not starting correctly. my system: fedora core 2 sun jdk 1.5 (jpackage.org) tomcat 5.5.4 alpha log4j 1.2.7 (the same with 1.2.8) do you need some more information? for now, i'll step back to tomcat 5.5.3. Your report is bogus, so step back all you want, but there won't be any fix. what's bogus there? i only wanted to let you know that there were changes from tc-5.5.3 to 5.5.4 that make the described error possible. if i've choses wrong words for this, then i'm sorry about that. if you think that the described behavior of tomcat is completely right there's no problem, i can stay with 5.5.3... regards, martin Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
RE: contrib directory
Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL
Re: tomcat 5.5.4 does not start when a single webapp fails
Martin Grotzke wrote: what's bogus there? The report. i only wanted to let you know that there were changes from tc-5.5.3 to 5.5.4 that make the described error possible. if i've choses wrong words for this, then i'm sorry about that. There are no relevant changes between 5.5.3 and 5.5.4. if you think that the described behavior of tomcat is completely right there's no problem, i can stay with 5.5.3... The report is invalid in bugzilla terms. I am certain you're not using an out-of-the-box 5.5.3. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31132] - startup scripts on the 400 fail to start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31132. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31132 startup scripts on the 400 fail to start --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 13:58 --- Created an attachment (id=13289) Patch for startup.sh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31132] - startup scripts on the 400 fail to start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31132. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31132 startup scripts on the 400 fail to start --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 13:58 --- Created an attachment (id=13290) Patch for catalina.sh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31132] - startup scripts on the 400 fail to start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31132. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31132 startup scripts on the 400 fail to start --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 13:58 --- Created an attachment (id=13291) Patch for setclasspath.sh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
On Mon, 2004-11-01 at 13:29, Remy Maucherat wrote: Martin Grotzke wrote: hello, that was only half of the story. what i forgot to mention: the web.xml contains a listener-entry for a class, that initializes log4j with a specified log4j.xml (here log4j.mescalin.xml). when i remove the entry for the listener in the web.xml, tomcat starts without any error... Your listener might mess up JAXP's configuration: download the compatibility package which includes Xerces with the regular package names. The Filter includes one statement: System.setProperty( javax.xml.parsers.DocumentBuilderFactory, org.apache.xerces.jaxp.DocumentBuilderFactoryImpl ); the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class. but the part that's not a tomcat-internals issue does not have to be discussed here, probably the tomcat-user-list is a better place for this... thanx for now, martin Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: tomcat 5.5.4 does not start when a single webapp fails
Martin Grotzke wrote: The Filter includes one statement: System.setProperty( javax.xml.parsers.DocumentBuilderFactory, org.apache.xerces.jaxp.DocumentBuilderFactoryImpl ); the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class. but the part that's not a tomcat-internals issue does not have to be discussed here, probably the tomcat-user-list is a better place for this... Without a security manager, any application can set system properties, which are global. So here the JAXP settings will be changed for the whole system, which will produce random results (since only your webapp has visibility on the Xerces class) :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Time for 5.0.30
Hi, Assuming no one is opposed (and if you are, that's fine, we can work out another time), I'd like to tag and cut Tomcat 5.0.30 this coming Thursday, November 4th, at 1800h GMT (http://www.timeanddate.com/worldclock/converted.html?month=11day=4yea r=2004hour=18min=0sec=0p1=0p2=43). 5.0.29 has a ton of good bug fixes, but was hampered by the JSP compilation bug I introduced. 5.0.30 has a few more fixes and would make for a good stable release I hope. Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
Remy Maucherat wrote: Martin Grotzke wrote: The Filter includes one statement: System.setProperty( javax.xml.parsers.DocumentBuilderFactory, org.apache.xerces.jaxp.DocumentBuilderFactoryImpl ); the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class. but the part that's not a tomcat-internals issue does not have to be discussed here, probably the tomcat-user-list is a better place for this... Without a security manager, any application can set system properties, which are global. So here the JAXP settings will be changed for the whole system, which will produce random results (since only your webapp has visibility on the Xerces class) :( There are clearly better ways to influence JAXP than this... If there are no other META-INF services entries for document builders in the class loader prior to the web app's (which I believe is the case in 5.5), then just having your Xerces (which should have such a META-INF entry) in your web app should suffice. But honestly, Xerces 1.4.4!?! That's positively ancient. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: contrib directory
why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone
RE: contrib directory
Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi, Without knowing the filter, I figured if .jpg was there than .png wasn't much different, and if .txt was there .css is not much different. So it made sense from a consistency standpoint. However, I have no particular attachment to the filter itself or this commit: if you don't like it, feel free to undo it ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:25 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav, you made the right choice. The checkin is good. Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:25 AM Subject: RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Hi, Without knowing the filter, I figured if .jpg was there than .png wasn't much different, and if .txt was there .css is not much different. So it made sense from a consistency standpoint. However, I have no particular attachment to the filter itself or this commit: if you don't like it, feel free to undo it ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:25 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29727] - JNDI env-entry not reload when context reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29727 JNDI env-entry not reload when context reloaded --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 14:53 --- Created an attachment (id=13292) If Environment entry is changed using admin app, the change is not visisble in JNDI. Patch to solve this problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib directory
Dear all, I've walked almost the same path with OS/2 on the NetBeans side as Meg with OpenVMS. A new sourceforge project could be a working idea. As then both TomCat and maybe tomcat-contrib would be a third-party stuff for NetBeans. So we might convince them to include this into their release (4.1 earliest). Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit
DO NOT REPLY [Bug 29727] - JNDI env-entry not reload when context reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29727 JNDI env-entry not reload when context reloaded --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 15:35 --- Sorry, this patch is wrong :-( Please do not apply it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: contrib directory
I guess that's what we'll have to do. -meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 10:23 AM To: Tomcat Developers List Subject: Re: contrib directory Dear all, I've walked almost the same path with OS/2 on the NetBeans side as Meg with OpenVMS. A new sourceforge project could be a working idea. As then both TomCat and maybe tomcat-contrib would be a third-party stuff for NetBeans. So we might convince them to include this into their release (4.1 earliest). Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we
Re: contrib directory
Garrison, Meg wrote: Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. It would be a good idea, but I don't think it is possible at the moment. Commit access requires a unix account on a machine, at least for cvs. Even if this could be solved - there are non-technical problems, ASF requires a CLA, and a certain review and oversight process. Ant has an ant-contrib project on sourceforge ( including few ant committers ). Maybe we should have a tomcat-contrib as well. This would be a good idea even for committers - there is experimental stuff and code that is not necesarily servlet container but is tomcat related ( like non-http servers, etc ). Costin Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29727] - JNDI env-entry not reload when context reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29727 JNDI env-entry not reload when context reloaded --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 16:05 --- The comments from Igor are not correct. It works ok if you change the variable via the admin interface - it does not work if you manually change the web.xml, and stop/restart the web application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib directory
Shapira, Yoav wrote: Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... It seems there is some mass - if the same idea is mentioned at the same time by more people :-) I think it would be good to have few tomcat committers as project admins - at least 3 (the magic number). I volunteer, it seems Yoav is also interested - anyone else ? Costin Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out.. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now.. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the
RE: contrib directory
FWIW, we have recently contributed some OpenVMS-specific changes to Ant, which they accepted. We did not contribute to Ant-contrib. I've signed CLAs for NetBeans, there isn't an issue on this end with that. I assume the ASF CLA isn't all that different from the others. Also, I use cvs from my windows desktop machine to access the cvs server where the netbeans cvs library resides. Or, if you really mean we need a Unix machine, we have lots of those here at HP ;-) But, in any case, if the only consensus we can reach at this point is that a tomcat-contrib project would be the best place to host these sorts of files, then yes, let's do it :-) I personally would prefer that the tomcat-contrib project only contain contributions like mine and Leslie's because I think the NetBeans folks would be comfortable taking things like launchers, rather than experimental stuff, but I realize I don't really get a say in this. Meg -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache Sent: Monday, November 01, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: contrib directory Garrison, Meg wrote: Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. It would be a good idea, but I don't think it is possible at the moment. Commit access requires a unix account on a machine, at least for cvs. Even if this could be solved - there are non-technical problems, ASF requires a CLA, and a certain review and oversight process. Ant has an ant-contrib project on sourceforge ( including few ant committers ). Maybe we should have a tomcat-contrib as well. This would be a good idea even for committers - there is experimental stuff and code that is not necesarily servlet container but is tomcat related ( like non-http servers, etc ). Costin Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Filip Hanik - Dev wrote: actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. Ahh :) Good then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thank you for delivery
You got a new message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32005] New: - Out of memory error when restarting application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32005.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32005
Out of memory error when restarting application
Summary: Out of memory error when restarting application
Product: Tomcat 5
Version: 5.0.14
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Each time I restart a Tomcat web application (using the Manager tool) more
memory is tied up by the Tomcat service. Eventually, the next restart will
fail with an out of memory error and I have to restart the service. Things
I've tried to resolve/diagnose this:
1. Checked for memory leaks in the application I was restarting. I didn't
find anything suspicious, so then I undeployed that (and all other
applications that I'd deployed). This left only the standard set of apps.
that are installed with Tomcat (/, /admin, /manager). Then I restarted
/admin repeatedly and replicated the problem (eventually I ran out of
memory).
2. Removed every jar file in {tomcat home}/common/lib that were not put
there by the initial Tomcat installation. (I had read some postings
that said that classes that are loaded from here are not garbage-collected
when an app.is restarted.) This did not correct the problem, either.
Please let me know if there is anything I can do to eliminate this behavior.
I'm also curoius as to whether setting reloadable to true in my production
environment would degrade performance significantly (this would of course
eliminate most of my need to restart production applications).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32005] - Out of memory error when restarting application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32005 Out of memory error when restarting application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 17:28 --- Please use tomcat-user for help. Otherwise - a memory profiler is the only way to debug this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32005] - Out of memory error when restarting application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32005 Out of memory error when restarting application --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 17:30 --- First, please try a more recent release like 5.0.28. Second, you might be interested in recent discussions on the tomcat-user mailing list (archives are publicly available, e.g. at AIMS) as to why neither reloadable nor reloading via the manager webapp is that practical in the real world. Third, if you're curious about the performance impact of setting reloadable=true, I suggest testing it out. It's usually negligible, but of course you need to test your own app on your own hardware. Finally, I suggest you use the mailing list to discuss this problem. Bugzilla is not intended to be a discussion forum, and is not good as such. If after discussing your issue on the mailing list you can come up with a WAR we can use to reproduce what you're seeing, then please reopen this issue and attach said WAR. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32002] - null page in deploy
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32002 null page in deploy [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 17:31 --- Works for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31998] - Tomcat Service Shutting down automatically
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31998. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31998 Tomcat Service Shutting down automatically [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 17:32 --- Doesn't happen for me, nor for anyone else I know (and I do know a few). It won't shut down automatically unless you tell it to, or there's an internal JVM crash. Both of those causes are not Tomcat's fault. I suggest you post your problem on the tomcat-user mailing list and ask for help there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32005] - Out of memory error when restarting application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32005 Out of memory error when restarting application --- Additional Comments From [EMAIL PROTECTED] 2004-11-01 19:47 --- Regarding your second comment below, I haven't be able to find the thread you're talking about. Can you suggest a search string that will get me to the right place? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java
luehe 2004/11/01 14:22:37
Modified:catalina/src/share/org/apache/catalina/connector
RequestFacade.java
Log:
Fixed formatting prior to making changes
Revision ChangesPath
1.6 +53 -28
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java
Index: RequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RequestFacade.java23 Jun 2004 08:24:57 - 1.5
+++ RequestFacade.java1 Nov 2004 22:22:37 - 1.6
@@ -49,7 +49,8 @@
// --- DoPrivileged
-private final class GetAttributePrivilegedAction implements PrivilegedAction{
+private final class GetAttributePrivilegedAction
+implements PrivilegedAction {
public Object run() {
return request.getAttributeNames();
@@ -57,7 +58,8 @@
}
-private final class GetParameterMapPrivilegedAction implements PrivilegedAction{
+private final class GetParameterMapPrivilegedAction
+implements PrivilegedAction {
public Object run() {
return request.getParameterMap();
@@ -65,30 +67,38 @@
}
-private final class GetRequestDispatcherPrivilegedAction implements
PrivilegedAction{
+private final class GetRequestDispatcherPrivilegedAction
+implements PrivilegedAction {
+
private String path;
+
public GetRequestDispatcherPrivilegedAction(String path){
this.path = path;
}
public Object run() {
return request.getRequestDispatcher(path);
- }
+}
}
-private final class GetParameterPrivilegedAction implements PrivilegedAction{
+private final class GetParameterPrivilegedAction
+implements PrivilegedAction {
+
public String name;
+
public GetParameterPrivilegedAction(String name){
this.name = name;
}
+
public Object run() {
return request.getParameter(name);
}
}
-private final class GetParameterNamesPrivilegedAction implements
PrivilegedAction{
+private final class GetParameterNamesPrivilegedAction
+implements PrivilegedAction {
public Object run() {
return request.getParameterNames();
@@ -96,26 +106,32 @@
}
-private final class GetParameterValuePrivilegedAction implements
PrivilegedAction{
+private final class GetParameterValuePrivilegedAction
+implements PrivilegedAction {
+
public String name;
+
public GetParameterValuePrivilegedAction(String name){
this.name = name;
}
+
public Object run() {
return request.getParameterValues(name);
}
}
-private final class GetCookiesPrivilegedAction implements PrivilegedAction{
+private final class GetCookiesPrivilegedAction
+implements PrivilegedAction {
- public Object run() {
+public Object run() {
return request.getCookies();
}
}
-private final class GetCharacterEncodingPrivilegedAction implements
PrivilegedAction{
+private final class GetCharacterEncodingPrivilegedAction
+implements PrivilegedAction {
public Object run() {
return request.getCharacterEncoding();
@@ -123,8 +139,11 @@
}
-private final class GetHeadersPrivilegedAction implements PrivilegedAction{
+private final class GetHeadersPrivilegedAction
+implements PrivilegedAction {
+
private String name;
+
public GetHeadersPrivilegedAction(String name){
this.name = name;
}
@@ -135,7 +154,8 @@
}
-private final class GetHeaderNamesPrivilegedAction implements PrivilegedAction{
+private final class GetHeaderNamesPrivilegedAction
+implements PrivilegedAction {
public Object run() {
return request.getHeaderNames();
@@ -143,7 +163,8 @@
}
-private final class GetLocalePrivilegedAction implements PrivilegedAction{
+private final class
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties
luehe 2004/11/01 14:38:44
Modified:catalina/src/share/org/apache/catalina/connector
RequestFacade.java LocalStrings.properties
Log:
Throw more meaningful exception (instead of NPE) if underlying request has been
recycled and attempt is made to access it via its facade
Revision ChangesPath
1.7 +335 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java
Index: RequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestFacade.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- RequestFacade.java1 Nov 2004 22:22:37 - 1.6
+++ RequestFacade.java1 Nov 2004 22:38:44 - 1.7
@@ -31,6 +31,8 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
+import org.apache.catalina.util.StringManager;
+
/**
* Facade class that wraps a Coyote request object.
@@ -42,9 +44,7 @@
* @version $Revision$ $Date$
*/
-
-public class RequestFacade
-implements HttpServletRequest {
+public class RequestFacade implements HttpServletRequest {
// --- DoPrivileged
@@ -218,6 +218,13 @@
protected Request request = null;
+/**
+ * The string manager for this package.
+ */
+protected static StringManager sm =
+StringManager.getManager(Constants.Package);
+
+
// - Public Methods
@@ -233,11 +240,23 @@
public Object getAttribute(String name) {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
return request.getAttribute(name);
}
public Enumeration getAttributeNames() {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
if (System.getSecurityManager() != null){
return (Enumeration)AccessController.doPrivileged(
new GetAttributePrivilegedAction());
@@ -248,6 +267,12 @@
public String getCharacterEncoding() {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
if (System.getSecurityManager() != null){
return (String)AccessController.doPrivileged(
new GetCharacterEncodingPrivilegedAction());
@@ -258,28 +283,57 @@
public void setCharacterEncoding(String env)
-throws java.io.UnsupportedEncodingException {
+throws java.io.UnsupportedEncodingException {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
request.setCharacterEncoding(env);
}
public int getContentLength() {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
return request.getContentLength();
}
public String getContentType() {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
return request.getContentType();
}
-public ServletInputStream getInputStream()
-throws IOException {
+public ServletInputStream getInputStream() throws IOException {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
return request.getInputStream();
}
public String getParameter(String name) {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
if (System.getSecurityManager() != null){
return (String)AccessController.doPrivileged(
new GetParameterPrivilegedAction(name));
@@ -290,6 +344,12 @@
public Enumeration getParameterNames() {
+
+if (request == null) {
+throw new IllegalStateException(
+sm.getString(requestFacade.nullRequest));
+}
+
if
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties
[EMAIL PROTECTED] wrote: luehe 2004/11/01 14:38:44 Modified:catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Log: Throw more meaningful exception (instead of NPE) if underlying request has been recycled and attempt is made to access it via its facade I think I always consistently refused this change (no use: if people who hack can't be bothered to look that up in the code, then I don't think they'll understand what your exception really means either), but I'll give up on that one. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.4 does not start when a single webapp fails
On Mon, 2004-11-01 at 15:05, Remy Maucherat wrote:
Martin Grotzke wrote:
The Filter includes one statement:
System.setProperty( javax.xml.parsers.DocumentBuilderFactory,
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl );
the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes
org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class.
but the part that's not a tomcat-internals issue does not have to be
discussed here, probably the tomcat-user-list is a better place for
this...
Without a security manager, any application can set system properties,
which are global. So here the JAXP settings will be changed for the
whole system, which will produce random results (since only your webapp
has visibility on the Xerces class) :(
You're right. The listener was not written by me, so i don't know
why this way was chosen.
I changed the implementation, now it checks if jaxp is yet configured.
Thanx for your pointers concerning this!
Perhaps interesting for you:
Write a servlet context listener with the following implementation
public void contextInitialized( ServletContextEvent sce ) {
System.setProperty( javax.xml.parsers.DocumentBuilderFactory,
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl );
}
this prevents tomcat 5.5.4 from starting successfully,
in tomcat 5.5.3 it has no impact.
cheers,
martin
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector ResponseFacade.java
luehe 2004/11/01 15:21:58
Modified:catalina/src/share/org/apache/catalina/connector
ResponseFacade.java
Log:
Fixed formatting prior to making changes
Revision ChangesPath
1.7 +13 -11
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java
Index: ResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ResponseFacade.java 23 Jun 2004 08:24:57 - 1.6
+++ ResponseFacade.java 1 Nov 2004 23:21:58 - 1.7
@@ -46,8 +46,11 @@
// --- DoPrivileged
-private final class SetContentTypePrivilegedAction implements PrivilegedAction{
+private final class SetContentTypePrivilegedAction
+implements PrivilegedAction {
+
private String contentType;
+
public SetContentTypePrivilegedAction(String contentType){
this.contentType = contentType;
}
@@ -58,7 +61,9 @@
}
}
-private final class DateHeaderPrivilegedAction implements PrivilegedAction {
+private final class DateHeaderPrivilegedAction
+implements PrivilegedAction {
+
private String name;
private long value;
private boolean add;
@@ -90,7 +95,6 @@
public ResponseFacade(Response response) {
this.response = response;
-
}
@@ -443,18 +447,16 @@
return;
response.setStatus(sc, sm);
-
}
- public String getContentType() {
- return response.getContentType();
- }
+public String getContentType() {
+return response.getContentType();
+}
- public void setCharacterEncoding(String arg0) {
+public void setCharacterEncoding(String arg0) {
response.setCharacterEncoding(arg0);
- }
-
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector ResponseFacade.java
luehe 2004/11/01 15:34:04
Modified:catalina/src/share/org/apache/catalina/connector
ResponseFacade.java
Log:
Throw more meaningful exception (instead of NPE) if underlying response
has been recycled and attempt is made to access it via its facade
Revision ChangesPath
1.8 +86 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java
Index: ResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ResponseFacade.java 1 Nov 2004 23:21:58 - 1.7
+++ ResponseFacade.java 1 Nov 2004 23:34:04 - 1.8
@@ -29,6 +29,7 @@
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.util.StringManager;
/**
* Facade class that wraps a Coyote response object.
@@ -38,8 +39,6 @@
* @author Jean-Francois Arcand
* @version $Revision$ $Date$
*/
-
-
public class ResponseFacade
implements HttpServletResponse {
@@ -98,7 +97,14 @@
}
-// - Instance Variables
+// --- Class/Instance Variables
+
+
+/**
+ * The string manager for this package.
+ */
+protected static StringManager sm =
+StringManager.getManager(Constants.Package);
/**
@@ -120,15 +126,23 @@
public void finish() {
-response.setSuspended(true);
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+response.setSuspended(true);
}
public boolean isFinished() {
-return response.isSuspended();
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+return response.isSuspended();
}
@@ -136,6 +150,12 @@
public String getCharacterEncoding() {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.getCharacterEncoding();
}
@@ -205,6 +225,12 @@
public int getBufferSize() {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.getBufferSize();
}
@@ -255,6 +281,12 @@
public boolean isCommitted() {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return (response.isAppCommitted());
}
@@ -280,6 +312,12 @@
public Locale getLocale() {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.getLocale();
}
@@ -295,26 +333,56 @@
public boolean containsHeader(String name) {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.containsHeader(name);
}
public String encodeURL(String url) {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.encodeURL(url);
}
public String encodeRedirectURL(String url) {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.encodeRedirectURL(url);
}
public String encodeUrl(String url) {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
return response.encodeURL(url);
}
public String encodeRedirectUrl(String url) {
+
+if (response == null) {
+throw new IllegalStateException(
+sm.getString(responseFacade.nullResponse));
+}
+
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector LocalStrings.properties
luehe 2004/11/01 15:35:39 Modified:catalina/src/share/org/apache/catalina/connector LocalStrings.properties Log: Throw more meaningful exception (instead of NPE) if underlying response has been recycled and attempt is made to access it via its facade Revision ChangesPath 1.5 +1 -0 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/LocalStrings.properties Index: LocalStrings.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/LocalStrings.properties,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LocalStrings.properties 1 Nov 2004 22:38:44 - 1.4 +++ LocalStrings.properties 1 Nov 2004 23:35:39 - 1.5 @@ -45,6 +45,7 @@ coyoteRequest.attributeEvent=Exception thrown by attributes event listener coyoteRequest.postTooLarge=Parameters were not parsed because the size of the posted data was too big. Use the maxPostSize attribute of the connector to resolve this if the application should accept large POSTs. requestFacade.nullRequest=Null request object +responseFacade.nullResponse=Null response object # # MapperListener - 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/connector RequestFacade.java LocalStrings.properties
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/11/01 14:38:44 Modified:catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Log: Throw more meaningful exception (instead of NPE) if underlying request has been recycled and attempt is made to access it via its facade I think I always consistently refused this change (no use: if people who hack can't be bothered to look that up in the code, then I don't think they'll understand what your exception really means either), but I'll give up on that one. In this case, it's useful because rather than instinctively filing a bug against Tomcat when seeing a NPE, people will be reminded to check their code first, because they're obviously using Tomcat in a way it was not intended to be used. We just ran into this internally. Jan - 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/connector RequestFacade.java LocalStrings.properties
- Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 01, 2004 3:41 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/11/01 14:38:44 Modified:catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Log: Throw more meaningful exception (instead of NPE) if underlying request has been recycled and attempt is made to access it via its facade I think I always consistently refused this change (no use: if people who hack can't be bothered to look that up in the code, then I don't think they'll understand what your exception really means either), but I'll give up on that one. In this case, it's useful because rather than instinctively filing a bug against Tomcat when seeing a NPE, people will be reminded to check their code first, because they're obviously using Tomcat in a way it was not intended to be used. I agree with Remy: It's totally unnecessary, and gives somebody reading the code that the request can be null. The javadocs should probably be updated with something like: * @exception IllegalStateException If you are a total moron without a clue ;-) We just ran into this internally. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - 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/connector RequestFacade.java LocalStrings.properties
Bill Barker wrote: - Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 01, 2004 3:41 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/11/01 14:38:44 Modified:catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties Log: Throw more meaningful exception (instead of NPE) if underlying request has been recycled and attempt is made to access it via its facade I think I always consistently refused this change (no use: if people who hack can't be bothered to look that up in the code, then I don't think they'll understand what your exception really means either), but I'll give up on that one. In this case, it's useful because rather than instinctively filing a bug against Tomcat when seeing a NPE, people will be reminded to check their code first, because they're obviously using Tomcat in a way it was not intended to be used. I agree with Remy: It's totally unnecessary, and gives somebody reading the code that the request can be null. The javadocs should probably be updated with something like: * @exception IllegalStateException If you are a total moron without a clue ;-) In the case I was referring to, some project was storing a servlet request (facade) in a ThreadLocal and, due to a bug in their code, was hanging on to it beyond the request's lifetime. This was happening only under rare circumstances. So in this case, the Request behind the facade was indeed null. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
