1 Reply Latest reply on Jul 24, 2006 3:52 AM by niesar

    How to get some debug information?

      Hi guys,

      I'm close to get crazy because I don't find a way to debug what JSF/Seam is doing behind the curtain.

      My current problem is that I'm displaying a data table and I want to enable the user to select a few of these rows using checkboxes. I'm doing fine to display the table, and all the rows which should be pre-selected by default are indeed checked. However, I'm getting a funny result when I'm getting the user's input back from JSF. (_all_ table rows are returned as non-selected, regardless of what the user actually selected)

      Well, I'm sitting with this problem for the complete weekend now and don't know which way I could find out what is going wrong. Could anybody please give me any idea how I could debug this baby? I tried a lot in the last days, but it looks like I'm missing the point - and I don't know how to find out what's going wrong.


      To give you an idea what I'm doing:

      I'm writing a data table like this:

      <h:dataTable value="#{sortedTangibleLocations}" var="distanceLocationPair" rendered="#{sortedTangibleLocations!=null and sortedTangibleLocations.rowCount>0}">
       ... [display distanceLocationPair, never mind - works fine]
       <h:column>
       <f:facet name="header">"In" Area #{areaSearch.selectedArea}</f:facet>
       <h:selectBooleanCheckbox value="#{areaMemberSelections[distanceLocationPair]}" />
       </h:column>
       </h:dataTable>

      I kind of need to understand what happens with "areaMemberSelection." areaMemberSelection is a Map<DistanceLocationPair,Boolean> and it is supposed to carry the information which data row is selected to and from the JSF page.
      @In(scope=ScopeType.CONVERSATION,required=false)
       @Out(scope=ScopeType.CONVERSATION,required=false)
       private Map<DistanceLocationPair,Boolean> areaMemberSelections;

      As I said before, I'm able to pre-select rows from the data table (List sortedTangibleLocations). Map areaMemberSelections is initialized with those (few) table rows which should be displyed as pre-selected. Please note that I don't include all table rows here, just those which should be marked as selected.

      However, when I get the user selecetions back in the action bean, I always get the same strange result. Map areaMemberSelections is obviously changed - but it's wrong. I'm getting a map with _all_ the rows from the displayed table - and none of them is selected, the Boolean is always false. No matter what the user does and no matter what the default selections were. In the end I'm only getting "unselected" table rows.

      You see, since populating my "input fields" (checkboxes) worls fine, I think I'm on the right track. Furthermore, it's done quite closely following the Seam examples (dvdstore). So I would really like to debug what's going on and why I keep on getting this strange result with everything unselected. But I don't know how to do that. Any ideas what to do, please?

        • 1. Re: How to get some debug information?

          Never mind, guys, I found the problem. My mistake.

          My fault was that the data table with the selectBooleanCheckboxes weren't inside the form brackets. So when I got the wrong result back from JSF, I was kind of mislead. Instead of getting your data back unchanged, by default you're getting "false" aka "unselected" for all checkboxes.

          If I place the checkboxes properly in the form, everything works fine.


          However, the original question remains: is there a way to debug such a problem? In this case I helped myself by writing a "LoggerMap extends HashMap" and passed that one to JSF. But that's an awful lot of work if you need to supply custom "debugger" classes like this for all of your debugging problems. Right now it looks to me like debugging your JSF stuff is a bit like programming in the early 80s - log everything by hand in what you could be interested in, and continue until you found what's going wrong. Kind of unproductive nowadays.

          Well, the good news for me is that I was finally able to locate the problem. But it's consuming time. 2 weekends for 2 problems - by far too much.