I used the shale-framework-1.0.3-SNAPSHOT, which I downloaded on July 27. I'd be happy to test a newer snapshot or nightly shale-framework build, but I can't find one...
-Jon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, August 21, 2006 2:24 PM To: [email protected] Subject: Re: variable resolver/dependency injection problem On 8/21/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote: > > I believe I have identified the cause of the problem described in my > original post. > > Without the shale-tiger jar in my webapp, the following managed-bean > definition is instantiated successfully: > <managed-bean> > <managed-bean-name>viewIdMenuModel</managed-bean-name> > > <managed-bean-class>org.apache.myfaces.trinidad.model.ViewIdPropertyMe > nu > Model</managed-bean-class> > <managed-bean-scope>none</managed-bean-scope> > <managed-property> > <property-name>viewIdProperty</property-name> > <value>viewId</value> > </managed-property> > <managed-property> > <property-name>wrappedData</property-name> > <value>#{navTreeModel}</value> > </managed-property> > </managed-bean> > > With the shale-tiger jar in my webapp, the wrappedData property above > does not get instantiated successfully. This appears to be because > the shale variable (or property?) resolver resolves the wrappedData > property first, but wrappedData's successful resolution (instantiation > of all properties in its hierarchy) depends on the viewIdProperty > property having a valid value. > > In contrast, the myfaces variable (or property?) resolver resolves the > viewIdProperty property first, so the wrappedData property is > instantiated successfully. > > I switched the order of the property definitions above, and both bean > hierarchies described in my original post are now instantiated > correctly by the shale resolver. > (This bean was from webapp A in my original post.) > > Do the respective variable/property resolvers use different algorithms > to determine the order in which the properties will be resolved? Is > this a well-known caveat that I missed? If not, does it meet the > criteria for a bug? > > -Jon > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Craig McClanahan > Sent: Friday, August 18, 2006 3:08 PM > To: [email protected] > Subject: Re: variable resolver/dependency injection problem > > 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 > This definitely sounds like a bug ... but I do have one question for you. How recent a version of Shale were you using for these tests? I ask this because, last week, I fixed some bugs in how annotated managed beans get themselves initialized, and it might have some bearing on what you are seeing. If you're using code since this weekend or so, then it's definitely a bug that we need to address. Craig
