Reviewing JSF 2.0 cookbook

Well, readers, I am reviewing a book for Packt Publishing, called the JSF 2.0 Cookbook by Anghel Leonard.  My mind is open and I am expectant about the content, as it surely seems like good subject matter; I will be getting started reviewing it probably on the plane ride back to Denver tomorrow.

Here is more information about the book:  book link  

I will let you know my impressions for this book and the two other big ones I am working on as well, as usual.

Conversion and Validation in JSF 2.0

Well, we have all the old stuff plus some new stuff here. The most remarkable additions I can see here are that a validator tag can now wrap a set of tags…not just be a child in one that needs a validator added to it. So your page can have default validators. Another addition that I don't entirely understand the syntax of yet is Java EE 6 Bean Validation. This seems very useful, but the syntax is a bit odd to me. But mostly this is because I am not familiar with defining custom annotations. Also they seem to have come up with a new usage of generics…I guess it is the same, but the usage bent my mind in a new direction.

So let me elaborate. ("Go right ahead!" you are probably thinking) Let's say I start by removing the 'validator="#{userBean.validateEmail}"' code from my h:inputText tag. I do this because when I get everything switched to Bean Validation, I will not need this JSF tag validation any more. I then put the custom annotation @Email above my UserBean.java property declaration for the "protected String email;" property. If I recompile at this point I get an error: UserBean.java:18: Cannot find symbol…symbol: class Email… So the compiler knows this is an annotation but it does not know about it yet…because I have not created that class yet.

Now I define the class that defines my annotation (code taken from (Ed Burns, 2010)):

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.validation.Constraint;

@Documented
@Constraint (validatedBy = EmailConstraintValidator.class)
@Target ({ElementType.METHOD, ElementType.FIELD})
@Retention (RetentionPolicy.RUNTIME)
public @interface Email {
String message() default "{validator.email}";

    Class<?>[] groups() default {};

    Class<? extends ConstraintPayload>[] payload() default {};
}

If you have never defined your own annotation before there a lot of mysteries to unfurl in this class. The two bits I think are the most important is the part that points to the class where our validation code is stored (…validatedBy = EmailConstraintValidator.class…), and also the bit which stores what message will occur should the validation indicate that (in this case) our email is not valid.


 
OK: so now when I try to compile Email .java, I get a complaint that package javax.validation does not exist. This is my JSF 2.0 manual says the Constraint annotation lives. So that means there is a jar out there I need to find somehow. This is not surprising since my manual (Ed Burns, 2010) says that this is a Java EE 6 (container) thing and not just a JSF thing. So…where to look…I am using glass fish, so I imagine that Glass Fish knows about this jar. Maybe if I ask it nicely, it will tell me where it is kept.


 
OK, I went looking through administrator's console, and there is nothing jumping out at me…like "find a jar with a known class in it". Maybe JDev fine search will prove useful…well not so much. Of course I was trying to use the search files tool. Maybe there is a different tool?


 
Meanwhile I went on a manual hunt through all glassfish jar files with suspicious names. Like for example there is a javax.annotation.jar Well, then!! That certainly sounds promising! But when I used VIM to inspect the contents of this jar file…I found…no javax.annotation.Constraint!! Very odd. I also searched for javax and annotation in all the files under the glassfish installation directory. It was not there. So: maybe glassfish does not offer Bean Validation? I thought it did since it was Java EE 6. But maybe it is not the Enterprise edition or the weaseldoodle's edition or some-such. I will have to ask what is going on with this when I get out of the sky in back into internet areas.


 
OK: so this is a good URL to know to find this JAR… http://jcp.org/aboutJava/communityprocess/final/jsr303/index.html


 
Javax.constraints.ConstraintPayload.class seems to be a hard one to track down. The JSR says that the reference implementation is hibernate validator. When I open that up I see the source contains one jar called validation-api-1.0.0.GA.jar but this has no class in it called ConstraintPayload. It does have a "Payload" class in it however. So then I tried to do a mvn install on the online code for chapter 8 for (Ed Burns, 2010) and it all built ok. His source included references to ConstraintPayload…so I reasoned that he must have a different jar. So I looked in his pom.xml for this code and it referred to bean-validator.jar, and referred to org.glassfish (great! That is what I am using!) and also JBoss (darn…not what I am using) and something about Beta (yikes!!). Sure enough there is a bean-validator.jar in my glassfish distribution (yay!!) also with no mention of ConstraintPayload.class (damn, damn, damn). Apparently I have to download a jar from http://download.java.net/maven/2//org/glassfish/bean-validator/3.0-JBoss-4.0.0.Beta3A/bean-validator-3.0-JBoss-4.0.0.Beta3A.jar


 
Jeez! I am beginning to wonder whether they renamed ConstraintPayload.class to just Payload.class…


 
And of course…this is correct according to http://opensource.atlassian.com/projects/hibernate/browse/HV-319 "Hardy Ferentschik added a comment - 06/May/10 4:55 AM --javax.validation.ConstraintPayload got renamed into {javax.validation.Payload}} for the final release of the Bean Validation spec…" Well, OK then. So I am going with the jar that came with GlassFish!! That is: bean-validator.jar, and change my ConstraintPayload.class references to Payload.class.

