When a client requests a partial uri in a webapp with no matching static resource or servlet/jsp in the DD, Tomcat should process the <welcome-file list> in the DD and append each <welcome-file> entry to the partial request. After appending Tomcat should look for a matching static resource or servlet. [1] Problem as follows: When using a <welcome-file>foo.bar</welcome-file> and having a servlet matching the pattern *.bar, this servlet is not invoked. Using a normal path extension in the welcome file works. working: <servlet-mapping> <servlet-name>BarServlet</servlet-name> <url-pattern>/home</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>home</welcome-file> </welcome-file-list> not working: <servlet-mapping> <servlet-name>BarServlet</servlet-name> <url-pattern>*.bar</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>foo.bar</welcome-file> </welcome-file-list> I know that the deafult servlet maps to <url-pattern>/</url-pattern> so that it will be invoked before any extension matching servlet, when accessing http://example.com/mywebapp/ , but when going deeper in the directory structure the BarServlet should be invoked when accessing e.g. http://example.com/mywebapp/buzz/ . The partial request "/buzz/" should be extended by "foo.bar" becoming "/buzz/foo.bar" and a match with *.bar should invoke BarServlet. I used Tomcat 5.5.12. Regards, Peter Menzel [1] The Servlet spec 2.4 (SRV 9.10) states: "The web server must append each welcome file in the order specified in the DD to the partial request and check whether a static resource or servlet in the WAR is mapped to that request URI."
That's normal, it can't be implemented.
So you mean the expressiveness of the Java language is not sufficient to solve this problem? By not implementing this feature, Tomcat does not implement the full Servlet 2.4 spec. So what happens about its status as a reference implementation of this spec. ?
(In reply to comment #2) > By not implementing this feature, Tomcat does not implement the full Servlet 2.4 > spec. So what happens about its status as a reference implementation of this spec. ? > Another day in BZ, another round of useless statements, another round of whining. Tomcat IS NOT the "reference implementation of this spec". This feature is not desirable, and has very bad consequences. As a result, it is not implemented. If you don't like it, you can either tweak your Tomcat version or use another implementation of the Servlet specification.
Oh sorry, I did not know that Tomcat is NOT the official reference implementation. Obviously I misunderstood the first sentence on http://tomcat.apache.org which states: "Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies." ;-) Can you tell which very bad consequences this feature involves ?
not working: <servlet-mapping> <servlet-name>BarServlet</servlet-name> <url-pattern>*.bar</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>foo.bar</welcome-file> </welcome-file-list> Workaround: Create empty "foo.bar" file in every directory you need BarServlet to execute.
(In reply to comment #4) > Oh sorry, I did not know that Tomcat is NOT the official reference implementation. > Obviously I misunderstood the first sentence on http://tomcat.apache.org which > states: > "Apache Tomcat is the servlet container that is used in the official Reference > Implementation for the Java Servlet and JavaServer Pages technologies." > ;-) "used" does not mean "used as is". > Can you tell which very bad consequences this feature involves ? The (mandatory) default configuration includes "index.jsp" in the welcome file list, as well as a servlet mapped to "*.jsp". This will not work well at all if your interpretation of the specification is correct.
I'd suggest you might get further if you provide an example of a container where it is actually implemented as you say. Might be wrong, but I think nearly all the container implementations behave the same way as Tomcat (at least I can't remember one that acts like you mentioned).
(In reply to comment #6) Can you tell which very bad consequences this feature involves ? > The (mandatory) default configuration includes "index.jsp" in the welcome file > list, as well as a servlet mapped to "*.jsp". This will not work well at all if > your interpretation of the specification is correct. So why should this bear problems? When having "index.jsp" in the welcome-file-list and accessing "/buzz/", "index.jsp" is appended, resulting in "/buzz/index.jsp", which in turn is mapped to the JspServlet which matches "*.jsp". When this works, why should the ".bar" extension not? <servlet-mapping> <servlet-name>BarServlet</servlet-name> <url-pattern>*.bar</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>foo.bar</welcome-file> </welcome-file-list>
(In reply to comment #8) > (In reply to comment #6) > Can you tell which very bad consequences this feature involves ? > > The (mandatory) default configuration includes "index.jsp" in the welcome file > > list, as well as a servlet mapped to "*.jsp". This will not work well at all if > > your interpretation of the specification is correct. > > So why should this bear problems? > When having "index.jsp" in the welcome-file-list and accessing "/buzz/", > "index.jsp" is appended, resulting in "/buzz/index.jsp", which in turn is mapped > to the JspServlet which matches "*.jsp". > When this works, why should the ".bar" extension not? Note it works only if "index.jsp" exists. Same with "foo.bar" - you want it served, you have to make sure it exists.
Hi Lilianne, Remy, I work in what has been a BEA shop for longer than the 3 years I've been here and have been been trying to convince management that Tomcat provides a better value proposition than WL. We've just been presented with an opportunity to use Tomcat instead of WLX in a new server environment but when migrating apps found this bug. I have a couple of points to make: 1. Whilst the JSP Servlet is only invoked if index.jsp is present I see no problem with it being invoked regardless (as it is if you request /index.jsp directly). Either way I'd expect a 404 (although yes I acknowledge other welcome file list options might match successfully). 2. WL 8.1 SP3 does implement the spec correctly in this area (in relation to comment 7). Is it unreasonable to request a configuration switch that enables the spec behaviour?
I don't see where exactly the problem of supporting an extension match for welcome pages lies. I've searched both the servlet and jsp specs for references to default (implicit) welcome pages, but could not find any. Notice that in the list of welcome pages declared in default-web.xml: <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list> index.jsp comes last. Also notice this comment in default-web.xml: <!-- If you define welcome files in your own application's web.xml --> <!-- deployment descriptor, that list *replaces* the list configured --> <!-- here, so be sure that you include any of the default values that --> <!-- you wish to include. Therefore, the welcome pages declared in default-web.xml, and in particular the index.jsp welcome page, will never interfere with any application-defined welcome pages. This means that if a webapp declares its own welcome file list, the index.jsp welcome file from the default-web.xml, for which an extension mapping always exists, will not be considered and will not be able to "hijack" any of the webapp's welcome pages. I think Mapper.java could be modified as follows: I've moved the existing Rule 4c to 4d, and inserted a new rule 4c that performs the extension mapping. That failing, Rule 4d is invoked, which checks if the welcome file exists as a physical resource, and if so, maps it to the default servlet. That still failing, the next welcome file in the list is checked: // Rule 4a -- Welcome resources processing for exact macth internalMapExactWrapper(exactWrappers, path, mappingData); // Rule 4b -- Welcome resources processing for prefix match if (mappingData.wrapper == null) { internalMapWildcardWrapper (wildcardWrappers, context.nesting, path, mappingData); } // Rule 4c -- Welcome resources extension match if (mappingData.wrapper == null) { internalMapExtensionWrapper(extensionWrappers, path, mappingData); } // Rule 4d -- Welcome resources processing // for physical folder if (mappingData.wrapper == null && context.resources != null) { Object file = null; String pathStr = path.toString(); try { file = context.resources.lookup(pathStr); } catch(NamingException nex) { // Swallow not found, since this is normal } if (file != null && !(file instanceof DirContext) && context.defaultWrapper != null) { mappingData.wrapper = context.defaultWrapper.object; mappingData.requestPath.setChars (path.getBuffer(), path.getStart(), path.getLength()); mappingData.wrapperPath.setChars (path.getBuffer(), path.getStart(), path.getLength()); mappingData.requestPath.setString(pathStr); mappingData.wrapperPath.setString(pathStr); } } Please let me know what you think and if you want me to supply any diffs. I don't think we need any configuration switch for this feature: It should be supported by default if approved. Jan
I agree that if you do not override the welcome-file-list from default-web.xml (by providing your own welcome-file-list in your web.xml), dir listings will always be disabled (since index.jsp will always be mapped to JspServlet), and the JspServlet will return a 404 if index.jsp does not exist. But this goes back to my original question: I searched again, and could not find any reference in the Servlet or JSP specs about a list of built-in welcome pages a container must support. If a webapp relied on the welcome-file-list in default-web.xml, it would be non-portable. So in order to support extension mappings for welcome pages, we need to remove index.jsp from the welcome-file-list in default-web.xml.
(In reply to comment #12) > I agree that if you do not override the welcome-file-list from default-web.xml > (by providing your own welcome-file-list in your web.xml), dir listings will > always be disabled (since index.jsp will always be mapped to JspServlet), and > the JspServlet will return a 404 if index.jsp does not exist. I understand you have an interest in forcing Tomcat into supporting nonsensical specification features, as your own server has to do. This project fortunately does not have to do that anymore. In a way, this is the role of the RI: finiding out what really doesn't make sense when comes the time of implementing something. Personally, I think you need to make more useful contributions to this project rather than attempt to fix non issues that bother everyone else, including: - the getId stuff - the charset encoding nonsense - and now, this one
Here's an additional requirement from the servlet spec that can be supported only if extension mappings were applied to welcome pages in the same fashion as they are for any other types of resources: SRV.9.10 ("Welcome Files") has this: The container may send the request to the welcome page resource with a forward, a redirect, or a container specific mechanism that is indistinguishable from a direct request. For a server than sends a request to a welcome page using a redirect, it will be impossible to later determine whether the target resource is being accessed directly or as the result of the redirect, and suppress or perform extension mappings accordingly.
In response to Comment#13: Please notice that the extension mapping for welcome pages issue was not initially raised by me. It was first reported by petermenzel@gmx.de, and I only jumped on it recently because this very issue has been raised by others. Considering the number of replies on this thread, I would not consider this a "non-issue". I agree if the Servlet or JSP specs required support for a built-in welcome page "index.jsp" (as you implied in one of your comments), the specs would have an issue. But fortunately, neither spec requires this. I just read your email to the EG. I hope this issue can be clarified to everybody's satisfaction. I'm not sure what you mean by the "getId stuff". Are you referring to the new method that was added to javax.servlet.jsp.tagext.TagSupport? If so, please check with the JSF and JSP expert groups for the motivation behind this new method. The "charset encoding nonsense" has been the result of alignment work between the JSP and Servlet EGs. It was not suggested by me.
I have problems with Tomcat only getting the annoyances and no useful contributions at all. I do not find that acceptable. Hopefully you understand what I mean. Indeed, I did just send an email to the expert group in an attempt to resolve some points of the specification which do not make any sense in the real world. I expect to be ignored. (about the getId stuff, I mean HttpSession.getId throwing an ISE for no reason)
Hi Remy, I'm not pointing fingers at Tomcat at all. Look at it this way: I am just trying to help resolve a customer issue, so I hope you find this a somewhat useful contribution. ;-) As for HttpSession.getId() throwing an ISE on an invalidated session, I agree this is useless and requires all kinds of workarounds, but I claim innocence on this as well. This issue has a long history: Apparently, getId() and getLastAccessedTime() were always supposed to throw this exception, but there used to be a typo in the tag name ("@exeption" instead of "@exception") in the HttpSession.java source file, which meant the exception was never reflected in the javadocs. Unfortunately, the EG decided to "fix" this in the 2.4 Errata. I with they had taken this as a hint and removed this exception, at least in the case of getId(). You have my support on this! :) I will reply separately to your email that you just sent to the EG.
I'm going to have to vote with Remy on this one. As Remy has pointed out, Tomcat isn't the RI any more so supporting silly and (as writen in the 2.4 spec) unclear requirements in Tomcat isn't really an issue. And, in any case there is a simple, one-line way to get this working under Tomcat (just create an empty 'index.do' file under all subdirectories). +1 for leaving as WONTFIX.
(In reply to comment #17) > Hi Remy, > > I'm not pointing fingers at Tomcat at all. Look at it this way: I am just trying > to help resolve a customer issue, so I hope you find this a somewhat useful > contribution. ;-) > > As for HttpSession.getId() throwing an ISE on an invalidated session, I agree > this is useless and requires all kinds of workarounds, but I claim innocence on > this as well. Guess what: I got some customer issues too about the getId stuff :) So after trying it out, I now think this sort of fix is actually negative, and impacts production usage. I don't know from where the default welcome file list comes from (for some reason, I cannot find it anymore). It has always been there like it is now, I think.
+1 on Bill's -1. It will be very painful for users if they change their welcome file order to make *.jsp a higher precendence than index.html. Doing so will NEVER allow a user to serve an html file as a welcome file with the proposed change. That is horrible usability. [I don't even want to touch the topic of the struts folks with the index.do mapping] The servlet spec's notion of mapping is full of holes. An example: when asking for a RequestDispatcher for a non-existant resource - a RequestDispatcher is still returned. And if the RequesDispatcher is executed - a 404 or ISE occurs (depending on how and when it was executed). This is confusing from a developer point of view due to the mappings of the default servlet.
Currently the SingleSignOn Valve not working anymore with the getLastAccessTime() ISE! s. user mailing thread last week. I thing we can implement that a "*.do" mapping can handle by welcome file directly. The idea to generate index.do files is not very acceptable to end user.
(In reply to comment #21) > Currently the SingleSignOn Valve not working anymore with the getLastAccessTime() ISE! > s. user mailing thread last week. > > I thing we can implement that a "*.do" mapping can handle by welcome file directly. The > idea to generate index.do files is not very acceptable to end user. For the first part, this is OT, but session events should be sent while the session is still considered valid (I was talking about session attributes implementing the binding listener interface, and most of these are using getId - for example, our own example/test webapps were). Please post a reference to the post. Note: Can you make an effort with your English ?
Here is the missing discussion link: http://marc.theaimsgroup.com/?l=tomcat-dev&w=2&r=1&s=llegalstate+during+invalidate+delta&q=b