dev@javaserverfaces.java.net

Re: JSF 2.2 FlashELResolver direct usage of ELFlash

From: Ken Finnigan <kfinniga_at_redhat.com>
Date: Tue, 16 Jul 2013 09:03:23 -0400 (EDT)

Hi Neil,

My main concern was around implementing a class that extended the FlashWrapper and relied on the FlashFactory to return it, as the FlashELResolver would not use that instance for that particular call.

My initial thought is that if there is the possibility to create a class that extends FlashWrapper, then it should be used wherever a flash needs to be used, unless what needs to be done with the flash is completely implementation specific and there is absolutely no way someone would need to change its behavior when extending FlashWrapper.

In this case the value set on ELFlash directly is then used as part of the get() call, and I think it would be a mistake to assume that anyone extending FlashWrapper would call super.get() before/during whatever they need to change in the implementation of their get() implementation.

I'm not sure whether the solution is to move the method from ELFlash to Flash, so that FlashWrapper can modify its behavior if needed and FlashELResolver can use the flash retrieved from the factory, or whether to investigate if the value being set directly on ELFlash has any impact whatsoever in how it behaves (at the moment I don't personally think it does).

Ken

----- Original Message -----

> From: "Neil Griffin" <neil.griffin_at_portletfaces.org>
> To: dev_at_javaserverfaces.java.net
> Sent: Monday, July 15, 2013 4:04:10 PM
> Subject: Re: JSF 2.2 FlashELResolver direct usage of ELFlash

> Hi Ken,

> I took a look at the Mojarra 2.2 FlashELResolver and ELFlash classes and I
> definitely see the concerns you have.

> This is a tough one, because the Flash API is pretty limited. I guess I can't
> blame the Mojarra folks for putting implementation-specific stuff inside of
> the FlashELResolver, since technically, the FlashELResolver class is part of
> the Mojarra implementation.

> If it were necessary to develop a full-blown FlashCustomImpl (which is a lot
> of development work), then I suppose creating a custom Flash ELResolver
> wouldn't be that much more work. It could simply live in the ELResolver
> chain of delegation earlier than the Mojarra one.

> However, if developing class with the new JSF 2.2 FlashWrapper, then it might
> be possible to have the FlashFactory return something that simply decorates
> the Mojarra ELFlash where necessary. I'm not 100% sure, but I think that
> might be enough in most cases.

> Thoughts?

> Neil

> On Jul 8, 2013, at 10:45 AM, Ken Finnigan < kfinniga_at_redhat.com > wrote:

> > All,
>

> > On line 260 of FlashELResolver, in Mojarra 2.2.0, it makes a direct call to
> > ELFlash to set a flag.
>

> > This prevents a developer from developing their own Flash implementation,
> > that can be retrieved from the FlashFactory, and
>
> > have it function as expected within the FlashELResolver.
>

> > On closer inspection of the flag being set on ELFlash, it appears to only
> > be
> > used within the ELFlash.get() method. However, the structure of the code
> > within that method means
>
> > that whether the flag is set or not, the result of the get() method will be
> > identical, as both situations result in a call to ELFlash.
> > getPhaseMapForReading().get(key).
>

> > I have a two fold question around this:
>

> > 1) Can we remove the direct usage of ELFlash from FlashELFactory?
>

> > 2) And is the best way to remove that direct usage by simply removing the
> > setKeepFlag() method, and associated get and clear, from ELFlash? As
> > opposed
> > to adding methods onto Flash.
>

> > Regards
>
> > Ken Finnigan
>

> > ========================
>
> > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
>