3 Replies Latest reply on Feb 2, 2009 4:15 AM by waltc

    IllegalArgumentException type mismatch

    waltc
      I have a somewhat difficult to describe problem.
      The environment is Seam 2.1.1.GA running under Seam-5.0.0.GA. This is a straight-forward CRUD application on one table performing a 'View' action causes an IllegalArgumentException type mismatch. Here is a snippet of the stack trace.



      `Exception during request processing:
      Caused by javax.el.ELException with message: "java.lang.IllegalArgumentException: argument type mismatch"

      javax.el.BeanELResolver.setValue(BeanELResolver.java:116)
      javax.el.CompositeELResolver.setValue(CompositeELResolver.java:68)
      com.sun.faces.el.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:100)
      org.jboss.el.parser.AstPropertySuffix.setValue(AstPropertySuffix.java:73)
      org.jboss.el.parser.AstValue.setValue(AstValue.java:84)
      org.jboss.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
      org.jboss.seam.core.Expressions$1.setValue(Expressions.java:117)
      org.jboss.seam.navigation.Pages.applyConvertedValidatedValuesToModel(Pages.java:860)
      org.jboss.seam.navigation.Pages.postRestore(Pages.java:459)
      org.jboss.seam.jsf.SeamPhaseListener.postRestorePage(SeamPhaseListener.java:546)
      org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:392)
      org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:228)
      org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
      com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
      com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
      com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
      com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
      javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
      `

      There are a couple of things that make this table unique:
      1) there is no primary key, Hibernate built a composite key of all the columns.
      2) there is one column which is a single char, length of 1. This appears to be non-alphanumeric as what gets displayed in the list screen (with view and edit as actions) is a single | although perhaps not as tall.
      3) there is a single foreign key which points to another table.
      4) the table pointed to by the foreign key displays fine and even displays those rows from the first table as children of the selected record from that list.
      5) if, in the generic list operation I go to the last page it is completely blank. If from there I go to the previous page it too is completely blank etc etc even though I can display all the rows in another table viewer. 
      I can not determine where the actual exception is getting generated, much less why. I am not sure how to debug this at this point.

      If there are any observations or ideas for where I should look next I will greatly appreciate them.

      Thanks,

      Walt Corey
        • 1. Re: IllegalArgumentException type mismatch
          waltc

          As a quick addendum to my previous, I added a primary key as an autogenerated field and the problem went away. I am not sure this isn't a bug, albeit an edge case. Frankly up until yesterday I thought in order to have a relationship (as in relational data base) every row had to be uniquely differentiated from every other row. The assumption Hibernate made was the aggregation of all columns in the row made a unique id. I am not sure that necessarily follows but mismatched argument is not the appropriate error message for that.


          So is this a bug with Seam, Hibernate, or not a bug at all?


          Thanks,


          Walt Corey

          • 2. Re: IllegalArgumentException type mismatch
            joblini

            Based on the stacktrace you posted, the problem was in pages.xml setting a value on the model.

            • 3. Re: IllegalArgumentException type mismatch
              waltc

              Here is the original pages.xml for that webpage.


                 <param name="upddocumentupdatelogFrom"/>
                 <param name="upddocumentupdatelogUpdDocumentUpdateLogAction" value="#{upddocumentupdatelogHome.upddocumentupdatelogId.updDocumentUpdateLogAction}"/>
                 <param name="upddocumentupdatelogUpdDocumentUpdateLogBatchNum" value="#{upddocumentupdatelogHome.upddocumentupdatelogId.updDocumentUpdateLogBatchNum}"/>
                 <param name="upddocumentupdatelogUpdDocumentUpdateLogDateOfInsert" value="#{upddocumentupdatelogHome.upddocumentupdatelogId.updDocumentUpdateLogDateOfInsert}"/>
                 <param name="upddocumentupdatelogUpdDocumentUpdateLogDocId" value="#{upddocumentupdatelogHome.upddocumentupdatelogId.updDocumentUpdateLogDocId}"/>
                 <param name="upddocumentupdatelogUpdDocumentUpdateLogUpdateId" value="#{upddocumentupdatelogHome.upddocumentupdatelogId.updDocumentUpdateLogUpdateId}"/>

              Hibernate made a composite object to serve as the candidate key. This object was made of the above individual fields. These fields form the request params in the URL, correct? Here is what it was once I merely added an autoincrement field to the table.

                 <param name="upddocumentupdatelogFrom"/>
                 <param name="upddocumentupdatelogId" value="#{upddocumentupdatelogHome.upddocumentupdatelogId}"/>

              The former didn't work yet the later does. I am wondering how, from what is provided in the url, would seam know to create the composite object, basically, all attributes of the selected row to become the DataModel Selection item?

              Since this is all seam-gen generated code I am trying to determine if I was asking it to do something it couldn't do, couldn't do correctly (a bug), or I should have intervened with the generated code, I think that is also a bug. I concede it could be something I should have done but I am at a loss for what that would be.

              Is there more information needed to resolve this?


              And thanks again!

              Walt