Ternary Expressions Problem with JSF 1.2

This is a followup on my previous post that offered a workaround to this error message, as seen when working with JSF 1.2:

javax.el.ELException: Error Parsing: 
Caused by: com.sun.el.parser.ParseException: Encountered ":text"

In my first post, I failed to find the root cause, so I took the path of least resistance in the interest of the project schedule (using the heavy-handed approach of two separate panel groups, backing the condition out to the "rendered" attribute of each group). As it turns out, the root cause is lack of white space around the colon, as explained in this article from Oracle. That is, given an expression:

#{isThisTrue?doThis:doThat}

...and depending on what the deployment environment is, you'll either notice nothing or bump into this error message. When that first post was written, I was deploying to Glassfish 8.x - and I needed to use the workaround described above. Recently, I deployed to JBoss 4.x and later to 5.1, and here I did not notice anything - but then I redeployed to embedded Jetty 6.1.x, and the problem re-appeared. This is probably because JBoss shielded me from needing the magic combination of JSF, JSP, Facelets, JSTL and etc. to make things work, but vanilla Jetty does not.

In either event, you might have better luck than I with determining the dependency mix, including tweaking the web.xml to configure the correct expression factory, trying various permutations of Jetty's JSP libraries, and etc. (aka "time sink"); but, more simply, the fix is to change the problematic expression (well, actually it's a bug in JSF 1.2) to this:

#{isThisTrue?doThis : doThat}

This time, I googled for the right thing ("JSF 1.2 ternary parse exception") and, by now, the article from Oracle had finally been published (it wasn't there until after I originally bailed out with my workaround).

Netbeans 6.7 + JBoss 5.1 Library Dependencies

Moving my IDE from NetBeans 6.1 to 6.7.1 (not a GA, but the nightly build 200906051401) resulted in failure in my web application compilation. I had pointed NetBeans to the same JBoss 5.1 installation as I used in NB 6.1, and associated my web app project with that server, so this "should" have worked, but did not. I don't have the time to analyze exactly why, so I won't discuss that; instead, I'll just provide the solution:

1. Create a NetBeans library (named e.g. JBoss-5.1-Common) that points to all jarfiles under $JBOSS_HOME/common/lib, and add that to your project. Make sure to uncheck the Package checkbox for that library or it'll be added to your deployed warfile, which could result in classloading problems
2. Add the JSF 1.2 library that comes out of the box with NetBeans - again, uncheck the Package option for the same reason.

This should address compile-time issues, or more accurately I should say "it worked for me".

Tip: Use Facelets 1.1.15 in JBoss 5.x

I've begun my research into RichFaces, and decided to actually read their developer guide instead of just winging it. Sometimes I do crazy things, I know. Anyway, one of their initial suggestions was to get a plain JSF application in place and working, and I thought this was a decent starting point - that way, any anomalies could be more easily traced as I added RichFaces stuff.

So I put a plain vanilla Facelets-JSF app together (i.e., one that doesn't use a third-party component set, like IceFaces or RichFaces) , and got it working just fine on JBoss 4.2.2 (here I'm using Facelets 1.1.14). However, with my migration to JBoss 5.1, this rather dumb prototype stopped working, with this exception on initial deployment of the webapp:

SEVERE [compiler] Missing Built-in Tag Libraries! Make sure they are included within the META-INF directory of Facelets' Jar
15:35:25,318 SEVERE [viewhandler] Error Rendering View[/index.xhtml]
java.lang.NullPointerException
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:524)
.............

On subsequent page loads, the "Missing Built-in Tag Libraries" message stopped appearing, but the NPE on NamespaceHandler continued to happen. Googling on the NPE was not entirely fruitful, but searching against the tag libraries problem led me to various known solutions; I addressed it by using the 1.1.15 version of Facelets.

For decent guidance on constructing a simple Facelets web app, here's a nice Facelets tutorial.

Netbeans + JBoss 4.2/5.x + IceFaces + Facelets: Gotcha

