You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Simon Lessard <si...@gmail.com> on 2007/08/23 16:35:05 UTC

JSF 1.2 API question

Hello all,

Reading the JAF 1.2 API I found the following:
getResourceBundle

public java.util.ResourceBundle *getResourceBundle*(FacesContext
<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/context/FacesContext.html>
ctx,
                                                  java.lang.String name)

Find a ResourceBundle as defined in the application configuration resources
under the specified name. If a ResourceBundle was defined for the name,
return an instance that uses the locale of the current
UIViewRoot<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/component/UIViewRoot.html>
.

The default implementation throws UnsupportedOperationException and is
provided for the sole purpose of not breaking existing applications that
extend this class.

*Returns:*ResourceBundle for the current UIViewRoot, otherwise null *Throws:
* FacesException<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/FacesException.html>-
if a bundle was defined, but not resolvable
java.lang.NullPointerException - if ctx == null || name == null*Since:*1.2 and
in MR 1:
getResourceBundle

public java.util.ResourceBundle *getResourceBundle*(FacesContext
<http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/context/FacesContext.html>
ctx,
                                                  java.lang.String name)

Find a ResourceBundle as defined in the application configuration resources
under the specified name. If a ResourceBundle was defined for the name,
return an instance that uses the locale of the current
UIViewRoot<http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/component/UIViewRoot.html>
.

The default implementation throws UnsupportedOperationException and is
provided for the sole purpose of not breaking existing applications that
extend this class.

*Returns:*ResourceBundle for the current UIViewRoot, otherwise null *Throws:
* FacesException<http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/FacesException.html>-
if a bundle was defined, but not resolvable
java.lang.NullPointerException - if ctx == null || name == null*Since:*1.2
Both are exactly the same. However, I wonder why the doc says the default
implementation provides that method only to not break existing applications
when JSF 1.1 did not even have that method... I really cannot figure that
one out. Can anyone enlighten me? Also, what is the correct way to access
the bundle if not that one? I hope it's not involve using the
ExpressionFactory with #{name} expression.


Regards,

~ Simon

Re: JSF 1.2 API question

