JSF spec 1.0 prd

JSF 1.0 prd states in a number of places that the spec will likely change. Could someone enlighten those of us who are not directly involved on the thinking and arguments behind these statements?
Thanks!
Song He

The spec is still being developed; the current draft is the first Public Draft, intended to solicit feedback from people interested in the technology and willing to play with it a bit.
A number of details are known to require more work, and the sections where the "expert group" is already working on enhancements or alternatives are marked as "will change" in the Public Draft.
For more on the Java Community Process (used to develop the JSF spec as well as all other "sanctioned" Java specs) and all the stages a spec goes through before it's final, see http://jcp.org.

Similar Messages

Bug of JSF spec?

I am not good at English. But but... please hear my JSF Problem.
<h:form>
    <h:inputText id="input1" required="#{true}"/>
    <h:message for="input1"/>
    <h:inputText id="input2" value="#{testBean.value}">
        <f:convertNumber integerOnly="true"/>
    </h:inputText>
    <h:message for="input2"/>
    <h:commandButton/>
</h:form>From browser:
1.Input empty string at input1. (this cause validation error.)
2.Input empty string at input2. (convet to null.)
3.Click commandButton.
I hope:
Display value at input2 is empty string. (My input value is keeped.)
But result is:
Display value at input2 is "#{testBean.value}". (My input value is forgotten...)
In my research:
1.converter converts empty string to null.
2."local value" is set to null.
3.Go to Rnder Response Phase By Input1 validation error.
4.getValue ignore "local value" if it is null and see VE.
Uhh... Why getValue method doesn't see isLocalValueSet?
I can't understand... Please Help me...

Unfortunately I've had no luck with this solution. In my case I am performing a search using a session scope bean. My results are listed in a dataTable and I have an actionListener on a request scoped bean. All of that works fine.
faces-config.xml
<managed-bean>
     <managed-bean-name>searchBean</managed-bean-name>
     <managed-bean-class>com.package.SearchBean</managed-bean-class>
     <managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
     <managed-bean-name>detailBean</managed-bean-name>
     <managed-bean-class>com.package.DetailBean</managed-bean-class>
     <managed-bean-scope>request</managed-bean-scope>
</managed-bean>
public class DetailBean
     private String field1;
     private String field2;
     //Bind the dataTable component to the controller
     protected transient UIData dataTable;
     //The object used to populate the row in the table that was selected
     protected transient Object row;
     public DetailBean()
          super();
          FacesContext facesContext = FacesContext.getCurrentInstance();
          Boolean isPostback = facesContext.getRenderKit().getResponseStateManager().isPostback(facesContext);
          if(!isPostback) //always seems to be true
               if(dataTable != null)
                    row = dataTable.getRowData();
     public void detail(ActionEvent event)
          row = dataTable.getRowData();
          if(row != null)
               Map<String,String> record = (Map<String,String>)row;
               setField1(record.get("field1"));
               setField2(record.get("field2"));
     public String edit()
          //do the edit
          return "success";
<h:inputText id="field1" value="#{detailBean.field1}" required="true"/>
<h:inputText id="field2Input" value="#{detailBean.field2}"/>
<h:outputText id="field2Text" value="#{detailBean.field2}"/>
<h:inputText id="field2Hidden" value="#{detailBean.field2}"/>
<h:commandLink id="edit" action="#{detailBean.edit}" value="edit"/>
<h:messages errorStyle="color:red" showSummary="true"/>     The values from the table are successfully populated and the page is shown with the values:
field1=test1
field2Input=test2
field2Text=test2
field2Hidden=test2when I clear field1 (required) and submit I have the following:
field1=
field2Input=test2
field2Text=
field2Hidden=test2
message about field1 being requiredI would expect field2Text to still retain the value.
Furthermore if I set the field2Text to readonly="true", it, too, does not retain its value. However in both cases once the required field has a value and is submitted, all values show as expected.
My only workaround for this is to set my detailBean session scope, but that avoids the problem.

JSF Spec - State management

Any reason why the spec chose to use the visitor pattern with saving state versus leveraging serialization/externalizable?

Serialization imposes a lot of things we didn't want to require:
- The structure has to remain stable across releases
- You must save the entire object's state (which we do today, but with improvements in the JSP spec, may not need to).
- There's no real guarantees about when serialization will be called or what state your object might be in or what you'll have access to; StateHolder offers just that, as you'll have access to a FacesContext and know when you'll be called.

Does Oracle Application Server (10.1.3.4.0) support JSF 1.2?

