Re: [Springframework-developer] MVC DispatcherSevlet vs HandlerServlet

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

I see... you consider scanning the services in the middle-tier application
context. This won't be that straightforward, though: a
BeanFactoryPostProcessor only applies to beans in its *own* context. So all
you could do is scan all beans in the entire context hierarchy through
getBeanNames/getType calls, which I'm not particularly fond of.

Frankly, I don't really see the need for another abstraction: people do *not
have to* implement their own custom servlets already - the current
DispatcherServlet works just fine for exporting remote services only! If
Jason doesn't want to touch our DispatcherServlet because it smells like
Spring Web MVC to him, which he wants to stay away from for religious
reasons, that's - bluntly said - his problem, not ours.

You do have a point there regarding MVC vs servlet support separation.
However, that would only work with a restructing of the package hierarchy
there, because the current "web.servlet" package is essentially the direct
basis for the controllers and views of the MVC framework. If we wanted to
separate those into different modules, we'd get a problem, because we'd need
to separate classes in the same subpackage tree there.

The current line drawn between spring-web.jar and spring-webmvc.jar is that
the latter includes "web.servlet" plus subpackages and the former includes
everything else. That works pretty well in general, because spring-web.jar
is all you need to make a Spring application context work with Struts, JSF,
Tapestry, any third-party MVC framework.

Of course, once you want to export HTTP-based remote services, you do need
spring-webmvc.jar even when working with a third-party web MVC framework. I
consider that acceptable, though: spring-webmvc.jar simply includes a
generic dispatcher necessary for HTTP-based remoting, which will coexist
nicely with any third-party MVC framework.

That's why I asked whether we have a real problem to solve here. In essence,
everything already works sufficiently well, in my opinion. Well, we could
save some kilobytes if we tailored a jar file for HTTP-based remote
exporters, but is this really about jar file size?? A 100 KB up or down
really doesn't matter in a server-side application, in particular with big
1.6 MB babies such as Hibernate3 and Axis around.

If exporting remote services through annotations only becomes a major use
case, we can still add a special servlet for that - which wouldn't even
derive from FrameworkServlet, though, because it wouldn't have its own
application context. And for scenarios where exporters are defined
explicitly in a Spring application context (which I expect to stay around),
DispatcherServlet should be just fine.

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Alef Arendsen
  Sent: Monday, April 18, 2005 10:34 AM
  To: spr...@li...
  Subject: RE: [Springframework-developer] MVC DispatcherSevlet vs
HandlerServlet


  Autodetecting services could be done by a Bean(Factory)PostProcessor
inspecting all beans in the middle-tier application context. Not that I
particularly like doing it using annotations, but it's possible.

  There were two reasons for introducing another abstraction. One was merely
an estethic (keeping people from have to implement their own custom
servlets - I don't like custom stuff that much :). The other was to
facilitate a possible separating of the MVC stuff from the core servlet
packages (we *are* still planning a restructuring of the project for 1.3,
aren't we).

  About the Handler interface: that wouldn't really be an appropriate name,
would it, since we already have the HandlerAdapter. We'd then have to create
a HandlerHandlerAdapter? Besides that I don't think it would add much value
(as you noted already).




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