Posted by simon <si...@chello.at>.
On Thu, 2007-08-23 at 10:35 -0400, Simon Lessard wrote:
> Hello all,
> 
> Reading the JAF 1.2 API I found the following:
> 
> getResourceBundle
> public java.util.ResourceBundle getResourceBundle(FacesContext ctx,
> 

>         The default implementation throws
>         UnsupportedOperationException and is provided for the sole
>         purpose of not breaking existing applications that extend this
>         class.
>         
> Returns:
>         ResourceBundle for the current UIViewRoot, otherwise null
> Throws:
>         FacesException - if a bundle was defined, but not resolvable
>         java.lang.NullPointerException - if ctx == null || name ==
>         null
> Since:
>         1.2
> 
> Both are exactly the same. However, I wonder why the doc says the
> default implementation provides that method only to not break existing
> applications when JSF 1.1 did not even have that method... I really
> cannot figure that one out. Can anyone enlighten me? 

I think what they are saying here is that they really wanted to add an
abstract method here, forcing all the subclasses to provide an
implementation.

However if they had added an abstract method, then they could have
broken existing code. Suppose someone had subclassed this class in
JSF1.1, then tried to load that binary subclass into memory with the
JSF12 library present. Any attempt to instantiate their class would
fail, because their class is now technically abstract - the ancestor
class has an abstract method that has not been implemented. I'm not
actually sure whether then exception would happen when the constructor
is called, or when the class is loaded into memory, or whether for some
JVMs it would actually work unless someone called the method that
doesn't exist, but regardless you can see that adding an abstract method
to a class is a change that breaks existing code.

The workaround used here is to make sure the method is not abstract, by
providing a dummy implementation that just throws an exception. When
subclasses of the old version are now loaded, they work fine as long as
no-one calls that new method.

However for code that really has been written for use with JSF1.2, the
subclass should have a proper implementation of that new method. And so
you can safely call that method as long as you know the concrete
implementation is not legacy JSF11 code.

Regards,

Simon


Re: JSF 1.2 API question

Posted by Adam Winer <aw...@gmail.com>.
Ah... there's another method you might want to see:

http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/application/Application.html#evaluateExpressionGet(javax.faces.context.FacesContext,%20java.lang.String,%20java.lang.Class)

-- Adam


On 8/24/07, Simon Lessard <si...@gmail.com> wrote:
> Ah, I see! So it's safe to assume that, in a JSF 1.2 environment, all
> implementations will work and not throw an UnsupportedOperationException
> then. I thought it meant that this was an optional operation that wasn't
> certain to succeed.
>
> As for the other part, it's just that I dislike to create ValueExpression in
> Java just to evaluate it right away. I guess I would have been forced to do
> that if the above method was not guaranteed to work.
>
>
> Regards,
>
> ~ Simon
>
>
> On 8/23/07, Adam Winer <aw...@gmail.com> wrote:
> > The idea is to avoid AbstractMethodErrors on pre-existing
> > apps that happen to have a 1.1 Application implementation.
> > You'd still get an UnsupportedErrorException.  The
> > Application implementation provided by a 1.2 implementation
> > has to return a ResourceBundle (or throw an exception).
> >
> > I'm not sure what you mean by "the correct way to
> > access the bundle" - this is the programmatic way,
> > in EL you'd use #{name}.
> >
> > -- Adam
> >
> >
> > On 8/23/07, Simon Lessard <si...@gmail.com> wrote:
> > > Hello all,
> > >
> > > Reading the JAF 1.2 API I found the following:
> > >  getResourceBundle public java.util.ResourceBundle
> > > getResourceBundle(FacesContext ctx,
> > >
> > >  java.lang.String name)
> > >
> > >
> > > Find a ResourceBundle as defined in the application configuration
> resources
> > > under the specified name. If a ResourceBundle was defined for the name,
> > > return an instance that uses the locale of the current UIViewRoot.
> > >
> > > The default implementation throws UnsupportedOperationException and is
> > > provided for the sole purpose of not breaking existing applications that
> > > extend this class.
> > >
> > >  Returns:ResourceBundle for the current UIViewRoot, otherwise null
> Throws:
> > > FacesException - if a bundle was defined, but not resolvable
> > > java.lang.NullPointerException - if ctx == null || name == nullSince:1.2
> and
> > > in MR 1:
> > >  getResourceBundle public java.util.ResourceBundle
> > > getResourceBundle(FacesContext
> > >  ctx,
> > >   java.lang.String name)
> > >
> > >
> > > Find a ResourceBundle as defined in the application configuration
> resources
> > > under the specified name. If a ResourceBundle was defined for the name,
> > > return an instance that uses the locale of the current UIViewRoot .
> > >
> > > The default implementation throws UnsupportedOperationException and is
> > > provided for the sole purpose of not breaking existing applications that
> > > extend this class.
> > >
> > >  Returns:ResourceBundle for the current UIViewRoot, otherwise null
> Throws:
> > > FacesException - if a bundle was defined, but not resolvable
> > > java.lang.NullPointerException - if ctx == null || name == nullSince:1.2
> > > Both are exactly the same. However, I wonder why the doc says the
> default
> > > implementation provides that method only to not break existing
> applications
> > > when JSF 1.1 did not even have that method... I really cannot figure
> that
> > > one out. Can anyone enlighten me? Also, what is the correct way to
> access
> > > the bundle if not that one? I hope it's not involve using the
> > > ExpressionFactory with #{name} expression.
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > >
> >
>
>

Re: JSF 1.2 API question

Posted by Simon Lessard <si...@gmail.com>.
Ah, I see! So it's safe to assume that, in a JSF 1.2 environment, all
implementations will work and not throw an UnsupportedOperationException
then. I thought it meant that this was an optional operation that wasn't
certain to succeed.

As for the other part, it's just that I dislike to create ValueExpression in
Java just to evaluate it right away. I guess I would have been forced to do
that if the above method was not guaranteed to work.


Regards,

~ Simon

On 8/23/07, Adam Winer <aw...@gmail.com> wrote:
>
> The idea is to avoid AbstractMethodErrors on pre-existing
> apps that happen to have a 1.1 Application implementation.
> You'd still get an UnsupportedErrorException.  The
> Application implementation provided by a 1.2 implementation
> has to return a ResourceBundle (or throw an exception).
>
> I'm not sure what you mean by "the correct way to
> access the bundle" - this is the programmatic way,
> in EL you'd use #{name}.
>
> -- Adam
>
>
> On 8/23/07, Simon Lessard <si...@gmail.com> wrote:
> > Hello all,
> >
> > Reading the JAF 1.2 API I found the following:
> >  getResourceBundle public java.util.ResourceBundle
> > getResourceBundle(FacesContext ctx,
> >
> >  java.lang.String name)
> >
> >
> > Find a ResourceBundle as defined in the application configuration
> resources
> > under the specified name. If a ResourceBundle was defined for the name,
> > return an instance that uses the locale of the current UIViewRoot.
> >
> > The default implementation throws UnsupportedOperationException and is
> > provided for the sole purpose of not breaking existing applications that
> > extend this class.
> >
> >  Returns:ResourceBundle for the current UIViewRoot, otherwise null
> Throws:
> > FacesException - if a bundle was defined, but not resolvable
> > java.lang.NullPointerException - if ctx == null || name == nullSince:1.2and
> > in MR 1:
> >  getResourceBundle public java.util.ResourceBundle
> > getResourceBundle(FacesContext
> >  ctx,
> >  java.lang.String name)
> >
> >
> > Find a ResourceBundle as defined in the application configuration
> resources
> > under the specified name. If a ResourceBundle was defined for the name,
> > return an instance that uses the locale of the current UIViewRoot .
> >
> > The default implementation throws UnsupportedOperationException and is
> > provided for the sole purpose of not breaking existing applications that
> > extend this class.
> >
> >  Returns:ResourceBundle for the current UIViewRoot, otherwise null
> Throws:
> > FacesException - if a bundle was defined, but not resolvable
> > java.lang.NullPointerException - if ctx == null || name == nullSince:1.2
> > Both are exactly the same. However, I wonder why the doc says the
> default
> > implementation provides that method only to not break existing
> applications
> > when JSF 1.1 did not even have that method... I really cannot figure
> that
> > one out. Can anyone enlighten me? Also, what is the correct way to
> access
> > the bundle if not that one? I hope it's not involve using the
> > ExpressionFactory with #{name} expression.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
>

Re: JSF 1.2 API question

Posted by Adam Winer <aw...@gmail.com>.
The idea is to avoid AbstractMethodErrors on pre-existing
apps that happen to have a 1.1 Application implementation.
You'd still get an UnsupportedErrorException.  The
Application implementation provided by a 1.2 implementation
has to return a ResourceBundle (or throw an exception).

I'm not sure what you mean by "the correct way to
access the bundle" - this is the programmatic way,
in EL you'd use #{name}.

-- Adam


On 8/23/07, Simon Lessard <si...@gmail.com> wrote:
> Hello all,
>
> Reading the JAF 1.2 API I found the following:
>  getResourceBundle public java.util.ResourceBundle
> getResourceBundle(FacesContext ctx,
>
>  java.lang.String name)
>
>
> Find a ResourceBundle as defined in the application configuration resources
> under the specified name. If a ResourceBundle was defined for the name,
> return an instance that uses the locale of the current UIViewRoot.
>
> The default implementation throws UnsupportedOperationException and is
> provided for the sole purpose of not breaking existing applications that
> extend this class.
>
>  Returns:ResourceBundle for the current UIViewRoot, otherwise null Throws:
> FacesException - if a bundle was defined, but not resolvable
> java.lang.NullPointerException - if ctx == null || name == nullSince:1.2 and
> in MR 1:
>  getResourceBundle public java.util.ResourceBundle
> getResourceBundle(FacesContext
>  ctx,
>  java.lang.String name)
>
>
> Find a ResourceBundle as defined in the application configuration resources
> under the specified name. If a ResourceBundle was defined for the name,
> return an instance that uses the locale of the current UIViewRoot .
>
> The default implementation throws UnsupportedOperationException and is
> provided for the sole purpose of not breaking existing applications that
> extend this class.
>
>  Returns:ResourceBundle for the current UIViewRoot, otherwise null Throws:
> FacesException - if a bundle was defined, but not resolvable
> java.lang.NullPointerException - if ctx == null || name == nullSince:1.2
> Both are exactly the same. However, I wonder why the doc says the default
> implementation provides that method only to not break existing applications
> when JSF 1.1 did not even have that method... I really cannot figure that
> one out. Can anyone enlighten me? Also, what is the correct way to access
> the bundle if not that one? I hope it's not involve using the
> ExpressionFactory with #{name} expression.
>
>
> Regards,
>
> ~ Simon
>
>