Sorry for the double post, but I realized this was more appropriate in the OC4J forum so posted it there. Not sure how to delete this one :-(.
I am trying to migrate from JSF 1.1 to JSF 1.2 on OC4j 10.1.3.4.0 and am running in to problems. I recently stumbled on this post:
http://kjvarga.blogspot.com/2008/12/oc4j-1013-does-not-support-jsf-12.html
Which reads as follows:
I spent a very frustrating day wading through the version soup that is JavaServer Faces and trying to deploy a JSF 1.2 app on on OC4J 10.1.3 container. To save you a lot of time, OC4J DOES NOT SUPPORT JSF 1.2.
This technical paper explains that OC4J 10.1.3 (all versions) supports Servlet 2.4, JSP 2.0 and JSF 1.1.
http://www.oracle.com/technology/tech/java/oc4j/1013/whitepapers/OC4J-FOV-10131.pdf
And this handy webpage explains that "JSF 1.2 is the latest release and it works with servlet 2.5 and jsp 2.1". So obviously it's not compatible. It also details all the versions of Java technologies that each JSF version relies upon.
http://www.roseindia.net/jsf/jsf-versions.shtml
Is this true? I can't use the JSF spec released in 06 on the most current version of oracle application server? Could someone please confirm/deny/shed some light?
Thanks so much,
Yeuker
Edited by: yeuker on Jun 29, 2009 10:54 AM

Found a bit more information located here:
http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI
See the section entitled
"Do I have to use a JSP 2.1/Servlet 2.5 container with the Mojarra version 1.2?" which states:
If you're using JSPs for your view descriptions, then yes, you will need to use a JSP 2.1/Servlet 2.5 compliant container. However, if you're using another view technology, such as Facelets or JSFTemplating, you can run JSF 1.2 within a Servlet 2.4 container with out issue.
Now here is the part that may make me look like a newb... not sure if I am "using JSP's for my view descriptions"... what does that mean anyway?
I dont think I am not using Facelets or JSFTemplating. I'm just using standard JSF... All of my pages end in jsp and the standard faces servlet that makes all *.faces requests go through the faces controller servlet. There is really no JSP EL code in my faces pages, just standard jsf tags h:form, f:selectItems, h:inputText etc...
So my question is... am I using JSP's for my view descriptions?

JSF 2.0: Why is nbsp; Illegal in Included Files?

I have a file containing a snippet with nbsp; (with an ampersand) as below. The file will later be referenced with ui:include.
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
foo&nbsp;bar
</ui:composition>Result: "Error Parsing /snippets/header.xhtml: Error Traced[line: 3] The entity "nbsp" was referenced, but not declared."
It works fine if I change it to #160; (with an ampersand) as here:
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
foo&#160;bar
</ui:composition>Now, this was also the behavior of facelets in JSF 1.x, but I had been under the impression that it was a bug, not a feature. Is this the expected behavior in JSF 2.0? If so, why? And where does it say so in the spec?
I am using Mojarra 2.0.1 FCS with Java 6.0.15 and Tomcat 6.0.18.
Thanks!
- Marty
[JSF 2.0 Training Courses|http://courses.coreservlets.com/public-courses/jsf2/]

BalusC wrote:
Facelets uses XHTML. XHTML is based on XML. HTML-style entities (&name;) are illegal in XML. You should use XML-style entities instead. Thus, use &#codepoint; instead wherein `codepoint` represents the unicode codepoint.I believe you are mistaken.
First of all, the XHTML 1.0 specification (http://www.w3.org/TR/xhtml1/) specifically says in section A.2 "the XHTML entity sets are the same as for HTML 4, ...". And, the spec uses "lt;", "gt;", "quot", and "euro;" (and probably more) within various parts of the spec. And, named character entities validate without error at http://validator.w3.org/ [Note that I deliberately left the ampersands off the front in the text above]
Second, nbsp; works fine in normal facelets pages. It is only in included pages where the current Mojarra implementation has problems.
After I posted my message, I got email from a JSF spec member who said it is a bug in the current implementation, and that I should report it. I did.
Cheers-
- Marty
[JSF 2.0 Training Courses|http://courses.coreservlets.com/public-courses/jsf2/]

What do I need to run/use JSF ??

Sorry for a rather dumb question. We have a client/server system we would like to convert into a Web Based app using JSF.. we developed our system on J2SE 1.4
1. What software/runtime environment do I need ?
2. What downloads must I grab to start using it ??
Thanks very much
Mike

Hi,
first you'll need the JSF (latest current release EA3) found under:
http://java.sun.com/j2ee/javaserverfaces/
then an application server, e.g. tomcat/catalina supplied with the JWDSP and the J2EE platform found at:
http://java.sun.com/webservices/downloads/webservicespack.html
and
http://java.sun.com/j2ee/download.html
respectively.
Having installed the JSF you'll find a JSF Spec and tutorial where everything else (configuration, etc.) is explained.
If you're experiencing problems with the JWSDP 1.1 try getting hold of JWSDP 1.01.
Good luck & have fun....

[Swiss JSF Users] JSF Special-Interest-Group Switzerland

JSF is proving more and more competitive each day. A increasing number of
companies are developing applications based on JSF.
Often the same questions/problems/hints are valid for almost all users of
JSF. Internationally some active communities have been established. Last
year a first encounter of JSF-entusiasts created the idea of "JSFDays Europe",
a conference that allows to get in touch with the main players int he
JSF-universe and to meet also informally. This first encounter took place
in Munich, was organized on very short notice during the Oktoberfest. An
intense session with the JSF expert group lead Ed Burns allowed the users
to voice their wishes for JSF 2.0 and regognize the "approachability" of
the JSF-people at Sun. Within Switzerland so far the contacts between the
users are rather sporadic and more on a one-to-one basis.
Hopefully some contacts have been added during the Jazoon-conference. We
would like to go one step further and establish the networking between
Swiss-JSF users. An active community can help in solving problems or even
create components that are usefull for some or all members. And in
Switzerland we encounter some problems (like i18n, as most of our
applications need to be available in multiple languages) that other
international users do not encounter or encounter later or to a lesser extent.
The JSF-specification is driven by requirements that are brought to the
Expert Group discussing the specifications. So far much input has come
from framework-architects, appserver-providers and tool-creators. It's
about time the actual users let hear their voices as well. Although the
expert group members can be contacted and have proven to be very
responsive, requirements coming from an official user-group have more
importance.
Establishing a "JSF user group" as a independant community or a
"special interest group" under the umbrella of the
"JUGS (Java User Group Switzerland)" could be the outcome of this meeting.
The underline the importance of "interaction" and communication for the
community, we propose short presentations with much space for discussion.
Date: Thursday, 2007-06-28 (right after the end of Jazoon 07)
Place: Zurich, close to the location of Jazoon 07 (but not yet defined)
Agenda:
- 16:30 - 17:30: HTTP-GET interface into JSF-applications
     Presenter: Ed Burns
     Abstract: First ideas on the upcoming GET-interface into
JSF-applications. ...
     30 minutes presentation, 30 minutes discussion on
these ideas and their implications on the applications
- 17:30 - 18:30 (resp. open end): JSF, Quo Vadis?
     Presenter: Ed Burns, Alexander Jesse
     Abstract:
     - Where is JSF heading? The Expert Group is forming and discussing
the next version of the JSF-spec right now.
What are the ideas driving the EG?
     - Where is JSF heading in Switzerland? Can we say a User Group is
forming right now? What could be the plans of this group? Should
it participate in the "JSFDays Europe" initiative?
In order to plan the upcoming first meeting (room,...) we would appreciate
feedback from all interested people. Also from those that cannot come to
the first meeting, but would welcome the foundation of the
JSF Special-Interest-Group Switzerland.

Is JSF evolving to a web framework?

hi;
initially i thought JSF would be a full web framework (like struts, WAF etc..).
is there any intention of doing this?
what is the reason of not doing this and having a standard J2EE web framework?
thanks

I just read the JSR for JSF and noticed that teh
Apache Software Foundation was objected to the passing
the JSR. That objection is out of date and has probably been repealed.
Am I correct in assuming that unless the JSR
gets a majority, it will not pass. Even if it does,
without support from a big player like IBM, JSF will
be more like a lame duck.IBM is fully behind JSF.. they're already building a JSF editor for WebSphere Studio.
This JSR conflicts with the Apache open source project
Struts. Considering Sun's current position that JSRs
may not be independently implemented under an open
source license, we see little value in recreating a
technology in a closed environment that is already
available in an open environment.that has changed under the new JSR rules.
To the extent that this JSR extends beyond Struts
today, we would encourage the Sun developers proposing
this JSR to join the Sun developers already leading
Struts to create an open solution at Apache, something
which when finished would be assured of being able to
be implemented as open source.The JSF JSR lead, Craig McClanahan is the creator of Struts. He's also contributing code to Struts-Faces ( http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ ) that integrates JSF and Struts.
The only concern I have with that is that Open Source
is not the greatest model for commerical companies.
There is no money in it. Will it help keep things
standardized...or lead ot more fragmentation. The way
it is right now, u see 5 diff open source frameworks-
all to do the same thing. JSF has a lot of commercial potential, since it standardizes the third party component playing field.. Write your components to the JSF spec and conceivably (*here's hoping*) developers will just drag & drop your components into their webapps.
Ivar

Expected date for JSF RI 1.2?

Hi,
I'm wondering when the implementation of the JSF 1.2 specfication will be available. It's the duplicate button press problem I'm concerned about. It has been logged as issue 31 with the JSF spec https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=31
Depending on the date we can wait for the solution in JSF RI 1.2 or we will have to implement ourselves a solution that ideally streams the rendered output from the first request to the last request received.
Obviously I'd rather wait. :-)
Sincerely,
Joost de Vries

I've implemented this in the past in an application although that application was not on top of jsf.
What we did was: before processing a request it is checked wether there is already a request processing for this client.
If not: flag that this request is going to process. After request processing, before streaming the response to the client check wether there is a new response writer for this client and stream the response to this writer.
If there is: set this response writer as the new response writer for this client and abandon further request processing or rendering for this client.
We buffered rendering to make the final streaming to the client 'more atomic'. This has a memory penalty of course.
This does solve single-client concurrency for the non-rendering part of the processing lifecycle. Once streaming to the client of the first thread has started though I see no way of handling this gracefully unless you have buffered the response streamed by the first thread: in that case you can send this buffered response to the client.
I expect the difficulty to be in finding the right hooks in the JSF framework for 1 checking wether there is already a thread processing for this client, 2 in supplying the rendering phase the right response writer and 3 in finishing the later concurrent thread without having it render itself.
Come to think of it: nr 3 might mean that 'the' response must be streamed by the last entering thread. Especially since the previously entering thread probably hits an IOException since the browser closes the reading socket in favour of the later request.
If you decide to implement this: email me at sultan_boabdil x hotmail y com (substitute x and y with the obvious signs to make it and email address) so we can find out wether we can share resources.
Groeten uit Nederland,
Joost de Vries

Integration of other JSF Components

Has anyone had success importing the OurFaces components into Creator?
Is there an established best approach on how to add custom components to Creator? I know the JSF spec needs to be enhanced in this area but I am in the process of implementing several custom components and want to ensure they will be integratable (sp?) into Creator.
Thanks a bunch!
Ernie :)

Helo Ernie,
I wouldnt say I had success in importing OurFaces components into Creator but I was able to import the components and see a list of the OurFaces components in the Palette. Here is what I did :
In the palette -> added components I right clicked and chose Import components. In the component runtime jar I browsed and chose the ourfaces.jar located in the D:\OurFaces\ourfaces\webapps\ourfaces\WEB-INF\lib directory. I chose the same ourfaces.jar for the Tool design time jar also. I clicked ok and I could see the list of components. I am not sure of how correct this is because when I drag and drop any of the components I cant see them on the form but they appear under Page1 -> html of the application outline window. I am not sure if anything has to be entered for Default tag library prefix and Default tag library URI. Since I have not really worked with OurFaces components I think I am missing out something here. I hope someone will be able to take it from here and get it working.
Cheers :-)

Myfaces, tomahawk, jsf sun

Hello,
what is the relationship between myfaces and tomahawk. And if i want to develop a myfaces app do i have to use jsf sun components?
thanks

Hello,
what is the relationship between myfaces and
tomahawk. And if i want to develop a myfaces app do i
have to use jsf sun components?
thanksFrom http://myfaces.apache.org/tomahawk/
In addition to custom components not found in the JSF specification, the MyFaces components bundle also includes an "extended" version of some of the default components. These are basically components that exist in either the core or html tag libraries but additional functionality has been addded that goes beyond the specification.
Summarized: MyFaces implements JSF spec and Tomahawk goes beyond JSF spec.

Spec wishlist: Renderer config/customization options

I'm hoping that perhaps those involved in future JSF specs might lurk around here.
I was wondering if there was a plan in near future to add configurable customization to components when they are output by a specific Renderer.
Currently it's very cumbersome to add client side JavaScript to existing HTML components as you have to override code (and the code is specific per JSF implementation). A better option would be to:
- associate small pieces of text with a component,
- allow one to add onblur/onfocus (etc) attributes to components and,
- have the RenderKit do things like ensure that JavaScript segments are only added to the page once, and other housekeeping/lifecycle items.
Ideally the scripts and attributes would be applied to the component (in which case they are always added to the output), or associated with the component if certain validators and/or converts are attached to the component. Note in the example below that one of the attribute values uses EL to resolve runtime options - I'm not sure if this is the best way to go but it allows rich customization without resorting to code and that is my intent.
Finally, if the configuration could be applied to a UIComponent and a 'render type' (like HTML) instead of the specific Renderer implementation itself, that would be much cleaner.
Example config from faces-config.xml
<renderer>
<class>com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer</class>
<onetime-text>
    <![CDATA[
      <script type="text/javascript" src="js/notnull.js"/>
    ]]>
</onetime-text>
<attributes>
    <attribute><name>onblur</name><value>enforceNotNull(this)</value></attribute>
</attributes>
<on-validator>
    <class>javax.faces.validator.LengthValidator</class>
    <onetime-text>
      <![CDATA[
        <script type="text/javascript" src="js/checkLength.js"/>
      ]]>
    </onetime-text>
    <attributes>
      <attribute>
        <name>onblur</name>
        <value>enforceLength(this,#{LengthValidator.min},#{LengthValidator.max})</value>
    </attribute>
    </attributes>
<on-validator>
</renderer>

Hi,
I am also getting the same error.
How did you managed to solve it?
Thanks for any guidance,
Abdul

Problem with f:attribute and EL.

Hello ppl,
Im trying to add a atribute a component, with EL, but when i try to get the components atrributes, this parameter isent there. The JSF spec says that the f:param accepts expressions but its not working.
Help please.
<rich:dataTable id="tableMetas"
          value="#{encaminhamentosManager.encaminhamentos}"
          var="encaminhamento" style="width:100%;"
          onRowMouseOver="this.style.backgroundColor='#CCDDEE'"
          onRowMouseOut="this.style.backgroundColor='#{a4jSkin.tableBackgroundColor}'">
          <rich:column>
               <h:commandLink value="#{encaminhamento.candidato.nome}"
                    actionListener="#{consultaAlunoManager.avancar}" >
                    <f:attribute name="nextMapping" value="buscar_avaliacao"/>
                    <f:attribute id="candidato" name="candidato"
                    value="#{encaminhamento.candidato}"/>
               </h:commandLink>
          </rich:column>
</rich:dataTable>And my ActionListener try to acess like this:
public void avancar(ActionEvent event) {
    FacesContext faces = FacesContext.getCurrentInstance();
    Application app = faces.getApplication();
    HtmlCommandLink link = (HtmlCommandLink) event.getComponent();
    String nextMapping = (String) link.getAttributes().get("nextMapping");
    //NULL
    Candidato candidato = (Candidato) link.getAttributes().get("candidato");
}the String nextMapping is right, but the Candidato isent in the atrributes.
Thanks for the help
Ferry

You're passing an out-of-scope datatable row to the f:attribute value. The f:attribute is component-specific, not row-specific.
Rather use HtmlDataTable#getRowData() inside the action method to retrieve the current row from the datatable.
I don't know how to do it in the rich:dataTable (check the API spec yourself), so I'll give a basic example with h:dataTable:<h:dataTable binding="#{myBean.table}" value="#{myBean.rows}" var="row">
    <h:column><h:commandLink value="click here" action="#{myBean.action}" /></h:column>
</h:dataTable>MyBeanprivate HtmlDataTable table;
private List<RowObject> rows;
// + getters + setters
public void action() {
    RowObject currentRow = (RowObject) table.getRowData();
    // Handle.
}Also see http://balusc.xs4all.nl/srv/dev-jep-dat.html for some new insights.

Detailed comments

I've gone through the EAD spec. and I've come up with a detailed list of comments that I'd like to post here and also will post over at TheServerSide.com and send directly to the JSR group. This area will give the community a chance to discuss this more. There are a few things that I did not finish commenting on, but over-all this document is fairly complete with my comments thus far. But then again, I've only read the spec twice and spent a day considering it.
I'll continue to add to this thread as I think of more.
Brian Pontarelli
Included document
JSF 2.1
Assuming that most applications will be setup like:
HTML->HTTP->FacesServlet->reconstitute phase->validation phase->model phase
This leads to an enormous amount of duplication as well as overhead. The information for each form component will be stored in the HttpServletRequest, expanded into the UIComponent Tree and stored in the FacesContext and finally migrated to the Application�s Model. Although this seems to be a small amount of work when considering smaller forms with two or three fields, it could become larger with 20-30 field forms. This continues to grow when considering an intensive web application with many users (i.e. 20+ requests per minute). In addition, the cost of the UIComponent and Application�s Model classes themselves might further increase the amount of memory consumed by this triple duplication as they may contain other member variables that increase each instances foot-print. In addition, without some comparison mechanism, the HttpSerlvetRequest parameters will be copied to the UIComponents local values, which will be copied to the Application�s Model each request. If, for example, the request goes all the way to the Invoke Application phase and then encounters an error, which will redirect the user back to the form so that they can fix some values, after they have fixed the values and resubmitted, the triple transfer happens, in its entirety, again (unless the application program is exceptionally savvy and is willing to build in an update recognition component that could skip application model updates when they are not needed).
The simpler and more concise design seems to be a single duplication of data. This would be from the HttpServletRequest to the Application�s Model. This would remove the UIComponent�s local values entirely. The UIComponent tree could still be constructed and optimized however the JSF spec allows. Likewise, the UIComponent�s themselves could be �backed� by the Application�s Model classes as is the case in the MVC design of Java�s Swing APIs.
The decoding process would work the same but would store the decoded information in the Application�s Model. Likewise, the encoding would retrieve it from the Application�s Model. This mimics other frameworks such as Jakarta Struts with their ActionForm classes that are essentially the Application�s Model (or at least positioned in such a way that they could be).
JSF 2.3
This has been tried many times and shown to be lacking. Server-side event models do not scale well because of the overhead of marshalling and unmarshalling the entire HttpServletRequest including all the form parameters, so that a single checkbox can change the values in a single selectbox (for example). The only solution to this problem seems to be the use of contained transmission systems, which transmit only the needed components state to the server. The server can respond with updates to any component, or whatever it needs. In order to attempt to accomplish this in a web browser, some very extensive JavaScript needs to be written which can cause enormous amounts of support issues. I think that you�ll find very little need for RequestEventHandlers and find that nearly 98%+ of the work will be done in the ApplicationEventHandlers.
JSF 2.6
This needs to be rewritten. This contains information about the Lifecycle management process before the reader knows what that is.
JSF 2.7
I don�t really like the concept of 1 Tree to 1 page yet, but I don�t know why. Need to think about this and draw some concrete conclusions about how this is lacking and what impacts it will have.
How will applications be able to forward to HTML pages? It doesn�t seem possible in the current setup without creating Tree objects for pages that don�t contain JSF code. Likewise, it seems that the requirement of having response Trees dictate the outbound page require that every JSP page in the entire application use JSF code (in order to seem conceptually correct). This seems like a large requirement for businesses with existing info-structure. Not to mention the need to be redirected out of the J2EE application server to an ASP server. Of course no one wants that, but it is a reality. This seems very restricting. The flow should be flexible enough to support forwards and redirects to any resource inside and outside the container.
JSF 2.8
The requirement on forcing the Tree to be saved to the response or the session seems very restricting. This section is very ambiguous about what writing the Tree to the response means. Does this mean doing nothing because the JSF tags will do everything for you? Or does it mean adding additional information to the HTML about the state of the JSF system? In the latter case, this is simply duplication of the information that the JSF tags write out, is it not? And there might be implementations with large Trees and many users that do not want to bug down the session with this information and would rather spend the computing cycles to reconstruct it each time from the request. Additionally, would there be cases where a developer would want to send the information from a normal HTML page to the JSF system and have it construct a UIComponent Tree? This seems likely and not possible (?) with the requirement from this section.
If you decide to leave in the local values and model values that I disagreed with above, you�ll need to be specific about where the values for the response come from when encode is called. It they come from the local values of the UIComponent, then the application logic will need to be responsible for migrating the values from the Application�s Model to the UIComponent�s local values. If they come from the Application�s Model, then every component will need to supply model references (I think). Or a better solution to this problem would be to add another phase to the lifecycle called �Update Local Values� which is designed to update the UIComponent�s local values from the Application�s Model if necessary. Or you could simply do away with the UIComponent�s local values altogether in favor of a more MVC oriented system where the view is directly backed by the Application�s Model (similar to Swing).
JSF 3.1.2
You probably want to add a way to determine a components individual and absolute id (bar and /foo/bar). This will be useful in tools as well as debugging.
JSF 3.1.5-3.1.6
See above about my issues with model references and local values. What if I write a JavaScript Tree component? This would mean that UIComponent�s local value would be of type com.foo.util.Btree (or something) and my Application�s Model might be the same. There is a lot of overhead doing things this way. What if my tree stores the groups and all the employees for a company with 50,000 people and 500 groups (not the best way to do things, but possible)? What if the Tree is roughly 1K in size (Java object size) and 2000 users are banging away at the system all day? Let�s see that�s 1K for the UIComponent�s local value, 1K for the Application�s Model, 2000 users, and roughly 4 Megs consistent memory usage for a single component.
JSF 3.5.x
This was a major concern to me when I wrote both of my frameworks. A reusable Validator is excellent because it reduces the amount of code duplication. However, it is very difficult to tailor messages for specific UIComponents using a reusable Vaildator. For example, on one page I just a text box for age and on another I use if for income. I don�t want my error messages to be generic stating that, �This value must be greater than 0 and less than X�. I want the user to know what must be within the range.
One solution is to use the name of the input in the error message. This forces the user to name inputs in human readable form, which might not be possible. For example, I have an input for monthly overhead and I name it monthlyOverhead so that it is a legal variable name. You can�t have a message that reads, �monthlyOverhead must be greater than 0�. This just won�t fly in a production environment. It needs to be nice and human readable and say, �Your monthly overhead must be greater than zero.� However, you can�t name your UIComponent �Your monthly overhead� especially I you intend to do JavaScript on the page. Besides, it�s just bad style.
Another solution is requiring specific sub-classes for each message required, or some parameter from the page to denote the specific message to use. The former clutters up the packages with tons of Validators and also requires way too much coding. The latter completely negates the ability to use parameterized messages without further bogging down the page with all the (un-localized) parameters to the error message or forces the placing of all the parameters inside the resource bundle for the error messages with a standard naming scheme (i.e. for the first parameter to the message �longRange.montlyOverhead.0=Your monthly overhead�). Since 1/3 of any application is really the view and interaction of which a large chunk is error messages, this is a major issue that must be considered. Because it always happens that the CEO plays around with the application one day and says, �I really wish this error message read this �� and then you�re in for some major headaches, unless this problem is solved up front.
JSF 3.5.2.x and 4.x and 7.6.x
These sections seem to break up the flow of reading. The previous sections were charging forward with information about the interfaces, the JSF classes and specifics about what is required for each Phase. Then we need to down shift quite a bit to talk about default/standard implementations that ship with JSF or are required to be implemented by implementers. I think that these should be contained in a later section after 5, 6, 7 and 8.
JSF 5.1.2
What are the implications of this decision on Internationalization? When different UIComponents encode using different Locales and the HttpServletResponse�s content type has already been set, there could be rendering problems on the client side in the browser.
JSF 5.1.5
Messages added to the message queue during validation or processing contain Unicode String Objects and could be written in any language. The Message Object does not contain information about the Locale that the message needs to be converted to and this is needed for internationalization. If I have a multi-lingual portal and output error messages in multiple languages, the spec needs to really consider what and where the charset for the HTTP header is going to be set. What if JSF realizes it needs to use UTF-8 but another tag library an application is using assumes fr_FR, who is correct and what will happen? How will JSF determine what encoding to use when it has Messages in ten different languages? What if the container starts writing the output to the stream before the header is set? Etc. etc.
JSF 8.1
This is possibly the most confusing and poorly written section in the entire document. This uses terms that don�t relate to anything, old class names and un-described tables. This needs to be re-written in a more concise way. I did not understand what a custom action was until I reached section 8.2.6 and realized that an action was really a tag implementation. Action is a poor choice of words because not all tags equate to actions. What is the action of an input tag? I understand action when talking about for-loop tags, but not input tags.
JSF 8.3
This seems quite contradictory to section JSF 2.8 because it leads the reader to believe that they have no control over the implementation of the use_faces tag and the method of saving the JSF state. That is UNTIL they read section 8.5. These two sections need to be combined to clarify the document.
Comments:
I think that JSF is a very good idea in general and that it is a very complicated thing to define (due mostly to the use of HTTP, which is a stateless protocol). There are so many frameworks out there and each has its own benefits and downfalls. However, it is imperative that this specification attempt to solve as many problems as possible and not introduce any more. The spec must be flexible enough to support implementations that drive for speed and those that drive for flexibility. It must also support enormous amounts of flexibility internally because as vendors attempt to comply with it, they want to make as few changes to their own code base as possible.
Right now, JSF has not accomplished these goals. I think that it needs to consider a lot more than it has and really needs to address the more complex issues.

Brian,
I've gone through the EAD spec. and I've come up with
a detailed list of comments that I'd like to post here
and also will post over at TheServerSide.com and send
directly to the JSR group. Thanks for the feedback, it's really appreciated. I've included some comments below. Even though I'm a member of the spec group, these are just my personal comments and do not represent any official position of the group. It's very important that you send feedback you want the spec group to consider to the mail address listed in the spec draft. Some of us read this forum, and try to answer questions and clarify things as best we can, but the only way to make sure the feedback is considered is to send it to the JSR-127 mail address.
Included document
JSF 2.1
Assuming that most applications will be setup like:
HTML->HTTP->FacesServlet->reconstitute
phase->validation phase->model phase
This leads to an enormous amount of duplication as
well as overhead. The information for each form
component will be stored in the HttpServletRequest,
expanded into the UIComponent Tree and stored in the
FacesContext and finally migrated to the Application�s
Model. [...]This is not so bad as it may seem, since typically it's not copies of the information that get stored in multiple places, just references to the same object that represents the information.
Consider a simple text field component that is associated with a model object. The text value arrives with the request to the server which creates a String object to hold it. The UI component that represents the text saves a reference to the same String object and eventually updates the model's reference to point to the same String object. The application back-end eventually gets a reference to the value from the model and, say, saves it in a database. Not until you hit the database do you need to make a copy of the bytes (in the database, not in the JVM).
JSF 2.3
This has been tried many times and shown to be
lacking. Server-side event models do not scale well
because of the overhead of marshalling and
unmarshalling the entire HttpServletRequest including
all the form parameters, so that a single checkbox can
change the values in a single selectbox (for example).
The only solution to this problem seems to be the use
of contained transmission systems, which transmit only
the needed components state to the server. The server
can respond with updates to any component, or whatever
it needs. In order to attempt to accomplish this in a
web browser, some very extensive JavaScript needs to
be written which can cause enormous amounts of support
issues. I think that you�ll find very little need for
RequestEventHandlers and find that nearly 98%+ of the
work will be done in the ApplicationEventHandlers.I agree with you that a web app can never be as responsive as a thick-client app unless client-side code (JavaScript) is used. Web apps must be designed with this in mind, which can be a challenge in itself.
But there are still advantages with an event-based model, namely that it provides a higher abstraction layer than coding directly to the HTTP request data. And even in a web app, having stateful components that generate events simplifies the UI development. As an example, say you have a large set of rows from a database query you want to display a few rows at a time. A stateful component bound to this query result can take care of all the details involved, rendering Next/Previous buttons as needed. Clicking on one of the buttons fires an event that the component itself can handle to adjust the display to the selected row subset.
Coding the logic for this over and over in each application that needs it (as you need to do without access to powerful components like this) is error prone and boring ;-)
Finally, JSF components can be smart and generate client-side code as well to provide a more responsive user interface.
JSF 2.6
This needs to be rewritten. This contains information
about the Lifecycle management process before the
reader knows what that is.Many parts of the draft needs to be rewritten; it's still a work in progress.
JSF 2.7
I don�t really like the concept of 1 Tree to 1 page
yet, but I don�t know why. Need to think about this
and draw some concrete conclusions about how this is
lacking and what impacts it will have.I have the same concerns, and think we need to take a close look at how a response can be composed from multiple JSF Trees, or a combination of regular JSP pages and JSF Trees, etc. I know others in the spec group agree that this is a vague area that needs more attention.
How will applications be able to forward to HTML
pages? It doesn�t seem possible in the current setup
without creating Tree objects for pages that don�t
contain JSF code. Likewise, it seems that the
requirement of having response Trees dictate the
outbound page require that every JSP page in the
entire application use JSF code (in order to seem
conceptually correct). [...]I don't think this is a problem. The application can decide to redirect (or forward) to any resource it wants when it processes an application event; it doesn't have to generate a new JSF response. But yes, navigation is also an area that needs attention in general.
JSF 2.8
The requirement on forcing the Tree to be saved to the
response or the session seems very restricting. This
section is very ambiguous about what writing the Tree
to the response means. [...]It is, isn't it ;-) Again, this is an area that still needs work, and I believe we must be able to provide a lot of flexibility here. Depending on the type of components in the Tree, the size of the Tree, the number of concurrent users and size of the application, etc. different approaches will be needed. How much data must be saved is also dependent on the type of component.
Additionally, would there be cases where a developer
would want to send the information from a normal HTML
page to the JSF system and have it construct a
UIComponent Tree? This seems likely and not possible
(?) with the requirement from this section.In that case the request initiated from the HTML page would be directed directly to application code (a servlet, maybe) which would create an appropriate JSF component Tree and generate a response from it.
If you decide to leave in the local values and model
values that I disagreed with above, you�ll need to be
specific about where the values for the response come
from when encode is called. It they come from the
local values of the UIComponent, then the application
logic will need to be responsible for migrating the
values from the Application�s Model to the
UIComponent�s local values. If they come from the
Application�s Model, then every component will need to
supply model references (I think). [...]I think this is pretty clear in the current EA draft. First, a model is optional for the basic component types (while more complex things, like a DataGrid, may require it). The draft says (in 3.16): "For components that are associated with an object in the model data of an application (that is, components with a non-null model reference expression in the modelReference property), the currentValue() method is used to retrieve the local value if there is one, or to retrieve the underlying model object if there is no local value. If there is no model reference expression, currentValue() returns the local value if any; otherwise it returns null."
Other parts of the spec (can't find it now) deals with how the local value is set and reset. The effect for the normal case is that if there's a non-null model reference, its value is used, otherwise the local value is used. In special cases, a local value can be set to explicitly ignore the model value.
JSF 3.5.x
This was a major concern to me when I wrote both of my
frameworks. A reusable Validator is excellent because
it reduces the amount of code duplication. However, it
is very difficult to tailor messages for specific
UIComponents using a reusable Vaildator. For example,
on one page I just a text box for age and on another I
use if for income. I don�t want my error messages to
be generic stating that, �This value must be greater
than 0 and less than X�. I want the user to know what
must be within the range. [...]I agree that this is a concern. In addition to the solutions you have suggested, I think a way to solve it is by letting validators fire "invalid value" events of different types. These events would contain a default message but also getter method for the interesting parts (e.g. the invalid value, the start and the stop value for an "invalid range" event). An event handler can use the getter methods for the individual values and build a message that's appropriate for the application,
JSF 5.1.2
What are the implications of this decision on
Internationalization? [...]
JSF 5.1.5
Messages added to the message queue during validation
or processing contain Unicode String Objects and could
be written in any language. The Message Object does
not contain information about the Locale that the
message needs to be converted to and this is needed
for internationalization. [...]I need to read up on the latest i18n proposals, but in general I think you're right that there's more work to do in this area.
JSF 8.1
This is possibly the most confusing and poorly written
section in the entire document. This uses terms that
don�t relate to anything, old class names and
un-described tables. [...]The whole JSP layer is still immature, but IMHO, we need to get the API right before we address the JSP issues.
I did not understand what a custom
action was until I reached section 8.2.6 and realized
that an action was really a tag implementation. Action
is a poor choice of words because not all tags equate
to actions. What is the action of an input tag? I
understand action when talking about for-loop tags,
but not input tags. [...]Actually, "action" is the proper name defined by the JSP specification for what's described in this section. A "JSP action" is represented by an "XML element" in a page, which in turn consists of a "start tag", a "body" and an "end tag", or just an "empty tag".
Comments:
I think that JSF is a very good idea in general and
that it is a very complicated thing to define (due
mostly to the use of HTTP, which is a stateless
protocol). There are so many frameworks out there and
each has its own benefits and downfalls. However, it
is imperative that this specification attempt to solve
as many problems as possible and not introduce any
more. The spec must be flexible enough to support
implementations that drive for speed and those that
drive for flexibility. It must also support enormous
amounts of flexibility internally because as vendors
attempt to comply with it, they want to make as few
changes to their own code base as possible.
Right now, JSF has not accomplished these goals. I
think that it needs to consider a lot more than it has
and really needs to address the more complex issues.I agree, and thank you for the feedback. There are many holes yet to be filled and many details to nail down. All of this takes time, since you must build support for the spec among a large number of vendors and other market groups, as well as among developers; this is one of the most important goals for any specification.

Issue: Combining oracle 11g with richfaces

Hi All,
I'm using Oracle JDeveloper 11G release (11.1.1.7.0) with JSF1.2. I need to implement ajax functionality in the application. I am trying to add richfaces-3.3.2.SR1 to the app.
Tried multiple combinations of filters in the web.xml, also tried to manipulation of the renderer-kits.
Please find below the stacktrace:
java.lang.NullPointerException at oracle.adfinternal.view.faces.renderkit.rich.RichRenderUtils.isEmailablePage(RichRenderUtils.java:755) at oracle.adfinternal.view.faces.config.rich.URLEncodingConfigurator$RestrictedResourceURLEncoder.encodeResourceURL(URLEncodingConfigurator.java:83) at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:26) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.encodeResourceURL(ExternalContextDecorator.java:122) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.encodeResourceURL(ExternalContextDecorator.java:122) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.encodeResourceURL(ExternalContextDecorator.java:122) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.encodeResourceURL(ExternalContextDecorator.java:122) at org.ajax4jsf.resource.ResourceBuilderImpl.getUri(ResourceBuilderImpl.java:326) at org.ajax4jsf.resource.InternetResourceBase.getUri(InternetResourceBase.java:218) at org.ajax4jsf.resource.BaseResourceRenderer.encodeBegin(BaseResourceRenderer.java:64) at org.ajax4jsf.resource.OneTimeRenderer.encodeBegin(OneTimeRenderer.java:48) at org.ajax4jsf.resource.BaseResourceRenderer.encode(BaseResourceRenderer.java:47) at org.ajax4jsf.resource.InternetResourceBase.encode(InternetResourceBase.java:313) at org.ajax4jsf.context.ViewResources.encodeSkinningResources(ViewResources.java:294) at org.ajax4jsf.context.ViewResources.processHeadResources(ViewResources.java:510) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:193) at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._renderResponse(LifecycleImpl.java:979) at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:408) at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:237) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:128) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446) at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:271) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:177) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at com.ejada.railways.filters.CustomCharacterEncodingFilter.doFilter(CustomCharacterEncodingFilter.java:29) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119) at java.security.AccessController.doPrivileged(Native Method) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:324) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460) at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103) at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171) at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:163) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
My application is a "Generic application". Any help/pointer to resolve this is highly appreciated.
Thanks

Hi,
What kind of ajax functionality do you intend to use. ADF has AJAX support in built for its components ? . My guess is here the filters and implementation of JSF spec are interfering with each other.
Regards,
Ramandeep

JSF spec 1.0 prd

Similar Messages

Maybe you are looking for