My facelets are no longer parsed – an adventure in Google and Java
The new feelitlive.com website is powered by Seam running over Hibernate and JSF. The stuff you see – the HTML source code – is generated by Facelets.
Facelets is a layer over JSF and the two work well together. I have mixed feelings on JSF – I don’t think I’d use it without the corrections made by Seam – but the combination of Facelets+JSF+Seam is quite compelling – once you get it set up. If you are an ex-ASP.NET guy like me then Facelets is equivalent to the union of “master pages” and “user controls”. JSF is equivalent to the whole supporting notion of “controls” in ASP.NET, but has has a cleaner separation of front and back end logic.
In Facelets the “master pages” part is known as “templating” and gives you a template for the whole page. Your content is added into the middle.
The “user controls” feature is known as “composition components” and gives re-useable blocks that you can drop into the page or template ad-hoc by simply adding a namespace qualified element. These are used all over feelitlive.com for everything from individual links and images to whole blocks of content.
my composition components were not being parsed
So, I was a little shocked to find that all of a sudden my composition components were not being parsed! Though live for months, half the site was now simply missing; little bits of each page eaten away like swiss cheese!
I had moved to using Netbeans and was focusing on a backend web service so hadn’t actually run my homepage from my development machine for a week or so. When I went to do so, the templates and every built-in tag library was working, but the tag library containing my composition components was not parsed or executed. In facelets the tag libraries are assigned a URL and that URL becomes the the XML namespace in the XHTML source file – today all the XML in my own namespace was simply transferred into the output verbatim.
So, I scoured my change-log for evidence of any relevant changes I might have forgotten. I found nothing that even the most desperate coder would choose to consider related. I tried building from the command line – still no joy.
Netbeans was using the very latest Apache 6.0.20, so I tried the locally built WAR in three different versions of Apache including the version used in live – nothing. So “great”, I thought, “I can’t even release untested code if I wanted to”.
Thinking of the live server gave me an idea, so I downloaded the WAR file running from live and ran that in two of the Tomcat versions I had locally. Nothing. “Huh? Surely that should work”!
What about the JVM? Nope, my JVMs didn’t seem to have changed. This was mysterious – I’m sure I remembered an update arriving, but then I have three computers I use regularly.
So, no clues. Stuck. I’m a team of one on this project so nobody to ask. I could possibly change JVM anyway, though I’m not sure what I’d change it to, or where to get an older version. Possibly I could try downloading old versions of the code and trying to do a binary search for the change that caused it, but that’s assuming a code change had caused it and nothing logged looked likely. I could waste a lot of time on this one!
understanding this issue was secondary to fixing it
I left those two ideas untried, because something else occurred to me. Some stuff was working – the built in tag libraries. These are packaged in the facelets JAR and I could see them being picked up by facelets in the tomcat log. My tag lib was not being picked up. I decided that understanding this issue was secondary to fixing it, and went about building a version of my tag library in a separate JAR, breaking it out of its home inside the main WAR file, and hoping that making it look more like that stuff tat worked would cause it to work.
I followed the layout of the seam-mail JAR, but this doesn’t use composition components – only custom components. So I added my existing folder full of XHTML fragments into “META-INF/facelets” with the “fil.tablib.xml” in “META-INF”. My fragments were already identified as “facelets/fragment.xhtml”. I created a separate Maven project for all that, added it to the parent POM as a module, to the WAR as a dependency.
I built the new JAR, then built the WAR.
I then checked the layout was showing up okay in the “Libraries” folder in Netbeans – the JAR layout matched the ones that were picked up. Good.
Build again – can’t hurt.
Right click — run.
Wait.
Drum roll.
Bang! It worked – phew.
So what. The hell. Was that all about…..
Googling was useless
I don’t know. I still need to check it all over to make sure its all there back working, but frantic Googling was useless on this one so I wanted to share the adventure and the solution out of pity for the next developer down the road. I’d also like to make an observation about the process of searching for a solution on line.
This problem occurred near the top of a stack of technology starting at Windows XP, then Sun’s JVM, Apache’s Tomcat, JBoss’ Seam, then my code and finally Sun’s Facelet’s implementation. The stack could have been interfered with by the IDE – Netbeans – and the build tool – Apache’s Maven, or by any Maven plugin I’m using. Searching the web for the phrase “facelets composition components are no longer parsed” gives you a blog post saying “please use my new site at [blah], I will no longer be keeping this one up to date” even the migrated article was not relevant, but did mention facelets. Fail. Big stinking fail.
What I needed was to find all documents – blog and forum posts, bug reports, and knowledge base articles – related to any of the technology components I listed and to the feature of “Facelets” called “composition components”. Properly understood, that is a small set of documents. Bonus points would have gone to the search engine that allowed me to select my symptoms from a list (they are not uncommon) but using supplied keywords to rank with would be good enough. A find-engine like this could have also offered an alert service and gone to work trying to find more results over a course of days, even monitored new bug reports and forum posts for results.
I got my answer after about 5 or more hours of work spread over two days. I’d have been jubilantly happy to have had my answer after 2 hours. Others might be happy with 6 rather than 24, or 24 rather than 72, but I don’t think it would have taken anything like that long. I think you could do this kind of thing in interactive time, but the point is it doesn’t need to be that fast to be useful. I can always find other stuff to do as long as I can expect an answer. With Google I can’t get that answer without reading thousands of pages, and without hope of the answer being there.
Of course, linked data is the only current technology likely to ever offer answers to this sort of query. It involves too much precise classification and description for a statistical-web approach. How do statistics tell you the release history of the Maven plugins which are used to build WAR files? They don’t. How do statistics provide an unambiguous list of the features in Facelets? They don’t. The runtime dependencies of JSF? Likewise. Can statistics help to rank pages according to the nature of their relationship with other concepts? Can stats weight pages directly related to given concepts over those with links to concepts two degrees apart? Maybe. Placing problem reports over brochures, or holding that product components are more relevant than competitive products? Unlikely.
People say we don’t need semantic search because we can always add keywords, or they put up ridiculous road blocks because they think its “too hard”. Don’t they ever encounter issues like this one? Really? This is long tail stuff, but its definitely worth addressing. Those five hours were worth over £200. Once it exists I will use the web site that does this, I’d even pay a fee for the privilege.
