Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Defining a duplicate error page in webdefault.xml and web.xml
Ultimately this seems like a bug.

But ...

The origin of the final ultimate "descriptor" is a complicated mess in the servlet spec, that includes a combination of all of the following ...
  • various javax.servlet annotations
  • web fragments in WEB-INF/lib
  • the WEB-INF/web.xml
The order of which these load is also further complicated by the fact that the various XML based ones can specify the order of the resolution of the other ones.
Then, Jetty has a few other ways, on top of the servlet spec, to set the descriptor too.
  • the default descriptor (webdefault.xml)
  • any manually entered ones from the WebAppContext
  • (all of the webapp internal descriptors from above)
  • the override descriptor
This order is fairly consistent and predictable, but that step #3 can sometime seem like a Far Side (tm) "then a miracle occurs" moment.

Can you file a bug about this?  A small webapp with just a WEB-INF/web.xml that proves out this deployment flaw would be good.

Another minor niggle, it is nearly impossible to handle error code 400 in your WEB-INF/web.xml
The problem is that if a bad request comes in, theres no guarantee that the client connecting to you is even HTTP, and since it was a bad request, we have no clue what context's error 400 to dispatch to.



--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Fri, Feb 6, 2015 at 2:53 AM, Todorov, Miroslav <Miroslav.Todorov@xxxxxxxxxxxxxx> wrote:
Hello Jetty developers,
 
 
My use case is the following. I have a Jetty server which hosts lots of different web applications. There is one common deployment descriptor webdefault.xml and each application has its own web.xml. In webdefault.xml there are some definitions of error pages, e.g.:
<error-page>
  <error-code>400</error-code>
  <location>/error_400</location>
</error-page>
...
<error-page>
  <error-code>500</error-code>
  <location>/error_500</location>
</error-page>
...
 
The error pages are defined in webdefault.xml because I want the server to provide some default error handling to the hosted web applications. However, for a certain web application I want to change the default behaviour. For example for web application "app1" I want to define a custom error page which handles error "401 Unauthorized".
 
If I try to define the custom error page in app1/WEB-INF/web.xml, Jetty throws an exception during the deployment of "app1". The message is "Duplicate global error-page". However if I define the custom error page in an override-web.xml for "app1", there is no error and the new error page is applied.
 
My question is whether this behaviour is intended or not? Shouldn't web.xml override the contents of webdefault.xml? A web application can have a list of overriding descriptors which are applied one after another. Shouldn't web.xml be treated just like the first descriptor in this list?
 
 
I found that the exception is thrown in the code which processes the deployment descriptor (web.xml):
 
StandardDescriptorProcessor.java:1200 (from tag jetty-9.3.0.M1):
throw new IllegalStateException("Duplicate global error-page "+location);
 
If you agree that <error-page> entries in web.xml should override such entries in webdefault.xml, I can report a new Jetty bug and provide a fix which fixes this part of StandardDescriptorProcessor.visitErrorPage().
 
 
Regards,
Miroslav Todorov,
My webMethods Server developer,
Software AG
 
 

_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

Back to the top