On creating a new WebApp project in NetBeans 6.x, I noticed a number of frameworks offered that support various technologies. Since I was prototyping a JSF-Facelets app, I chose the Facelets framework; as a result, NetBeans added the jsf-facelets.jar to my project libraries (which means these jars would be deployed as part of the warfile). I'll now file that decision in the "seemed like a good idea at the time" category: NetBeans users, here's a heads-up; please read on.

My goal was to compare RichFaces and IceFaces component sets (about which I'll post my findings later). Starting with IceFaces 1.8, I added dependencies as their documentation guided me for the JBoss 5.x app server - including the icefaces-facelets.jar, which I assumed was their own icefaces-specific layer above the standard Facelets distro. As it turns out, not so much.

On putting together a simple JSF page with Facelets tags, the page load yielded this exception:

java.lang.NullPointerException
com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse(D2DFaceletViewHandler.java:268)
com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:153)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
........

This seemed to point to a problem between IceFaces and Facelets, so my first instinct was to think that JBoss 5.x already had the Facelets classes loaded, and I was confusing things by adding my own version of these. As it turned out, I was on the right track...but more blind leads were to follow: in trying to reload the page, I got this exception:

java.lang.IllegalStateException: BaseClassLoader@144e022{vfsfile:}
classLoader is not connected to a domain (probably undeployed?) for class
javax.servlet.jsp.SkipPageException

This made me think that the removal of the Facelets jar was a mistake. Actually, no it was not; my mistake was trying to reload the page too quickly after redeploying. JBoss 5.0 takes a bit longer to complete a redeployment than I expected; had I simply waited another 5-10 seconds before reloading the page, I would have seen my original NPE problem solved instead of thinking I'd traded it for a different one.

What made this more confusing was that I tried the same webapp in JBoss 4.2, and had no problem at all. The IceFaces documentation around dependencies for JBoss 4.x vs 5.x is exactly the same; so it was mysterious why the webapp would work OK in 4.2 but not in 5.x.

After a bit more experimentation, I stumbled on the answers to all of the above:

1. The standard Facelets jar should not be deployed when icefaces-facelets.jar is deployed; the latter appears to be an IceFaces-specific adaptation of the standard. This means NetBeans users should not choose the Facelets framework for a new WebApp project if they are going to be using Facelets with IceFaces.
   
2. JBoss 4.2 classloading masks this issue by (apparently) loading the IceFaces version of these classes instead of the standard version, so things worked out just fine with 4.2.
   
3. JBoss 5.0 loads the standard version of Facelets classes first (apparently), hence the problem.
4. JBoss 5.0 redeployment of webapps takes a bit longer than you'd expect - in fact I noticed the TomcatDeployment mechanism undeploying/deploying my webapp three times before it finally stabilized, at which point page reloads will succeed without the misleading IllegalStateException.
5. JBoss 5.1 redeployment goes by much faster; TomcatDeployment undeploys my webapp only once.

Problem with ports-03 binding in JBoss 4.2

If you're setting up multiple instances of JBoss 4.2.x, you might run into this problem with the 3rd alternate configuration (ports-03).

There's a good writeup here for guidance on setting up multiple instances; I won't go into the motivation for doing it, let alone any details around how to do it here. I'll just assume you're reading this because you already know what I'm talking about - the topic at hand is already esoteric enough to require some prior knowledge, and I'd like to keep this post short.

When I set up a process to use the ports-03 binding, error messages appeared on deployment stating "Address already in use" for port 4446. Examining the binding-manager.xml file, I found that the service-config section that should override that default port was missing - and since my process using the default bindings was already running, the port conflict happened. Fix this by adding a copy of the "remoting connector" service-config section to the ports-03 configuration, changing the port to (e.g.) 7446, restart...and now you'll find that port 3873 has the same problem. Fix this by adding a copy of the "EJB3 Remoting Connector" section, changing the port to (e.g.) 4173, restart and you should be good to go.