Re: [Springframework-developer] Re: MVC DispatcherSevlet vs HandlerServlet

[Juergen H. <ju...@in...>]

Well, I should mention a limitation of that SimpleServletHandlerAdapter
approach (handling direct Servlet instances defined as beans): the Servlet
instances cannot be populated with ServletConfig init parameters - only with
the ServletContext and with bean properties that they expose. This rules out
many existing Servlet implementations, unfortunately.

There is a solution for holding any existing Servlet in a Spring
DispatcherServlet, though: ServletWrappingController. This essentially wraps
an entire Servlet, managing the lifecycle of the Servlet internally,
allowing to apply specific init parameters to it. This can be used to hold
an entire Struts ActionServlet within a Spring context, for example,
applying Spring HandlerInterceptors to it etc.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Sgarlata
Sent: Friday, April 15, 2005 11:03 PM
To: spr...@li...
Subject: [Springframework-developer] Re: MVC DispatcherSevlet vs
HandlerServlet


Oooh... I didn't know that!  This provides a very clear upgrade path to
Spring MVC from Struts.  Route all requests through Spring and have
Spring forward along control to legacy Struts actions where appropriate.
  Very nice!

Matt

Juergen Hoeller wrote:
> BTW, did you know that since Spring 1.1.5, you can even define
> javax.servlet.Servlet instances in a DispatcherServlet context - mapping
> them through HandlerMappings, automatically populating them with the
> ServletContext, destroying them on shutdown :-) It's been one of those
> gimmicks I've added to demonstrate that it's easily possible.
>
> Juergen
>
>
>
>     -----Original Message-----
>     *From:* spr...@li...
>     [mailto:spr...@li...]*On
>     Behalf Of *Juergen Hoeller
>     *Sent:* Friday, April 15, 2005 10:43 PM
>     *To:* spr...@li...
>     *Subject:* Re: [Springframework-developer] MVC DispatcherSevlet vs
>     HandlerServlet
>
>     Hi Alef,
>
>     Yes, XFire seems to become a viable alternative to Axis... which is
>     already overdue :-)
>
>     I'm not sure what to do about DispatcherServlet, though.
>     DispatcherServlet is deliberately kept as powerful as it is to be
>     able to serve both GUI controllers and remote exporters... Our
>     current exporters do implement Controller, right, but it is
>     perfectly valid for a Controller to return null to indicate that it
>     handled the response itself. Frankly, I don't see a real problem here.
>
>     Locale handling, view resolving and theme handling doesn't get in
>     the way *at all* if you just use a DispatcherServlet for exporting
>     remote services. I consider these as optional services that
>     DispatcherServlet offers, just like an ApplicationContext optionally
>     supports a MessageSource. If you don't need them for a specific
>     dispatcher, they are not even visible - no definitions necessary, no
>     corresponding arguments coming in (there is the ModelAndView return
>     value, admittedly, but I consider that acceptable).
>
>     Also, why would a separate HandlerServlet remove the need for a
>     xxx-servlet.xml? That application context definition is loaded by
>     *FrameworkServlet*, not DispatcherServlet itself... a HandlerServlet
>     derived from FrameworkServlet would still require its own context
>     definition file (which is the point of FrameworkServlet).
>
>     Even with annotated services, wouldn't you still need some
>     enumeration of the services to export? Or do you intend to auto-scan
>     all jar files for annotated classes and auto-expose them? (which has
>     been in discussion for EJB3 too, and which I don't really like -
>     coarse-grained facades such as Web Services should be defined
>     explicitly, at least their implementation class names. what if there
>     are multiple services in a jar, but just some of them should be
>     activated for a specific deployment?).
>
>     One advantage of the current remoting-exporter-as-Controller style
>     is that it is easy to mix-and-match GUI Controllers and remoting
>     exporters in the *same DispatcherServlet context definition*, if
>     desired. Of course you will want to separate those if there are
>     numerous remoting services, but it's nevertheless a nice option to
>     combine those into the same dispatcher.
>
>     Essentially, what would be left if we strip off all those
>     DispatcherServlet services? A servlet that autodetects some services
>     to export, without an explicit context definition, autowiring those
>     services with Spring middle tier beans? That sounds like a quite
>     separate servlet to me, not sharing much with our full-power
>     DispatcherServlet in the first place... On the other hand, if remote
>     exporters are defined explicitly, Spring bean definitions in a
>     DispatcherServlet context sound perfectly appropriate to me!
>
>     Actually, I have considered introducing a Handler interface in the
>     web.servlet or web.servlet.handler package before, with a "void
>     handleRequest(request, response)" signature (that is, no optional
>     ModelAndView return value), to be implemented by our remote
>     exporters. We could quite easily retrofit this, without backwards
>     compatibility issues. With even the ModelAndView becoming invisible
>     to such Handler implementations, I don't see any issue with letting
>     our standard DispatcherServlet handle them.
>
>     If Jason wants to implement his own exporter servlet, that's fine
>     with me :-) I think we should approach this pragmatically: If
>     DispatcherServlet is perfectly sufficient for handling remote
>     exporters from a technical perspective (with some of its optional
>     services hiding), we don't need to create a separate servlet for
>     that, in particular if we want to keep the option to define remote
>     exporter definitions in web GUI contexts too.
>
>     What do you think? Did I miss your point? :-) Would that be an
>     acceptable way going forward for you? Do you think that such a
>     reduced Handler interface is valuable enough to warrant its
>     introduction?
>
>     Juergen
>
>
>
>
>         -----Original Message-----
>         *From:* spr...@li...
>         [mailto:spr...@li...]*On
>         Behalf Of *Alef Arendsen
>         *Sent:* Friday, April 15, 2005 6:03 PM
>         *To:* spr...@li...
>         *Subject:* [Springframework-developer] MVC DispatcherSevlet vs
>         HandlerServlet
>
>         Juergen, everybody,
>
>         As you might have seen, we're pretty busy promoting XFire. Jason
>         (Carreira) and Hani are both using it and as it seems they are
>         pretty positive! One thing that concerns me a bit is the
>         DispatcherServlet for Spring. Our current exporters are
>         Controllers while in fact the don't really have to return a
>         ModelAndView (they handle everything themselves). Furthermore
>         there is a lot of stuff going on in teh DispatcherServlet that
>         doesn't really concern remoting (locale handling, view
>         resolving, theme handling - of which I think the latter
>         should be deprecated in 1.3 and removed in 2.0 maybe since
>         nobody uses it). I was dicussing with Arjen (co-worker, XFire
>         committer) the option to introduce a extra level of abstraction
>         for the DispatcherServlet.
>
>         1) DispatcherServlet extends HandlerServlet extends
>         FrameworkServlet or
>         2) DispatcherServlet extends FrameworkServlet and an additional
>         RemotingServlet extends FrameworkServlet
>
>         The reasoning here would be the following:
>
>         a) remove the need to create a xxx-servlet.xml if you only have
>         annotated services (for instance with JSR181 annotations)
>         b) remove themehandling, localehandling, etcetera when exporting
>         services through http, rmi, soap, etcetera
>         c) remove the need for people (like Jason) that don't like
>         Spring Web MVC to use the DispatcherServlet (I know, it's
>         stupid, but Jason already implemented his own custom servlet :)
>
>         This might also facilitate the separation of the MVC bits and
>         the core if we want this (themehandling, localehandling are only
>         needed in case you're doing web mvc).
>
>         What do you think?
>
>         alef
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer