On Wed, Nov 29, 2017 at 4:14 PM, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
> 22. I am -1 to all those STRICT_SERVLET_COMPLIANCE conditionals. > Ok, I'm replying in the context of the dispatcher http mapping override. In that case, it's really a case where it is used elsewhere: the community disagrees with the behavior but it is explicit in the specification. The default-context-path element needs a lot more work, so I won't do anything at the moment. Good point on the fragment xsd. Rémy > > My reading of section "30. default-context-path Element" on page 202 > of 246 of servlet-4_0_FINAL.pdf (in chapter 14.4 Deployment Descriptor > Diagram) > is that this feature is only usable at deployment time. > > I think this is only a hit to an application deployer (the person > performing a deployment). > > Is there some other place in the Spec PDF where this feature is documented? > The changelog chapter does not mention other places, and I do not see > any others with a quick search. > > > As a similar example: "short-name" in a tld file of a Tag Library is a > hint for the prefix used for those tags. It is not the actual prefix. > > > Thus I think that we do not need to change our > auto-deployment/deploy-on-startup procedure. > > > I think that this feature belongs to the ways how a web application > may be deployed programmatically. E.g.: > > 1) Make "path" parameter optional in "text/deploy" command of Manager > web application, > > http://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html# > Deploy_A_New_Application_Archive_(WAR)_Remotely > > 2) Make "path" parameter optional in DeployTask of Ant. > > > > 3. If this feature is controlled by a system property, make a > separate property which default depends on STRICT_SERVLET_COMPLIANCE. > > Do not use STRICT_SERVLET_COMPLIANCE directly. > > As this is a deployment feature, I think it makes sense as an > attribute on Host rather that a system property. (Though as I wrong > above, I think we do not need to implement it). > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
