Re: issue 1826

From: Ed Burns <>
Date: Wed, 13 Oct 2010 14:04:19 -0700

>>>>> 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.


|        | office: +1 407 458 0017
| homepage:               |