So now the class that defines the Constraint annotation refers to the Validator. But the Validator class also makes reference to the annotation class. So neither one can finish compiling it seems…? This is kind of annoying…how does maven compile this shit as is? It must compile twice, the first time suspending failing compilation if there is this kind of cross-reference. It must be some kind of directive that is made just for annotations…OK: I'm a forgetful so-and-so: the class path must contain either jar's (that I knew) or directories that contain the base of packages you need during compilation. Interestingly I see that the java compiler compiled both files when I only explicitly asked for the compilation of one file:

In the C:\sandbox\jsf2-0book\facelets1\target\facelets1\WEB-INF\classes\com\jsfcompref\model directory, I issued a successful compilation command of EmailConstraintValidator.java, when it was dependent on another class called Email.java in the same directory. Email.java had not been compiled yet, but it was valid except for a reference to the EmailConstraintValidator.java class.

In the compilation command, javac -classpath jsf-api.jar;jsf-impl.jar;bean-validator.jar;..\..\.. EmailConstraintValidator.java, we see adding ..\..\.. gives visibility to the directory that contains the com\jsfcompref\model directory which is the base of the package that Email and EmailConstraintValidator declared as being located in.

SSL/SSO/JAZN-enable iAS 10.1.3 that is authenticated with 10.1.2 OID

So our client's topology was iAS 10.1.2 infra with OID on machine 1, and two mid-tiers on machine 2 -- one 10.1.2 Portal instance and the other 10.1.3 J2EE (OC4J) instance with added OHS (HTTP Server) to enable Oracle SSO.

We would create portal pages, and put iframe calls to web-apps in the 10.1.3 iAS. Since both were SSO-enabled authentication and authorization was no problem. I believe I have covered how to SSO/JAZN enable 10.1.3 a year or two ago on a different blog entry for this same blog.

However, when we added SSL (terminating at the Web Cache) this iframe arrangement did not work out so well. This is for several reasons: one the military establishment with which we were affiliated had the rule that only port 443 shall be used/seen by external users. With the iframe arrangement, there were additional HTTP ports (i.e., the 10.1.3 HTTP Server port) that needed to be open on everybody's firewalls. This was unacceptable to our end-users.

The second nastiness we encountered was that while our computer hostname was one thing (according to dns), there was another alias that pointed to the same IP which was the external users moniker of choice for our mid-tier computer. So the 10.1.3 mid-tier and SSO registration wanted to use the host name, while all external references were to the alias. So, when it came time to register the SSL certificate, we had to pick one...we thought. So we picked the external alias. Either choice would have created nasty certificate errors when the other name was attempted to be used, because a certificate is often for a particular name...although we learned that (for a fee, of course) our certificate company would allow wild-cards.

So our end users hated the certificate errors, so we called Oracle Support. We worked with them, and what we worked out...really...is the topic of this blog entry.

In short we implemented the section in the following Oracle doc Oracle Application Server Administrator's Guide 10g Release 3 (10.1.3.1.0) B28940

The above doc contains some information in section 6.4 entitled "Configuring Oracle Application Server 10.1.2 with Oracle Application Server 10.1.3"

Note that for the opmn.xml entry we saw that the port element showed a remote port, which we used to create an entry such as the following:

<notification-server interface="ipv4">
<port local="6100" remote="6202" request="6005"/>
<ssl enabled="true" wallet-file="$ORACLE_HOME/opmn/conf/ssl.wlt/default"/>
<topology>


