Spring Core 3.2 - Study Notes © 2013 Arnošt Havelka

Examples of special operations:

// querying for DML (insert/update/delete row)
jdbc.update(sql);
jdbc.update(PreparedStatementCreator, KeyHolder)


// executing DDL
jdbc.execute(sql);


// executing batch update
BatchPreparedStatementSetter setter = new  BatchPreparedStatementSetter() {
    public void  setValues(PreparedStatement stmt, int row) {}
    public int  getBatchSize() { return 0; }
}
jdbcTemplate.batchUpdate(sql, setter); // or pass  Object[] as second parameter

3.3 Hibernate

3.3.1 Configuration of a SessionFactoryBean in xml

Instances:

• LocalSessionFactoryBean - supports a list of Hibernate XML mapping locations (use mappingLocations).

  <bean id="sf" class="os.orm.hibernate3.LocalSessionFactoryBean">
      <property name="dataSource" ref="d" />
      <property name="mappingLocations">
          <list>
              <value>classpath:/package/hbm.xml</value>
          </list>
      </property>
  </bean> 
  

• AnnotationSessionFactoryBean - extends LocalSessionFactoryBean and adds support
  • annotatedClasses - for a list of annotated classes (wildcards are not supported)
  • packagesToScan - for packages to scan

  <bean id="sf" class="os.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
      <property name="dataSource" ref="d" />
      <property name="annotatedClasses">
          <list>
              <value>Class1</value>
              <value>Class2</value>
          </list>
      </property>
  </bean>
  

Read only transactions prevent Hibernate from flushing session.

3.4 Transactions

3.4.1 Configuration to declare a local transaction manager

<bean id="mgr" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property  name="dataSource" ref="dataSource"/>
</bean>

• HibernateTransactionManager - supports Hibernate and JDBC
• JdbcTransactionManager - only supports JDBC
• JpaTransactionManager - supports JPA and JDBC
• etc.

3.4.2 Configuration to declare a JTA transaction manager

<bean id="mgr" class="org.springframework.transaction.jta.JtaTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>

or

<tx:jta-transaction-manager />

3.4.3 The different ways to do declarative transaction management with Spring (xml, annotations)

We have to define transaction manager first (see previous chapters).

<aop:config>
    <aop:advisor pointcut-ref="p" advice-ref="ta" />
</aop:config>

<tx:advice id="ta">
    <tx:attributes>
        <tx:method name="update*" timeout="60" />
        <tx:method name="*" timeout="30"  read-only="true" />
    </tx:attributes>
</tx:advice>

Use annotation @Transactional as:

• applicable on public methods or class (not applicable on non-public methods - there will be no error, but no transaction will be applied)
• not recommend on interfaces b/c not all proxies will take them
• requires JDK 5

3.4.4 Usage of TransactionTemplate for programmatic transaction management (you simply need to understand a basic example based on the TransactionTemplate).

• Takes transaction manager in constructor
• Passes TransactionStatus to TransactionCallback which lets you call status.setRollbackOnly()

Example:

public Object  someServiceMethod() {
    return  transactionTemplate.execute(new TransactionCallback() {
        public Object  doInTransaction(TransactionStatus status) {
            try {
                updateOperation1();
            } catch (XyzException e) {
                status.setRollbackOnly();
            }
            return  resultOfUpdateOperation2();
        }
    });
}

3.4.5 Transactions and exception management: what is the default rollback policy? Can it be overridden?

• Default policy is rollback for a RuntimeException.
• Default policy can be overriden - for the @Transactional annotation, specify rollbackFor or noRollbackFor when passing Class or rollbackForClassname/noRollbackForClassname when passing Strings.

3.4.6 The @Transactional annotation: what are the main attributes that can be used for a transaction definition? Can this annotation also be used with a JTA Transaction Manager?

• timeout - specified in seconds
• readOnly - true or false
• isolation - Isolation.READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ or SERIALIZABLE
• propagation - Propagation.REQUIRES_NEW, REQUIRED, etc. (see chapter 3.4.7)
• rollbackFor or rollbackForClassname - list of exceptions
• noRollbackFor or noRollbackForClassname - list of exceptions

