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

I filed a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=459490

I did not realize how complex the rules for assembling the descriptor from web.xml, webfragment.xml and annotations are, until I opened the specification. I did not have time to read them... I leave it to the more experienced to decide how to fix the <error-page> bug.

Thanks,
Miroslav Todorov


Message: 1
Date: Fri, 6 Feb 2015 06:57:24 -0700
From: Joakim Erdfelt <joakim@xxxxxxxxxxx>
To: "Jetty @ Eclipse developer discussion list"
	<jetty-dev@xxxxxxxxxxx>
Subject: Re: [jetty-dev] Defining a duplicate error page in
	webdefault.xml	and web.xml
Message-ID:
	<CAG4zZZBJLXVm3S4RxBLLxX9BoaD4FeC3nD_BZ7ok83riWocVkA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

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>
webtide.com <http://www.webtide.com/> - intalio.com/jetty Expert advice, services and support from from the Jetty & CometD experts eclipse.org/jetty - cometd.org

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
>
>



Back to the top