You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Kris Coolsaet (JIRA)" <ji...@apache.org> on 2007/08/22 11:16:34 UTC

[jira] Created: (WW-2125) setApplication shouls come before setSession

setApplication shouls come before setSession
--------------------------------------------

                 Key: WW-2125
                 URL: https://issues.apache.org/struts/browse/WW-2125
             Project: Struts 2
          Issue Type: Bug
          Components: Interceptors
    Affects Versions: 2.0.9
            Reporter: Kris Coolsaet
            Priority: Minor


When an action is both SessionAware and ActionAware the ServletConfigInterceptor first calls setSession and then setApplication, while to me it seems more logical to do this the other way round.

Consider the following use case: a common superclass CustomerAction is used for actions that do something with the 'current customer' which is stored in session context. Everytime an action like this is called, a customer object is automatically loaded from the session into a field of the action object (this is done during 'setSession' time), however, part of this operation is to check with the database whether some customer properties need to be updated. The database is stored as a data source (or Hibernate session factory) in the application context.
Unfortunately, setApplication has not yet been called, hence the action cannot perform this check.

Granted, there are several workarounds to this particular example: the database check could be done as part of the 'execute', or as part of a 'prepare', or the data source could be stored in a static variable,... 

I cannot think of a use case which would be broken by changing this order - why would setApplication possibly need information from the
session?



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WW-2125) setApplication should come before setSession

Posted by "Don Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown updated WW-2125:
--------------------------

    Issue Type: Improvement  (was: Bug)

> setApplication should come before setSession
> --------------------------------------------
>
>                 Key: WW-2125
>                 URL: https://issues.apache.org/struts/browse/WW-2125
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Interceptors
>    Affects Versions: 2.0.9
>            Reporter: Kris Coolsaet
>            Assignee: Don Brown
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> When an action is both SessionAware and ActionAware the ServletConfigInterceptor first calls setSession and then setApplication, while to me it seems more logical to do this the other way round.
> Consider the following use case: a common superclass CustomerAction is used for actions that do something with the 'current customer' which is stored in session context. Everytime an action like this is called, a customer object is automatically loaded from the session into a field of the action object (this is done during 'setSession' time), however, part of this operation is to check with the database whether some customer properties need to be updated. The database is stored as a data source (or Hibernate session factory) in the application context.
> Unfortunately, setApplication has not yet been called, hence the action cannot perform this check.
> Granted, there are several workarounds to this particular example: the database check could be done as part of the 'execute', or as part of a 'prepare', or the data source could be stored in a static variable,... 
> I cannot think of a use case which would be broken by changing this order - why would setApplication possibly need information from the
> session?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WW-2125) setApplication should come before setSession

Posted by "Don Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown resolved WW-2125.
---------------------------

       Resolution: Fixed
    Fix Version/s:     (was: Future)
                   2.1.0
         Assignee: Don Brown

> setApplication should come before setSession
> --------------------------------------------
>
>                 Key: WW-2125
>                 URL: https://issues.apache.org/struts/browse/WW-2125
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Interceptors
>    Affects Versions: 2.0.9
>            Reporter: Kris Coolsaet
>            Assignee: Don Brown
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> When an action is both SessionAware and ActionAware the ServletConfigInterceptor first calls setSession and then setApplication, while to me it seems more logical to do this the other way round.
> Consider the following use case: a common superclass CustomerAction is used for actions that do something with the 'current customer' which is stored in session context. Everytime an action like this is called, a customer object is automatically loaded from the session into a field of the action object (this is done during 'setSession' time), however, part of this operation is to check with the database whether some customer properties need to be updated. The database is stored as a data source (or Hibernate session factory) in the application context.
> Unfortunately, setApplication has not yet been called, hence the action cannot perform this check.
> Granted, there are several workarounds to this particular example: the database check could be done as part of the 'execute', or as part of a 'prepare', or the data source could be stored in a static variable,... 
> I cannot think of a use case which would be broken by changing this order - why would setApplication possibly need information from the
> session?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WW-2125) setApplication should come before setSession

Posted by "James Holmes (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Holmes updated WW-2125:
-----------------------------

    Fix Version/s: Future
          Summary: setApplication should come before setSession  (was: setApplication shouls come before setSession)

> setApplication should come before setSession
> --------------------------------------------
>
>                 Key: WW-2125
>                 URL: https://issues.apache.org/struts/browse/WW-2125
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Interceptors
>    Affects Versions: 2.0.9
>            Reporter: Kris Coolsaet
>            Priority: Minor
>             Fix For: Future
>
>
> When an action is both SessionAware and ActionAware the ServletConfigInterceptor first calls setSession and then setApplication, while to me it seems more logical to do this the other way round.
> Consider the following use case: a common superclass CustomerAction is used for actions that do something with the 'current customer' which is stored in session context. Everytime an action like this is called, a customer object is automatically loaded from the session into a field of the action object (this is done during 'setSession' time), however, part of this operation is to check with the database whether some customer properties need to be updated. The database is stored as a data source (or Hibernate session factory) in the application context.
> Unfortunately, setApplication has not yet been called, hence the action cannot perform this check.
> Granted, there are several workarounds to this particular example: the database check could be done as part of the 'execute', or as part of a 'prepare', or the data source could be stored in a static variable,... 
> I cannot think of a use case which would be broken by changing this order - why would setApplication possibly need information from the
> session?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.