Yep, that's sure to be the problem. As for keeping record of
everything you put in the request, i'm not sure what the best way to
do this is. personally, i only rarely put things directly into the
request myself. i mostly use tools to access my request scoped data.
those are easy enough to keep track of in my toolbox.xml file.
but here's an off-the-top-of-my-head suggestion you could do to help
avoid namespace collisions like this: use different naming
schemes/prefixes for different parts of your application. for
instance, you could prefix all your resource bundle keys with "rb_"
or something like that.
On Thu, 10 Feb 2005 12:27:25 +0200, Markos Charatzas <[EMAIL PROTECTED]> wrote:
> Hello Nathan,
>
> Thank you for your prompt and detailed response.
>
> Yeah its true that I use request.setAttribute("destinations", destinations) at
> some point before rendering the template so that what is must be causing the
> problem.
>
> So...does that mean that I have to keep a record of every possible entry made
> to the request? How do I go on about this?
>
> Thanks in advance,
> Markos Charatzas
>
> On Wednesday 09 February 2005 19:25, Nathan Bubna wrote:
> > the relevant code (in veltools 1.1's StrutsUtils) is doing the following:
> >
> > resources = (MessageResources) request.getAttribute(bundle +
> > moduleConfig.getPrefix());
> >
> > if (resources == null) {
> > resources = (MessageResources) app.getAttribute(bundle +
> > moduleConfig.getPrefix());
> > }
> >
> > this seems to indicate that there is something in either your request
> > attributes or servlet context attributes under the key "destinationsX"
> > (where X is your module config prefix) that is not a MessageResources
> > object. i'm not sure how this would happen, but it is. for tracking
> > the problem down, you might first try retrieving that object yourself
> > and finding out what it is. you might also grep your app to find any
> > other place that an object would end up in your request or servlet
> > context attributes with that same key, because something is probably
> > doing so and thus replacing the MessageResources object that should be
> > there.
>
> ---------------------------------------------------------------------
> 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]
