Question

I have a jsf 1.2 command link

  <h:commandLink id="cars" action="${swapViewHandler.myFunction1}">
  <h:commandLink id="ships" action="${swapViewHandler.myFunction2}">

myFunction1 populates swapViewHandler.listA with cars and navigates to cars.xhtml

 <navigation-rule>
           <navigation-case>            
                <from-outcome>cars</from-outcome>
                <to-view-id>cars.xhtml</to-view-id>
                <redirect />
            </navigation-case>

myFunction2 populates the same swapViewHandler.listA with ships and
navigates to ships.xhtml

 <navigation-rule>
           <navigation-case>            
                <from-outcome>ships</from-outcome>
                <to-view-id>hips.xhtml</to-view-id>
                <redirect />
            </navigation-case>

I need to handle a user refresh (F5) so that when a refresh happens in
cars.xhtml myFunction1 gets called and repopulates listA (with cars )
and when ships.xhtml gets refreshed myFunction2 gets called and repopulates listA (with ships)

cars.xhtml and ships.xhtml have the same backingbean (swapviewhandler)

and they both contain

<c:forEach id="tablePicList" items="${swapViewHandler.listA}"  var="entity" varStatus ="status">

Answer 1

Each view should have its own backing bean. Put the bean in the request scope and do the job in its (post)constructor. This will then be invoked on every fresh new GET request. E.g.

public class CarHandler {

    private List<Car> cars;

    @EJB
    private CarService carService;

    @PostConstruct
    public void init() {
        cars = carService.list();
    }

    // ...
}

Don’t forget to change the command links to be normal output links. It’ll also give you extra SEO points as it apparently concerns pure page-to-page navigation and bookmarkable/refreshable GET requests.

<h:outputLink value="cars.jsf">cars</h:outputLink>
<h:outputLink value="ships.jsf">ships</h:outputLink>

If the lists are dependent on some request parameter or a session scoped managed bean, then you should inject that in the backing bean as a <managed-property> in faces-config.xml. It’ll be available inside the @PostConstruct method (but not in the constructor!).