But then why the RI uses it to fall into old view and state management behaviour in case of a postback if the artifact is implemented using <1.2. In our case, without that, in case of postback and the view being returned is null we throw a ViewExpiredException. The RI, in the same case, creates a new view.
Am I missing something? Cheers, Buno On 29/05/07, Adam Winer <[EMAIL PROTECTED]> wrote:
On 5/28/07, Bruno Aranda <[EMAIL PROTECTED]> wrote: > Hi, > > For backwards compatibility, when restoring the view we need to know > if older (<1.2) ViewHandler and StateManager are used in order to fall > into 1.1 behaviour if they are older. The RI checks the faces-config > file of the artifact [1], inferring the version from the XML grammar > (name of the DTD or schema). If it is not the 1.2 schema, the > behaviour is the 1.1 one. Do you have a better idea on how to check > the version used in the implementation of an artifact (e.g. tomahawk)? AFAIK, that is not the case: the faces-config version is only consulted to determine how to parse the faces-config file, and has no runtime effect other than that. -- Adam > > The resulting error of not tracking the version can be observed when > running the sandbox with myfaces 1.2, in the convertNumber example. > > cd tomahawk/sandbox/examples > mvn -PjettyConfig clean jetty:run -Djsf=12 > > With the RI (-Djsf=ri12) this does not happen. > > Cheers, > > Bruno > > [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=149 >
