Menu
▾
▴
springframework-developer
|
From: Alef A. <al...@jt...> - 2005-04-15 16:03:20
|
Juergen, everybody, =20 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. =20 1) DispatcherServlet extends HandlerServlet extends FrameworkServlet or 2) DispatcherServlet extends FrameworkServlet and an additional RemotingServlet extends FrameworkServlet =20 The reasoning here would be the following: =20 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 :) =20 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). =20 What do you think? =20 alef =20 |
|
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 > |
|
From: Juergen H. <ju...@in...> - 2005-04-15 20:43:34
|
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 |
|
From: Juergen H. <ju...@in...> - 2005-04-15 20:47:13
|
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
|
|
From: Matt S. <sga...@us...> - 2005-04-15 21:04:40
|
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 > |
|
From: Juergen H. <ju...@in...> - 2005-04-15 21:48:22
|
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 |
|
From: Juergen H. <ju...@in...> - 2005-04-15 21:09:34
|
On reconsideration, I'm not sure whether a separate Handler interface
without ModelAndView return value is really worth it. Implementing the
Controller interface and returning null seems acceptable to me too.
Aside from Jason refusing to define a Spring DispatcherServlet in his
WebWork app, even if just for the purpose of exposing remote services - is
there an actual problem that needs to be solved?
The implicit default LocaleResolver and ThemeResolver are not even *invoked*
for a DispatcherServlet that doesn't render a View... removing them doesn't
really add any value, as they hide so nicely anyway when not used. I think
it's fine to consider them as optional services, as I said, simply not used
when exporting remote services.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Juergen Hoeller
Sent: Friday, April 15, 2005 10:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] MVC DispatcherSevlet vs
HandlerServlet
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
|
