After v2 upgrade, should I change closures to methods?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

After v2 upgrade, should I change closures to methods?

John Moore
With v2, there is now a recommendation to use methods instead of closures for controller actions. Are the advantages of doing so such that it's worth changing existing closures to methods?
Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

Graeme Rocher
Administrator
yes, advantages are reduced memory consumption

On Fri, Jul 13, 2012 at 10:56 AM, John Moore <[hidden email]> wrote:

> With v2, there is now a recommendation to use methods instead of closures for
> controller actions. Are the advantages of doing so such that it's worth
> changing existing closures to methods?
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/After-v2-upgrade-should-I-change-closures-to-methods-tp4631499.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

John Moore
Graeme Rocher-4 wrote
yes, advantages are reduced memory consumption
That instantly persuades me, in a 'free beer' sort of way.
Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

John Moore
The process was easily done and accomplished without problems. Just a FYI for anyone wondering about doing it.
Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

sethfuller
I remember reading that you can use scope = "singleton" with a controller that has all methods, instead of closures. Are there any gotchas about making the controller a singleton? I don't have any properties defined on my controllers so it seems if I just add "static scope = 'singleton'" to the top of the controller class after converting all closures to methods I should be ok. Is making the controller a singleton a big win in memory usage or just a nice thing to do with a small gain in memory usage? I have controllers with over a dozen actions, some of them are ajax responses.
Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

Graeme Rocher
Administrator
As long as you are aware of the potential thread safety issues
accessing local fields then you should be fine. It will result in less
memory usage and better performance

Cheers

On Fri, Jul 13, 2012 at 7:33 PM, sethfuller
<[hidden email]> wrote:

> I remember reading that you can use scope = "singleton" with a controller
> that has all methods, instead of closures. Are there any gotchas about
> making the controller a singleton? I don't have any properties defined on my
> controllers so it seems if I just add "static scope = 'singleton'" to the
> top of the controller class after converting all closures to methods I
> should be ok. Is making the controller a singleton a big win in memory usage
> or just a nice thing to do with a small gain in memory usage? I have
> controllers with over a dozen actions, some of them are ajax responses.
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/After-v2-upgrade-should-I-change-closures-to-methods-tp4631499p4631533.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

OverZealous
I was about to implement singleton controllers in my own app (since, as is good design, I don't have any shared properties on my controllers).

However, a minor point of confusion: will injected properties & services work correctly?  How would flash or session be handled on a per-request basis?  What happens if the singleton controller needs to reference a request-scoped service in a multi-threaded context?

Tracking down how controllers work in the source code is complicated, to say the least.

Thanks!
- Phil DeJarnett

Graeme Rocher wrote:

> As long as you are aware of the potential thread safety issues
> accessing local fields then you should be fine. It will result in less
> memory usage and better performance
>
> Cheers
>
> On Fri, Jul 13, 2012 at 7:33 PM, sethfuller
> <[hidden email]> wrote:
>> I remember reading that you can use scope = "singleton" with a controller
>> that has all methods, instead of closures. Are there any gotchas about
>> making the controller a singleton? I don't have any properties defined on my
>> controllers so it seems if I just add "static scope = 'singleton'" to the
>> top of the controller class after converting all closures to methods I
>> should be ok. Is making the controller a singleton a big win in memory usage
>> or just a nice thing to do with a small gain in memory usage? I have
>> controllers with over a dozen actions, some of them are ajax responses.
>>
>> --
>> View this message in context: http://grails.1312388.n4.nabble.com/After-v2-upgrade-should-I-change-closures-to-methods-tp4631499p4631533.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

burtbeckwith
Whether Spring gives you the singleton instance that was wired up at startup or creates a new one for each getBean() call and wires it up then has no bearing on how flash, session, or other servlet API functionality works.

Burt

OverZealous wrote
I was about to implement singleton controllers in my own app (since, as is good design, I don't have any shared properties on my controllers).

However, a minor point of confusion: will injected properties & services work correctly?  How would flash or session be handled on a per-request basis?  What happens if the singleton controller needs to reference a request-scoped service in a multi-threaded context?

Tracking down how controllers work in the source code is complicated, to say the least.

Thanks!
- Phil DeJarnett
Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

Graeme Rocher-2
The only impact might be if you are injecting any beans that are in request or session scope, since we don't setup a proxy for a singleton controller as far as I'm aware, but other than that there should be no impact on using the various variables (session, request, flash etc.)

Cheers

-- 
Graeme Rocher

On Wednesday, July 25, 2012 at 9:44 AM, burtbeckwith wrote:

Whether Spring gives you the singleton instance that was wired up at startup
or creates a new one for each getBean() call and wires it up then has no
bearing on how flash, session, or other servlet API functionality works.

Burt


OverZealous wrote

I was about to implement singleton controllers in my own app (since, as is
good design, I don't have any shared properties on my controllers).

However, a minor point of confusion: will injected properties & services
work correctly? How would flash or session be handled on a per-request
basis? What happens if the singleton controller needs to reference a
request-scoped service in a multi-threaded context?

Tracking down how controllers work in the source code is complicated, to
say the least.

Thanks!
- Phil DeJarnett




--
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:


Reply | Threaded
Open this post in threaded view
|

Re: After v2 upgrade, should I change closures to methods?

ideasculptor


On Wed, Jul 25, 2012 at 1:04 AM, Graeme Rocher <[hidden email]> wrote:
The only impact might be if you are injecting any beans that are in request or session scope, since we don't setup a proxy for a singleton controller as far as I'm aware, but other than that there should be no impact on using the various variables (session, request, flash etc.)

Would you need a proxy for singleton controller? With spring mvc, if you autowire a request-scoped or session-scoped bean into a controller, it wires a proxy for the bean which knows how to resolve the bean from the appropriate scope.  It's totally transparent and works very well.  Wouldn't it work the same way in grails?

--sam