Menu
▾
▴
Re: [Springframework-developer] Access to ServletConfig in WebApplicationContext
|
From: Juergen H. <ju...@in...> - 2005-11-06 18:43:50
|
Sounds perfectly feasible. We will consider this when merging the Portlet support from the sandbox into the main source tree, which is gonna happen very soon now. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Yujin Kim Sent: Sunday, November 06, 2005 7:30 PM To: spr...@li... Subject: Re: [Springframework-developer] Access to ServletConfig in WebApplicationContext 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 > the 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 > underlying 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 > frameworks 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 CVS 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 > 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 > > > This message is a PRIVATE communication. > If you are not the intended recipient, please do not read, copy, or > use it, and do not disclose it to others. Please notify the sender of > the delivery 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. > Download 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. > Download 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. Download 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 |
