You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Ken Weiner <kw...@gmail.com> on 2005/08/23 22:34:43 UTC
Why not reuse jsf-api.jar from Sun?
I am confused about the nature of the javax.faces sources that are
included in the MyFaces jar file. They appear to have been written as
part of the MyFaces project. Sun includes alternative versions of the
javax.faces classes in its RI distribution, placing those classes in a
seperate jar file: jsf-api.jar. Why doesn't MyFaces reuse the
jsf-api.jar from Sun? Shouldn't there only be one version of the API
classes, with Sun RI, MyFaces, and other supplying only the "impl" of
the API?
The way it is now, if I were to write my own, let's say
MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my
components could break if I switch between the RI and MyFaces. I hope
someone can help me understand the nature of the JSF spec, API
classes, and various implementations. Thanks.
-Ken
Re: Why not reuse jsf-api.jar from Sun?
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, Ken Weiner <kw...@gmail.com> wrote:
> > Trust me ... you don't want to read all the EG threads on that topic
> > :-). But the short answer is, consider what happens in a future
> > version of JSF, when (for good reason) a new method signature is added
> > to the Renderer API. If it were an interface, you've just broken
> > every current implementation in the world. As an abstract base class,
> > you can add a default implementation that mirrors the previous
> > behavior, so the only potential breakage is if an implementation had
> > their own version of that very same method signature.
>
> It seems like you could get the best of both worlds with an interface
> and an abstract class that implements it. Since this has been
> well-vetted by the EG, I'll accept the reasons it was done without an
> interface.
>
That certainly would have been possible, and would have broken fewer
people (only those who chose to directly implement the interface
instead of extending the base class), but that wasn't the choice we
ended up making.
> > An actual instance, of course, must be of a concrete class that can be
> > instantiated. But whether that concrete class extends an abstract
> > base class, or implements an interface, is irrelevant to how many
> > copies there are. In this particular case, it simply has to be that
> > "instanceof Renderer" returns true, since the JSF implementation is
> > going to cast it to this before calling its methods.
>
> So, it sounds like the JSF implementation *does* get to choose whether
> or not javax.faces.render.Renderer is an abstract class or in
> interface since an "instanceof Renderer" check could be done for an
> instance of either. Am I understanding correctly?
>
No. Part of the compatibility tests for a JCP spec is a "signature
test" that ensures that every public class (or interface) in the javax
namespace has *exactly* the correct nature (public class, abstract
public class, interface, etc.) as well as *exactly* the correct public
and protected method/variable signatures. If different
implementations were allowed to choose interface versus base class
(i.e. we threw away the signature tests), then your Renderer
implementation would not be portable -- because the inheritance
hierarchy embedded in your compiled class would be different.
> >
> > Craig
> >
>
Craig
Re: Why not reuse jsf-api.jar from Sun?
Posted by Ken Weiner <kw...@gmail.com>.
> Trust me ... you don't want to read all the EG threads on that topic
> :-). But the short answer is, consider what happens in a future
> version of JSF, when (for good reason) a new method signature is added
> to the Renderer API. If it were an interface, you've just broken
> every current implementation in the world. As an abstract base class,
> you can add a default implementation that mirrors the previous
> behavior, so the only potential breakage is if an implementation had
> their own version of that very same method signature.
It seems like you could get the best of both worlds with an interface
and an abstract class that implements it. Since this has been
well-vetted by the EG, I'll accept the reasons it was done without an
interface.
> An actual instance, of course, must be of a concrete class that can be
> instantiated. But whether that concrete class extends an abstract
> base class, or implements an interface, is irrelevant to how many
> copies there are. In this particular case, it simply has to be that
> "instanceof Renderer" returns true, since the JSF implementation is
> going to cast it to this before calling its methods.
So, it sounds like the JSF implementation *does* get to choose whether
or not javax.faces.render.Renderer is an abstract class or in
interface since an "instanceof Renderer" check could be done for an
instance of either. Am I understanding correctly?
>
> Craig
>
Re: Why not reuse jsf-api.jar from Sun?
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, Ken Weiner <kw...@gmail.com> wrote:
> Martin, yes, I will file this as an issue in Jira and reference this
> email thread.
>
> Craig, thank you so much for your response. I now understand the
> relationship between a java spec and the physical API source code much
> better. You brought up an interesting point about JSF being different
> in that there is more executable code than in other frameworks. What
> was the reason that classes like javax.faces.render.Renderer were
> defined as abstract classes rather than interfaces?
Trust me ... you don't want to read all the EG threads on that topic
:-). But the short answer is, consider what happens in a future
version of JSF, when (for good reason) a new method signature is added
to the Renderer API. If it were an interface, you've just broken
every current implementation in the world. As an abstract base class,
you can add a default implementation that mirrors the previous
behavior, so the only potential breakage is if an implementation had
their own version of that very same method signature.
Breakage like this is not totally prohibited -- consider what has
happened in servlet (when new methods get added to the
HttpServletRequest interface) or JDBC (where there has been lots of
changes over the versions). But that kind of breakage affects
relatively small audiences (app server and database vendors) versus
the potential for breaking every JSF component written by every
component developer in the world.
> In Section 8.2,
> the spec refers to what an "instance" of Renderer should do. Does the
> word "instance" imply a class rather than interface or is it up to the
> implementation?
No, "instance" is used in the O-O sense of the word, referring to how
many objects are instantiated into the JVM's memory. In JSF, a
Renderer is an application-level singleton that is shared by all the
instances of the components (just like a Servlet is an application
level singleton that is shared by all requests mapped to the same URI
pattern). With UIComponents, for example, there is a separate object
instance for every component on your page -- but if you have four text
fields, the four component instances will all share the same renderer
instance.
An actual instance, of course, must be of a concrete class that can be
instantiated. But whether that concrete class extends an abstract
base class, or implements an interface, is irrelevant to how many
copies there are. In this particular case, it simply has to be that
"instanceof Renderer" returns true, since the JSF implementation is
going to cast it to this before calling its methods.
>
> -Ken
>
Craig
Re: Why not reuse jsf-api.jar from Sun?
Posted by Ken Weiner <kw...@gmail.com>.
Martin, yes, I will file this as an issue in Jira and reference this
email thread.
Craig, thank you so much for your response. I now understand the
relationship between a java spec and the physical API source code much
better. You brought up an interesting point about JSF being different
in that there is more executable code than in other frameworks. What
was the reason that classes like javax.faces.render.Renderer were
defined as abstract classes rather than interfaces? In Section 8.2,
the spec refers to what an "instance" of Renderer should do. Does the
word "instance" imply a class rather than interface or is it up to the
implementation?
-Ken
On 8/24/05, Martin Marinschek <ma...@gmail.com> wrote:
> Ken,
>
> can I ask you to file that as a jira-issue?
>
> If possible, include both yours and Craigs evaluation of the problem
> as comments.
>
> regards,
>
> Martin
>
> On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> > On 8/23/05, Ken Weiner <kw...@gmail.com> wrote:
> > > Thanks for the replies. Do other specs from JCP behave this way?
> >
> > Yes, they *all* do. An implementation of a JCP spec is required to
> > provide the javax.foo classes, as well as whatever implementation
> > classes they require to conform to the spec requirements. The primary
> > difference for JSF is there is relatively more executable code in the
> > javax.faces classes, rather than just specifying APIs. But the
> > compatibility test that MyFaces will be required to pass include
> > signature tests that ensure any given implementation implements
> > *exactly* the set of public and protected methods (and variables if
> > any) as is required by the spec.
> >
> > > don't remember ever seeing another situation where there are multiple
> > > versions of the same exact (same fully-qualified name) class.
> >
> > Question -- where do you get your definition of javax.servlet.Servlet
> > when you compile your webapp? Answer ... that is totally up to the
> > server implementation you are using -- they do *not* all necessarily
> > share the same physical source code (although such sharing is not
> > uncommon either -- lots of app server vendors use the same
> > javax.servlet classes that Tomcat does, for example, because they are
> > available under the Apache license).
> >
> > The same principle applies to all of the JCP specs.
> >
> > > Here is an example of how my component would break if I switched
> > > implementations:
> > >
> > > Let's say I am coding a component that has children components. My
> > > component extends javax.faces.render.Renderer. If I am using the RI,
> > > I may be tempted to accept (not override) the implementation of
> > > Renderer.encodeChildren() which simply iterates thought the children
> > > and renders them as follows:
> > >
> > > public void encodeChildren(FacesContext context, UIComponent component)
> > > throws IOException {
> > > if (context == null || component == null) {
> > > throw new NullPointerException();
> > > }
> > > Iterator kids = component.getChildren().iterator();
> > > while (kids.hasNext()) {
> > > UIComponent kid = (UIComponent) kids.next();
> > > kid.encodeBegin(context);
> > > if (kid.getRendersChildren()) {
> > > kid.encodeChildren(context);
> > > }
> > > kid.encodeEnd(context);
> > > }
> > > }
> > >
> > > Now if I switch to MyFaces, none of my children would render because
> > > the MyFaces version of javax.faces.render.Renderer.encodeChildren()
> > > does not render the children. It looks like this:
> > >
> > > public void encodeChildren(FacesContext context, UIComponent component)
> > > throws IOException
> > > {
> > > if (context == null) throw new NullPointerException("context");
> > > if (component == null) throw new NullPointerException("component");
> > > }
> > >
> > > So if I understand things correctly, my component would essentially
> > > break because none of its children would render with MyFaces. Does
> > > that make sense?
> > >
> >
> > There are a couple bunch of overlapping questions here.
> >
> > * Does the spec require a particular behavior of this method? If so,
> > then an implementation that doesn't follow those requirements is
> > totally broken, and should not be used until it is fixed.
> >
> > * Do the compatibility tests actually test that particular asserion?
> > This will vary by assertion (like any other piece of software, the
> > TCK tests are limited by how much resource can be devoted to
> > creating them), so you cannot expect 100% coverage of even the
> > testable assertions. But, even if an assertion is not tested,
> > failure to conform to the requirements means the implementation
> > is broken (and, to be fair, the MyFaces folks will go out of their way
> > to ensure compatibility with the spec requirements).
> >
> > * Does a particular implementation (either the RI or MyFaces in this case)
> > do something *not* required by the spec? That's also perfectly legal
> > as long as they don't violate any of the spec requirements in doing so.
> > However, apps that depend on that behavior are locking themselves
> > in to that particular implementation.
> >
> > Going back to the servlet API example above, how do *you* know that
> > your container's implementation of
> > HttpServletRequest.getSession(boolean) does the right thing? Only
> > because (a) the implementations that matter have all been tested
> > against the servlet API's tests, and (b) the community considers
> > compatibility with the specs important enough to insist that their
> > vendors conform. Note that this is true regardless of whether the
> > implementation class is a javax.foo class provided by the server, or
> > some internal com.foo class that implements a standard interface.
> >
> > > I realize I could override the encodeChildren() method to be safe, but
> > > don't you agree that it would be easy for someone to fall into a trap?
> > > Maybe, in this case, one of the implementations is not adhering to
> > > the spec.
> >
> > To the specific question on Renderer.encodeChildren, the requirements
> > are laid out in Section 8.2 of the spec (which references section
> > 3.1.12 for the description of the corresponding methods on
> > UIComponent, and in the RI javadocs, which are (by reference)
> > incorporated into the JSF spec. In 3.1.12 we read that
> > encodeChildren() is called only if the component's rendersChildren()
> > returns true, and is responsible for "creating the response data ...
> > corresponding to this component's children." If the MyFaces
> > implementation in UIComponentBase does not do that, it's broken and
> > needs to be fixed.
> >
> > We get a more explicit indication of the *required* functionality by
> > reading the Javadocs for UIComponent.encodeChildren():
> >
> > If our "rendered" property is "true", render the child
> > UIComponents of this UIComponent. This method
> > will only be called if the "rendersChildren" property
> > is "true".
> >
> > Seems pretty clear cut, right? An implementation either conforms to
> > the requirements or it doesn't. Implementations that don't need bug
> > reports filed against them in the areas of non-conformance, so that it
> > can be fixed.
> >
> > To be fair, the MyFaces developers have not yet been able to run the
> > TCK tests of the JSF spec against their implementation, so haven't
> > gotten the benefit of finding the issues that the tests will point
> > out. There is an ongoing negotiation to license the TCK to Apache
> > (using the scholarship characteristic of Apache for which Sun (as the
> > TCK developer in this partiular case) uses to make TCKs available at
> > no cost to qualified non-profits). Once that process is completed,
> > I'm sure a number of compliance issues will surface and be quickly
> > fixed.
> >
> > But, for you as an application developer -- you should count on *only*
> > the assertions described in the spec, and you should insist that your
> > JSF implementation conform to those assertions. Reliance on any
> > non-specified behavior (of either MyFaces or the RI, in this
> > particular scenario) risks making your application non-portable.
> >
> > >
> > > -Ken
> > >
> >
> > Craig McClanahan
> > (Co-Spec Lead, JSF 1.0)
> >
>
>
> --
Re: Why not reuse jsf-api.jar from Sun?
Posted by Martin Marinschek <ma...@gmail.com>.
Ken,
can I ask you to file that as a jira-issue?
If possible, include both yours and Craigs evaluation of the problem
as comments.
regards,
Martin
On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 8/23/05, Ken Weiner <kw...@gmail.com> wrote:
> > Thanks for the replies. Do other specs from JCP behave this way?
>
> Yes, they *all* do. An implementation of a JCP spec is required to
> provide the javax.foo classes, as well as whatever implementation
> classes they require to conform to the spec requirements. The primary
> difference for JSF is there is relatively more executable code in the
> javax.faces classes, rather than just specifying APIs. But the
> compatibility test that MyFaces will be required to pass include
> signature tests that ensure any given implementation implements
> *exactly* the set of public and protected methods (and variables if
> any) as is required by the spec.
>
> > don't remember ever seeing another situation where there are multiple
> > versions of the same exact (same fully-qualified name) class.
>
> Question -- where do you get your definition of javax.servlet.Servlet
> when you compile your webapp? Answer ... that is totally up to the
> server implementation you are using -- they do *not* all necessarily
> share the same physical source code (although such sharing is not
> uncommon either -- lots of app server vendors use the same
> javax.servlet classes that Tomcat does, for example, because they are
> available under the Apache license).
>
> The same principle applies to all of the JCP specs.
>
> > Here is an example of how my component would break if I switched
> > implementations:
> >
> > Let's say I am coding a component that has children components. My
> > component extends javax.faces.render.Renderer. If I am using the RI,
> > I may be tempted to accept (not override) the implementation of
> > Renderer.encodeChildren() which simply iterates thought the children
> > and renders them as follows:
> >
> > public void encodeChildren(FacesContext context, UIComponent component)
> > throws IOException {
> > if (context == null || component == null) {
> > throw new NullPointerException();
> > }
> > Iterator kids = component.getChildren().iterator();
> > while (kids.hasNext()) {
> > UIComponent kid = (UIComponent) kids.next();
> > kid.encodeBegin(context);
> > if (kid.getRendersChildren()) {
> > kid.encodeChildren(context);
> > }
> > kid.encodeEnd(context);
> > }
> > }
> >
> > Now if I switch to MyFaces, none of my children would render because
> > the MyFaces version of javax.faces.render.Renderer.encodeChildren()
> > does not render the children. It looks like this:
> >
> > public void encodeChildren(FacesContext context, UIComponent component)
> > throws IOException
> > {
> > if (context == null) throw new NullPointerException("context");
> > if (component == null) throw new NullPointerException("component");
> > }
> >
> > So if I understand things correctly, my component would essentially
> > break because none of its children would render with MyFaces. Does
> > that make sense?
> >
>
> There are a couple bunch of overlapping questions here.
>
> * Does the spec require a particular behavior of this method? If so,
> then an implementation that doesn't follow those requirements is
> totally broken, and should not be used until it is fixed.
>
> * Do the compatibility tests actually test that particular asserion?
> This will vary by assertion (like any other piece of software, the
> TCK tests are limited by how much resource can be devoted to
> creating them), so you cannot expect 100% coverage of even the
> testable assertions. But, even if an assertion is not tested,
> failure to conform to the requirements means the implementation
> is broken (and, to be fair, the MyFaces folks will go out of their way
> to ensure compatibility with the spec requirements).
>
> * Does a particular implementation (either the RI or MyFaces in this case)
> do something *not* required by the spec? That's also perfectly legal
> as long as they don't violate any of the spec requirements in doing so.
> However, apps that depend on that behavior are locking themselves
> in to that particular implementation.
>
> Going back to the servlet API example above, how do *you* know that
> your container's implementation of
> HttpServletRequest.getSession(boolean) does the right thing? Only
> because (a) the implementations that matter have all been tested
> against the servlet API's tests, and (b) the community considers
> compatibility with the specs important enough to insist that their
> vendors conform. Note that this is true regardless of whether the
> implementation class is a javax.foo class provided by the server, or
> some internal com.foo class that implements a standard interface.
>
> > I realize I could override the encodeChildren() method to be safe, but
> > don't you agree that it would be easy for someone to fall into a trap?
> > Maybe, in this case, one of the implementations is not adhering to
> > the spec.
>
> To the specific question on Renderer.encodeChildren, the requirements
> are laid out in Section 8.2 of the spec (which references section
> 3.1.12 for the description of the corresponding methods on
> UIComponent, and in the RI javadocs, which are (by reference)
> incorporated into the JSF spec. In 3.1.12 we read that
> encodeChildren() is called only if the component's rendersChildren()
> returns true, and is responsible for "creating the response data ...
> corresponding to this component's children." If the MyFaces
> implementation in UIComponentBase does not do that, it's broken and
> needs to be fixed.
>
> We get a more explicit indication of the *required* functionality by
> reading the Javadocs for UIComponent.encodeChildren():
>
> If our "rendered" property is "true", render the child
> UIComponents of this UIComponent. This method
> will only be called if the "rendersChildren" property
> is "true".
>
> Seems pretty clear cut, right? An implementation either conforms to
> the requirements or it doesn't. Implementations that don't need bug
> reports filed against them in the areas of non-conformance, so that it
> can be fixed.
>
> To be fair, the MyFaces developers have not yet been able to run the
> TCK tests of the JSF spec against their implementation, so haven't
> gotten the benefit of finding the issues that the tests will point
> out. There is an ongoing negotiation to license the TCK to Apache
> (using the scholarship characteristic of Apache for which Sun (as the
> TCK developer in this partiular case) uses to make TCKs available at
> no cost to qualified non-profits). Once that process is completed,
> I'm sure a number of compliance issues will surface and be quickly
> fixed.
>
> But, for you as an application developer -- you should count on *only*
> the assertions described in the spec, and you should insist that your
> JSF implementation conform to those assertions. Reliance on any
> non-specified behavior (of either MyFaces or the RI, in this
> particular scenario) risks making your application non-portable.
>
> >
> > -Ken
> >
>
> Craig McClanahan
> (Co-Spec Lead, JSF 1.0)
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Why not reuse jsf-api.jar from Sun?
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, Ken Weiner <kw...@gmail.com> wrote:
> Thanks for the replies. Do other specs from JCP behave this way?
Yes, they *all* do. An implementation of a JCP spec is required to
provide the javax.foo classes, as well as whatever implementation
classes they require to conform to the spec requirements. The primary
difference for JSF is there is relatively more executable code in the
javax.faces classes, rather than just specifying APIs. But the
compatibility test that MyFaces will be required to pass include
signature tests that ensure any given implementation implements
*exactly* the set of public and protected methods (and variables if
any) as is required by the spec.
> don't remember ever seeing another situation where there are multiple
> versions of the same exact (same fully-qualified name) class.
Question -- where do you get your definition of javax.servlet.Servlet
when you compile your webapp? Answer ... that is totally up to the
server implementation you are using -- they do *not* all necessarily
share the same physical source code (although such sharing is not
uncommon either -- lots of app server vendors use the same
javax.servlet classes that Tomcat does, for example, because they are
available under the Apache license).
The same principle applies to all of the JCP specs.
> Here is an example of how my component would break if I switched
> implementations:
>
> Let's say I am coding a component that has children components. My
> component extends javax.faces.render.Renderer. If I am using the RI,
> I may be tempted to accept (not override) the implementation of
> Renderer.encodeChildren() which simply iterates thought the children
> and renders them as follows:
>
> public void encodeChildren(FacesContext context, UIComponent component)
> throws IOException {
> if (context == null || component == null) {
> throw new NullPointerException();
> }
> Iterator kids = component.getChildren().iterator();
> while (kids.hasNext()) {
> UIComponent kid = (UIComponent) kids.next();
> kid.encodeBegin(context);
> if (kid.getRendersChildren()) {
> kid.encodeChildren(context);
> }
> kid.encodeEnd(context);
> }
> }
>
> Now if I switch to MyFaces, none of my children would render because
> the MyFaces version of javax.faces.render.Renderer.encodeChildren()
> does not render the children. It looks like this:
>
> public void encodeChildren(FacesContext context, UIComponent component)
> throws IOException
> {
> if (context == null) throw new NullPointerException("context");
> if (component == null) throw new NullPointerException("component");
> }
>
> So if I understand things correctly, my component would essentially
> break because none of its children would render with MyFaces. Does
> that make sense?
>
There are a couple bunch of overlapping questions here.
* Does the spec require a particular behavior of this method? If so,
then an implementation that doesn't follow those requirements is
totally broken, and should not be used until it is fixed.
* Do the compatibility tests actually test that particular asserion?
This will vary by assertion (like any other piece of software, the
TCK tests are limited by how much resource can be devoted to
creating them), so you cannot expect 100% coverage of even the
testable assertions. But, even if an assertion is not tested,
failure to conform to the requirements means the implementation
is broken (and, to be fair, the MyFaces folks will go out of their way
to ensure compatibility with the spec requirements).
* Does a particular implementation (either the RI or MyFaces in this case)
do something *not* required by the spec? That's also perfectly legal
as long as they don't violate any of the spec requirements in doing so.
However, apps that depend on that behavior are locking themselves
in to that particular implementation.
Going back to the servlet API example above, how do *you* know that
your container's implementation of
HttpServletRequest.getSession(boolean) does the right thing? Only
because (a) the implementations that matter have all been tested
against the servlet API's tests, and (b) the community considers
compatibility with the specs important enough to insist that their
vendors conform. Note that this is true regardless of whether the
implementation class is a javax.foo class provided by the server, or
some internal com.foo class that implements a standard interface.
> I realize I could override the encodeChildren() method to be safe, but
> don't you agree that it would be easy for someone to fall into a trap?
> Maybe, in this case, one of the implementations is not adhering to
> the spec.
To the specific question on Renderer.encodeChildren, the requirements
are laid out in Section 8.2 of the spec (which references section
3.1.12 for the description of the corresponding methods on
UIComponent, and in the RI javadocs, which are (by reference)
incorporated into the JSF spec. In 3.1.12 we read that
encodeChildren() is called only if the component's rendersChildren()
returns true, and is responsible for "creating the response data ...
corresponding to this component's children." If the MyFaces
implementation in UIComponentBase does not do that, it's broken and
needs to be fixed.
We get a more explicit indication of the *required* functionality by
reading the Javadocs for UIComponent.encodeChildren():
If our "rendered" property is "true", render the child
UIComponents of this UIComponent. This method
will only be called if the "rendersChildren" property
is "true".
Seems pretty clear cut, right? An implementation either conforms to
the requirements or it doesn't. Implementations that don't need bug
reports filed against them in the areas of non-conformance, so that it
can be fixed.
To be fair, the MyFaces developers have not yet been able to run the
TCK tests of the JSF spec against their implementation, so haven't
gotten the benefit of finding the issues that the tests will point
out. There is an ongoing negotiation to license the TCK to Apache
(using the scholarship characteristic of Apache for which Sun (as the
TCK developer in this partiular case) uses to make TCKs available at
no cost to qualified non-profits). Once that process is completed,
I'm sure a number of compliance issues will surface and be quickly
fixed.
But, for you as an application developer -- you should count on *only*
the assertions described in the spec, and you should insist that your
JSF implementation conform to those assertions. Reliance on any
non-specified behavior (of either MyFaces or the RI, in this
particular scenario) risks making your application non-portable.
>
> -Ken
>
Craig McClanahan
(Co-Spec Lead, JSF 1.0)
Re: Why not reuse jsf-api.jar from Sun?
Posted by Ken Weiner <kw...@gmail.com>.
Thanks for the replies. Do other specs from JCP behave this way? I
don't remember ever seeing another situation where there are multiple
versions of the same exact (same fully-qualified name) class.
Here is an example of how my component would break if I switched
implementations:
Let's say I am coding a component that has children components. My
component extends javax.faces.render.Renderer. If I am using the RI,
I may be tempted to accept (not override) the implementation of
Renderer.encodeChildren() which simply iterates thought the children
and renders them as follows:
public void encodeChildren(FacesContext context, UIComponent component)
throws IOException {
if (context == null || component == null) {
throw new NullPointerException();
}
Iterator kids = component.getChildren().iterator();
while (kids.hasNext()) {
UIComponent kid = (UIComponent) kids.next();
kid.encodeBegin(context);
if (kid.getRendersChildren()) {
kid.encodeChildren(context);
}
kid.encodeEnd(context);
}
}
Now if I switch to MyFaces, none of my children would render because
the MyFaces version of javax.faces.render.Renderer.encodeChildren()
does not render the children. It looks like this:
public void encodeChildren(FacesContext context, UIComponent component)
throws IOException
{
if (context == null) throw new NullPointerException("context");
if (component == null) throw new NullPointerException("component");
}
So if I understand things correctly, my component would essentially
break because none of its children would render with MyFaces. Does
that make sense?
I realize I could override the encodeChildren() method to be safe, but
don't you agree that it would be easy for someone to fall into a trap?
Maybe, in this case, one of the implementations is not adhering to
the spec.
-Ken
On 8/23/05, Sean Schofield <se...@gmail.com> wrote:
> > The way it is now, if I were to write my own, let's say
> > MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my
> > components could break if I switch between the RI and MyFaces. I hope
> > someone can help me understand the nature of the JSF spec, API
> > classes, and various implementations. Thanks.
>
> This shouldn't be the case. The JSF spec carefully defines not only
> the method signatures but the anticipated effects of these methods.
> Both implementations should be interchangeable.
>
> > -Ken
>
> sean
>
Re: Why not reuse jsf-api.jar from Sun?
Posted by Sean Schofield <se...@gmail.com>.
> The way it is now, if I were to write my own, let's say
> MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my
> components could break if I switch between the RI and MyFaces. I hope
> someone can help me understand the nature of the JSF spec, API
> classes, and various implementations. Thanks.
This shouldn't be the case. The JSF spec carefully defines not only
the method signatures but the anticipated effects of these methods.
Both implementations should be interchangeable.
> -Ken
sean
Re: Why not reuse jsf-api.jar from Sun?
Posted by Martin Marinschek <ma...@gmail.com>.
It is necessary - as by the nature of the JCP and its specifications -
to implement the javax.faces.* classes as well to be a full blown JSF
implementation.
We didn't provide those classes at first, and were (almost friendly ;)
pointed to the fact that we do necessarily need to provide the jsf-api
implementation as well.
So that's why!
regards,
Martin
On 8/23/05, Ken Weiner <kw...@gmail.com> wrote:
> I am confused about the nature of the javax.faces sources that are
> included in the MyFaces jar file. They appear to have been written as
> part of the MyFaces project. Sun includes alternative versions of the
> javax.faces classes in its RI distribution, placing those classes in a
> seperate jar file: jsf-api.jar. Why doesn't MyFaces reuse the
> jsf-api.jar from Sun? Shouldn't there only be one version of the API
> classes, with Sun RI, MyFaces, and other supplying only the "impl" of
> the API?
>
> The way it is now, if I were to write my own, let's say
> MyAbstractRenderer, and I extend javax.faces.render.Renderer, then my
> components could break if I switch between the RI and MyFaces. I hope
> someone can help me understand the nature of the JSF spec, API
> classes, and various implementations. Thanks.
>
> -Ken
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German