On Thu, 2 Aug 2001, Miles Daffin wrote: > Thanks Craig (see below) - reliable as ever. > > That was the only conclusion I could come to: to start > serving my own static content. A bit of a pain. > > As to what I am doing - experimenting with aspects of the > 2.2 Spec. Making myself aware of the options. > > What might one use a default servlet for?? I thought > I knew. Turns out I was wrong. Well, not every web app necessarily has static content. Or, you might want to customize the serving of static content in some way (and thereby override the default file-serving capability of your container). In practice, I've never found a need to replace this myself. > > Miles > Craig > > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 01, 2001 7:50 PM > To: [EMAIL PROTECTED] > Subject: Re: Default Servlet prevents loading of static resources. > > > On Wed, 1 Aug 2001, Miles Daffin wrote: > > > Hi There TC Peeps, > > > > I have added a default servlet to a little test webapp > > (<servlet-mapping>/</servlet-mapping>). > > > > After I did this I can no longer access static resources > > (html, images etc.) in the app. > > > > All requests, apart from those to other (mapped) servlets > > are picked up by the default. e.g. I have an index.html in the > > apps <welcome-file-list> that cannot be got at implicitly or > > explicitly. > > > > The same behaviour is noted in ORION. > > > > 1. Have I noticed something strange, or should it be this way? > > 2. If it should be this way what is the use of a default servlet? > > (Can anyone give an example of usage?) > > > > Miles > > > > In Tomcat at least (don't know about Orion but sounds like it might be the > same), static file serving is implemented as the "default" default servlet > :-). Defining your own default servlet means that the file-serving > servlet will never see the request, so it becomes your responsibility to > serve static content. > > What's your objective for defining your own default servlet? There might > be another way to approach that problem. > > Craig McClanahan > > > >
