I agree with what Joe said. In the latest release (1.2.7) the only thing you get passed to the MessageResourcesFactory's create method is the "parameter". I have changed it in 1.3.0 so that the MessageResourcesConfig is available in the MessageResourcesFactory when the create method is called. It might be a good idea to also provide the ServletContext as well - that would be a pretty simple change (getters/setters in the MessageResourcesFactory and a couple of lines in ActionServlet). The only thing I'm not sure about, is how complete the initialization process is at the point the Factory creates the message resources. You would probably either need to make sure Spring was initialized or store the ServletContext in the MessageResources.
That doesn't help you in the mean time - you could just let Struts create the MessageResources and store them - then, after intializetion, retrieve them from the ServletContext yourself and initialize your Spring stuff then - possibly with a Struts Plugin (or ServletContextListener) - they are stored in application scope using the key specified for the message resources plus the module prefix - or if no key is specified then Globals.MESSAGES_KEY plus the module prefix. Niall ----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> To: "Chris Bredesen" <[EMAIL PROTECTED]>; <user@struts.apache.org> Sent: Tuesday, October 04, 2005 7:49 PM Subject: Re: Access to ServletContext from MessageResources[Factory] > At 2:17 PM -0400 10/4/05, Chris Bredesen wrote: > >Hi Group, > > > >I'd like to create an implementation of MessageResources that is backed > >by Spring-sourced database accessors. I can't seem to get ahold of > >ServletContext form anywhere inside the MessageResources classes, and as > >such I cannot obtain my WebApplicationContext reference. Is there > >something I'm missing? > > I doubt it. I have to admit that I haven't reviewed this recently, > but I seem to recall feeling that the inability to do this evidenced > a design flaw in the resources API. > > I think that generally speaking, the route which Struts provides for > you involves changing the implementation of ModuleConfig, but here is > where throughout one sees signs of Struts development before the > paradigm of Dependency Injection took hold. In many places, Struts > is too committed to a single way of obtaining implementations of > various interfaces -- if you look in ActionServlet, you see that it > will only let you get a ModuleConfig implementation from a > ModuleConfigFactory, and you can only get a ModuleConfigFactory by > using the static getFactory() method provided by ModuleConfigFactory. > > This is one of the next big things about Struts that I'd like to see > fixed, although my own development time for it will be short for a > while -- I'd like to reorganize the processes by which Struts > assembles its key functions so that it is easier to inject different > kinds of behavior along the lines of what you suggest. It should be > possible to do this relatively gently, so as to preserve backwards > compatibility while opening things up. If you're interested in > getting deeper into the question and working on solutions, I'd invite > you to bring this discussion over the the [EMAIL PROTECTED] list. > > Joe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
