Grails
  1. Grails
  2. GRAILS-8450

Grails 2.0 RC3 spring security org.hibernate.LazyInitializationException: could not initialize proxy - no Session

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-RC3
    • Fix Version/s: 2.0 final
    • Component/s: None
    • Labels:
      None
    • Environment:
      Win7,java64,sts
    • Testcase included:
      yes

      Description

      This worked before 2.x, thats why I am not sure whether this is a bug, changed behavior or something else. Before 2.x this worked without needing to add withTransaction to the spring security generated classes, hence this should either be a JIRA or be added to the documentation.

      Is the correct behavior to fail? Why did it work in Grails 1.3x then?

      I understand the call chain is: controller (prototype), sitemesh/layouts, taglib (singleton) - so when in the User code do we have a session (because it all originates from the controller) or dont we because its called by a taglib?

      Unlike in http://jira.grails.org/browse/GRAILS-6701 where a view is mapped directly i am using a controller in URLMappings
      "/"(controller:"start")

      This may be related: http://jira.grails.org/browse/GRAILS-5911

      This how i had to fix in the plugin generated User.groovy:

      Set<Role> getAuthorities() {
      UserRole.withTransaction {
      UserRole.findAllByUser(this).collect

      { it.role }

      as Set
      }
      }

      StackTrace - Full Stack Trace:
      org.hibernate.LazyInitializationException: could not initialize proxy - no Session
      at com.s1.User$_getAuthorities_closure2.doCall(User.groovy:29)
      at com.s1.User.getAuthorities(User.groovy:29)
      at com.s1.User.isSuperAdmin(User.groovy:32)
      at vpmb.NavigationTagLib.getCurrentUsersRole(NavigationTagLib.groovy:203)
      at vpmb.NavigationTagLib.buildNavigation(NavigationTagLib.groovy:26)
      at vpmb.NavigationTagLib$_closure1.doCall(NavigationTagLib.groovy:21)
      at C_Users_dx_com_s1_vpm_grails_app_views_shared_nav_gsp.run(_nav.gsp:2)
      at C__Users_dx_com_s1_vpm_grails_app_views_layouts_main_gsp$_run_closure2_closure32.doCall(main.gsp:37)
      at grails.plugins.springsecurity.SecurityTagLib$_closure6.doCall(SecurityTagLib.groovy:138)
      at C__Users_dx_com_s1_vpm_grails_app_views_layouts_main_gsp$_run_closure2.doCall(main.gsp:39)
      at C__Users_dx_com_s1_vpm_grails_app_views_layouts_main_gsp.run(main.gsp:56)
      at org.grails.plugin.resource.DevModeSanityFilter.doFilter(DevModeSanityFilter.groovy:44)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:662)

        Activity

        Hide
        Lari Hotari added a comment -

        The Hibernate session in layouts might not be part of OSIV any more.
        Layout is rendered directly without forwarded request in 2.0.x.
        Looks like the PersistenceContextInterceptor solution needs some work.

        Show
        Lari Hotari added a comment - The Hibernate session in layouts might not be part of OSIV any more. Layout is rendered directly without forwarded request in 2.0.x. Looks like the PersistenceContextInterceptor solution needs some work.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Andre
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development