frameworks

1. Spring DI IoC
without frameworks, normally to invoke methods on another class (loose coupling), we need to create an instance of the class, then call the method.
IoC, inversion of control, is pre set up this for us, so called inversion of control. instead we call that method on that object, the object is prepared and injected for us.

DI is one implementation of IoC. Both spring and Guice are DI frameworks.
This saves a lot of efforts for developers, the cost is slower app start up time (so the effort/time is brought forward to spend). This is initial reason why spring started becoming popular even during webwork/struts days.

2. @autowired
spring used to use XML for bean creation, and DI. basically tell what’s the beans/class/Objects to be managed by spring bean factory/context. and what’s needed fields/beans for the beans to be created. Spring library would read these configuration and do the set up job.

with the annotation (using reflection) becomes popular, this saves efforts to maintain separate XML files, (at the same time, become less maintainable). So the XML configuration start having the annotation equivalent. @Auowired is the equivalent of telling needed constructs for bean creations in XML.

3. Spring MVC
this is the spring implementation of MVC pattern, corresponding to structs and java default servlet and other framework. basically to tell what’s the URL mapped to which class, and what’s the result(view), with the model passing around. (in XML)

with annotation this become, @RestController @Controller @RequestMapping @RequestParamter etc

4. thread safety in Spring
by default, spring beans are singleton, though this can be changed to be prototype (one bean per each request)

singleton beans are not thread safe, same as servlet, which is shared among requests/threads.

5. spring AOP
AOP is for those code cross cutting or scattering. there are a lot common tasks, like audit or access control, which without AOP, could be duplicating the same code in multiple different places
AOP basically define the point cut (places), cross point and advice (the real business to be done, like audit /access control)
Spring has mostly two proxy mechanism for AOP, default JDK dhynamic proxy or CGLIB (JDK is preferred by spring for performance consideration)

6. spring boot
spring boot trying to make the developers’ job easier, by providing a lot defaults (configuration over convention)
instead of XML, or a lot annotations, Spring boot assume conventions (and library on classpath)to preset up

7. hibernate
new Java EE ORM implemntation (no more EJBs), JPA, has same origin as new hibernate implementation. so there are a lot commonality.
Hibernate probably is the most popular JPA provider for now

8. myBatis
While hibernate translate between objects and SQLs, where we call objects create/insert/update/delete actually call the hbernate generated SQL to be run on RDBMS (or other DB);
myBatis is more for the reverse. if the DB is old, not possible to change schema, direct SQL is preferred than leaving to Hibernate to construct simple queries.
Even though hibernate has its own HQL, mybatis is since beginning more on the direct SQL type

9. apache camel vs spring integration
both are EIP. Apache Camel has a massive of supported start points/URI, like HTTP, MQ, Timer etc.
With Spring framework become more and more popular, it started to incorporate various other functionality (besides DI), Spring integration is Spring’s counterparts for Camel.

Advertisements

twio very useful struts2 interceptors

ScopeInterceptor

 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>

ServletConfigInterceptor

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.

struts, spring integration is very cool

<?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).