1

We decided to upgrade to JSF 2.0, unfortunately this didn't work very well. We now have Mojarra, Tomahawk 2.0 1.1.11, Spring Webflow / Faces 2.3.0 and JSF 2.0.

I followed the upgrading tutorial from BalusC. The first step was to fix the the web.xml and move to Servlet API 2.5.

<context-param>
    <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
    <param-value>/WEB-INF/facelets-taglibs/custom.taglib.xml</param-value>
</context-param>

<!-- Use JSF view templates saved as *.xhtml, for use with Facelets -->
<context-param>
    <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
    <param-value>.xml</param-value>
</context-param>

After this I replaced the dependencies and used the new versions of JSF.

<dependency>
  <groupId>com.sun.faces</groupId>
  <artifactId>jsf-api</artifactId>
  <version>2.0.3</version>
</dependency>

<dependency>
  <groupId>com.sun.faces</groupId>
  <artifactId>jsf-impl</artifactId>
  <version>2.0.3</version>
</dependency>

I adjusted our custom taglib and migrated to the new XML schema definition,

<?xml version="1.0" encoding="UTF-8"?>
<facelet-taglib version="2.0"
  xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
                 http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd">

<namespace>http://www.custom.org/facelets-taglib</namespace>

[...]

I've also done all changes to the faces-config.xml.

This is one of my *.jspx files. 

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" version="2.0"
  xmlns:jsp="http://java.sun.com/JSP/Page"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:c="http://java.sun.com/jstl/core"
  xmlns:sf="http://www.springframework.org/tags/faces"
  xmlns:os="http://www.custom.org/facelets-taglib">
     [...]
     ${os:json()}
</html>

Before the migration this file worked great, it's a call to a specific function. Now it prints:

Caused by: javax.faces.FacesException: /WEB-INF/views/example.jspx(10,2) 
        The attribute prefix os does not correspond to any imported tag library
    at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:115)
    at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135)
    at org.springframework.faces.webflow.FlowLifecycle.render(FlowLifecycle.java:80)
    at org.springframework.faces.webflow.JsfView.render(JsfView.java:90)
    at org.springframework.webflow.engine.ViewState.render(ViewState.java:296)
    at org.springframework.webflow.engine.ViewState.refresh(ViewState.java:243)
    at org.springframework.webflow.engine.ViewState.resume(ViewState.java:221)
    at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
    at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:261)
    ... 67 more
Caused by: org.apache.jasper.JasperException: /WEB-INF/views/example.jspx(10,2) 
        The attribute prefix os does not correspond to any imported tag library
    at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
    at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
    at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:148)
    at org.apache.jasper.compiler.Validator$ValidateVisitor$1FVVisitor.visit(Validator.java:1509)
    at org.apache.jasper.compiler.ELNode$Function.accept(ELNode.java:129)
    at org.apache.jasper.compiler.ELNode$Nodes.visit(ELNode.java:200)
    at org.apache.jasper.compiler.ELNode$Visitor.visit(ELNode.java:242)
    at org.apache.jasper.compiler.ELNode$Root.accept(ELNode.java:56)

Can you give me any hint where I did miss something or where a possible bug could hide? Thank you very much!

Community
  • 1
  • 1
