Starting a new top-post for discussion about the JSF 2.0 specification.

 

 

In order to download the Early Draft of the JSF2.0 specification, it was necessary to agree to a Sun licence agreement. The terms of this license are not very nice.

== Issues

Term 1:
<quote>
no part of the Specification may be reproduced in any form by any means without the prior written authorization of Sun Microsystems, Inc
</quote>

It seems rather rude to ask for review and feedback which will be incorporated into a document that can only be reproduced by permission of Sun. This is a document created via an expert committee plus external contributors, and therefore should be freely available.


Term 2:
<quote>
Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation:
(i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented;
(ii) is clearly and prominently marked with the word "UNTESTED" or "EARLY ACCESS" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and
</quote>

If this is meant to assert copyright over the API defined by this specification, then I do not believe that Sun has the right to prevent anyone from implementing a class named "javax.faces.context.FacesContext". As far as I know, APIs cannot be copyrighted. Restricting the right of implementations to claim to be "a certified implementation" or "a Sun-approved implementation" is reasonable. Claiming exclusive right to the name "javax.faces.context.FacesContext" is not.

If this is instead intended to mean that Sun will refuse to grant a patent license to anyone who implements a class with that name but does not pass the secret Sun TCK, then please include in the specification a list of the patents that Sun is asserting apply to this specification.

== Questions

Is it intended for the finished specification to be issued under the same terms?

== Recommendations

Remove term 1. This document is expected -- even intended -- to be widely read by anyone who contributes to the specification, implements the specification or even uses a JSF2.0 implementation. Forbidding distribution of this document by anyone but Sun is unreasonable.

If term 2 is intended to claim copyright over an API, then remove it; this is probably not legally enforceable and is in any case unreasonable.

* If term 2 is intended to grant patent rights only to implementations that pass the TCK, then list those patents in the specification.

 

 

Appendix B has a section "General changes". Quite a few of these references are to items resolved in JSF1.2. Shouldn't this section just contain a list of changes relevant to JSF2.0?

When reviewing the spec, it is important to be able to get a list of what changed since the last release. If all this info is directly from the issue tracker, and the issue tracker data is correct, then can it be generated with a query against the issue tracker?

 

 

Right, Appendix B is for changes between the preceding version and versions preceding the preceding version.


I agree that it is vital to be able to see "what's changed". That's why Roger and I put extra effort into the preface, which contains the list of changes between the version of the spec you are reading, and the previous version. In this case, between 2.0 EDR1 and 1.2 MR1.

Thanks,

Ed

 

 

Ed,

Recently on the Facelets mailing list there has been a discussion concerning the propriety of programmatic manipulation of the component tree. I understand that there has been some discussion of this topic within the EG as well. Can you provide any additional insight as to the EG's thinking in this regard, or point me to the relevant parts of the (EDR) specification? I am particularly interested in this topic applied to the Facelets integration.

Thanks,
Ray

 

 

Thanks for your feedback. I have taken the responsibility to forward your concerns on to management and will ensure I get a response from them.

Sincerely,

Ed

 

 

As described in spec section 11.4.5, there are a number of application-scope classes to which the decorator pattern can be applied.

These classes are abstract, and so are all their methods. This causes problems with regards to forward-compatibility in two ways:
adding any new abstract methods to this interface makes subclasses compiled against the old version invalid (concrete class that does not implement an inherited abstract method)
even if the new methods are non-abstract, they cannot delegate to the instance being decorated because they don't know what that instance is.

The solution taken in JSF1.2 was to define "Wrapper" classes that do delegation. But while this solves compatibility for JSF1.1 forwards, it does not provide the ability to run JSF1.1 code correctly on later JSF releases.

It also appears that although NavigationHandlerWrapper can be decorated as for other classes, the NavigationHandlerWrapper is missing. Adding it in the JSF2.0 release means that there is no way to decorate NavigationHandler portably between JSF1.2 and later releases (just like the problem between JSF1.1 and later releases for the other classes).

This approach is also inconsistent with the way that a number of artifacts are created using factory classes instead:
ApplicationFactory
FacesContextFactory
LifecycleFactory
RenderKitFactory

The objects these factories create are also reasonable candidates for applying decorator pattern to, in particular FacesContextFactory. But as far as I know there is no current solution to forward-compatibility problems for user code that decorates these when new JSF specifications add methods to these classes.

Have these issues been considered? The lack of FacesContext forward compatibility in particular is causing a lot of pain in some MyFaces projects (trinidad, orchestra). I do have some ideas for tackling this, but would like to know what approaches have been considered and rejected so far.

 

 

Ed,

Not sure if you saw my comment above, or if it fell through the cracks when you were replying to the other posts.

Thanks,
Ray

 

 

I am fairly new to JSF of any version. I have just started working with 1.2 and some limited use of facelets. Nevertheless i have taken a look at the 2.0 spec just to see what is coming.

There is a thing I do not quite understand yet. Relocatable resources. Basically the point is to allow components to write in locations where they have normally don't have access. It feels wrong to me. Writing in the head of a document should be done in the head not in the body and vice versa. javascript can be written in the body afaik and css just shouldn't be forced on the unsuspecting user. Conceptually the components should not be aware of other components or the page it is on or anything beyond itself. Writing to the head is then just begging for trouble.

I understand that this feature is all ready in use in many (all?) JSF implementations anyway.

What I am wondering is why? Why is it right to let a component reach beyond its scope? How is this not going to lead to problems? Why was this design choice made?

 

 

Need feedback on whether or not to introduce a binary backwards incompatibility with JSF 2.0.

Please see my blog entry on java.net.

Ed

 

 

JF> There is a thing I do not quite understand yet. Relocatable
JF> resources. Basically the point is to allow components to write in
JF> locations where they have normally don't have access. It feels wrong
JF> to me. Writing in the head of a document should be done in the head

Consider this scenario.

You have a JSF Component packaged in WEB-INF/lib/mycomponent.jar whose
rendering depends on an externally defined stylesheet, also bundled in
mycomponent.jar. Externally defined stylesheets MUST reside in the
HEAD.

JF> What I am wondering is why? Why is it right to let a component reach
JF> beyond its scope? How is this not going to lead to problems? Why was
JF> this design choice made?

This design choice was made precisely to support the usecase above.

Ed

 

 

Re the EditableValueHolder,

My understanding is that existing implementations would continue to work, in the sense that the class files could be used with the new implementation of JSF, as long as the new method is not invoked. This is similar to the situation with JDBC, where older drivers still work even on newer JREs, up to the point one of the newer methods is invoked. (Please correct me if I am wrong.)

So the question then becomes -- will the implementation have need to invoke this method?

The second question is, will the specification be able to supply reasonable default implementations for the existing implementors of EditableValueHolder, e.g. UIInput?

What would be nice would be a tool or a mode to javac which could detect and warn against new methods in interfaces which may need attention but might not otherwise be caught by the compiler. But that is not JSF's responsibility.

In summary, in light of the first point, I do not think it is a major problem.

 

 

@edburns00

I can see the point for that usecase, I just don't see it as a desirable function. Noone should want arbitrary access to even style information. While this may be a workaround for what is seen as a shortcoming in (x)html it isn't one I like or think should even be supported. I am not quite convinced it's also a security risk, I am convinced you shouldn't want this behavior. Of course I am perfectly free not to use it ;)

 

 

JSF 2.0 Early Draft Review 2 is available now on at JCP.org and the implementation is available as a nightly build at the Mojarra website.

Ed

Edited by: edburns00 on Sep 17, 2008 3:37 AM

 

 

Reading the section "13. AJAX Integration" i run into some problems:


1. viewState
Wouldn't it be more reusable if this method returns list with key-value pairs (array of 2 dimension)?
So when we call it in ajaxRequest, we can add the additional params into that array.
And then do encoding+formating of all the params in a third method with argument is that array.


2. ajaxRequest
The name/value of the source element (argument) must be send as post data.
But not all elements contain name and value.


3. callback
- ajaxRequest finishes with putting the request into queue
- the callback is responsible for enqueing/dequeing
- callback must send request if status is 0 (jsdoc)
So what enqueing should the callback do, this is done by ajaxRequest?
Should it be an endless loop with, always checks the queue and additional will be automatically called by browser when response comes in?