On 2024/06/07 12:54:44 Christopher Schultz wrote: > Michael, > > On 6/7/24 08:01, Michael Osipov wrote: > > On 2024/06/07 08:05:34 Mark Thomas wrote: > >> On 06/06/2024 16:30, Christopher Schultz wrote: > >>> All, > >>> > >>> Resurrecting this thread from 2019. > >>> > >>> I'd like to remove the SSI configuration from conf/web.xml and put it > >>> into webapps/docs/ssi-howto.html. > >>> > >>> Are there any objections? > >> > >> None here. > >> > >> Do we want to go further and consider removing it entirely for Tomcat 12 > >> onwards. Maybe a question for the users list? > > > > I need to admit that there are situations where SSI might be prefered over > > JSP. > > Example: I needed limited flexibility for some Asciidoctor generated > > documents dependening whether it is QA or prod. I didn't want to generate > > multiple sets of documents (reduce complexity). Now some lines of SSI > > display a proper QA banner. Good enough for the job. Getting JSP or PHP > > output with Asciidoctor is almost impossible. > > It's entirely possible to separate SSI into a different project. I > didn't do it because it uses helper-classes in Tomcat for certain things. > > But if SSI is desirable, it can be packaged separately at the cost of > some additional support classes/methods being copied outside of Tomcat. > > I don't want to support it anymore, but it should be easy *for someone > else* to extract and bundle separately :)
What is the pain having it off by default, but have the necessary classes still provided in the JARs? They do not require any maintenance. They just work, don't they? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