Yes

3.4.7 Regarding propagation modes, what is the difference between PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW

Main attributes of @Transactional annotation are:

• REQUIRED (default) - If there’s an existing transaction in progress, the current method should run within this transaction. Otherwise, it should start a new transaction and run within its own transaction.
• REQUIRES_NEW - The current method must start a new transaction and run within its own transaction. If there’s an existing transaction in progress, it should be suspended.
• SUPPORTS - If there’s an existing transaction in progress, the current method can run within this transaction. Otherwise, it is not necessary to run within a transaction.
• NOT_SUPPORTED - The current method should not run within a transaction. If there’s an existing transaction in progress, it should be suspended.
• MANDATORY - The current method must run within a transaction. If there’s no existing transaction in progress, an exception will be thrown.
• NEVER - The current method should not run within a transaction. If there’s an existing transaction in progress, an exception will be thrown.
• NESTED (unique Spring feature) - If there’s an existing transaction in progress, the current method should run within the nested transaction (supported by the JDBC 3.0 save point feature) of this transaction. Otherwise, it should start a new transaction and run within its own transaction.

MEM: If methodA calls methodB directly, the transaction attributes of methodB are NOT used (due to proxy issue).

3.4.8 Regarding isolation levels, what is the difference between READ_COMMITTED and READ_UNCOMMITTED?

• Dirty reads (Uncommitted Dependency) - A dirty read occurs when a transaction is allowed to read data from a row that has been modified by another running transaction and not yet committed.
  • T1 Read
  • T2 Update
  • T1 Read will be temporary and invalid.
  • T2 Rollback
• Nonrepeatable read - A non-repeatable read occurs, when during the course of a transaction, a row is retrieved twice and the values within the row differ between reads.
  • T1 Read
  • T2 Update
  • T1 Read value will be different
• Phantom read - A phantom read occurs when, in the course of a transaction, two identical queries are executed, and the collection of rows returned by the second query is different from the first.
  • T1 Read
  • T2 Insert
  • T1 Read will contain additional rows.

The options to solve the read phenomena are:

• DEFAULT - Uses the default isolation level of the underlying database. For most databases, the default isolation level is READ_COMMITTED.
• READ_UNCOMMITTED - Allows a transaction to read uncommitted changes by other transactions. The dirty read, nonrepeatable read, and phantom read problems may occur.
• READ_COMMITTED - Allows a transaction to read only those changes that have been committed by other transactions. The dirty read problem can be avoided, but the nonrepeatable read and phantom read problems may still occur.
• REPEATABLE_READ - Ensures that a transaction can read identical values from a field multiple times. For the duration of this transaction, updates made by other transactions to this field are prohibited. The dirty read and nonrepeatable read problems can be avoided, but the phantom read problem may still occur.
• SERIALIZABLE - Ensures that a transaction can read identical rows from a table multiple times. For the duration of this transaction, inserts, updates, and deletes made by other transactions to this table are prohibited. All the concurrency problems can be avoided, but the performance will be low.

4. Spring MVC

4.1 General configuration

• <mvc:annotation-driven /> - Registers the DefaultAnnotationHandlerMapping and AnnotationMethodHandlerAdapter beans that are required for Spring MVC to dispatch requests to @Controllers.
• <context:component-scan /> - To enable autodetection of such annotated controllers (as well as other stereotype components)..

4.1.1  This module shows how to configure a ViewResolver, a HandlerMapping and the DispatcherServlet. You won't be asked any question on how to configure those classes. However, you need to know what the goal of each of those components is.

• Identifies correct view to call (to resolve the view implementation based on a given logical name). All handler methods in the Spring Web MVC controllers must resolve to a logical view name. View resolver can not handle absolute path (to the view).
• Explicitly (e.g. by returning a String, View or ModelAndView). They can also return null/void (to use default view) or a concrete class such as new JstlView(path)
• Implicitly (i.e. based on conventions)
• Can be chained (using the "order" attribute). InternalResourceViewResolver must be last.
• RedirectView or "redirect:"

Some of implementations:

• AbstractCachingViewResolver - caches view
• XMLViewResolver - mapping config from xml file
• ResourceBundleViewResolver - mapping from property bundle file
• UrlBasedViewResolver - maps urls directly to views
• InternalResourceViewResolver - extends UrlBasedViewResolver, maps to servlets / jsps
• FreeMarkerViewResolver - extends UrlBasedViewResolver
• ContentNegotiatingViewResolver - maps based on request file name or Accept header  

• Identifies correct controller to call.
• Spring 3 uses the default one which goes by the @RequestMapping annotation defined in the @Controller. Can be overriden (in xml) if required

• Front controller delegating to web infrastructure beans (handler mappings, view resolvers, type converters) and calling controllers/views
• Scenario of handling request:
  1. Handler Mapping(Request) returns Controller
  2. Controller(Request) returns ModelAndView
  3. View Resolver(View Name) returns View
  4. View(Model) returns Response
  5. returns Response

4.1.2 You also need to understand the relationship between a DispatcherServlet ApplicationContext and a root ApplicationContext.

• DispatcherServletApplicationContext can see the root context's configuration, but the root context can not see DispatchServletApplicationContext.
• DispatchServletApplicationContext can override root context beans

4.2 Controllers

4.2.1 Bootstrapping a root WebApplicationContext using the ContextLoaderListener

The DispatcherServlet takes a contextConfigLocation parameter in the web.xml or uses the default of ${servlet_name}-servlet.xml. We need (to configure DispatcherServlet properly) to do:

• Define listener so it loads the root ApplicationContext before initializing the servlet as:

  <context-param> <!-- override default configuration name -->
      <param-name>contextConfigLocation</param-name>
      <param-value>/WEB-INF/application-config.xml</param-value>
  </context-param>
  
  <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  

• Define servlet as:

  <servlet>
  	<servlet-name>mvc-dispatcher</servlet-name>
  	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  	<init-param> <!-- override default configuration name -->
  		<param-name>contextConfigLocation</param-name>
  		<param-value>/WEB-INF/web-application-config.xml</param-value>
  	</init-param>
  	<load-on-startup>1</load-on-startup>
  </servlet>
  
  <servlet-mapping>
  	...
  </servlet-mapping>
  

4.2.2 General usage of the @Controller and @RequestMapping annotations

• @Controller - annotates a class containing @RequestMapping on methods returning ModelAndView, String, void, etc.
• @RequestMapping:
  • Takes value of path of URL to match on method level and optionally class level adding slashes as needed.
  • Combined, they form the absolute URL path including Ant style wildcards.
  • Can also restrict by type or filter by params/headers (e.g. method=RequestMethod.GET)
  • You can declare @RequestMapping on both the class/method level or just the method level. The method level is key because it tells Spring the method can handle requests.

Example of mapping "/appointments/new" to getNewForm() (for only GET):

@Conttroller
@RequestMapping("/appointments")                              
public class  AppointmentsController {...
    @RequestMapping(value="/new", method =  RequestMethod.GET)
    public  AppointmentForm getNewForm() {...}
}

• Ant style globs: @RequestMapping("/myPath/*/pets/{petId}")
• Parameter conditions: @RequestMapping(value = "/pets/{petId}", params="myParam=myValue")
• Header conditions: @RequestMapping(value = "/pets", method = RequestMethod.POST, headers="content-type=text/*")

