shale-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: ViewController question
Date Wed, 09 Aug 2006 05:52:00 GMT
On 8/8/06, Adrian Mitev <amittev@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message