Using another servlet front cntroller in Spring dm server

[vsbronnikov]

Hello!

I want to use Cocoon (cocoon.apache.org) as a web-framework in my application. But in Spring dm server, when build web.xml from manifest headers, servlet has a class "org.springframework.web.servlet.DispatcherServlet ".

But Cocoon has it's own front controller "org.apache.cocoon.servletservice.DispatcherServle t". And Cocoon also build on Spring-framework.

I would like, for example, to have another one manifest-header "Web-DispatcherServletClassName" to specify my own front controller.

How do you think about this idea?

[Sam Brannen]

Hi vsbronnikov,

I want to use Cocoon (cocoon.apache.org) as a web-framework in my application. But in Spring dm server, when build web.xml from manifest headers, servlet has a class "org.springframework.web.servlet.DispatcherServlet ".

But Cocoon has it's own front controller "org.apache.cocoon.servletservice.DispatcherServle t". And Cocoon also build on Spring-framework.

I would like, for example, to have another one manifest-header "Web-DispatcherServletClassName" to specify my own front controller.

How do you think about this idea?

It's not that bad an idea. In fact, I already had that idea and implemented it in an earlier version of the dm Server (i.e., during the initial beta period).

However, the test of time made it apparent that having too many Web-* manifest headers is overkill. Thus, we came up with a new idea called web.xml fragments which allow you to configure your web.xml deployment descriptor just as you normally would, and the auto-generated configuration from Web-* manifest headers is merged with the contents of your web.xml fragment. This is described in detail in the Web Modules section of the dm Server Programmer Guide.

Also, please note that the use of Web-* manifest headers (with the exception of Web-ContextPath) and web.xml fragments is only supported for Web Modules. Thus, with a standard Java EE WAR, Shared Libraries WAR, or Shared Services WAR, you can continue to configure your Spring-powered web application as you normally would in a single web.xml file.

Regards,

Sam

[vsbronnikov]

But if I will use web.xml fragment then final web.xml will contain 2 front controller:
- first - automatically generated by dm server;
- second - from web.xml fragment.

First controller never need to use. Can I somehow delete it from final web.xml?

Hi vsbronnikov,



It's not that bad an idea. In fact, I already had that idea and implemented it in an earlier version of the dm Server (i.e., during the initial beta period).

However, the test of time made it apparent that having too many Web-* manifest headers is overkill. Thus, we came up with a new idea called web.xml fragments which allow you to configure your web.xml deployment descriptor just as you normally would, and the auto-generated configuration from Web-* manifest headers is merged with the contents of your web.xml fragment. This is described in detail in the Web Modules section of the dm Server Programmer Guide.

Also, please note that the use of Web-* manifest headers (with the exception of Web-ContextPath) and web.xml fragments is only supported for Web Modules. Thus, with a standard Java EE WAR, Shared Libraries WAR, or Shared Services WAR, you can continue to configure your Spring-powered web application as you normally would in a single web.xml file.

Regards,

Sam

[Sam Brannen]

But if I will use web.xml fragment then final web.xml will contain 2 front controller:
- first - automatically generated by dm server;
- second - from web.xml fragment.

First controller never need to use.

That's correct: if you are configuring an additional front controller for a Web Module, you would then have two front controllers, and if you don't need the Spring MVC DispatcherServlet, then it would in effect not be used.

Can I somehow delete it from final web.xml?

For Web Modules, no, there is no way to completely disable the automatic creation of a DispatcherServlet; however, you could configure the URL mapping patterns to something that you don't use (e.g., *.ignored.extension). If this is not a viable solution for you, you can always use a Shared Services WAR to achieve practically the same results.

Hope this helps,

Sam