On 8/18/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote:
I have two hierarchies of managed beans to integrate in a JSF webapp (C). One comes from a webapp using myfaces+trinidad (A) and the other comes from a webapp using myfaces+shale (B). As separate webapps, each one's bean are initialized successfully. A uses org.apache.myfaces.el.VariableResolverImpl and B uses org.apache.shale.tiger.faces.VariableResolverImpl to do the respective jobs. Together in webapp C, the presence or absence of the shale-tiger jar determines which set of beans is instantiated correctly, but I can't get them both. A's beans initialize correctly w/o the shale-tiger jar or B's beans initialize correctly with it. I (sort of) understand why B's beans require the shale-tiger jar's variable resolver (because an underlying class uses generics), but I can't figure out why A's beans do not initialize properly with the shale-tiger jar present in my webapp. Is this a known issue with a solution? I'm using the shale-framework-1.0.3-SNAPSHOT downloaded on July 27 and myfaces-*-1.1.5-SNAPSHOT from August 1. I can provide the gory faces-config.xml details and respective exceptions/warnings if that will help, but I thought that would be a waste of time and space if this is a known problem with a solution. Thanks. -Jon The combination you describe is, in theory, supposed to work, but I
haven't explicitly tested it. However, this will only work if *both* custom variable resolvers follow the rule "create the new bean if *I* know how to do so; otherwise delegate to the previously registered variable resolver". That way, everything should work no matter which order the variable resolvers actually get registered in. The shale-tiger resolver behaves like this ... will need to look at the other ones that are involved. It would be super helpful if someone could create a small test app illustrating this, and attach it to a bug report against Shale ( http://issues.apache.org/struts). Craig
