Grails

OpenSessionInView does not work with SiteMesh

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: 1.0-RC2
  • Fix Version/s: 1.1.1
  • Component/s: View technologies
  • Labels:
    None
  • Environment:
    linux/windows

Description

The OpenSessionInView interceptor is applied to the UrlMappings filter and not the SiteMesh filter.

If the SiteMesh layouts access the database via taglibs or directly through GORM they will not be able to take advantage of an open Hibernate Session.

It would be better if the OSIV interceptor was applied to the SiteMesh filter rather than the UrlMappingFilter.

Activity

Hide
Jean-Noël Rivasseau added a comment -

This bug is hitting me too. The priority of this bug should be boosted to major at least I guess.

Show
Jean-Noël Rivasseau added a comment - This bug is hitting me too. The priority of this bug should be boosted to major at least I guess.
Hide
Peter Ledbrook added a comment -

It might make sense to install the OpenSessionInViewFilter ahead of the SiteMesh filter rather than using the interceptor. The downside is that I doubt the session can be set to read-only (or FlushMode.MANUAL I believe) before the views are rendered.

Show
Peter Ledbrook added a comment - It might make sense to install the OpenSessionInViewFilter ahead of the SiteMesh filter rather than using the interceptor. The downside is that I doubt the session can be set to read-only (or FlushMode.MANUAL I believe) before the views are rendered.
Hide
Graeme Rocher added a comment -

No the Filter approach is not an option, it is critical to set FlushMode to manual before view rendering to avoid changes being flushed from the view and potentially corrupting the markup if this happens after the view buffer has been flushed.

Show
Graeme Rocher added a comment - No the Filter approach is not an option, it is critical to set FlushMode to manual before view rendering to avoid changes being flushed from the view and potentially corrupting the markup if this happens after the view buffer has been flushed.
Hide
Jean-Noël Rivasseau added a comment -

Is this bug hard to fix? It's becoming more and more problematic for me. I think its severity should be at least bumped to Major or more... if G2One does not have the resources to fix it soon I could try to have a look at it

Show
Jean-Noël Rivasseau added a comment - Is this bug hard to fix? It's becoming more and more problematic for me. I think its severity should be at least bumped to Major or more... if G2One does not have the resources to fix it soon I could try to have a look at it
Hide
Graeme Rocher added a comment -

I wouldn't say its major, the solution is to eagerly initialize your association when querying or declaratively. It is currently something that is hard to fix and will need some careful thought on how we manage the session in the sitemesh layer

Show
Graeme Rocher added a comment - I wouldn't say its major, the solution is to eagerly initialize your association when querying or declaratively. It is currently something that is hard to fix and will need some careful thought on how we manage the session in the sitemesh layer
Hide
Jean-Noël Rivasseau added a comment -

Yes, there is a workaround, but there are two problems:

  • the issue can be a turn-off for newcomers to Grails;
  • everytime i run into this issue, it's hard to find the actual cause and I lose a lot of time before realizing I've been hit by this bug -> quite bad for a high productivity framework such as Grails.

If it's hard to fix I will leave this to G2One then and hope you guys fix it soon enough

Show
Jean-Noël Rivasseau added a comment - Yes, there is a workaround, but there are two problems:
  • the issue can be a turn-off for newcomers to Grails;
  • everytime i run into this issue, it's hard to find the actual cause and I lose a lot of time before realizing I've been hit by this bug -> quite bad for a high productivity framework such as Grails.
If it's hard to fix I will leave this to G2One then and hope you guys fix it soon enough
Hide
Peter Delahunty added a comment -

I would also vote that this is a BIG issue.

I have a scenario where i have a template that is only referenced from a sitemesh layout. This template calls a tag lib. This means this template is outsite the open session in view interceptor so the session is already closed.

My template:

<g:form controller="account" action="choose">
<input type="hidden" name="currentController" value="${params.controller}">
<input type="hidden" name="currentAction" value="${params.action}">
<label for="accountSelectId">Change account: </label><g:accountListSelect id="accountSelectId" name="id" onchange="this.form.submit();"/>
</g:form>

So i have this tag lib:

def accountListSelect = {attrs,body ->
User user = User.get(session.userId)
def accountList = user.accountAccesses.collect {it.account};
attrs.from = accountList
attrs.optionKey = 'id'
attrs.optionValue = 'name'
attrs.value = session.accountId
out << g.select(attrs)
}

Here my call is:

User user = User.get(session.userId)
def accountList = user.accountAccesses.collect {it.account};

This will now throw a lazy load exception because the session is not closed.

Show
Peter Delahunty added a comment - I would also vote that this is a BIG issue. I have a scenario where i have a template that is only referenced from a sitemesh layout. This template calls a tag lib. This means this template is outsite the open session in view interceptor so the session is already closed. My template: <g:form controller="account" action="choose"> <input type="hidden" name="currentController" value="${params.controller}"> <input type="hidden" name="currentAction" value="${params.action}"> <label for="accountSelectId">Change account: </label><g:accountListSelect id="accountSelectId" name="id" onchange="this.form.submit();"/> </g:form> So i have this tag lib: def accountListSelect = {attrs,body -> User user = User.get(session.userId) def accountList = user.accountAccesses.collect {it.account}; attrs.from = accountList attrs.optionKey = 'id' attrs.optionValue = 'name' attrs.value = session.accountId out << g.select(attrs) } Here my call is: User user = User.get(session.userId) def accountList = user.accountAccesses.collect {it.account}; This will now throw a lazy load exception because the session is not closed.
Hide
Jean-Noël Rivasseau added a comment -

Yes, I would hope it would be fixed for 1.1... does not look it actually will though

Show
Jean-Noël Rivasseau added a comment - Yes, I would hope it would be fixed for 1.1... does not look it actually will though
Hide
Kyle Pinette added a comment -

Has anything been done about this??

This a major issue...I need to pull content from the database in a layout...

Right now, I'm making a call to open a session manually FROM THE LAYOUT. That seems like a really dirty work around.

Show
Kyle Pinette added a comment - Has anything been done about this?? This a major issue...I need to pull content from the database in a layout... Right now, I'm making a call to open a session manually FROM THE LAYOUT. That seems like a really dirty work around.
Hide
Mos added a comment -

It would be nice if this could be fixed soon. Somebody put this to 1.1.1?
The workaround with "solution is to eagerly initialize" doesn't work very well, if second-level cache is used (which should be standard )

Show
Mos added a comment - It would be nice if this could be fixed soon. Somebody put this to 1.1.1? The workaround with "solution is to eagerly initialize" doesn't work very well, if second-level cache is used (which should be standard )
Hide
Peter Delahunty added a comment -

Gonna try some experiments to see what we can do for this.

Show
Peter Delahunty added a comment - Gonna try some experiments to see what we can do for this.
Hide
Peter Delahunty added a comment -

Hi Graeme

Out of interest what did you do to fix this ?

Show
Peter Delahunty added a comment - Hi Graeme Out of interest what did you do to fix this ?
Hide
Graeme Rocher added a comment -

It hasn't been fixed, the issue is stilll open

Show
Graeme Rocher added a comment - It hasn't been fixed, the issue is stilll open

People

Vote (9)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: