native Spring DelegatingVariableResolver & WSAD 5.1.2

[cquirk]

I hope this post is of some help? I am not sure why the native DelegatingVariableResolver does not work with Websphere's implementation of Java Server Faces but I cannot get an application to load with it? I have tried setting the server to trace and reconfiguring to output more information but I cannot seem to find anything of value. I just know that it tries to set the resolver and then the application bombs after a small wait. No exceptions that I can find are thrown and nothing is readily apparent to me. If there is anyone that has spent the time using this native VariableResolver and got it to work with IBM's implementation of JSF I would appreciate the advice. It seems though that the variable resolver from jsf-spring-2.6 works though.

Thanks.

[cquirk]

After looking at JSF-SPRING and getting it to work with a basic project I added the IBM JSF nature to the project and BAM! JSF-SPRING no longer worked. Fortunately with a tip from IBM I found that the JSF-SPRING's VariableResolver was not returning properly. It was not returning the original variable resolver: original.resolveVariable(facesContext,name)(Variab le Resolver original). So I did a little looking around and read in "Core Java Server Faces" that it is necessary for any Variable-Resolver to return the "Original" VariableResolver if it is not able to resolve the variable.

Well, the JSF-SPRING Variable resolver is complex so I looked back at the Native Spring DelegatingVariableResolver and noticed that it did not Return the original VariableResolver either. So I modified the source code and compiled it and it still did not work. I looked around and noticed that the Class FacesContextUtils was listed as Abstract, which IBM did not seem to like because as soon as I got rid of the Abstract signature the Variable resolver worked. So I am not sure who could make these changes or what process it takes but the following two files need the following changes...

FacesContextUtils.java

public abstract class FacesContextUtils {

should be changed to:

public class FacesContextUtils {

DelegatingVariableResolver.java

public Object resolveVariable(FacesContext facesContext, String name) throws EvaluationException {
		// ask original resolver
                ................
		}
		return null;
	}

should be changed to:

public Object resolveVariable(FacesContext facesContext, String name) throws EvaluationException {
		// ask original resolver
                ................
		}
		return originalVariableResolver.resolveVariable(facesContext,name);;
	}

As well, you could remove the code to ask the original VariableResolver because as I understand it the reason you must return the original VariableResolver is because these things chain together. Thus this would not be necessary but most likely explains why this would work unless someone tried to chain another VariableResolver on.(like IBM does)

Thanks and let me know if you have any more questions.

[Juergen Hoeller]

I don't understand why IBM's JSF implementation complains here: Spring's DelegatingVariableResolver does check the original VariableResolver! It just does so before it looks into the Spring context, to always resolve JSF variables in JSF itself and just consider unresolvable variables as potential Spring beans.

Spring's current implementation should perfectly valid: Even David Geary himself, author of Core JSF, has approved it. Sure, a custom VariableResolver has to ask the original VariableResolver, but it should be free to choose whether it does that before or after its own attempts.

Please double-check the "abstract" issue too: I don't see at all why IBM's JSF implementation can complain about that. A class with static methods only is allowed to be abstract without hassle; we're using this pattern throughout the framework.

JSF-Spring doesn't delegate to the original VariableResolver, AFAIK: It rather reimplements the entire JSF managed bean facility itself. It really should delegate to the original JSF implementation for this, though: That's why we provided our own DelegatingVariableResolver.

Essentially, I think that the bug is on IBM's side, not on ours. Our strategy does work with MyFaces and reportedly also with the latest Sun RI.

Juergen

[cquirk]

From my understanding of the text written by Geary/Horstmann in "Core JavaServer Faces" on page 626 the following: "Since you probably don't want to reimplement the existing lookup rules, you should use the decorator pattern for your own variable resolver. Apply your lookup rules and defer to the original resolver for all other cases.", means that the Spring DelegatingVariableResolver should not return null if it cannot resolve the variable. (i.e. the example on p. 627) It should return the original variable resolver. If this were the case the Spring DelegatingVariableResolver would not need to do a lookup itself, it could defer to what other variable resolvers are available.

But, on the other hand the Specification(jsf-1_0-fr-spec.pdf) says that "This method(public Object resolveVariable(FacesContext context, String name);) resolves the specified variable name, and returns the corresponding
object instance, or null if no such instance can be identified.", which would be exactly what the Spring DelegatingVariableResolver does.

On the other hand IBM claims that all VariableResolvers should be written so that they can "chain" appropriately. I am not sure where they got this term or what it means except that they claimed it was in the specification. I cannot find it myself.

Either way this is what I had to do to be able to use the Spring DelegatingVariableResolver with IBM WSAD 5.1.2's implementation of JSF, potentially in the future their VariableResolver will play nicely with the others.

Thanks for your response and nevermind the "abstract" issue as I am sure it is related to my using these classes outside the spring package.

Thanks.