Re: [Springframework-developer] Access to ServletConfig in WebApplicationContext

[Yujin K. <net...@gm...>]

Slightly off topic here, but something I mentioned in my recent post.
Would refactoring/abstraction of multipart handling considered worthwhile?

For example, currently there's MultipartHttpServletRequest which
contains three methods that are not tied to Servlet but the interface
itself is a subinterface of HttpServletRequest, which makes the whole
multipart servlet centric.

If an interim interface is introduced, then while still maintaing
MultipartHttpServletRequest and MultipartActionRequest, the rest of
the framework can operate off of the interim interface, which I think
can eliminiate quite a bit of code duplication.  (Multipart support
for Portlet was just sent over to John for his review.  And Enrique
also posted a version on wiki).

While I amt ait,  I was also wondering if it would be make a good
argument to introduce a "resolver" framework.  Currently it seems
DispatcherServlet (and DispatherPotlet for that matter) is doing a bit
of manual check on the beans implementing ServletContextAware and
processing of each resolvers registered.  it would be nice to define
pointcuts inside servlet workflow and make resolvers dynamically
injected upon autodiscoery.

Let me know if I am being ignorant and sily.

On 11/6/05, Juergen Hoeller <ju...@in...> wrote:
> At the core web MVC level, such an abstraction is arguably not worthwhile=
.
>
> The control flow in a Portlet environment is quite different, which needs=
 to
> be reflected in the corresponding controller model. Furthermore, web
> controllers should have full access to the native Servlet/Portlet
> facilities, not just to a least common denominator.
>
> On the view side, we have full reuse anyway, so it's really only about th=
e
> dispatcher / controller side, including handler mapping and co.
>
> Higher-level web UI frameworks such as Web Flow, JSF or Tapestry are a
> different matter here. To a large degree, they abstract from the underlyi=
ng
> request model, so can more naturally abstract from the concrete
> Servlet/Portlet facilities, or in fact even the dispatcher facility they =
run
> in.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Boyce, Keith Garry
> Sent: Sunday, November 06, 2005 5:10 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Access to ServletConfig in
> WebApplicationContext
>
>
> Sounds good to me... While you are at it have you considered if it's
> possible to abstract the http and portlet request and response similar to
> webflow so that the code doesn't have be so duplicated?
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> John Lewis
> Sent: Saturday, November 05, 2005 10:54 PM
> To: spr...@li...
> Subject: [Springframework-developer] Access to ServletConfig in
> WebApplicationContext
>
> I posted a question about this to the user list last week and no one had =
any
> secret tricks for this, so I'd like to propose a minor change to
> WebApplicationContext and to FrameworkServlet as follows:
>
> I'd like to provide beans running in a WebApplicationContext with access =
to
> the ServletConfig that they are running in.  I'd like to do this in order=
 to
> provide access to the portletName and the initParameters for the Servlet.=
  I
> know several other developers have expressed an interest in this.
>
> This can be done in the same way that Spring currently provides access to
> the ServletContext.  In fact, we can also provide a ServletConfigAware
> interface and inject the ServletConfig directly into any bean that wants =
it.
>
> I will then also provide equivalent functionality in the Portlet MVC code=
 so
> that beans running in a PortletApplicationContext have access the
> PortletConfig they are running in.  I'd like to do this in both framework=
s
> in order to keep them relatively synchronized.
>
> Any objections to all this?
>
> Juergen, I'd be happy to email you the code prior to committing it into C=
VS
> if you would like to review the changes first.  Please let me know.
>
> Thanks for your support.
>
> John Lewis
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your ver=
y
> own Sony(tm)PSP.  Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> This message is a PRIVATE communication.
> If you are not the intended recipient, please do not read, copy, or use i=
t,
> and do not disclose it to others. Please notify the sender of the deliver=
y
> error by replying to this message, and then delete it from your system.
> Thank you.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>