@RequestMapping(value="/owners/{ownerId}",  method=RequestMethod.GET)
public String findOwner(@PathVariable("ownerId")  String ownerId, Model model) {

4.2.3 A method annotated with @RequestMapping can return a String. What does it refer to? What are the main parameter types that this method can accept? (based on what you've seen in the class)

• A method annotated with @RequestMapping returns the view name - i.e. logical name of the view (to be determined by view resolver). For example, one can add a prefix/suffix to all strings returned, void (if the method handles the response directly), etc.
• Main parameter types of @RequestMapping method:
  • Servlet API - HttpSession, HttpServletRequest, HttpServletResponse
  • Stream - InputStream, Reader, OutputStream, Writer
  • Annotated - @PathVariable, @RequestParam, @RequestHeader, @RequestBody
  • Model - Map, Model, ModelMap
  • Other - Command or Form objects, Errors, SessionStatus

MEM: Method can not return absolute path to view.

4.2.4 Goal of the @RequestParam annotation

• To map request parameters to method parameters for use in the controller's methods.
• Can pass parameter name if doesn't match one in method.

@RequestMapping(method=RequestMethod.GET)
public String findOwner(@RequestParam("ownerId")  String ownerId, Model model) {

4.2.5 Configuring Spring MVC via XML

<mvc:annotation-driven />
<mvc:interceptors  />

4.2.6 Does Spring handle Multipart request?

Yes

• If you specify a multipart file resolver, the request is inspected for multiparts.

  <bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
      <!-- one of the properties available; the maximum file size in bytes -->
      <property name="maxUploadSize" value="100000"/>
  </bean>
  

• If multiparts are found, the request is wrapped in a MultipartHttpServletRequest for further processing by other elements in the process.
• In the controller, use: @RequestParam("myParam") MultipartFile file

4.3 REST

4.3.1 Differences between GET, POST, PUT and DELETE

@RequestMapping defines URI to resource, action (what to do with the resource) is defined by HTTP method:

• GET = select (read only)
• POST = create
• PUT = update
• DELETE = delete

4.3.2 Usage of the @PathVariable annotation

Maps parts of the url in @RequestMapping to a parameter (marked by annotation @PathVariable). For example the URL /account/{id} goes with @PathVariable id in the method signature. See URI template in chapter 4.2.2

4.3.3 What is the RestTemplate?

Programmatic client for calling RESTful URLs.

String result =  restTemplate.getForObject("http://example.com/hotels/{hotel}/bookings/{booking}", String.class,"42", "21");
RestTemplate t = new RestTemplate();
t.getForObject(uri, MyResponse.class, id);
t.postForObject(url, request, MyResponse.class, var1,  var2) or t.postForLocation(url, request, var1, var2)
t.put(uri, mine);
t.delete(uri);

4.3.4 Purpose of the @ResponseStatus Annotation

• Send an HTTP response code with the response. For example, @ResponseStatus(HttpStatus.CREATED).
• If defined on the method, sends that header.
• If defined on an exception, only sends if that error occurs.
• An empty body can be used for REST so no view is used.
• @ResponseStatus annotation can go on @RequestMapping method or an exception class.

4.3.5 Purpose of the @ExceptionHandler Annotation

• Specify which method is invoked when an exception of a specific type is thrown during the execution of controller methods
• If cannot annotate the actual exception, defines a response status in controller.

For example:

@ExceptionHandler({MyException.class})
@ResponseStatus(value = HttpStatus.NOT_FOUND, reason = "My Response Status Change….!!")
public void handleMyException(MyException ex, HttpServletResponse response) {
	logger.info("Handlng MyException - Catching: " + ex.getClass().getSimpleName());
}

4.3.6 What are HttpMessageConverters?

• HttpMessageConverter to convert to / from HTTP
• Objects passed to and returned from the methods getForObject(), postForLocation(), and put() are converted to HTTP requests and from HTTP responses by HttpMessageConverters.
• Concrete implementations for the main media (mime) types are provided in the framework and are registered by default with the RestTemplate on the client-side and with AnnotationMethodHandlerAdapter on the server-side.
• Use @RequestBody to map params, use @ResponseBody to map return value

5. Advanced topics

5.1 Remoting

5.1.1 Advantages of using Spring Remoting rather than plain RMI?

• Hide plumbing/complexity
• Support multiple protocols
• Simplify things when both ends of remote call run Spring

5.1.2 Goal and general configuration of the RMI Service Exporter

• Handle server side of RMI interaction
• Bind to registry
• Expose endpoint (used for everything except EJB; EJB already has mechanism to export remote)

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
    <property name="serviceName" value="AccountService"/> <!-- name in registry -->
    <property name="service" ref="accountService"/> <!-- reference to POJO implementing  serviceInterface -->
    <property name="serviceInterface" value="example.AccountService"/> <!-- interface classname -->
    <property name="registryPort" value="1199"/> <!-- defaults to 1099 -->
</bean>

5.1.3 Goal and general configuration of RMI Proxy Generator

• Handle client side of RMI interaction
• Communicate with endpoint
• Convert remote exception to runtime exception
• Can treat remote EJBs as POJOs

<bean id="accountService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
    <property name="serviceUrl" value="rmi://HOST:1199/AccountService"/> <!-- endpoint in registry (rmi://server:port/serviceName) -->
    <property name="serviceInterface" value="example.AccountService"/> <!-- interface classname -->
</bean>

5.1.4 Difference between the RMI Service Exporter and the HttpInvoker

• HttpInvoker uses HTTP POST while RMI one uses RMI.
• Bean classes to expose bean are HttpInvokerServiceExporter or RmiServiceExporter with the definition of service (reference to POJO implementing serviceInterface) and service interface (interface classname).
• Bean classes to connect bean are HttpInvokerProxyFactoryBean or RmiProxyFactoryBean with the definition of service URL (endpoint to the bean) and service interface (interface classname).
• The serviceName is specified as the name of the bean because default is to use BeanNameUrlHandlerMapping.

<bean name="/AccountService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
    <property name="service" ref="accountService"/> <!-- reference to POJO implementing  serviceInterface -->
    <property name="serviceInterface" value="example.AccountService"/> <!-- interface classname -->
</bean>

<bean id="httpInvokerProxy" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
    <property name="serviceUrl" value="http://remotehost:8080/remoting/AccountService"/>
    <property name="serviceInterface" value="example.AccountService"/> <!-- interface classname -->
</bean>

5.1.7 Does the HttpInvoker require to run a web server on the client side? On the server side?

Hessian (Caucho's binary-based format), Burlap (Caucho's XML-based format), HttpInvoker (spring's binary-based format) need a web server on the server side, but not on the client side.

5.2 Security

Basic concepts:

• Authentication is the process of verifying a principal's identity against what it claims to be.
• A principal can be a user, a device or a system, but most typically, it's a user.
• A principal has to provide evidence of identity to be authenticated. This evidence is called a credential, which is usually a password when the target principal is a user.
• Authorization is the process of granting authorities to an authenticated user so that this user is allowed to access particular resources. The authorization process must be performed after the authentication process. Typically, authorities are granted in terms of roles.
• Access control means controlling access to an application's resources. It entails making a decision on whether a user is allowed to access a resource. This decision is called an access control decision, and it's made by comparing the resource's access attributes with the user's granted authorities or other characteristics.

Security is configured (activated) in web.xml as:

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

Auto-config includes:

<http>
    <form-login /> <!-- to set form login authentication (login-pages, default-target-url, authentication-failure-url) -->
    <http-basic /> <!-- to set HTTP basic authentication -->
    <logout /> <!-- to set logout-success-url -->
    <anonymous username="guest"  granted-authority="ROLE_GUEST" /> <!-- to setup the anonymous user -->
    <remember-me /> <!-- to setup Remember-Me support -->
</http>

5.2.1 What is the "Security filter chain" used in Spring Security?

Series of servlet filters (declared in web.xml) that must be passed before/after resource is accessed. The chain is declared in web.xml (as servlet filter) and consists of:

• HttpSessionContextIntegrationFilter - loading HttpSession's context
• LogoutFilter - logging out if needed (logout was triggered)
• AuthenticationProcessingFilter - authenticating if needed
• ExceptionTranslationFilter - throwing proper exception (after only)
• FilterSecurityInterceptor - checking role (authorization)

5.2.2 Syntax to configure Spring Security to intercept particular URLs? (you need to have a good understanding of the various examples using intercept-url in the course)

<security:http>
    <security:intercept-url pattern="/stuff/**"  [method="GET"] access="role1, role2" />
</security:http>

• Always end url with a "*" to prevent hackers skipping the check by adding extra request parameters
• Pattern uses Ant syntax (** is any level of directories), can change to reg exp
• Access can get IS_AUTHENTICATED_FULLY or a list of roles
• If more than one intercept-url, matched top to bottom
• filters="none" - no security applied
• Anonymous users have the ROLE_ANONYMOUS role

5.2.3 Syntax to configure method level security

<security:global-method-security>
    <security:protect-pointcut expression="execution(* doStuff())" access="hasRole('ROLE_USER')" />
</security:global-method-security>

<bean id="..." >
    <security:intercept-methods>
        <security:protect method="com.apress.springrecipes.board.service.MessageBoardService.listMessages" access="ROLE_USER,ROLE_GUEST" />
    </security:intercept-methods>
</bean>

5.2.4 Method level security using @Secured or @RolesAllowed

• XML activation - <security:global-method-security secured-annotations="enabled" />
• Usage - @Secured("role1") to pass allowed roles

• XML activation - <security:global-method-security jsr250-annotations="enabled" />
• Usage - @RolesAllowed("role1") to pass allowed roles

5.2.5 Possible mechanisms to store user details: database? LDAP? Others?

• Database: <security:jdbc-user-service data-source-ref="ds" />
• In memory: <security:user-service properties="a.properties" />
• xml or properties files
• LDAP, JAAS, SSO, OpenId, etc.

Example:

<authentication-manager>
    <authentication-provider>
        <user-service>
            <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
            <user name="bob" password="bobspassword" authorities="ROLE_USER" />
        </user-service>
    </authentication-provider>
</authentication-manager>

5.2.7. When working with an authentication provider, is it possible to use a password encoder?

Yes - <security:password-encoder hash="abc" />

5.2.8 In the security tag library, what is the purpose of the <security:authorize /> tag?

To say what roles are permitted access to a section of the JSP. Attribute access may have value or EL (but not both).

<security:authorize access="hasRole('supervisor')">do stuff</security:authorize>
<security:authorize ifAnyGranted="roles">do stuff</security:authorize>

Possible properties:

• access (hasRole, hasAnyRole, isAnonymous, isAuthenticated)
• url
• ifAnyGranted
• ifAllGranted

5.3 JMS

• Components: message, destination, connection, session, message producer and consumer
• JMS message types: TextMessage, ObjectMessage, MapMessage, etc.
• Destination is where we listen for a message
• Response-destination is needed if the method doesn't return void
• Configuration:
  • Create connection factory and queues by creating bean for standalone or <jee:jndi-lookup jndi-name="jms/aaa" />
  • Can wrap with CachingConnectionFactory if need caching

• Reasons to use: see chapter 5.3.1
• Instances of the JmsTemplate class are thread-safe once configured.
• All send methods put message on queue and resume.
• All receive methods are blocking / synchronous.
• MessagePostProcessor interface gives you access to the message after it has been converted.
• Properties:
  • Connection Factory (e.g. SingleConnectionFactory or CachingConnectionFactory - required
  • Use "defaultDestination" (destination does not need to be specified for each send / receive call) - Spring bean (reference name) or DestinationResolver.
• Methods (use MessageCreator - if need to map object to/from Message for nonstandard type):
  • convertAndSend() - delegates conversion to the MessageConverter bean (set on the JmsTemplate) and then sends message
  • receiveAndConvert() - waits to receive message and then delegates to the MessageConverter bean (set on the JmsTemplate).
  • execute() - use for SessionCallback and ProducerCallback
  • No callback methods exist.

  <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate"
            p:connectionFactory-ref="jmsProducerConnectionFactory"
            p:defaultDestination-ref="destination" />
  </bean>
  

  jmsTemplate.send(this.queue, new MessageCreator() {
      public  Message createMessage(Session session) throws JMSException {
              return  session.createTextMessage("hello queue world");
      }
  });
  

5.3.1 Purpose of the JmsTemplate

• Simplify usage of JMS
• Reduce boilerplate code
• Handle exceptions
• etc.

5.3.2 How to declare a JMS Listener? Can a JMS Listener be a POJO?

• Use Message-Driven POJOs (which must be thread-safe)
• Implement javax.jms.MessageListener (JavaEE) or SessionAwareMessageListener (Spring-specific)
• Use the MessageListenerAdapter class (as spring bean), e.g.:

  <bean id="messageListener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter">
      <constructor-arg>
          <bean class="MyDelegate"/>
      </constructor-arg>
  </bean>
  

• Define a container

  <jms:listener-container connection-factory="connFactoryRef">
      <jms:listener destination="queue.orders" ref="myDelegate" />
  </jms:listener-container>
  

• Extend JmsGatewaySupport - use SimpleMessageListenerContainer (non-txn aware) or DefaultMessageListenerContainer (txn aware)

Yes - just register in XML inside a listener-container

<jms:listener destination="d" ref="myDelegate" method="m" response-destination="rd" />

5.3.3 Is it possible to run JMS inside a plain Servlet container without full Java EE support (such as Tomcat or Jetty)?

Yes - with usage SimpleMessageListenerContainer (for basics) or DefaultMessageListenerContainer (for transactions).

5.4 JMX

• Gather information from application (in runtime)
• Dynamically reconfigure application
• Trigger operations in application
• etc.

• Spring easily export Spring-managed beans as JMX bean with <context:mbean-export>
• Use <context:mbean-server> to create MBean server
• Use Spring annotations to define attributes (@ManagedAttribute) and operations (@ManagedOperation)

5.4.1 Role of the MBeanExporter

This class is responsible for taking your Spring beans and registering them with a JMX MBeanServer (expose POJO as MBean).

5.4.2 Using Spring JMX, is it possible to export a POJO as an MBean?

Yes - register as a bean and use MBeanExporter

<bean class="org.springframework.jmx.export.MBeanExporter">
    <property name="beans">
        <util:map>
            <entry key="bean:name=mine" value-ref="beanRef" />
        </util:map>
    </property>
</bean>

• Bean is exposed as an MBean under the ObjectName bean:name=mine
• By default, the Spring MBeanExporter exports all public properties of a bean as MBean attributes and all public methods as MBean operations.
• Use an MBeanInfoAssembler to control attributes and operations
• Use org.springframework.jmx.export.annotation.AnnotationMBeanExporter to detect @ManagedResource annotations
• Use <context:mbean-export server="mbeanServer" default-domain="bean" />

5.4.3 Using Spring JMX, is it possible to automatically register an existing MBean with an MBeanServer?

Yes - just register them as a bean in the XML config and Spring will notice they are already MBeans (i.e those beans implementing classes that ends with MBean).

5.4.4 Purpose of the @ManagedResource, @ManagedAttribute and @ManagedOperation annotations

• @ManagedResource(objectName="mine") - identifies class as MBean
• @ManagedAttribute – expose field to JMX – place on getter and setter
• @ManagedOperation – expose method to JMX

@ManagedResource(description = "some description")
public class MyJmxBean implements Foo {

	private int counter=0;

	@ManagedAttribute(description="Get counter value")
	public int getCounter() {
		return counter;
	}
	
	@ManagedOperation(description="Increase counter")
	public void increaseCounter() {
		this.counter++;
	
}

5.4.5 How to declare an MBeanServer

• Automatic registration of existing MBeans: <bean id="mine" class="ExistingMBean" />
• Define MBeanServer: <context:mbean-server />
• Or declare the MBeanServerFactoryBean with the locateExistingServerIfPossible property so it can use an existing server or create a new one.

5.4.6 Accessing remote MBean (through a proxy)

<bean id="mbeanServerConnection"... />
    <bean  id="..." class="org.springframework.jmx.access.MBeanProxyFactoryBean">
        <property name="server" ref="mbeanServerConnection" />
        <property name="objectName" value="bean:name=mine" />
        <property name="proxyInterface" value="Mine" />
    </bean>
</beans>