>>>>> On Tue, 12 Oct 2010 10:51:58 -0700, Sheetal Vartak <sheetal.vartak_at_oracle.com> 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
--
| ed.burns_at_sun.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/