Prettyfaces + Hibernate + Spring lazy initialization

Splash Forums PrettyFaces Users Prettyfaces + Hibernate + Spring lazy initialization

This topic contains 6 replies, has 3 voices, and was last updated by  Christian Kaltepoth 5 years ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #18374

    fabio.patricio
    Participant

    Hi,

    I have an application with primefaces, spring and hibernate set up and working. But in one particular case it fails.

    Whenever I go to create an editing screen and do the following process:

    I run the edit method by carrying my object id, after that, I point to the page editing as follows.

    return “pretty: edit”;

    Thus the loading screen it returns a lazy initialization exception. I have the Spring filter set, but I think that when I call this the filter is no longer running, or has been executed.

    This may be related to the redirect?

    My filter is configured so after prettyfaces.

    <filter>

    <filter-name> hibernate </ filter-name>

    <filter-class>

    org.springframework.orm.hibernate3.support.OpenSessionInViewFilter

    </ filter-class>

    </ filter>

    <filter-mapping>

    <filter-name> hibernate </ filter-name>

    <url-pattern> / * </ url-pattern>

    <dispatcher> FORWARD </ dispatcher>

    <dispatcher> REQUEST </ dispatcher>

    <dispatcher> ERROR </ dispatcher>

    </ filter-mapping>

    Best Regards

    #22551

    This sound like you are calling an action method to “prepare” the edit page by loading the corresponding object from the database, then doing return "pretty: edit"; which redirects the user to the actual edit page. Correct?

    In this case the exception is easy to explain. You are first loading the object and then you do a redirect. After the redirect the object will be detached resulting in a lazy initialization exception because the redirect results in a new request to the server.

    This is a pattern that is not recommended. You should instead encode the ID of the object you want to edit in the URL. Then load the object in an URL action. This way you get a clean bookmarkable URL like /user/edit/5.

    The example 3.1 in this chapter of the documentation:

    http://ocpsoft.org/docs/prettyfaces/3.3.2/en-US/html/Configuration.html#config.actions

    I hope this helps :)

    Christian

    #22552

    Yes, I agree with Christian’s assessment. You’ll either need to use a long-running conversation with Hibernate, store your object in the session (not recommended unless you have performance problems,) or you’ll need to pass the ID of your object via the URL of the edit page.

    ~Lincoln

    #22553

    fabio.patricio
    Participant

    Hi,

    Perfect.

    Is there a design example of how an application should work PrettyFaces, urls, configuration, eg for a crud?

    What would be good practice.

    When the User clicks the edit button:

    pretty: edit

    Directs to the url: / user/edit/5

    In the bean is loaded object 5 is shown to the User.

    It changes some information and clicks the save button: pretty: update

    Upon arriving at this object bean must be reloaded to avoid the lazy? And after copying the properties of the filled object on the screen?

    What would best solution?

    Best Regards,

    #22554

    I can only for myself, but I’m typically using the following pattern.

    The entry point is a list view containing all the entities. The Java class typically looks like this:

    @Named
    @RequestScoped
    @URLMapping(id = "userList", pattern = "/admin/users", viewId = "/admin/user-list.jsf")
    public class UserListBean {

    private List<User> list;

    @URLAction
    public void init() {
    list = userDao.list();
    }

    /* getter + setter */

    }

    The dataTable contains a column with an edit link. This link refers to the edit page like this:

    <h:dataTable var="user" value="#{userListBean.list}">

    <!-- .... -->

    <h:column>
    <pretty:link mappingId="editUser">
    <f:param value="#{user.id}" />
    Edit
    </pretty:link>
    </h:column>

    </h:dataTable>

    This renders a simple HTML link. The bean responsible for the edit page looks like this:

    @Named
    @RequestScoped
    @URLMapping(id = "editUser", pattern = "/admin/user/#{userEditBean.id}", viewId = "/admin/user-edit.jsf")
    public class UserEditBean {

    private Long id;

    private User user;

    private String firstname;
    private String lastname;

    @URLAction
    public void init() {

    // load user to edit from the DB
    user = userDao.getById( id );

    // load values to edit
    firstname = user.getFirstname();
    lastname = user.getLastname();

    }

    public String save() {

    // update database object
    user.setFirstname(firstname);
    user.setLastname(lastname);

    // back to list view
    return "pretty:userList";
    }

    /* getter + setter */

    }

    Simple, isn’t it? :)

    I typically prefer to have separate fields in the JSF bean which hold the properties of the database object that are editable. I prefer that because you can post process these values (like to a String.trim()) and do complex validations that aren’t possible with JSF validators. But you could also bind the input components directly to the database entity.

    Christian

    #22555

    fabio.patricio
    Participant

    Hi Cristian,

    In the edit page as you call the save method?

    action=”#{userEditBean.save}”

    This is my big question, what the correct way to perform the method change.

    Calling the bean directly, or by calling an action of Pretty: pretty:save

    Best Regards

    #22556

    Just call the bean directly. This makes most sense here because it allows you to process all the form data.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Comments are closed.