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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > On 8/23/05, Ken Weiner <[EMAIL PROTECTED]> 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)
> >
>
>
> --
