|
From: Matt S. <sga...@us...> - 2005-04-15 16:43:14
|
I was thinking some of the behavior in the DispatcherServlet could be isolated as servlet filters. That way they could be applied to other servlet's such as Jason's servlet, or Struts' ActionServlet :) Matt Alef Arendsen wrote: > 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 > |