Christopher Klewes
  • 10,311
  • 15
  • 71
  • 101
  • 2
    The exception is basically telling that `/WEB-INF/facelets-taglibs/custom.taglib.xml` cannot be found. Are you certain that the filename is correct and that namespace is correct (case sensitive!). I also see that you're using Maven, can you ensure that the `/WEB-INF/facelets-taglibs/custom.taglib.xml` file is also really there in the deployed WAR file in the target container? – BalusC Aug 09 '11 at 17:15
  • The name is definetily correct, I only make it anonymous, by removing the project name. The namespace is correct (and case sensitive). Also the `custom.taglib.xml` is in the deployed war. We additionally have `SpringApplication` which extends javax.faces.application.Application.Application, it loads some components from spring. Can there be an error? Or a new method which is not implemented correctly? – Christopher Klewes Aug 09 '11 at 17:35
  • 1
    Wait... You're using JSPX instead of Facelets! Not sure if this is the cause because I've never used JSPX for JSF2, but try renaming `.jspx` to `.xhtml` (and also removing the now superfluous `xmlns:jsp` taglib). Remove also that `javax.faces.DEFAULT_SUFFIX` context param. It defaults to `.xhtml` already. Let me know if that solves the problem, then I'll turn this comment into an answer. – BalusC Aug 09 '11 at 18:40
  • I'll try it tommorow and let you know for sure! Thank you for your help. – Christopher Klewes Aug 09 '11 at 21:25
  • 1
    The problem to deal with .jspx files was handled in JSF 2.1, thanks to some guys that maintains MyFaces Trinidad. See [Appendix A 1.2.1.1](http://jcp.org/aboutJava/communityprocess/mrel/jsr314/index2.html) The facelets-processing element. Enabling this, you can read .jspx files with facelets engine and keep changes to minimal. – lu4242 Aug 10 '11 at 01:30
  • I can't use JSF 2.1.x because it's not running on tomcat unfortunately. – Christopher Klewes Aug 10 '11 at 07:18
  • @BalusC: These hints really did the trick! Thank you, you should create this as answer, I will accept it. – Christopher Klewes Aug 10 '11 at 09:36
  • I posted it. By the way, Mojarra 2.1.1 and newer should work fine on Tomcat/Jetty. Mojarra 2.1.0 has indeed a major bug where Glassfish-specific annotation scanning code was accidently been embedded in the source. http://javaserverfaces.java.net/nonav/rlnotes/2.1.0/issues.html – BalusC Aug 10 '11 at 12:10
  • MyFaces 2.1.x works on Tomcat without problem. In theory there is no reason why JSF 2.1 could not run on tomcat 6.x or 7.x, so maybe it is an specific bug on Mojarra. – lu4242 Aug 10 '11 at 19:40
  • @BalusC: You mentioned that Mojara 2.1.1 should work fine on Tomcat, but the release notes says something different, are you sure? http://javaserverfaces.java.net/nonav/rlnotes/2.1.1/releasenotes.html – Christopher Klewes Aug 12 '11 at 11:31
  • I only had a problem with SWF 2.3, I fixed this issue by adding `#isReleased()` to the wrapper context. – Christopher Klewes Aug 12 '11 at 11:56

2 Answers2

2

You're using JSPX instead of Facelets. This is not going to work flawlessly on JSF 2.0. If upgrading to JSF 2.1 where JSPX is been supported is not an option, then you need to rename your .jspx files to .xhtml and remove the now superfluous xmlns:jsp taglib declaration. Remove also that javax.faces.DEFAULT_SUFFIX context param which defaults to .xhtml already.

BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
1

The problem to deal with .jspx files was handled in JSF 2.1, thanks to some guys that maintains MyFaces Trinidad. See Appendix A 1.2.1.1 The facelets-processing element. Enabling this, you can read .jspx files with facelets engine and keep changes to minimal. In few words just add this on your faces-config.xml:

<faces-config-extension>
    <facelets-processing>
        <file-extension>.jspx</file-extension>
        <process-as>jspx</process-as>
    </facelets-processing>
</faces-config-extension>

And maybe configure javax.faces.FACELETS_VIEW_MAPPINGS or javax.faces.DEFAULT_SUFFIX web config param to add the jspx extension.

After this, maybe the only problem you could have is translate you old jsp tags into facelets TagHandler, and maybe convert EL functions into facelets functions. I think that is an easy task and it is worth to do it. Note with the other alternative (convert to xhml) anyway you'll need to do this step too.

This alternative has the advantage that you don't need to change your existing navigation rules or page extensions, so from JSF spec point of view this alternative is preferred.

If you have more questions about this you can suscribe to MyFaces Users and Dev Mailing Lists and ask questions there.

lu4242
  • 2,268
  • 1
  • 13
  • 15