Re: [PATCH] Re: SSI Servlet has big problems
You're right. It should have been -r TOMCAT_4_1_2 (which checks out fine for me). - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 6:06 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems Hi Bill. Didn't have any luck with that either (see below). Does it work for you? Any idea what the message about the CVS locks means / how to fix it? Yeah, I see what you mean re: files in the attic. I'm curious how things looked before I started changing things, to better understand what caused this code collision... -Dan Here's what I got when I tried to do the -r thing: [dan@oogie tmp]$ echo $CVSROOT :ext:[EMAIL PROTECTED]:/home/cvs [dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0 Protocol error: uncounted data discarded Bill Barker wrote: -r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name param-value1/param-value /init-param load-on-startup4/load-on-startup /servlet --- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SSIServlet/servlet-class init-param
Re: [PATCH] Re: SSI Servlet has big problems
Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name
Re: [PATCH] Re: SSI Servlet has big problems
Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? It's all in CVS. If you checkout the source code from some time in December you should get it all back in util and util/ssi. It looks like my last check-in was on November 29th or so. I too made some pretty significant changes. It looks like my final test.xml never made it in, but I'm attaching it here. (Only the SSI parts are relevant of course.) All of the golden files look like they're still there. I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. The motivation for my original changes was to fix the nesting of .shtml files (ie: a .shtml file including another .shtml file) and to add support for set, variable substitution, conditionals, etc.. When I looked at the original version and saw it was such a mess, I did pertty much a complete rewrite. Some of my changes are similar to yours, but I got rid of classes like SsiMediator and such. All of this included fixing how variables were kept for includes and such, as well as parsing fixes and the addition of some new commands. It's all pretty significant and may not naturally fit some of your refactoring. To be honest, it might be easier to redo your changes against my stuff than it would be to graft my stuff onto yours. Even though I know that's probably a real pain in the a**. In it's current state, I think the current fixed version has much less functionality than the previous fixed version. Hopefully we can work something out. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? Must have. The fact that you even have an SsiMediator means you were changing an older version. Unfortunately, Bill didn't notice this when he committed your stuff and probably just whole-sale nuked the older files. Don't feel too bad about that, though. My original rewrite did something similar. Only in my case, it was only a small bug fix that was reverted. Still a little disconcerting from my point of view. Probably my own fault for taking a two-month break from the lists. And I had no idea I could have parlayed those patches into committer access. :) -Paul -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml
Re: [PATCH] Re: SSI Servlet has big problems
Ugh this is painful. I'll checkout your stuff within the next few days. If the architecture looks good and does have significantly greater functionality I will merge my changes into your code. I also fixed the included variable problem and the nested include problems. The conditional stuff was the only thing I thought I was missing. I'm curious: How could I have checked out an older version accidently? Wouldn't I have had to explicitly specify a date or tag or something? ... This is all quite depressing ... -Dan Paul Speed wrote: Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? It's all in CVS. If you checkout the source code from some time in December you should get it all back in util and util/ssi. It looks like my last check-in was on November 29th or so. I too made some pretty significant changes. It looks like my final test.xml never made it in, but I'm attaching it here. (Only the SSI parts are relevant of course.) All of the golden files look like they're still there. I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. The motivation for my original changes was to fix the nesting of .shtml files (ie: a .shtml file including another .shtml file) and to add support for set, variable substitution, conditionals, etc.. When I looked at the original version and saw it was such a mess, I did pertty much a complete rewrite. Some of my changes are similar to yours, but I got rid of classes like SsiMediator and such. All of this included fixing how variables were kept for includes and such, as well as parsing fixes and the addition of some new commands. It's all pretty significant and may not naturally fit some of your refactoring. To be honest, it might be easier to redo your changes against my stuff than it would be to graft my stuff onto yours. Even though I know that's probably a real pain in the a**. In it's current state, I think the current fixed version has much less functionality than the previous fixed version. Hopefully we can work something out. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? Must have. The fact that you even have an SsiMediator means you were changing an older version. Unfortunately, Bill didn't notice this when he committed your stuff and probably just whole-sale nuked the older files. Don't feel too bad about that, though. My original rewrite did something similar. Only in my case, it was only a small bug fix that was reverted. Still a little disconcerting from my point of view. Probably my own fault for taking a two-month break from the lists. And I had no idea I could have parlayed those patches into committer access. :) -Paul -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
Re: [PATCH] Re: SSI Servlet has big problems
I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Don't know... have you tried an absolute date or is 4 months ago just an example for the list's benefit. Any date in feb/april should be sufficiently late enough. Hope it works, -Paul Dan Sandberg wrote: I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Dan Sandberg wrote: Ugh this is painful. I'll checkout your stuff within the next few days. If the architecture looks good and does have significantly greater functionality I will merge my changes into your code. I also fixed the included variable problem and the nested include problems. The conditional stuff was the only thing I thought I was missing. Hmmm... maybe it isn't as bad as I thought? I don't know. I know there were some parsing problems that kept variable substituation from working correctly. I'm curious: How could I have checked out an older version accidently? Wouldn't I have had to explicitly specify a date or tag or something? Well, if you started working from a tarball of the source, that might have done it. I think that's what happened in my case originally. I can't remember exactly, but the tarball I had might have even had CVS directories in it with sticky tags already set... ie: keeping me from easily getting the latest without checking out the whole source tree from scratch. ... This is all quite depressing ... Indeed. Thanks for being so gracious about all of this. I really felt quite sick when I saw what I missed. That'll teach me to ignore my inbox. :) -Paul -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
I tried an absolute date first. April didn't work. Does this work on your end? have even had CVS directories in it with sticky tags already set... ie: keeping me from easily getting the latest without checking out the whole source tree from scratch. Hmm. That is a possibility. Definitely not a mistake I'll make twice ( assuming I made it at all! ) Indeed. Thanks for being so gracious about all of this. I really felt quite sick when I saw what I missed. That'll teach me to ignore my inbox. :) Pitty that no one mentioned that you had last updated things when I asked about the SSI stuff initially. I would have e-mailed you. -Dan Paul Speed wrote: (resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Don't know... have you tried an absolute date or is 4 months ago just an example for the list's benefit. Any date in feb/april should be sufficiently late enough. Hope it works, -Paul Dan Sandberg wrote: I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
-r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
Hi Bill. Didn't have any luck with that either (see below). Does it work for you? Any idea what the message about the CVS locks means / how to fix it? Yeah, I see what you mean re: files in the attic. I'm curious how things looked before I started changing things, to better understand what caused this code collision... -Dan Here's what I got when I tried to do the -r thing: [dan@oogie tmp]$ echo $CVSROOT :ext:[EMAIL PROTECTED]:/home/cvs [dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0 Protocol error: uncounted data discarded Bill Barker wrote: -r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Re: SSI Servlet has big problems
Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name param-value1/param-value /init-param load-on-startup4/load-on-startup /servlet --- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SSIServlet/servlet-class init-param param-namebuffered/param-name param-value0/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param load-on-startup4/load-on-startup /servlet 209d205 ssi.jar Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
I've just checked in your patch to the CVS HEAD of tomcat-4.0. You are correct that it is a straight refactoring, with no change in functionality. I'm willing to play code monkey (copy; Pier) for the SSI specific stuff. Hopefully Amy is going to be willing to answer questions that I'll likely have, but otherwise it will just take me a little longer. You should continue to send patches to the tomcat-dev list, since I can't always promise when I'll have available time. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Bill Barker [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Remy Maucherat [EMAIL PROTECTED] Sent: Friday, May 10, 2002 7:16 PM Subject: Re: SSI Servlet has big problems Hi Bill. The patch I sent in already is just code refactoring ( not SSI specific ) and a few tiny utility classes ( also not SSI specific ). The next patch will be the SSI stuff, and is a complete rewrite. The old stuff is so broken that even if my stuff has major bugs ( and I've tested it by comparing output to Apache SSI with a very complex test case ) it will still be an improvement. So really, the commiter doesn't need to understand it per-se ( even though that would be easy--the code is quite clean now ) but rather to check that I haven't done anything malicious. Thanks, -Dan Bill Barker wrote: I really don't know the SSI stuff very well at all, so I'd prefer if someone who knows it better. Amy seems to be the only currently active committer who has spent time on it however. If she really can't, then I'll take a crack at learning it. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Bill Barker [EMAIL PROTECTED] Sent: Friday, May 10, 2002 5:59 PM Subject: Re: SSI Servlet has big problems Hi Bill. Can you be my 'point-man' on the CVS submissions, or suggest someone else who might be willing to do the submissions? It seems like asking for 'someone on the list to commit these changes' (as I did) will just result in everyone waiting for someone else to do it. I'd very much like to get the SSI changes into 4.1, as the existing code is extremely broken ( not thread-safe and broken anyway ). The new code will fix bug Bug#6299 and Bug#5758, as well as adding new functionality. It also leaves the code much more readable and modular. I asked Remy the same thing two days ago but got no response. Please let me know either way. Thanks! -Dan Bill Barker wrote: The standard way is to attach the output of cvs diff to an e-mail message with a subject beginning with the string [PATCH]. If you continue to make work for us enough by doing this, eventually someone will propose you as a committer :-). - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 9:39 PM Subject: Re: SSI Servlet has big problems Remy Maucherat wrote: Implementing the SingleThreadedServlet interface will not help thi Are you sure ? (I didn't look at the code at all, so I'm just wondering) Otherwise, it would be a really cheap way to make it work. Thanks for looking into it anyway. Implementing SingleThreadedServlet doesn't mean only one thread will be running the servlet at a time. It means only one thread will be running a given INSTANCE of the servlet. So you could still have two threads running two different instances of the same servlet. This will still get massively messed up with all the sharing of static variables. Are the two authors still mantaining this code? Bip Thelin? Amy Roh? Not really. I didn't hear about Bip for a while, and Amy has been busy with other things. Usually an easy way to get commit access if you have time to dedicate to contributing is to take over the maintenance of some abandoned component(s). CGI also needs a maintainer, BTW. Remy I'll fix this problem, and I'll create a filter that does SSI on any output ( so that a JSP page can use SSI, for example ). I don't have any interest in being a maintainer/having commit access, however. So what's the best way to give back my bug fixes/filter? Thanks for the response, btw. -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
Dan Sandberg wrote: I'll be done with the SSI rewrite tomorrow. I'd like to get the community's advice on a number of issues: 1-I changed the names of the files from Ssi... to SSI... This seems to be more consistent with the naming scheme of other files, and made things easier for me since I did a gradual rewrite of everything. This will make it harder to see what I changed when I submit a diff, however. I changed 75% of everything, so I'm not sure this matters. Is it ok? Thats fine, please put the SSI servlet code into a sub package in servlet also. i.e. org.apache.catalina.servlet.ssi.*. Write now the servlet (one class) is in: org.apache.catalina.servlets While all its supporting classes are in: org.apache.catalina.util.ssi I propose moving all the SSI support classes to: org.apache.catalina.ssi They don't belong in servlet, since they CAN be used without a servlet ( for example, in a filter ) and they prob. don't belong in util, since they can't be used by anything other than the SSIServlet, and the SSIFilter. 2-What's the story with the SSI jar having the .renametojar extension? I'm surmising that this is because this class will be loaded under the system class loader rather than the user servlet class loader, causing the #exec functionality to be a security risk. Can't we just have a directory where we put servlets that should be loaded under the 'safe' class loader? Yes, this is so SSI can not be used without the admin explicitely enabling it by renaming the jar. Whether the Runtime.exec() method can be called is dependent upon the catalina.policy, not on what ClassLoader is used. I have proposed a reorganization of the servlets into sub packages in org.apache.catalina.servlets. In addition moving the jar files for the servlets into a separate directory. /server/servlets for those which require access to privileged internal catalina code, and /shared/servlets for those which do not require access to privileged catalina code. Sounds good. Why is this not a problem with JSP pages then? How is doing an exec in SSI different than doing a Runtime.exec in JSP? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
I'll be done with the SSI rewrite tomorrow. I'd like to get the community's advice on a number of issues: 1-I changed the names of the files from Ssi... to SSI... This seems to be more consistent with the naming scheme of other files, and made things easier for me since I did a gradual rewrite of everything. This will make it harder to see what I changed when I submit a diff, however. I changed 75% of everything, so I'm not sure this matters. Is it ok? 2-What's the story with the SSI jar having the .renametojar extension? I'm surmising that this is because this class will be loaded under the system class loader rather than the user servlet class loader, causing the #exec functionality to be a security risk. Can't we just have a directory where we put servlets that should be loaded under the 'safe' class loader? 3-Right now the SSIServlet has an initialization parameter to determine whether unsupported commands ( #foobar ) should be ignored. It seems like the issue should be more complicated than this. There is a difference between #foobar and #if. #foobar is not supported by anyone, and should be handled the same way apache would do it ( echo an error ). #if however, IS handled by apache, and is not handled by the SSIServlet. Therefore it seems that the initialization parameter mentioned should only apply to the latter case. Personally I think this initialization parameter should be axed completely, as I don't see where its use solves more problems that it creates. For example, if a person did have code that used #if, #else, etc., then by ignoring these directives we'd end up making the output be even weirder ( and with no explanation of why! ) than if we just stuck [an error occurred while processing this directive] all over the place. 4-Right now we are not logging invalid atribute names ( --#echo nonExistantAttribute=foobar -- ), or logging invalid commands, or logging invalid settings for attributes ( --#echo encoding=noSuchEncoding var=DOCUMENT_NAME -- ). Apache logs this stuff, it seems like we should too. Where do I log it to ( what classes/methods do I use )? Should there be a way to turn this logging off? 5-The command #echo var='SOMETHING' is not too useful right now, because what SOMETHING can be is highly constrained. I'd like to make so that this command searches the request attributes ( for a variable named SOMETHING ). This will make this servlet more useful when writing filters that use it. More importantly, it lets existing users who are using SSI already have more power without needing to rewrite their .shtml files in .jsp. [The company that I consult for said they would find this useful, so I'm not making this up] I'd like to also implement the #set command, so that it sets a variable in the request. Anyone have objections to this? 6-This servlet has the option of being buffered or unbuffered. Can someone explain to me why this is useful? The SSIServlet should never throw an error, so I don't see why this would matter. Thanks, Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
SSI Servlet has big problems
Hi everyone. I ran into bug #6299 today (two server-side includes fail with buffering on), did some debugging, and found the cause of it. I have no doubt that a bunch of other bugs in bugzilla are caused by the same issue. Basically, the class and its helper classes have a pretty serious design flaw: they declare lots of information static ( like the servlet output stream ) that should not be shared between threads and/or instances of the servlet. Specifically, SsiInvokerServlet.java declares SsiMediator as static. SsiMediator in turn declares LOTS of things static, like the request, response, output stream, etc. This is probably causing garbled output, socket closed errors, etc. when multiple users are viewing .shtml files at the same time and/or when users are viewing output with buffered=true. Implementing the SingleThreadedServlet interface will not help this problem. Are the two authors still mantaining this code? Bip Thelin? Amy Roh? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
Hi everyone. I ran into bug #6299 today (two server-side includes fail with buffering on), did some debugging, and found the cause of it. I have no doubt that a bunch of other bugs in bugzilla are caused by the same issue. Basically, the class and its helper classes have a pretty serious design flaw: they declare lots of information static ( like the servlet output stream ) that should not be shared between threads and/or instances of the servlet. Specifically, SsiInvokerServlet.java declares SsiMediator as static. SsiMediator in turn declares LOTS of things static, like the request, response, output stream, etc. This is probably causing garbled output, socket closed errors, etc. when multiple users are viewing .shtml files at the same time and/or when users are viewing output with buffered=true. Implementing the SingleThreadedServlet interface will not help this problem. Are you sure ? (I didn't look at the code at all, so I'm just wondering) Otherwise, it would be a really cheap way to make it work. Thanks for looking into it anyway. Are the two authors still mantaining this code? Bip Thelin? Amy Roh? Not really. I didn't hear about Bip for a while, and Amy has been busy with other things. Usually an easy way to get commit access if you have time to dedicate to contributing is to take over the maintenance of some abandoned component(s). CGI also needs a maintainer, BTW. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
Remy Maucherat wrote: Implementing the SingleThreadedServlet interface will not help thi Are you sure ? (I didn't look at the code at all, so I'm just wondering) Otherwise, it would be a really cheap way to make it work. Thanks for looking into it anyway. Implementing SingleThreadedServlet doesn't mean only one thread will be running the servlet at a time. It means only one thread will be running a given INSTANCE of the servlet. So you could still have two threads running two different instances of the same servlet. This will still get massively messed up with all the sharing of static variables. Are the two authors still mantaining this code? Bip Thelin? Amy Roh? Not really. I didn't hear about Bip for a while, and Amy has been busy with other things. Usually an easy way to get commit access if you have time to dedicate to contributing is to take over the maintenance of some abandoned component(s). CGI also needs a maintainer, BTW. Remy I'll fix this problem, and I'll create a filter that does SSI on any output ( so that a JSP page can use SSI, for example ). I don't have any interest in being a maintainer/having commit access, however. So what's the best way to give back my bug fixes/filter? Thanks for the response, btw. -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSI Servlet has big problems
The standard way is to attach the output of cvs diff to an e-mail message with a subject beginning with the string [PATCH]. If you continue to make work for us enough by doing this, eventually someone will propose you as a committer :-). - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 9:39 PM Subject: Re: SSI Servlet has big problems Remy Maucherat wrote: Implementing the SingleThreadedServlet interface will not help thi Are you sure ? (I didn't look at the code at all, so I'm just wondering) Otherwise, it would be a really cheap way to make it work. Thanks for looking into it anyway. Implementing SingleThreadedServlet doesn't mean only one thread will be running the servlet at a time. It means only one thread will be running a given INSTANCE of the servlet. So you could still have two threads running two different instances of the same servlet. This will still get massively messed up with all the sharing of static variables. Are the two authors still mantaining this code? Bip Thelin? Amy Roh? Not really. I didn't hear about Bip for a while, and Amy has been busy with other things. Usually an easy way to get commit access if you have time to dedicate to contributing is to take over the maintenance of some abandoned component(s). CGI also needs a maintainer, BTW. Remy I'll fix this problem, and I'll create a filter that does SSI on any output ( so that a JSP page can use SSI, for example ). I don't have any interest in being a maintainer/having commit access, however. So what's the best way to give back my bug fixes/filter? Thanks for the response, btw. -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
