springframework-developer Mailing List for Spring Framework (Page 136)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

View results here -> http://opensource.jteam.nl/build/buildresults/springmodules?log=log20050418142638Lbuild.2

View results here -> http://opensource.jteam.nl/build/buildresults/springmodules?log=log20050418132057Lbuild.1

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

Everybody,

I'm currently preparing everything for the actual 1.2 RC2 release, which
will happen this afternoon - finally, after various last-minute bug fixes
and enhancements slipped in...

I've already upgraded to Hibernate 3.0.1, which has been released this
morning, and will now go into testing the sample apps. Please refrain from
commits until the release is finished!

Juergen

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.
=20
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).
=20
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).
=20

________________________________

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,
=20
Yes, XFire seems to become a viable alternative to Axis... which is
already overdue :-)
=20
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.
=20
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).
=20
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).
=20
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?).
=20
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.
=20
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!
=20
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.
=20
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.
=20
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?
=20
Juergen
=20
=20
=20

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

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050418001550Lbuild.248

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050417001643Lbuild.247

We do now! :-)

Actually there was a bug in the Preview 2 release that was causing problems. 
That's fixed now and I've added a "Flow Launcher" sample application that 
demonstrates launching flows with input parameters: as stand-alone flow, as 
subflow or from and end state of another flow.

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Monday, April 11, 2005 9:25 PM
Subject: Re: [Springframework-developer] Web Flow: forwarding to another 
flow...

> Erwin,
>
> do you have any examples of redirecting from one flow to another...?
>
> Dmitriy.
>
> Erwin Vervaet wrote:
>
>> You can't do it with a forward because of the problem you describe, but 
>> it is possible with a "redirect:..". If you want to pass parameters to 
>> the launching flow, pass them as request parameters (not attributes since 
>> you're redirecting).
>>
>> Erwin Vervaet
>> erw...@er...
>> ----- Original Message ----- From: "Will Butler" 
>> <wil...@ra...>
>> To: <spr...@li...>
>> Sent: Monday, April 11, 2005 8:24 PM
>> Subject: [Springframework-developer] Web Flow: forwarding to another 
>> flow...
>>
>>
>>> Is it possible to use a "forward:..." in an end state to halt execution
>>> of one flow and start another? When the request is made to the first
>>> flow to make the transition to the end state, its flow id has been
>>> placed in the request parameters. This is necessary, of course, to look
>>> up the first flow. When the forward occurs, the flow id from the first
>>> flow is still in the request. The flow execution manager then tries to
>>> look up the second flow using the first flow's id, which fails
>>> miserably. Is this something that just cannot be done, or is there a
>>> workaround that I could try?
>>>
>>> Thanks!
>>>
>>> Will
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>
>
>
>
> -------------------------------------------------------
> 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
>
> 

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050416001601Lbuild.246

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

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

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
>          

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,