You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Dan Sandberg <x...@cs.stanford.edu> on 2002/05/18 00:31:02 UTC
[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-name>ssi</servlet-name>
< <servlet-class>
< org.apache.catalina.servlets.SsiInvokerServlet
< </servlet-class>
< <init-param>
< <param-name>buffered</param-name>
< <param-value>1</param-value>
< </init-param>
< <init-param>
< <param-name>debug</param-name>
< <param-value>0</param-value>
< </init-param>
< <init-param>
< <param-name>expires</param-name>
< <param-value>666</param-value>
< </init-param>
< <init-param>
< <param-name>isVirtualWebappRelative</param-name>
< <param-value>0</param-value>
< </init-param>
< <init-param>
< <param-name>ignoreUnsupportedDirective</param-name>
< <param-value>1</param-value>
< </init-param>
< <load-on-startup>4</load-on-startup>
< </servlet>
---
> <servlet>
> <servlet-name>ssi</servlet-name>
>
<servlet-class>org.apache.catalina.servlets.SSIServlet</servlet-class>
> <init-param>
> <param-name>buffered</param-name>
> <param-value>0</param-value>
> </init-param>
> <init-param>
> <param-name>debug</param-name>
> <param-value>0</param-value>
> </init-param>
> <init-param>
> <param-name>expires</param-name>
> <param-value>666</param-value>
> </init-param>
> <init-param>
> <param-name>isVirtualWebappRelative</param-name>
> <param-value>0</param-value>
> </init-param>
> <load-on-startup>4</load-on-startup>
> </servlet>
209d205
<
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Paul Speed <ps...@progeeks.com>.
(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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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
>>>>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
>>>>
>>>>
>>>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Paul Speed <pa...@objectsciences.com>.
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
> >>===================================================================
> >>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-name>ssi</servlet-name>
> >>< <servlet-class>
> >>< org.apache.catalina.servlets.SsiInvokerServlet
> >>< </servlet-class>
> >>< <init-param>
> >>< <param-name>buffered</param-name>
> >>< <param-value>1</param-value>
> >>< </init-param>
> >>< <init-param>
> >>< <param-name>debug</param-name>
> >>< <param-value>0</param-value>
> >>< </init-param>
> >>< <init-param>
> >>< <param-name>expires</param-name>
> >>< <param-value>666</param-value>
> >>< </init-param>
> >>< <init-param>
> >>< <param-name>isVirtualWebappRelative</param-name>
> >>< <param-value>0</param-value>
> >>< </init-param>
> >>< <init-param>
> >>< <param-name>ignoreUnsupportedDirective</param-name>
> >>< <param-value>1</param-value>
> >>< </init-param>
> >>< <load-on-startup>4</load-on-startup>
> >>< </servlet>
> >>---
> >> > <servlet>
> >> > <servlet-name>ssi</servlet-name>
> >> >
> >><servlet-class>org.apache.catalina.servlets.SSIServlet</servlet-class>
> >> > <init-param>
> >> > <param-name>buffered</param-name>
> >> > <param-value>0</param-value>
> >> > </init-param>
> >> > <init-param>
> >> > <param-name>debug</param-name>
> >> > <param-value>0</param-value>
> >> > </init-param>
> >> > <init-param>
> >> > <param-name>expires</param-name>
> >> > <param-value>666</param-value>
> >> > </init-param>
> >> > <init-param>
> >> > <param-name>isVirtualWebappRelative</param-name>
> >> > <param-value>0</param-value>
> >> > </init-param>
> >> > <load-on-startup>4</load-on-startup>
> >> > </servlet>
> >>209d205
> >><
> >>
> >> ------------------------------------------------------------------------
> >> Name: ssi.jar
> >> ssi.jar Type: Java Archive (application/java-archive)
> >> Encoding: base64
> >> Download Status: Not downloaded with message
> >>
> >> ------------------------------------------------------------------------
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Paul Speed <ps...@progeeks.com>.
(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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Bill Barker <wb...@wilshire.com>.
You're right. It should have been "-r TOMCAT_4_1_2" (which checks out fine
for me).
----- Original Message -----
From: "Dan Sandberg" <x...@cs.stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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:dsandberg@cvs.apache.org:/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" <x...@cs.stanford.edu>
> >To: "Tomcat Developers List" <to...@jakarta.apache.org>
> >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:
> >>
> >>
> ><ma...@jakarta.apache.org>
> >
> >
> >>For additional commands, e-mail:
> >>
> >>
> ><ma...@jakarta.apache.org>
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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:dsandberg@cvs.apache.org:/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" <x...@cs.stanford.edu>
>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>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:
>>
>>
><ma...@jakarta.apache.org>
>
>
>>For additional commands, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Bill Barker <wb...@wilshire.com>.
"-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" <x...@cs.stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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-name>ssi</servlet-name>
>>< <servlet-class>
>>< org.apache.catalina.servlets.SsiInvokerServlet
>>< </servlet-class>
>>< <init-param>
>>< <param-name>buffered</param-name>
>>< <param-value>1</param-value>
>>< </init-param>
>>< <init-param>
>>< <param-name>debug</param-name>
>>< <param-value>0</param-value>
>>< </init-param>
>>< <init-param>
>>< <param-name>expires</param-name>
>>< <param-value>666</param-value>
>>< </init-param>
>>< <init-param>
>>< <param-name>isVirtualWebappRelative</param-name>
>>< <param-value>0</param-value>
>>< </init-param>
>>< <init-param>
>>< <param-name>ignoreUnsupportedDirective</param-name>
>>< <param-value>1</param-value>
>>< </init-param>
>>< <load-on-startup>4</load-on-startup>
>>< </servlet>
>>---
>> > <servlet>
>> > <servlet-name>ssi</servlet-name>
>> >
>><servlet-class>org.apache.catalina.servlets.SSIServlet</servlet-class>
>> > <init-param>
>> > <param-name>buffered</param-name>
>> > <param-value>0</param-value>
>> > </init-param>
>> > <init-param>
>> > <param-name>debug</param-name>
>> > <param-value>0</param-value>
>> > </init-param>
>> > <init-param>
>> > <param-name>expires</param-name>
>> > <param-value>666</param-value>
>> > </init-param>
>> > <init-param>
>> > <param-name>isVirtualWebappRelative</param-name>
>> > <param-value>0</param-value>
>> > </init-param>
>> > <load-on-startup>4</load-on-startup>
>> > </servlet>
>>209d205
>><
>>
>> ------------------------------------------------------------------------
>> Name: ssi.jar
>> ssi.jar Type: Java Archive (application/java-archive)
>> Encoding: base64
>> Download Status: Not downloaded with message
>>
>> ------------------------------------------------------------------------
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Re: SSI Servlet has big problems
Posted by Paul Speed <ps...@progeeks.com>.
(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-name>ssi</servlet-name>
> < <servlet-class>
> < org.apache.catalina.servlets.SsiInvokerServlet
> < </servlet-class>
> < <init-param>
> < <param-name>buffered</param-name>
> < <param-value>1</param-value>
> < </init-param>
> < <init-param>
> < <param-name>debug</param-name>
> < <param-value>0</param-value>
> < </init-param>
> < <init-param>
> < <param-name>expires</param-name>
> < <param-value>666</param-value>
> < </init-param>
> < <init-param>
> < <param-name>isVirtualWebappRelative</param-name>
> < <param-value>0</param-value>
> < </init-param>
> < <init-param>
> < <param-name>ignoreUnsupportedDirective</param-name>
> < <param-value>1</param-value>
> < </init-param>
> < <load-on-startup>4</load-on-startup>
> < </servlet>
> ---
> > <servlet>
> > <servlet-name>ssi</servlet-name>
> >
> <servlet-class>org.apache.catalina.servlets.SSIServlet</servlet-class>
> > <init-param>
> > <param-name>buffered</param-name>
> > <param-value>0</param-value>
> > </init-param>
> > <init-param>
> > <param-name>debug</param-name>
> > <param-value>0</param-value>
> > </init-param>
> > <init-param>
> > <param-name>expires</param-name>
> > <param-value>666</param-value>
> > </init-param>
> > <init-param>
> > <param-name>isVirtualWebappRelative</param-name>
> > <param-value>0</param-value>
> > </init-param>
> > <load-on-startup>4</load-on-startup>
> > </servlet>
> 209d205
> <
>
> ------------------------------------------------------------------------
> Name: ssi.jar
> ssi.jar Type: Java Archive (application/java-archive)
> Encoding: base64
> Download Status: Not downloaded with message
>
> ------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>