Bip Thelin wrote:
>
> > -----Original Message-----
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> >
> > For the curious reader, after looking into this code at some length
> > it seems clear why the set command was not added. All SSI requests
> > share the same environment, which not only makes a set command
> > impossible but also means that multiple SSI requests (or even nested
> > SSI requests) trample all over each other. A simple shtml file that
> > includes two other shtml files illustrates this quite nicely.
>
> Do you have a smal testcase? We have unittests with Tomcat that have
> nested includes and several includes in one page. All Ssi directives
> share the same enviroment per page through a mediator, this is due to
> the fact that you can have a config directive that changes the error
> message that you would get for a failed include further down on the same
> page, for instance.
Actually, SsiInvokerServlet has a static reference to SsiMediator.
Furthermore, all of SsiMediators fields are static.
A simple test case that I use is a .shtml page that includes the same
.shtml page twice. Only the first one will actually be included
because of the way the Request object in SsiMediator is overwritten.
>
> However if pageA includes pageB, if pageB is also an shtml/ssi file it
> would have a new fresh enviroment and could not tamper with pageA's
> enviroment.
>
> So you could easily do a set command simmilar to the config command.
Actually, includes should share the environment of the parent...
in fact, if they set server variables the parent will see them.
>
> > Since I'm between assignments at the moment, I'm working on a patch
> > here locally. It's pretty significant, though, so it may take me a
> > few days. It will include the set command though since that's what
> > I'm going to use to test it. :)
>
> Patches and additions are gladly appreciated.
Cool. I'm almost done refactoring. I'm basically replacing the
SsiMediator with an SsiEnvironment that is then stuck into a
request attribute. In the process, I'm moving some things around
a little since all of the commands were relying on the fact that
they were SsiMediator subclasses... and therefore directly accessing
the static fields of SsiMediator.
Hopefully I'll have something done in the morning. Even more
hopeful, it will be worth committing. ;) We'll see...
-Paul Speed