</notification-server>

... where 6200 was the remote port of the portal mid-tier and 6202 was that of the 10.1.3 mid-tier...as you can see in the "port" element above. Note that all we added was the <toplogy> element and its nodes child as per the doc I mentioned.

Also per the aforementioned doc, we altered the mod_oc4j.conf file. We added additional Oc4jMount entries to tell the Web Cache (I think? or maybe the HTTP Server) of the Portal instance to communicate with 10.1.3 instance whenever it saw a context-root (i.e., the part of the JSF web-app url that is right after the domain but before the "faces" bit. It designates with J2EE/Java EE app you are referring to on the server you are addressing with your URL. Some of these entries looked like this:

Oc4jMount /ContextRoot1 ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot1/* ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot2 ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot2/* ajp13://ourmachinename.oursite.org:8888

Note that we obtained the 8888 port by doing an "opmnctl status -l" on the 10.1.3 site, and looking for the primary ajp port for the OC4J to which our apps were deployed.

httpd.conf on the Portal/Web Cache instance we had been using proxy and reverse proxy entries for these two apps (as designated by the ContextRoot* designations above. We had to comment those out.

I appologize that I cannot give more details about SSL enabling the topology, because I was not really involved more with that process. It was involved though, and took the people that knew what they were doing 3 hours to hand-enable a pre-existing production topology as I described. That might give you an idea of what was involved in this SSL enabling process for this technology stack.

post-redirect-get in JSF 2.0

In Burns's and Schalk's JAVASERVER FACES 2.0: THE COMPLETE REFERENCE, the authors do some exercises regarding redirects. There are new facilities in JSF 2.0 to allow using redirect to easily follow the post-redirect-get convention (instead of the normal JSF post-forward convention). Now with these facilities we have bookmarkable url’s in our web browser. We also expose some of our parameters to whomever looks at their address line. Under some circumstances this is OK.

The conversion of a page that does not use this to one that does is pretty quick. I took the same book's registration application and converted it to use PRG (post-redirect-get) in one airplane ride (3 hours) and I only worked 2 of those hours, and I worked very slowly.

There are apparently two ways to communicate between pages that use redirect in JSF 2.0. One of them is to use a new “scope” called Flash. Flash allows you to store information between redirected pages; apparently request scope does not. Redirecting makes a second request, whereas the normal post-forward does the page/view navigation all in one request. So that means that things stored on request scoped managed beans will persist from one page to the next, while redirects will re-instantiate request scoped beans.

The other way to store stuff in between redirects is to pass parameters on the request url. Interestingly the new view parameter facility has the parameters defined on the page you are going to. If you define them on this page/view, then there they will be…on your request url, as if you had put them there yourself (which you did…indirectly ;-)

Interestingly enough, ADF 11g, the controller portion, has solved the same issue in JSF 1.2 with something called bookmarks. These bookmarks make a structure called a task flow compensate (like view parameters and redirecting combination in JSF 2.0) for the same issue. I suspect in the long run ADF will adopt JSF 2.0. I wonder if at that point, view parameters will have something to do with the implementation of bookmark parameters.

thread dump for OC4J JVM

To get a thread trace on a JVM, make sure your opmn java-options in your start-options does not include -Xrs. (If you had to remove it, be sure to restart your AS (maybe the OC4J restart would be enough...)) This -Xrs option reduces signaling capability. Then (in UNIX) you get the JVM process id to kill. One way is through Enterprise manager. In 10.1.3.4 EM, in your topological list of oc4j's, you should have a link showing how many JVM's you have for each oc4j you have in you iAS. If you click on this, the resulting page will show you your process id. If you then type

kill -3 <theprocessidyoujustlookedup>

and hit enter, your opmn log (you know: the one in $ORACLE_HOME/opmn/logs that has your oc4j's name in the middle of it, with tilde's in the name...*THAT* log) should display a lovely thread dump.

I wanted a thread dump because such a thing seems to be how Oracle characterizes their bugs against their iAS. So for example they might say, if a thread dump shows the following...then you have this problem...and here's how to fix it.

Thanks to Mike Lehmann for his helpful article, which you can see, is just a click away; I basically took what he did, distilled it and added the things I had to go look up.

JSF 2.0 exploration notes

As I embark along the path to learning JSF 2.0 from a having a fairly firm, intermediate grasp of JSF 1.1/1.2; I am following Burns and Schalk’s JSF 2.0: the complete reference. I got my current grasp of JSF in no small part from studying and referring to their book by the same name which pertained to JSF 1.1/1.2. In that former book they started you off doing the assembly of the deployable war by hand from the source code which they walked you through in the book in detail. The newer book starts similarly, except that the new book seems to rely on Maven to construct the war file. While I have maven installed on my machine, my lack of the downloadable pom file from the book’s on-line downloadable source code website, the book’s failure to spell out the pom file (probably due to size??) in the text of the book, the fact that I am on an airplane and unable to download anything, and my undeniable stubbornness – all these things add up me now assembling the exploded war directory by hand – according to the book’s documentation of what this exploded directory structure should look like and what it should contain. When I have this, I will use jar –c to build a war file because I just don’t have the patience to wait until I get off the plane to build my first JSF 2.0 program! I will have to go from memory and jar --help and experimentation to accomplish this. Wish me luck!
Some observations so far: jsf-api.jar and jsf-impl.jar seem to be all you need to compile a JSF 2.0 program (which does not use any external libraries). That is to say…no more standard.jar, or commons*.jar any more…which is not surprising, since JSF 2.0 is based on Facelets, and not JSP/JSTL etc. Also: no more faces-config.xml (if you don’t want to); you can go with all annotations if you want that.

After I installed java 1.6 JDK, set up the exploded directory copying the xhtml to the exploded directory’s root directory, copied the two jsf jars into the WEB-INF/lib and the source packages into the WEB-INF/classes directory of my exploded directory, and the web.xml file into my WEB-INF directory, I executed the following command:

javac -classpath ../../../../lib/jsf-api.jar;../../../../lib/jsf-impl.jar UserBean.java

…where UserBean.java is the book’s first sample class (backing bean/request-scoped-managed bean).
Then I went to the root directory of the exploded directory and executed the jar command to make the war:

C:\sandbox\jsf2-0book\personaltrainer\target\jsfreg>jar cvf jsfreg.war *
added manifest
adding: register.xhtml(in = 2690) (out= 730)(deflated 72%)
adding: WEB-INF/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/com/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/com/jsfcompref/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/com/jsfcompref/model/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/com/jsfcompref/model/UserBean.class(in = 2305) (out= 109
1)(deflated 52%)
adding: WEB-INF/classes/com/jsfcompref/model/UserBean.java(in = 2378) (out= 757)
(deflated 68%)
adding: WEB-INF/classes/com/jsfcompref/model/UserBean.java~(in = 2377) (out= 754
)(deflated 68%)
adding: WEB-INF/lib/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/lib/jsf-api.jar(in = 591845) (out= 530662)(deflated 10%)
adding: WEB-INF/lib/jsf-impl.jar(in = 1816536) (out= 1682891)(deflated 7%)
adding: WEB-INF/web.xml(in = 883) (out= 384)(deflated 56%)

C:\sandbox\jsf2-0book\personaltrainer\target\jsfreg>dir
Volume in drive C is SW_Preload
Volume Serial Number is B2D3-A76F

Directory of C:\sandbox\jsf2-0book\personaltrainer\target\jsfreg

03/05/2010 07:56 PM <dir> .
03/05/2010 07:56 PM <dir> ..
03/05/2010 07:56 PM 2,219,418 jsfreg.war
02/28/2010 07:37 PM 2,690 register.xhtml
03/05/2010 07:10 PM <dir> WEB-INF
2 File(s) 2,222,108 bytes
3 Dir(s) 111,780,872,192 bytes free

I am confident (grin) that this war file will deploy ok on the glass fish web server that I downloaded and have yet to try (at least after I correct all my typos) from copying the book’s code manually.)

Looks like I am already using port 8080, so I will need to ask glassfish nicely to use some other port as its default… (or Oracle XE…that seems to be the other user of this port number…). Oh well: the trip back.

3/14/2010 8:23:25 PM

OK, I finally got my own code going…that is to say…the code I tried to copy manually form chapter 1 I finally got to run on glassfish app server.

Apparently I had made a number of critical typos, which has interesting results. The most interesting of these was the mistakes I made in the web.xml file:
1. In the root element (web-app?) the xsi:schemaLocation attribute’s value has a couple of places in it where it should say “…/xml/…”. For some reason I had mistakenly typed “…/sml/…”. This letter difference was enough to confuse the html server for glass fish in to responding with a 404 code, saying that a “resource” was missing. Obviously that was not a very helpful error. Once I got through that however there was …
2. In the servlet-mapping element I had a sub-element defined called url-mapping. I should have called this sub-element url-pattern instead. This however kept deployment from happening properly.

After solving these errors, I had to correct three minor typos in register.xhtml, then things worked fine. These typos were mine, not the book’s – I am sure.

Anyway, as I was getting things in running condition, I remembered reading that I could deploy on glass fish as an exploded directory. I had done such a thing on weblogic server (when it was still bea weblogic (10.3 I think)). Up until trying to do this on glassfish, I had been using the jar command above to package things up as a jar in between changes. I got pretty quick at it, but not quick enough to compete with the speed of working on an exploded directory and just recompiling when necessary.

So basically I just deployed the root directory I had been jar-ing up, and it worked fine. I made a change or to to the xhtml files, and hit f5; then I saw the changes I had just made. Great!

Back to the book now for more information…

4/16/2010 7:26 PM

So some new things I have learned today about JSF 2.0:
1. On page 96 of [Burns] is a section called invoking arbitrary methods in EL. This means that, for instance, if you have a method that returns a string you can conjure up an expression like the following, and put it right in the middle of your page: #{myManagedBean.myMethod(someOtherManagedBean.property1, anotherManagedBean.property2)} (BTW: the caveat here really got my attention: this kind of invocation in EL is only available if your EE6 container is Java-based. I was not aware there were any other EE6 containers besides Java-based EE6 containers.)
2. …

I next want to talk about Facelets. I have made a stab or two at working with Facelets. Now that I am studying JSF 2.0, Facelets is the standard, not JSP any more

So in my first experiment, I took the files (the little registration program in chapter 3) and tried to use the templating concepts presented in Chapter 4 a reality; so I got the template file and template client file which references the template through the ui:composition tag. But when I start referencing the template instead of the full page I had in the register.xhtml page I get the following errors:

• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix body but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix title but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix tr but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix tr but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix html but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix td but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix table but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix h1 but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix head but no taglibrary exists for that namespace.
• Warning: This page calls for XML namespace http://www.w3c.org/1999/xhtml declared with prefix meta but no taglibrary exists for that namespace.

Here is the error I made to cause that:

<html xmlns="http://www.w3c.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">

Can you see it? I could not, but the error message kept driving me back to this line…here is how it is supposed to be:

<html xmlns=http://www.w3.org/1999/xhtml …

Now can you see it? I had to see a file that was working side by side to get it. I typed “w3c” instead of “w3”. I thought w3c was the name of the domain. Oh, well: live and learn.

ADF/BC JDBC to retrieve structured data from packaged function

Got a request for code to show how to retrieve a collection of structured data (Oracle Type Objects) using JDBC in an ADF/BC scenario. The first parameter is the name of the Oracle Type that is the collection of your structured data type.

public Object callStoredFunctionReturningArrayOfRecords(String pfunctionReturnType, String stmt,Object[] bindVars) throws SQLException {
oracle.sql.STRUCT [] returnArray = null;
String [] recordArray = null;
Connection conn = getDBTransaction().createStatement(1).getConnection();
//Connection conn = getConnection();
// Now, declare a descriptor to associate the host array type with the
// array type in the database.


ArrayDescriptor arrayDescriptor=ArrayDescriptor.createDescriptor(pfunctionReturnType, conn);
// example:  StructDescriptor structDescriptor = StructDescriptor.createDescriptor("TEST_ARR_OF_REC_TYPE", conn);


// Create the ARRAY objects to associate the host array
// with the database array.


oracle.sql.ARRAY returnARRAY = new oracle.sql.ARRAY(arrayDescriptor,conn,returnArray);

OracleCallableStatement st = null;
try {
// 1. Create a JDBC CallabledStatement
st = (OracleCallableStatement)getDBTransaction().createCallableStatement(
"begin ? := " + stmt + ";end;", 0);


// 2. Register the first bind variable for the return value
st.registerOutParameter(1, OracleTypes.ARRAY, pfunctionReturnType);
if (bindVars != null) {
// 3. Loop over values for the bind variables passed in, if any
for (int z = 0; z < bindVars.length; z++) {
// 4. Set the value of user-supplied bind vars in the stmt
st.setObject(z + 2, bindVars[z]);
}
}
// 5. Set the value of user-supplied bind vars in the stmt
st.executeUpdate();
// Associate the returned arrays with the ARRAY objects.


returnARRAY = (oracle.sql.ARRAY)st.getARRAY(1);
// OracleResultSet mainRS = (OracleResultSet)st.getResultSet();
// ARRAY anotherARRAY = mainRS.getARRAY(1);


// Get the data back into the data arrays.
// NOTE: I got an NPE on the following line at one point...not sure why...
// I saw this error in opmn log; not sure if returnARRAY was null or
// if there are special rules about casting null into an array.
Object[] oarray = (Object[])returnARRAY.getArray();
// Object[] oarray = (Object[])anotherARRAY.getArray();


for (int i = 0; i < oarray.length; i++) {
oracle.sql.STRUCT struct = (oracle.sql.STRUCT)oarray[i];//new STRUCT(structDescriptor, conn, recordArray);
StructDescriptor structDescriptor = struct.getDescriptor();
ResultSetMetaData rsmd = structDescriptor.getMetaData();
Object [] attrs = struct.getAttributes();
if (rsmd != null && attrs != null && attrs[0] != null && attrs[1] != null) {
getLogger().fine("nested row [" + i + "]: " + rsmd.getColumnLabel(1) +
" " + attrs[0].toString() + " " + rsmd.getColumnLabel(2) +
" " + attrs[1].toString());
}
}
// 6. Return the value of the first bind variable
return oarray;
} catch (SQLException e) {
throw new JboException(e);
} finally {
if (st != null) {
try {
// 7. Close the statement
st.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
}

dojo and JSF integration page unload solution when auto-saving

If you have integrated dojo and JSF in the way described here in the authors' first method of integration, the you probably ran into a problem of how to copy the values back to the hidden field -- if you are trying to implement an auto-save feature.  In other words, if you want to allow a user to not have to click a link/button in order to save their changes then you must find some other client event to tap into.  I believe the authors of that article I referred to used an example for their first method which simply used onclick of a button to save back a value.

For the purposes of my auto-save feature, I went with something much more piggy:  onkeyup for the dojo field itself.  So with every keystroke I copy back the value to the hidden field.  This fix was quick, and it really is not that slow.

For a more efficient implementation, you could program javascript to wait 5 seconds after every keystroke, then check to see if the value has changed, but I wonder if the simple copy would be more efficient than all that...probably!

ADF dialog framework simplified?

If you can overcome about any (needless) fear you might have about implementing a custom JSF NavigationHandler, you can actually open up your applications for many new possibilities.

The focus of this blog post is not how to create custom JSF framework extensions.  It is just this:  every time you use ADF's dialog framework (where you create an navigation outcome of the form "dialog:...", set useWindow in the af:commandButton/Link to true, partialSubmit to true) it is possible to create a bit of custom NavigationHandler code that simply launches a dialog window programatically instead of doing the normal navigation function. 

I tried this out because I was "forced to" due to a quirk of af:commandButton/Link which somehow has useWindow property ignored when inside of an af:iterator.  So I tried to think of the spot where it made the most sense to programmatically call up the dialog...duh!  The NavigationHandler of course.

JSF 2.0, Part I.b.

Initially the example I got working was just the downloaded code from the book.  Since then I also found out why my own assembed version (copied from the text of the book) did not work.

The short answer is:  I made some typos.

The longer answer is that:  I discovered that in web.xml, the JSF runtime is very sensitive to inaccuracies in the root node attributes.  I guess I thought they were not that important, but jsf runtime could not even run my application without correcting a typo in these attributes.  Before I corrected this typo I kept getting a "resource cannot be found" or something like that.

After that correction, I still had several more typos, but for each there was a sensible JSF error to help me find it, unlike the first.

Also used maven to compile the book's examples...first on-line...then on a different example...offline.  maven is such a boon the way it downloads what it needs the first time you run it, so that if you run it again on the same pom...or one with similar dependencies...it uses what it downloaded the last time to assemble things.  Very cool.

I should also mention in Glassfish that I deployed my exploded directory also, so now I can change xhtml files on the fly and just refresh the page and I see my page with the new changes in it when running the Glassfish JSF 2.0 app.