difference myfaces and RI

[valbosoft]

Hi,

After mgrating from myfaces to ri 2.1 I'm having a problem, I don't know if it's seam related or RI.

The case is: I have a selectOneMenu on a seam search page (request scoped). When I submit the form, with RI it doesn't maintain the selected value, but with myfaces it does. However, in the model, the chosen value is preserved (when I have a outputText for that value, it shows the correct value).

Has anybody had the same problem?

Cheers, Bo

[keithnaas]

A long, long time ago when we made the same switch to RI (a year ago), I seem to recall some similar kinds of issues.  What kind of action are you kicking off?  Could you post the view code?

[valbosoft]

Hi,

here's the view code:
                         

h:selectOneMenu styleClass='formText' id="localidad_selectOneMenu"                         value="#{viviendaList.localidad}" converter="LocalidadConverter"
s:selectItems value="#{viviendaList.localidadList}" var="localidad" label="#{localidad.name}" noSelectionLabel="Seleccione una localidad..."/
a:support event="onchange" reRender="zonaDecoration" /
/h:selectOneMenu

(I don't know how to keep the brackets on this forum!)

It's inspired by the seam-gen search pages, so actually I'm subthe form, and viewtime the datatable gets rebuilt with the parameter values.

[keithnaas]

Is the selected value a JPA or Hibernate entity?  Is it an Enum?  Is it just a list of non persisted POJOs?  If its a JPA/Hibernate entity, are you using a Seam Managed PersistenceContext or Container Managed?  What is the Scope of the bean that contains the viviendaList?  You might want to run your server in debug mode and set some breakpints in the selectOneMenu JSF components decode method as well as in the LocalidadConverter. 

[valbosoft]

Hi,

it's JPA, with Hibernate as the persistence manager. the selected value is directly the Localidad class, it's set after converting with the LocalidadConverter. Thebean viviendaList is request scoped.
I'm running on Tomcat 5.5, so it's seam menaged persistenceContext.

The weird thing is that the localidad is set correctly, but not selected after rendering the next page..

[keithnaas]

Possibly an issue with multiple transactions.  I remember a scenario where we determined that the value wasn't being displayed by a select component because when it went to render the html select, the list was loaded in a different transaction from the actual selected value.  This caused the equals check to fail and thus the select didn't have a selected value.

Based on the details you've provided, that's the best I can come up with.

[valbosoft]

That definately makes sense. The problem is I don't know how to attack this.
I don't know if it has to do with it, but in faces-config.xml I have the phase listener defined as org.jboss.seam.jsf.TransactionalSeamPhaseListener, while in the examples org.jboss.seam.jsf.SeamPhaseListener is used. If I change this, if I recall correctly I started to get persistence problems..

[keithnaas]

When loading the data, how are you injecting the EntityManager?  Using @In or @PersistenceContext?

[valbosoft]

I use @In

[keithnaas]

It appears that you are using an old version because TransactionalSeamPhaseListener doesn't exist in Seam 2. 

In Seam 1.x TransactionSeamPhaseListener causes

A transaction spans the restore view, apply request values, process validations, update model values and invoke application phases. It is committed when invoke application is complete, or renderResponse() or responseComplete() is called. A second transaction spans the render response phase.

Could it be possible that the list of values is being populated during the render response phase (first transaction), while the value itself is loaded in a different transaction (the second) or perhaps on the next request?  What happens if you use the Conversation scope for the action?  When I get to work tomorrow, I'll see if I can find the code we have that does something similar on a search screen.

[valbosoft]

Hi,

I'm using seam 1.2.1 GA. I guess you also did, when you migrated a year ago?
What strikes me, if the cause is the one you mention, that myfaces handles it in such a different way than RI..

[keithnaas]

myfaces does a lot of things differently, some good, some bad. 

Well, looking at our code, we have two different kinds of backing beans with select lists, Conversation scoped and page scoped.

Also, our components.xml sets up the persistence context like this.

    <core:managed-persistence-context name=entityManager auto-create=true persistence-unit-jndi-name=java:/storeDbEntityManagerFactory/>

with a persistence.xml like:

   <persistence-unit name=storedb>
      <provider>org.hibernate.ejb.HibernatePersistence</provider>
      <jta-data-source>java:jdbc/DataSource</jta-data-source>
      <non-jta-data-source>java:jdbc/NoTxDataSource</non-jta-data-source>     
      <properties>
         <property name=javax.persistence.transactionType value=JTA/>
         <property name=cache.provider_class value=org.hibernate.cache.NoCacheProvider/>
         <property name=hibernate.cache.usequerycache value=false/>
         <property name=jboss.entity.manager.factory.jndi.name value=java:/storeDbEntityManagerFactory/>
      </properties>
   </persistence-unit>