6 Replies Latest reply on Mar 1, 2010 4:56 PM by dbixler

    Issue with some Richfaces tags

      I finally got Richfaces working on the lasted release in Jboss, but am receiving the following exception:

       

      <rich:dataGrid> Tag Library supports namespace: http://richfaces.org/rich, but no tag was defined for name: dataGrid

       

      Other tags work, only some of the data iteration tags do not.  I'm using 3.3.3.CR1 libraries for JSF2.  I also verified that the TLD was in the jar file as well as the supporting class.

       

      Does anyone have any suggestions for what can be going wrong?  The pertinent parts of the file are:

       

      <html xmlns="http://www.w3.org/1999/xhtml"
      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:a4j="http://richfaces.org/a4j"
      xmlns:rich="http://richfaces.org/rich">

       

      ...

      <rich:dataGrid columns="2" elements="6" value="">
      Test
      </rich:dataGrid>

      ...

      Nothing special that I can see.

        • 1. Re: Issue with some Richfaces tags
          nbelaevski

          Hi Dave,

           

          TLD files are not used bu Facelets. Can you please check if *,taglib.xml contains the tag?

          • 2. Re: Issue with some Richfaces tags

            Wouldn't the taglib.xml be found in one of the richfaces.jar files?  I'm assuming richfaces-ui-3.3.3.CR1.jar.

             

            If that is the case, there are a bunch of them:

             

            a4j.component-dependencies.xml

            a4j.taglib.xml

            ajax4jsf.taglib.xml

            jsp.taglib.xml

            rich.taglib.xml

            richfaces.taglib.xml

             

            I searched through rich.taglib.xml and found:


            <tag>

                <tag-name>dataGrid</tag-name>

                <component>

              <component-type>org.richfaces.DataGrid</component-type>

                  <renderer-type>org.richfaces.DataGridRenderer</renderer-type>

                          <handler-class>org.richfaces.taglib.RowKeyConverterComponentHandler</handler-class>

                    </component>

              </tag>


            And that class does, in fact, reside in the correct place in the JAR file.  I also verified that this JAR file, is inside of the WAR file that gets deployed on the server.
            • 3. Re: Issue with some Richfaces tags
              nbelaevski
              Yes, ti should be there. Please clarify what JBoss version is used.
              • 4. Re: Issue with some Richfaces tags
                I'm using 6M2.  So I started diving into things a little more and made some changes to my web.xml file because I think it may have something to do with the filter.  Per the documentation, I added: 

                <context-param>
                          <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
                          <param-value>true</param-value>
                </context-param>


                Which had the effect of completely disabling processing of any tags in the XHTML file (not too surprising).  Next I added:

                <context-param>
                <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
                <param-value>com.sun.facelets.FaceletViewHandler</param-value>
                </context-param>


                Which caused the exception about the FaceletsViewHandler not being found.  I then included the JAR file:  jsf-facelets-1.1.15.B1.jar

                and modified the header of my faces-config.xml file to read:

                <faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
                xmlns:xi="http://www.w3.org/2001/XInclude"
                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-facesconfig_1_2.xsd">


                Which solved that problem but now I'm here:

                09:37:43,674 INFO  [org.ajax4jsf.cache.LRUMapCacheFactory] Creating LRUMap cache instance of default capacity 09:37:58,855 ERROR [org.ajax4jsf.webapp.BaseXMLFilter] Exception in the filter chain: javax.servlet.ServletException      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:325)      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336)      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)      at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)      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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)      at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)      at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)      at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)      at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)      at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872)      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)      at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.StackOverflowError      at org.jboss.logmanager.ExtLogRecord.(ExtLogRecord.java:77)      at org.jboss.logmanager.Logger.log(Logger.java:796)      at org.jboss.logmanager.Logger.log(Logger.java:811)      at org.jboss.logmanager.log4j.BridgeLogger.error(BridgeLogger.java:72)      at org.jboss.seam.interop.jul.Log4JConversionFilter.logWithThrowable(Log4JConversionFilter.java:86)      at org.jboss.seam.interop.jul.Log4JConversionFilter.isLoggable(Log4JConversionFilter.java:68)      at org.jboss.logmanager.Logger.logRaw(Logger.java:836)      at org.jboss.logmanager.Logger.log(Logger.java:799) ...

                Surprisingly, I think this is actually FORWARD progress, but it's a little disheartening.  I've searched for issues pertaining to this with not a lot of luck.  I'm not using SEAM, only the Richfaces library.
                Any other thoughts?
                • 5. Re: Issue with some Richfaces tags

                  I saw a post mentioning something about the admin console exhibiting some of the same behavior that my application is experiencing, and the solution was to remove the jboss-seam-jul-xx.jar file.  However, my application does not have that library in WEB-INF\lib as I'm not using Seam (at least not yet, anyhow).  I'm attaching a copy of my web.xml file.  If anyone sees something wrong that would cause the StackOverflowError, please let me know.

                   

                  Thanks!

                  • 6. Re: Issue with some Richfaces tags

                    The error seems to be caused by any exception that occurs inside of one of my .xhtml pages.  Any exception that gets thrown is causing the StackOverflowError.  I believe it has something to with logging being messed up (i.e. it's trying to log an error, but getting into some endless loop).  Has anyone else experienced this?

                     

                    Thanks!