Re: [Springframework-developer] MVC DispatcherSevlet vs HandlerServlet

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

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