Re: [VOTE] minimal JSR 154 only distribution
Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [ ] 0 [ ] -1 [x] [I will quickly change to a +1 if the minimal change I suggest is made. Others prob. will as well] Explanation: Beginners want ease of use over minimality because they want to get started. They can't choose between a dist. with Jasper + Manager vs. one without Jasper and Manager because they don't know what Jasper is ( though they prob. do know what JSP is ) and they don't know what the manager does. Advanced users want security, because they are admins and want to deploy rather than just play. Advanced users are more willing and able to go through extra steps in order to secure software. They are more likely to have the security paranoia (rightly) often conveyed in this thread. My *ideal* is that a script comes with the full distribution that moves all Jasper JARS, SSI stuff, Management, etc. to a temporary directory under the tomcat root. It can also replace ( if no mods have been made ) the web.xml file appropriately. Assuming everyone thinks this idea sucks for some reason or another, then I would go +1 as long as it is agreed that the minimal distribution is CLEARLY marked something along the lines that it is for experts only, and does not support JSP pages. (yes, I know it runs compiled jsp pages). Cause newbies often think to themselves minimal sounds good, cause it's less crap I'll have to understand, not realizing that they actually want/need the crap. -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
SSI Security Hack
What's the story with the servlets-ssi.renametojar hack? Are the classloader issues that necessitated this going to be fixed in Tomcat 5? Will they be backported to Tomcat 4? If this won't be fixed in Tomcat 5, than we can split servlets-ssi into the insecure part ( which can run exec ) and the secure part ( everything else ). This would make using SSI much easier, as renaming jars and changing web.xml, etc, won't be necessary unless the user wants to support the #exec command. [Just trying to keep an eye on end-user simplicity] -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problems with SSI extensions
I've been a bad boy by not taking care of this. This is just the kind
of encouragement I need to movitate my guilty butt. I'll work on it
tonight and with any luck commit it tomorrow.
Which branch do I commit this to? And if the answer is the 4.x branch,
who/how does it get forward-ported?
-Dan
Paul Speed wrote:
These worked at one time. Then that entire version of SSI was
clobbered and replaced with a version that only supported a subset
of the commands. None of my clobbered rewrite has been ported
forward again and I haven't had the time (or motivation) to rewrite
my rewrite again and try to get a patch committed.
I only mention this so that if someone wants to scratch this particular
itch they know that there's code in the CVS attic that does this.
They'd just have to port it somehow. Might save someone some time.
-Paul
Richard Hallier wrote:
Hello,
Tomcat 4.1.12 with SSI enabled
Basic functions work well, but i'm in trouble with :
1/ !--#if is not supported (i've got an unknown command), maybe it's
normal
2/ This command in my .shtm : !--#include virtual=${QUERY_STRING} --
generates the following error:
2002-11-19 21:11:20 ssi: #include--Couldn't include file: ${QUERY_STRING}
java.io.IOException: Couldn't find file: /${QUERY_STRING}
Thank you for your help.
--
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: ServletOutputStreamWrapper
Paul, it would be a lot easier to help if I knew what you were trying to
do specifically.
If you want to find a class that extends another, why not just search
the source-code textually?
On my unix system, I just do:
findj extends ServletOutputStream
where findj is an alias:
alias findj='find . -name *.java -not -path */autogenerated/* |
xargs grep'
which returns:
./util/ssi/ServletOutputStreamWrapper.java:extends ServletOutputStream {
./connector/ResponseStream.java:extends ServletOutputStream {
-Dan
Paul Hunnisett wrote:
Actually, a good example of a ServletInputStream subclass with a read()
implementation would be helpful too. I am trying to find al lthese
examples in the source, but am haviong limited success tracking down the
appropriate classes
On Tue, 2002-11-12 at 10:13, Paul Hunnisett wrote:
The main reason I was looking at this class in the first place was to
try to find a good way of overriding the write(int) method of
OutputStream in a server context. Is there another class which extends
ServletOutputStream and would give me a more real world example?
On Tue, 2002-11-12 at 00:03, Dan Sandberg wrote:
Hi Paul.
That class is specific to the server-side include code, so the server
doesn't need to know anything about the writeTo method.
Basically, the ServletOutputStreamWrapper is used so that we can capture
the result of Tomcat processing a page, so that we may include the
contents of one page within another.
o.a.c.servlets.SsiInvokerServlet calls the writeTo method. If you have
any questions after looking at the source-code, let us know.
Is anyone familiar with this class?
Yup.
-Dan
Paul Hunnisett wrote:
I have been examining the source code for
org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
a writeTo() method that writes the current buffer to the OutputStream.
What I can't quite see is how this method would be called. It is not
part of the servlet spec, so the web application won't be calling it.
So I assume that the server calls it, but how does the server know when
to write the buffer out?
Any information would be appreciated.
Paul Hunnisett
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: ServletOutputStreamWrapper
Hi Paul. That class is specific to the server-side include code, so the server doesn't need to know anything about the writeTo method. Basically, the ServletOutputStreamWrapper is used so that we can capture the result of Tomcat processing a page, so that we may include the contents of one page within another. o.a.c.servlets.SsiInvokerServlet calls the writeTo method. If you have any questions after looking at the source-code, let us know. Is anyone familiar with this class? Yup. -Dan Paul Hunnisett wrote: I have been examining the source code for org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered a writeTo() method that writes the current buffer to the OutputStream. What I can't quite see is how this method would be called. It is not part of the servlet spec, so the web application won't be calling it. So I assume that the server calls it, but how does the server know when to write the buffer out? Any information would be appreciated. Paul Hunnisett -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: CVS problem
I mucked with the CVS repository ( had no choice ) and fixed my CVS problems. I moved the SSIServlet.java,v file ( which had no java source ) into /tmp. This fixed the problems I had with core dumping when trying to check out old versions of jakarta-tomcat-4.0. Now I'll work on combining the two SSI implementations together. -Dan Dan Sandberg wrote: How? I'm not running any CVS commands. You need admin access to delete the #cvs.wfl or #cvs.lock files, which I don't have. If there's a way for me to fix this, please let me know. -Dan Remy Maucherat wrote: Trying to tag the CVS with 4.1.7 ... cvs server: [03:59:27] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets cvs server: [04:00:00] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets Dan, can you fix it ASAP ? Remy -- 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: CVS problem
How? I'm not running any CVS commands. You need admin access to delete the #cvs.wfl or #cvs.lock files, which I don't have. If there's a way for me to fix this, please let me know. -Dan Remy Maucherat wrote: Trying to tag the CVS with 4.1.7 ... cvs server: [03:59:27] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets cvs server: [04:00:00] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets Dan, can you fix it ASAP ? Remy -- 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
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
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
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
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]
Insufficient Karma
I tried to commit some changes relating to the SSI regression tests, and got the message below. Can someone fix this or tell me what I have to do to fix this? Thanks, -Dan In directory .: Message: cvs [server aborted]: correct above errors first! Message: Parser Error: ' Access denied: Insufficient Karma (dsandberg|jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi)' Message: Parser Error: 'cvs server: Pre-commit check failed' Message: Parser Error: ' Access denied: Insufficient Karma (dsandberg|jakarta-tomcat-4.0/tester/web/golden)' Message: Parser Error: 'cvs server: Pre-commit check failed' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Insufficient Karma
Good call. I had been using /cvs/cvspublic Thanks, Dan Pier Fumagalli wrote: Dan Sandberg [EMAIL PROTECTED] wrote: I tried to commit some changes relating to the SSI regression tests, and got the message below. Can someone fix this or tell me what I have to do to fix this? Thanks, -Dan In directory .: Message: cvs [server aborted]: correct above errors first! Message: Parser Error: ' Access denied: Insufficient Karma (dsandberg|jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi)' Message: Parser Error: 'cvs server: Pre-commit check failed' Message: Parser Error: ' Access denied: Insufficient Karma (dsandberg|jakarta-tomcat-4.0/tester/web/golden)' Message: Parser Error: 'cvs server: Pre-commit check failed' Weird... You do have karma for that CVS repo... Make sure you're using /home/cvs as your CVSROOT, and going through SSH... Pier -- 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: http 302 issue on tomcat 4.0.1
The spec says that for each welcome file you must check 'whether a resource in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches. ' This is somewhat ambiguous--do they mean resource like getResource(...) or do you mean a mapping in the deployment descriptor. Given the example you mentioned, it seems they probably mean resource like getResource(...). If this is true, then bug 9016 is actually by design... [PROPOSAL] We could do the following, which might be a good compromise between the two possible interpretations: If there is one welcome-file, then always redirect to it. If there is no corresponding resource, then this could give us a 404 ( if it is a JSP ) or work properly ( if it is a *.do ). Happily this does not violate the spec, because the spec says that if no resource if found, the container can do whatever it wants anyway. If there is more than one welcome-file, then we do need to check for corresponding resources. If none are found, we probably give a 404, right? This is a little ugly since one wouldn't expect the behavior to change when adding a welcome-file, but it might be the best solution. Thoughts? I'm slightly leaning towards saying the behavior in bug 9016 is spec-mandated. As for the speed issue, I would be happy to address it with caches or something else ( I love optimizing ) when someone gave me very conclusive proof that the mapping overhead is significant. -Dan Remy Maucherat wrote: if matchingWelcomeFile.contains(/): # psycopathic case no one cares about ( ie. welcome file is a/b.jsp ) redirect, old style //we show the filename here, but if we didn't we'd break relative paths else: if path.endsWith(/): # happy, smiley family case redispatch, using welcome-file full path (ie. /foo/index.jsp ) for security checking This redirect may cause problems, because it will happen regardless of whether or not the path exist (or it makes sense to redirect). Example: You have index.jsp and index.html in the welcome files. No matter what you do, the request will always be redirected to Jasper, which will always return a 404. Checking for the presence of the physical file won't work either (you could have a *.do mapping like Struts uses). Any idea to avoid that problem ? Also, the changes are going to make the mapping slower. I plan to refactor that operation (use an automaton and bytes instead of String manipulations) in the next major version of Tomcat, which should help tremendously, but until then ... else: if adding slash causes a servlet mapping match: # we handle the stupid case of having two servlet mappings # ( /foo and /foo/ ) in web.xml. redirect, old style //we show the filename here, but if we didn't we'd call the wrong servlet else: redirect, adding / ( ie. redirect /foo to /foo/ ) Remy -- 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: http 302 issue on tomcat 4.0.1
Ok, but this changes the bahavior of Tomcat, so this has the potential to break things. Also, the new spec clarifies it a bit, and requires to be able to do welcome files on non-existing paths, but which map to something (so getResource is not a good test). Since everything maps to the default servlet, I don't see how to implement this. It seems like there are only a few things we can do about this: 1. Call the servlet, buffer its output, and see if it is an error. If it is an error, try the next file in the welcome list. If not, use it. This relies on servlets honoring this convention. It also slows down throughput. 2. API change or some kind of convention for the servlet to tell the container that the servlet can handle the path given. This seems icky. 3. Decide bug 9016 behavior is by design, and wait for the spec to clarify how to implement the behavior wanted in bug 9016. I'd say no, because it could be a directory listing. Ok. As for the speed issue, I would be happy to address it with caches or something else ( I love optimizing ) when someone gave me very conclusive proof that the mapping overhead is significant. I did some OptimizeIt profiles, and the mapping is quite bad. Going with a byte-based mapping would help. Ok, when everything is all coded, I'll think about addressing this. -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: http 302 issue on tomcat 4.0.1
Fixing this requires mucking with the core of Tomcat, which I find scary.
Do we have any regression tests I can use to see if my changes have
broken anything? Or should I just commit the changes when they are
ready, and hope someone will notice any bugs before we release?
I'm asking because I would hate to be the cause of a totally messed up
release...
Thanks,
Dan
Dan Sandberg wrote:
Hi Remy.
I filed a bug report about this a week ago at:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9559 ( which was
marked invalid )
Apparently this is a long-standing issue, as I found the following bug
( marked invalid ):
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=456
I hope to submit a patch for it within a week. I may also fix the
following welcome-related bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9016
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752
-Dan
remy.menetrieux wrote:
Hello,
When browsers request my url containing a filename, Tomcat does not
internally redirect this request, it sends a HTTP 302 redirect.
How can we configure and patch Tomcat to disable this feature ?
Thx for any help.
Here is what we get :
GET / HTTP/1.0
host: www.SiteName.com
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Date: Tue, 28 May 2002 10:34:13 GMT
Location: http://www.SiteName.com/index.htm
Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
Connection: close
htmlheadtitleApache Tomcat/4.0.1 - Error
report/titleSTYLE!--H1{font-family :
sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;}
B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.1 - HTTP Status 302 - Moved
Temporarily/h1HR size=1 noshadepbtype/b Status
report/ppbmessage/b uMoved
Temporarily/u/ppbdescription/b uThe requested resource
(Moved Temporarily) has moved temporarily to a new location./u/pHR
size=1 noshade/body/html
--
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: http 302 issue on tomcat 4.0.1
Yes, this is true. Also, a request to /foo which becomes /foo/index.jsp
would also screw up relative links.
I believe the following behavior would do what people want 99% of the
time while still not screwing up the scenario you mentioned or the one I
mentioned above (forgive the pythonic pseudocode):
if matchingWelcomeFile.equals(a/b.jsp): //if the welcome file has a
slash in it
redirect( pathRequest + [forwardSlash if needed] + a/ )
else:
if pathRequested.endWith('/'):
redispatch // see below for meaning
else:
pathRequest += '/'
redirect( pathRequest )
This only does redirects when necessary to preserve relative link
meanings, and does not make so the redirected URL contains the
welcome-file filename in any circumstance. This is what people prob.
want, since if people bookmark /shoppingCart, they'll still have the
right URL even if people switch from .jsp to .xtp or whatever
Incidentally, this is the behavior that Resin has--I checked.
I believe that this code shouldn't be in DefaultServlet.java. It should
be in the code that maps the request to a servlet. I think this is
clear from the spec ( SRV.9.10 ): If no matching welcome file is found
in the manner described, the container may handle the request in a
manner it finds suitable. For some configurations this may mean invoking
a default file servlet, or returning a directory listing. For other
configurations it may return a 404 response.
So by redispatch, I mean 'pretend that the changed path is what was
originally requested'. This should be easy to do in the wrapper mapping
ocde.
Since I won't be forwarding ( since I won't be handling this in
DefaultServlet ) your security constraint problems should be allayed.
And I think I can fix the 'mapping welcome files onto servlet' problem
while I'm at it.
Comments?
-Dan
Remy Maucherat wrote:
Fixing this requires mucking with the core of Tomcat, which I find scary.
Do we have any regression tests I can use to see if my changes have
broken anything? Or should I just commit the changes when they are
ready, and hope someone will notice any bugs before we release?
I'm asking because I would hate to be the cause of a totally messed up
release...
A forward is not used in that case because a security constraint may be
applied on the target URI.
Also, welcome pages such as foo/index.html are allowed, and using a
forward would mess up the links from that welcome page (maybe that's normal,
but it's not very clear to me).
Remy
--
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: [VOTE] New Committer Dan Sandberg
I think Pier's conerns are quite reasonable. Let me bring up a few points that I think are central to the debate: A. Security. This is the most important concern in allowing new commiters. If they purposely or accidently introduce security issues, this tarnishes the Tomcat name. Code review is the most important way of preventing this. How much does asking someone else to commit the code for you force them to look over it for bugs of this kind? How much would other people look over CVS submissions that were done directly by a new commiter? The ratio between these numbers is critical. If it is 1, then there is no harm in giving commit access easily. B. Introducing bugs. This is a concern much like A., but because the SSI code had glaring bugs to begin with, I don't think it is much of an issue in my case. If a new contributor has commit access, it makes it easier for her to fix any bugs they introduce, and presumably they would because of the pride-factor. C. Commiter may not stay long. In my case, I explicitly said that I didn't want to be a commiter originally. I didn't want to spend lots of time on this project. As things turned out, my 3 hour change turned into a 3 day change, and it has become obvious to me that a few more commits will probably be necessary. I asked for commit access because 1) I want to take the load of others and 2) The latency of waiting for others to review/commit the code is fairly high. Nevertheless, I'll say this explicitly: I don't want to become a 'major' contributor to Tomcat. Act accoringly. D.Scope. Must a commiter have scope to the entire project? Can't the access file be changed only in the o.a.c.ssi directory and the servlet directory? Would this address any concerns? Thanks, Dan Pier Fumagalli wrote: jean-frederic clere [EMAIL PROTECTED] wrote: Remy Maucherat wrote: In the middle it's good, extremes (I believe) not... And since this is the second time in less than a week (Denis posted 14 times, the first time on 4/27 if I'm not wrong and Dan 7 times, the first time on 5/1), and it's starting to be a little bit extreme and it doesn't make me feel very comfortable... You have to consider the importance and quality of the patch. In Denis' case, that's why I nominated him. I have yet to see trouble caused by a guy who was granted commit access, and the idea is to encourage people to contribute more. Probably the status of Developer as described in the http://jakarta.apache.org/site/roles.html is not used correctly. For me, if someone that brings one good patch reaches the developer rank, not yet the committer rank (Or are the committers too lazy to commit contributions from the developers?). From the same document you mentioned... Committers: Developers who give frequent and valuable contributions to a subproject of the Project can have their status promoted to that of a Committer for that subproject. Ok, we all agree that Denis gave a valuable contribution, but as far as I can see, can we say that this is frequent? I honestly can't... And again, I have _nothing_ against Dan or Dennis, actually, I would like to thank them for their patches... Pier -- 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: CVS problem with SSIServlet file
Perhaps Bill had the same problem when he tried to submit my code. The code I posted on this list had the file named SSIServlet.java ( not SsiServlet.java ) and the web.xml file called it SSIServlet.java. Bill changed those both to SsiServlet, perhaps because of the problems you are having. Maybe SSIServlet.java is already is in the repository attic and is causing a conflict? Maybe there's some case-insensitivity thing going on ( I know CVS is case-sensitive )? Can someone muck around in the repository and see what's going on? -Dan Remy Maucherat wrote: Remy, I just fixed the SSiCommand.java case and have updated several times from CVS without any problems. Tomcat 4 CVS HEAD now builds fine for me. One of my updates did get delayed for 10-15 seconds while you had a lock on one of the SSI files. I no longer see an SSIServlet.java or SSiServlet.java in my local copy of the TOmcat 4 cvs repository. I removed the file, but wasn't able to add it back, because of the error I got from the server :-( Remy -- 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: [VOTE] New Committer Dan Sandberg
Granting that I'm not as experienced with open-source collaboration as the rest of you are, my intuition is that the easier it is for people to make changes to the code-base ( assuming their contributions are reviewed ) the faster the code-base will improve and bugs will be eliminated. Again, this is contigent on the belief that contributions will be reviewed by somebody for security, bugs, and code quality. As for the question that Pier asked: How much responsibility am I willing to take on? I am willing to address bugs, and review contributions to the SSI code. I would usually not vote on committers unless I know that they should be + or -, which will be rare. Similarly, I would vote on release plans, the future of the project, etc., if and only if I feel I had something to add in those areas, which will probably be rare. If you want to know the real price of becoming a commiter - it's loosing all control over the code you write, having to play flame wars and grow a thick skin. And you may spend many weekends doing work that is just thrown away. I'm thick-headed and thick-skinned, so this is not a problem. I'll skip on the flame wars though. :) Are you interested? I don't want to sound bad, but hey everything comes at a price :) :) :) I don't view committer status as a trophy. I just want to fix things that are broken. Having commit access makes this easier for me and for everyone else. If you want my advice - create a sourceforge account, do all the work on SSI there, and have fun. ( and maybe give access to other tomcat commiters who are interested to work on SSI ). Not sure how this helps. If I understand the suggestion correctly, this is equivalent to forking the SSI code, which definitely won't help the development process. I just read Pier's proposal, and I agree with him. Sorry to have instigated all this, but I suppose it's something that would have had to be dealt with sooner or later... -Dan Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 24 May 2002, Pier Fumagalli wrote: Just one question on this. Being a committer implies that you're going to have the right (and the due, of course, like in any good democracy) to (for example) elect PMC members, have -also- a some sort of responsibility over what you do, and what others do, meaning code reviews, deciding on the future of the whole tomcat project, voting on future release plans and such... As I said, this is not only a right, but also a responsibility. As a committer you _should_ be doing that. Now, my question is, do you want _at_this_point_ to have that responsibility? Are you interested? I don't want to sound bad, but hey everything comes at a price :) :) :) Most tomcat commiters review only a small ammount of the commits, that is relevant to what they know. Voting ( or beeing voted ) in PMC is optional. If you want to know the real price of becoming a commiter - it's loosing all control over the code you write, having to play flame wars and grow a thick skin. And you may spend many weekends doing work that is just thrown away. Pier is right in this aspect - and I fully agree with him that beeing a jakarta commiter comes at a much bigger price than you may think. If you want my advice - create a sourceforge account, do all the work on SSI there, and have fun. ( and maybe give access to other tomcat commiters who are interested to work on SSI ). Very constructive, Costin, indeed... See my next email (at least I'm trying to propose something)... Pier -- 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: Prove me wrong - take this quiz
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering,
it occurs in the OutputStream provided by the container, and is
therefore available to the container.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
It's funny, I was just looking at this yesterday because I was having a
problem similar to what you are describing.
from java.io.PrintWriter ( JDK1.40 ):
public PrintWriter(OutputStream out, boolean autoFlush) {
this(new BufferedWriter(new OutputStreamWriter(out)), autoFlush);
}
So yes, it is buffered :(.
-Dan
--
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
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]
