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.ViewIdPropertyMenu
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: user@shale.apache.org
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
