Re: [Springframework-developer] MVC DispatcherSevlet vs HandlerServlet

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

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