RE: [Springframework-developer] Release schedule

[<jue...@we...>]

Paul,

I must admit I haven't thought about the internals of Struts support =
earlier. But now that I've reviewed your plugin, I am aware of how easy =
this actually is. We just need to initialize the ApplicationContext and =
expose it to the ServletContext, and off we go writing Struts actions =
that use Spring beans via retrieving the ApplicationContext from the =
ServletContext.

Facing this simple way, I wonder if we need explicit Struts support at =
all, at least in the technical sense. Isn't setting up a standard =
ContextLoaderServlet or ContextLoaderListener in web.xml just as easy as =
registering a Struts-specific plugin in struts-config.xml? The Struts =
plugin doesn't seem to add any specific handling, as the ServletContext =
contained by the ActionServlet instance should be equal to the standard =
ServletContext of the web application.

The only obvious difference seems to be the attribute name, which is not =
meant for manual usage in standard Spring. But Struts actions could =
simply retrieve the current ApplicationContext via =
com.interface21.web.context.support.WebApplicationContextUtils.getWebAppl=
icationContext(ServletContext), using Spring's standard attribute name =
underneath.

So, should we adopt my proposed pattern? Its major advantage is its =
simplicity - it does not need any specific Struts support at all, =
especially no binary dependency on Struts classes within Spring. And it =
should work nicely, at the same level of convenience as the Struts =
plugin. Is there any added value of the latter that I am missing?

Finally, with Spring's newly refactored ContextLoader class, a minimal =
Plugin implementation should do the job now, analogous to the =
ContextLoaderListener implementation - if one really needs configuration =
via struts-config.xml. Instead of replicating the initialization code, =
the following should be enough:

  public void init(ActionServlet servlet, ModuleConfig config) throws =
ServletException {
    ContextLoader.initContext(servlet.getServletContext(), =
contextClass);
  }

But still, I consider configuration via web.xml equally simple.

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Thursday, March 06, 2003 12:06 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Juergen/group
>=20
> Wow - I am very impressed with the amount of work you are=20
> contributing towards the Spring framework - if only I could=20
> find the time I would love to be more active.
>=20
> Personally, I think it would help if tasks were cleary=20
> defined and assigned to individuals - I am unsure what areas=20
> need looking at and am conscience that I may be duplicating=20
> effort if I just dive in.  I know that tasks are discussed=20
> within this list but this should be documented  - or does=20
> this go against the open source idealogy.
>=20
> BTW I have attached a struts plugin that I have written and=20
> am using with success - it needs reviewing.
>=20
> Here is a brief description of its use - I assume struts familarity:
>=20
> A Struts PlugIn can be used to provide close integration with=20
> Spring's bean based infrastructure.  The root=20
> com.interface21.web.context.WebApplicationContext object,=20
> which defines JavaBeans and their relationships ,can be added=20
> to a web application's ServletContext by this PlugIn, as an=20
> alternative to using the ContextLoaderServlet.
>=20
> PlugIn modules can be configured using the <plug-in> element=20
> in the struts-config.xml file.  Classes that implement the=20
> PlugIn interface must have a zero-argument constructor,=20
> configuration is performed by providing standard JavaBeans=20
> property setter methods.
>=20
> The PlugIn requires a single configuration parameter to be=20
> provided in the deployment descriptor, contextClass. This=20
> parameter is the class name of the WebApplicationContext=20
> implementation to provide a context for this
> application, in this case XmlWebApplicationContext.   The=20
> PlugIn merely
> instantiates the class and provides it with the current=20
> ServletContext object.
>=20
> <plug-in className=3D"com.phoenix.web.context.ContextLoaderPlugin">
>     <set-property property=3D"contextClass"=20
> =
value=3D"com.interface21.web.context.support.XmlWebApplicationContext"/>
> </plug-in>
>=20
> The WebApplicationContext requires a configUrl to be set in=20
> the web.xml file.  This is the URL to the configuration file=20
> that defines the business objects and their relationships. =20
> These are exposed as JavaBeans to classes in the web=20
> application framework, servlet filters and JSP custom tags.
>=20
> <context-param>
>     <param-name>configUrl</param-name>
>     <param-value>/WEB-INF/applicationContext.xml</param-value>
> </context-param>
>=20
> Struts Actions can access these business objects by looking=20
> up the WebApplicationContext in the ServletContext.
>=20
> Note:  Certain bean names have special significance and one=20
> must be provided in the configuration file, "messageSource". =20
> This defines an internationalizable repository for errors and=20
> other messages.  Even if the application uses the Struts=20
> resource bundle, this is still required, along with the=20
> messages.properties file in /WEB-INF/classes.
>=20
> <bean name=3D"messageSource"=20
> class=3D"com.interface21.context.support.ResourceBundleMessageSource">
>     <property name=3D"basename">messages</property>
> </bean>
>=20
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
>=20
>=20
> Hi committers,
>=20
> We should try to approach a 0.8 release ASAP, as the lack of=20
> a formal distribution definitely hinders Spring adopting. IMO=20
> we should aim at end of March.
>=20
> Unfortunately, the lack of documentation is a major issue:=20
> Currently, a potential user should have both Rod's book and=20
> the framework sources. I consider polishing JavaDoc comments=20
> and including generated JavaDoc a must, already for 0.8.=20
> Separate online documentation will be a must for 1.0, but not=20
> earlier, I guess. Any volunteers for either?
>=20
> The further schedule will probably consist of 0.9 at end of=20
> April and 1.0 around June. Of course, the actual dates will=20
> be determined by Spring's quality and stability, not by a=20
> deadline. Nevertheless, I have the urge to proceed release-oriented.
>=20
> IMHO, we are easily feature-complete for 0.8 now, as=20
> multipart request handling can also wait until 0.9. Beyond=20
> that, we should think about further must-haves for 1.0. The=20
> Struts plugin comes to my mind, for example, and better test=20
> coverage and homogeneous code style. Beyond the framework=20
> itself, we will need example apps, and a nice little website=20
> with some sort of "project identity".
>=20
> What do you think?
>=20
> Regards,
> Juergen
>=20
>=20
> DI J=FCrgen H=F6ller
> Senior System Architect
> __________________________________
>=20
> werk3ATS - division systementwicklung
> part of werk3AT internetmedien oeg
>=20
> europaplatz 4
> A - 4020 linz
>=20
> t.  +43 (0) 732 71 65 29
> f.  +43 (0) 732 71 65 29 3
> jue...@we...
> www.werk3at.com
> __________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger for complex code. Debugging C/C++=20
> programs can leave you feeling lost and disoriented.=20
> TotalView can help you find your way. Available on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20