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

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

     [ 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.