Hi Craig,

when something changed in the way a ViewControllerMapper is defined, the Wiki 
page on that topic (http://wiki.apache.org/shale/ViewControllerMapper) should 
be updated. Unfortunately I'm not using/evaluating Shale any longer, so I won't 
have time to do this as I did before.

Cheers,

René


----- Original Message -----
From: Craig McClanahan
[mailto:[EMAIL PROTECTED]
To: [email protected]
Sent: Wed, 09 Aug
2006 07:52:00 +0200
Subject: Re: ViewController question


> On 8/8/06, Adrian Mitev <[EMAIL PROTECTED]> wrote:
> >
> > Hi guys! I`ve wrote my own ViewControllerMapper implementation but its
> > not working. I mapped it in the web.xml like that:
> >         <context-param>
> >                 <param-name>
> >                         org.apache.shale.view.VIEW_CONTROLLER_MAPPER
> >                 </param-name>
> >                 <param-value>test.VCMapper</param-value>
> >         </context-param>
> > wrote test.VCMapper class that implements ViewControllerMapper
> >
> > mapViewId method code:
> > public String mapViewId(String viewId) {
> >         log.debug(viewId);
> >         return null;
> > }
> >
> > But the method mapViewId is not invoked. Any suggestions?
> 
> 
> Adrian,
> 
> How recent is the version of Shale you are trying this with?  That's
> relevant because I checked in a change in the way this lookup is handled a
> couple of nights ago, and might have broken something by accident.
> 
> The intent was to deprecate the usage of a context init parameter for this
> purpose (although the context init parameter approach should still work at
> present).  The idea now is that Shale defines a default managed bean for the
> mapper (under a bean name specified by constant
> org.apache.shale.view.faces.VIEW_MAPPER).  If the application doesn't do
> anything, the default standard implementation will be used.  If you want to
> use your implementation instead, you should store an application scope
> attribute under this key (perhaps in a ServletContextListener that is
> invoked at application startup time).  That way, your bean will already
> exist when Shale asks for it, and the default implementation will never be
> invoked.  You'll need a nightly build dated 20060807 or later for this to
> work.  (The context init parameter should still work too for the moment --
> failure of that is a bug that needs to be reported to the issue tracking
> system at http://issues.apache.org/struts/).
> 
> Also, I assume you've checked that your logging system is actually set up to
> output debug level messages, instead of suppress them?  I've been bit by
> that kind of thing more times than I'm willing to admit on a public forum
> :-).
> 
> Craig
> 
> 

Reply via email to