At 3:36 PM -0400 10/4/05, Chris Bredesen wrote:
Gents,
Thanks for the informative replies. I'm happy to know that my little
issue has sparked some intelligent conversation. I think a plugin is
going to be the winner for me, but I'll have to read a bit more on how
far they reach and at what point things happen. The one Struts book we
have on hand here is pretty thin in that area.
Niall, I think making ServletContext available to the
MessageResourcesFactory would be a worthwhile benefit, particularly in
use cases like my own. The concern about the state of Struts at this
point is probably not too worrisome because anyone who employs this sort
of setup would certainly need to be aware of the order in which things
happen.
I would advocate for a few cycles of thought before choosing this, as
I am also hoping to minimize Struts' direct dependencies on the
Servlet Context API. That is, the MessageResourcesFactory API should
not depend on ServletContext. On the other hand, if we had a more
DI-style configuration process, one could conceivably produce a
MessageResourcesFactory implementation which did have a dependency on
ServletContext and inject that factory into the classes which need
it. Here's why relying merely on the
MessageResourcesFactory.createFactory is a problem.
Fortunately, it seems as though that method is only used in two
places: once in ActionServlet, and once in the static
MessageResources.getResources(String) which is used in many places to
support internal messages for Struts' own behavior. So, in short,
you could override
protected void initModuleMessageResources(ModuleConfig config)
in ActionServlet and change either how the MessageResourcesFactory is
bootstrapped or perhaps just short-circuit the factory and implement
your own behavior which results in the placing into the
ServletContext the necessary MessageResources objects under the
correct keys.
When we work on fixing this in Struts own code, we want to steer
towards having an object which encapsulates the Module's resources
and behavior, so that instead of putting the MessageResources objects
in the ServletContext, you'd put them in the Module itself (or some
object of which there were one application-scoped instance per
module) This could then be passed around to anything which deals
with "application-scoped" behavior where now things are done directly
in the ServletContext.
Joe
It makes sense that the change would be relatively trivial since most
other extension points provide access to ServletContext. I would
attempt to submit a patch (never done so before) but it would probably
take longer to review, apply and commit a user patch than for a
committer to simply add the feature. I'm willing to help in any way
possible, though.
Cheers,
Chris
-----Original Message-----
From: Niall Pemberton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 04, 2005 3:21 PM
To: Struts Users Mailing List
Subject: Re: Access to ServletContext from MessageResources[Factory]
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
