org.apache.struts2.interceptor.ScopeInterceptor This is designed to solve a few simple issues related to wizard-like functionality in Struts. One of those issues is that some applications have a application-wide parameters commonly used, such pageLen (used for records per page). Rather than requiring that each action check if such parameters are supplied, this interceptor can look for specified parameters and pull them out of the session. This works by setting listed properties at action start with values from session/application attributes keyed after the action's class, the action's name, or any supplied key. After action is executed all the listed properties are taken back and put in session or application context. To make sure that each execution of the action is consistent it makes use of session-level locking. This way it guarantees that each action execution is atomic at the session level. It doesn't guarantee application level consistency however there has yet to be enough reasons to do so. Application level consistency would also be a big performance overkill. Note that this interceptor takes a snapshot of action properties just before result is presented (using a PreResultListener), rather than after action is invoked. There is a reason for that: At this moment we know that action's state is "complete" as it's values may depend on the rest of the stack and specifically - on the values of nested interceptors. Interceptor parameters: session - a list of action properties to be bound to session scope application - a list of action properties to be bound to application scope key - a session/application attribute key prefix, can contain following values: CLASS - that creates a unique key prefix based on action namespace and action class, it's a default value ACTION - creates a unique key prefix based on action namespace and action name any other value is taken literally as key prefix type - with one of the following start - means it's a start action of the wizard-like action sequence and all session scoped properties are reset to their defaults end - means that session scoped properties are removed from session after action is run any other value or no value means that it's in-the-middle action that is set with session properties before it's executed, and it's properties are put back to session after execution sessionReset - name of a parameter (defaults to 'session.reset') which if set, causes all session values to be reset to action's default values or application scope values, note that it is similar to type="start" and in fact it does the same, but in our team it is sometimes semantically preferred. We use session scope in two patterns - sometimes there are wizard-like action sequences that have start and end, and sometimes we just want simply reset current session values. reset - boolean, defaults to false, if set, it has the same effect as setting all session values to be reset to action's default values or application. autoCreateSession - boolean value, sets if the session should be automatically created. Extending the interceptor: There are no know extension points for this interceptor. Example code: <!-- As the filter and orderBy parameters are common for all my browse-type actions, you can move control to the scope interceptor. In the session parameter you can list action properties that are going to be automatically managed over session. You can do the same for application-scoped variables--> <action name="someAction" class="com.examples.SomeAction"> <interceptor-ref name="basicStack"/> <interceptor-ref name="hibernate"/> <interceptor-ref name="scope"> <param name="session">filter,orderBy</param> <param name="autoCreateSession">true</param> </interceptor-ref> <result name="success">good_result.ftl</result> </action>
org.apache.struts2.interceptor.ServletConfigInterceptor An interceptor which sets action properties based on the interfaces an action implements. For example, if the action implements ParameterAware then the action context's parameter map will be set on it. This interceptor is designed to set all properties an action needs if it's aware of servlet parameters, the servlet context, the session, etc. Interfaces that it supports are: ServletContextAware ServletRequestAware ServletResponseAware ParameterAware RequestAware SessionAware ApplicationAware PrincipalAware Interceptor parameters: None Extending the interceptor: There are no known extension points for this interceptor. Example code: <action name="someAction" class="com.examples.SomeAction"> <interceptor-ref name="servletConfig"/> <interceptor-ref name="basicStack"/> <result name="success">good_result.ftl</result> </action> See Also: ServletContextAware ServletRequestAware ServletResponseAware ParameterAware SessionAware ApplicationAware PrincipalAware
to automatically pop the parameters inside action context(request, or session etc),into the action class. besides, scopeInterceptor can be used to update the session attribute automatically.
Hot deployment and hot swap are completly different beasts, Valeri. Hot swap is the ability to change class definitions while a VM is running, without the application ever noticing that. This is provided so you can reload quick changes to a class while you’re debugging. Hot swap is provided by the JVM, and while quite useful in server-side development, has no direct link to J2EE or application servers. Hot swap also has a number of limitations, as you already discovered.
Now, hot deployment is the ability to reload an entire J2EE application without bringing down the container. This is implemented by application servers is very different ways, and has no direct links to the JVM.
In general, all situations where you don’t have a clear separation between the development stage and the running application are difficult to handle. A J2EE application cannot modify its own configuration at runtime. The deployment descriptors are parsed and interpreted at the time of deployment but afterwards they are cast in stone. There’s no API to modify those aspects of the system that are in the deployment descriptors. If you want to dynamically change any of those aspects at runtime, you have to work around J2EE or resort to coding to extremely low level J2EE SPI interfaces like writing your own JCA resource adapter.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <struts> <package name="prc-buySellAvail" namespace="/1" extends="prc-root"> <!-- Buy / Sell Availability starts here --> <action name="rtrvCurrencies" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rtrvCurrencies"> <interceptor-ref name="prcRootStack"> <param name="scope.type">start</param> <param name="scope.session">masterProdList</param> </interceptor-ref> <result name="success" type="tiles">rtrvCurrencies</result> </action> <!-- jackie, retrieve denom list, ST --> <action name="rtrvCurrenciesDenom" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rtrvCurrenciesDenom"> <interceptor-ref name="prcRootStack"> <param name="scope.type">start</param> <param name="scope.session">prodDto</param> </interceptor-ref> <result name="success" type="tiles">rtrvCurrenciesDenom</result> </action> <!-- jackie, retrieve denom list, EN --> <action name="rtrvCcyList" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rtrvCcyList"> <result name="success">/WEB-INF/jsp/availability/CurrencyList.jsp</result> </action> <action name="rtrvMetals" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rtrvMetals"> <interceptor-ref name="prcRootStack"> <param name="scope.type">start</param> <param name="scope.session">masterProdList</param> </interceptor-ref> <result name="success">/WEB-INF/jsp/availability/MetalSetup.jsp</result> </action> <action name="searchAvailMetals" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="searchAvailMetals"> <result name="success">/WEB-INF/jsp/availability/MetalList.jsp</result> </action> <action name="rtrvPendingProducts" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rtrvPendingProducts"> <result name="success">/WEB-INF/jsp/availability/AuthorizeProducts.jsp</result> </action> <action name="populateMetalList" method="populateMetalList" class="com.db.cfc.pricing.action.BuySellAvailabilityAction"> <result name="success" type="json"> <param name="root">productsList</param> </result> </action> <!-- Buy / Sell Availability starts here --> </package> <package name="prc-buySellAvail-edit" namespace="/2" extends="prc-root"> <action name="saveCurrencySettings" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="saveCurrencySettings"> <interceptor-ref name="prcRootStack"> <param name="scope.session">masterProdList</param> </interceptor-ref> <result name="success">/WEB-INF/jsp/availability/CurrencySetup.jsp</result> </action> <action name="saveMetalSettings" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="saveMetalSettings"> <interceptor-ref name="prcRootStack"> <param name="scope.session">masterProdList</param> </interceptor-ref> <result name="success">/WEB-INF/jsp/availability/MetalSetup.jsp</result> </action> <action name="approveProductSettings" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="approveProductSettings"> <result name="success">/WEB-INF/jsp/availability/PendingAuthConfirmation.jsp</result> </action> <action name="rejectProductSettings" class="com.db.cfc.pricing.action.BuySellAvailabilityAction" method="rejectProductSettings"> <result name="success">/WEB-INF/jsp/availability/PendingAuthConfirmation.jsp</result> </action> </package> </struts>
not only, the attributes of the action class, would be auto wired with spring beans.
besides, the attributes of the action class (never defined within spring), can be passed back to the struts.xml, utilizing this objects in session, or jsp.
i am to study the theory behind this.
Feb 17, 2011
The work behind this is, spring auto wiring + ScopeInterceptor(Strust2) + ServletConfigInterceptor(Struts2).