You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bruno Aranda <br...@gmail.com> on 2007/05/28 18:40:17 UTC
MyFaces 1.2 backwards compatibility
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)?
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
Re: MyFaces 1.2 backwards compatibility
Posted by Bruno Aranda <br...@gmail.com>.
Well, you could use reflection if from the tomahawk you check the
version of JSF being used. But we are talking here about the opposite,
in order to restore the view correctly the JSF implementation needs to
know the version used by the artifact to know which behaviour to
follow... tomahawk is based on 1.1, for instance and myfaces 1.2 needs
to be aware of that...
Cheers,
Bruno
On 28/05/07, Martin Marinschek <ma...@gmail.com> wrote:
> Reflection? Checking for method-names?
>
> regards,
>
> Martin
>
> On 5/28/07, Bruno Aranda <br...@gmail.com> 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)?
> >
> > 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
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: MyFaces 1.2 backwards compatibility
Posted by Martin Marinschek <ma...@gmail.com>.
Reflection? Checking for method-names?
regards,
Martin
On 5/28/07, Bruno Aranda <br...@gmail.com> 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)?
>
> 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: MyFaces 1.2 backwards compatibility
Posted by Adam Winer <aw...@gmail.com>.
Wow, the RI *does* do that. Hadn't noticed that bit of code
before, thanks for pointing it out.
IMO, this is clever code, but not a great direction - I don't
know of wiggle room in the JSF spec for a 1.2 implementation
to sometime behave like 1.1, and it seems like it'd be generally
unpredictable seeing as the order of ViewHandler registration is
unpredictable, and it's far from clear that the "top" ViewHandler
is even really what you care about, seeing as you might
have a 1.2 decorator around a 1.1 view handler.
This also looks like the only case of this particular version
tracking behavior in the RI.
Anyway, I'd say don't bother.
-- Adam
On 5/29/07, Bruno Aranda <br...@gmail.com> wrote:
> 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 <aw...@gmail.com> wrote:
> > On 5/28/07, Bruno Aranda <br...@gmail.com> 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
> > >
> >
>
Re: MyFaces 1.2 backwards compatibility
Posted by Bruno Aranda <br...@gmail.com>.
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 <aw...@gmail.com> wrote:
> On 5/28/07, Bruno Aranda <br...@gmail.com> 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
> >
>
Re: MyFaces 1.2 backwards compatibility
Posted by Adam Winer <aw...@gmail.com>.
On 5/28/07, Bruno Aranda <br...@gmail.com> 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
>