Re: issue 1826

From: Sheetal Vartak <>
Date: Fri, 15 Oct 2010 12:44:16 -0700

Thanks Ed. I'll work on the specified fix.

On Oct 13, 2010, at 2:04 PM, Ed Burns wrote:

>>>>>> On Tue, 12 Oct 2010 10:51:58 -0700, Sheetal Vartak <> said:
> SV> Can we have something like the following :
> SV> specify an interface for StateHolderSaver in jsf-api. Have multiple
> SV> implementations as required. This way, in UIOutput or other
> SV> components, one can check if the instance is an impl of the
> SV> interface of StateHolderSaver. If so, work on that instance
> SV> accordingly. Would this require a spec change?
> Yes, it would, but more than that I want StateHolderSaver to remain an
> impl detail.
> SV> How will having both artifacts jsf-api and jsf-impl clubbed into one
> SV> solve the problem? It does not seem like a good idea to directly
> SV> access the com.sun.faces classes from jsf-api classes. Should'nt the
> SV> API and impl remain separate? Or am I missing the point?
> The separation between jsf-api and jsf-impl has never been more than
> superficial. I spoke to Jerome about this yesterday and he suggested a
> very simple solution: use the OSGi password facility to allow a
> com.sun.faces class declared in jsf-api to be used in jsf-impl, but not
> violate any TCK issues. He said to look of the string "password" in any
> of the *.bundle packages that dot the GlassFish 3.1 workspace. If you
> care to take this task, we could declare
> com.sun.faces.component.StateHolderSaver as a public class in jsf-api,
> but not have to worry about it leaking through to the "real" public API.
> Ed
> --
> | | office: +1 407 458 0017
> | homepage: |
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: