Spring Core

1. handles server-side of RMI interaction
2. declarative exposes an existing service to RMI registry
3. avoid traditional RMI requirements
   => Service interface doe NOT extend Remote

NOTE: Transferred object however still need to implement the interface java.io.Serializable

1. handles client-side of RMI interaction
2. communicates with endpoint (Service Exporter)
3. converts checked RemoteException into Spring's runtime hierarchy of RemoteAccessException
4. can treat remote EJB's as POJOs

Configuration starts with a existing POJO service with id "transferService"

<bean class="org.springframework.
    remoting.rmi.RmiServiceExporter">
    <property name="serviceName" 
                        value="transferService" />
    <property name="serviceInterface"
                        value="app.TransferService" />
    <property name="service" ref="transferService" />
    <property name="registryPort" value="1096" />
</bean>

NOTE:
serviceName      = name in RMI registry
service                 = reference to POJO service
serviceInterface = interface classname
registryPort         = optional / defaults to 1099

<bean id="transferService" class="org.springframework.
    remoting.rmi.RmiProxyFactoryBean">
    <property name="serviceInterface" 
                        value="app.TransferService" />
    <property name="serviceUrl"
                        value="rmi://foo:1096/transferService" />
</bean>

NOTE:
serviceInterface = interface classname
serviceUrl           = endpoint in registry
                                 rmi://server:port/serviceName

1. HTTP POST
2. HttpInvokerServiceExtporter
   NOTE: bean definition needs name attribute!
3. HttpInvokerProxyFactoryBean
4. Port 8080

NOTE: HttpInvoker needs webserver on server side, but NOT on client side!

NOTE: HttpInvoker is a Java-to-Java technology only!

NOTE: Both sides need Spring!

1. Message
2. Destination
3. Connection
4. Session
5. MessageProducer
6. MessageConsumer

1. TextMessage
2. ObjectMessage
3. MapMessage
4. BytesMessage
5. StreamMessage

1. Queue
   = Point-to-Point messaging / 1 receiver
2. Topic
   = Publish-Subscribe messaging / several receiver

1. simplifies usage of JMS API
2. handles exception properly
3. converts checked exception to runtime equivalents
4. provides conveniance methods and callbacks
5. delegates to collaborators to handle some of the work
   => MessageConverter
   => DestinationResolver

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

Property overview:
- connectionFactory = mandatory
- defaultDestination = optinal

JmsTemplate:

• synchronous message reception
  (= methods are blocking)
• jmsTemplate.receive()

MessageListener:

• asynchronous message reception
• MessageListenerContainers are needed

1. acts as receiver for JMS messages
2. must implement javax.jms.MessageListener

Note: Must be thread-safe when receiving messages from multiple threads!

public class MyListener implements MessageListener
{
    public void onMessage(Message msg) { ... }
}

Spring provides lightweight alternatives to traditional EJB containers.

1. SimpleMessageListenerContainer
   = no transactionall support
   = creates a fixed number of sessions
2. DefaultMessageListenerContainer
   = adds transactional capability

<!-- Message-Driven POJO (MDP) -->
<bean id="msgListener" class="example.MyListener"  />

<bean id="jmsContainer class="org.springframework.
    jms.listener.DefaultMessageListenerContainer">
    <property name="connectionFactory" ref="..." />
    <property name="destination" ref="..." />
    <property name="messageListener" ref="msgListener" />
</bean>

1. <jms:listener-container>
   = no required attributes
   = container-type="default" (default)
   = connection-factory="connectionFactory" (default)
2. <jms:listener destination="..." ref="..." />
   = required attributes are 'destination' and 'ref'
       (destination name / bean name of listener)

POJO example:
public class OrderService {
    public OrderConfirmation order(Order o) { ... }
}

Listener configuration:
<jms:listener ref="orderService" method="order" destination="..." response-destination="..." />

1. gather information from application in runtime
2. dynamically reconfigure application
3. trigger operations in application

1. MBeanServer
   = maintains a keyed reference to all MBeans
   = acts as broker for communication between
       - multiple local MBeans
       - remote clients and MBeans
2. MBean
   = object with additional management metadata
       - Attributes = properties
       - Operations = mehtods
3. MBeanExporter
   = takes existing POJO beans and registers
      them with MBeanServer

@ManagedResource(description="...")
public class JmxCounterImpl implements JmxCounter
{
    @ManagedAttribute(description="Counter Value")
    public int getCount() { ... }

    @ManagedOperation(description="Increment value")
    public void increment() { .. }
}

<context:mbean-export />

Existing POJO bean:
<bean id="msgService" class="example.MsgService" />

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

With context namespace:
<context:mbean-server />
=> automatic registration of existing MBeans
     <bean id="..." class="ExistingMBean" />

Declare it explicitly:
<bean id="mBeanServer" class="org.springframework.
    jmx.support.MBeanServerFactoryBean">
    <property name="locateExistingServerIfPossible"
        value="true" />
</bean>
 

1. constructor dependency injection
2. setter dependency injection

• enforce mandatory dependencies
• promote immutability
• concise for programmatic usage

<bean id="service" class="example.ServiceImpl">
    <constructor-arg ref="repository"/>
</bean>

<bean id="repository" class="example.RepositoryImpl" />

NOTE: Ambiguity in args is NOT allowed!
<constructor-arg type="int">
    <value>7</value>
</constructor-arg>

• allow optional dependencies and defaults
• have descriptive names
• inherited automatically

<bean id="service" class="example.ServiceImpl">
    <property name="repository" ref="repository"/>
</bean>

<bean id="repository" class="example.RepositoryImpl" />

1. get application context

ApplicationContext context = new ClassPathXmlApplicationContext(...);

2. get bean from application context

OLD:
ClientService service = (ClientService) context.getBean("clientService");

NEW: since Spring 3.0
=> no more cast, type is a method param

ClientService service = context.getBean("clientService", ClientService.class);

=> no need for bean id if type is unique

ClientService service = context.getBean(ClientService.class);

1) factory-method="getInstance"

useful for existing singeltons or factories
NOTE: getInstance() should always be static!

2) factory-bean="clientServiceFactory" factory-method="getNewInstance"

no need of class attribute

3) beans implementing FactoryBean interface are auto-detected

getObject() called by Spring automatically

NOTE: useful for generically build e.g. in-memory db at start time

ApplicationContext ctx = new ClassPathXmlApplicationContext("com/example/appl-config.xml")

ApplicationContext ctx = new FileSystemXmlApplicationContext("C:\\etc\\appl-config.xml")

ApplicationContext ctx = new XmlWebApplicationContext(./config/appl-config.xml)

ApplicationContext ctx = new AnnotationConfigApllicationContext(Config.class)

Prefixes & wildcards:

classpath: = search in classpath but only first matching folder/jar is included

classpath*: = search in classpath and all sources (jar files & source folders) are included

file: = search in filesystem

http:

1. application beans and infrastructure beans can be separated
2. allows partitioning into logical groups (e.g. application modules)
3. data source specific beans can be substituted easily (e.g. change of db)
4. test and productive environment can be easily seperated

1. bean is handed what it needs to work
2. promotes programming to interfaces
3. improves testability
4. allows for centralized control over object lifecycle

1. simple and expressive configuration
2. provide abstraction and semantic validation
3. defined for categories of related framework functionality (aop, beans, context, jms, tx, ...)
4. it's possible to write own namespace

common annotations

@PostConstruct / javax.annotation.PostConstruct

@PreDestroy / javax.annotation.PreDestroy

Spring makes use of these annotations to trigger lifecycle events

@PostConstruct
@PreDestroy

NOTE: NOT @Autowired!

1. initialization phase
2. use phase
3. destruction phase

application services

• are created
• are configured
• may allocate system resources

prepares for use / application is not usable until this phase is complete

application services

• process client request
• carry out application behavior

99.99% of time is spent in this phase

application services

• release any system resources
• are eligible for garbage collection

Shut Down

1. load bean definitions

• XML files are parsed
• bean definitions are loaded into context (each indexed under its id)
• BeanFactoryPostProcessor beans are invoked

2. initialize bean instances

• beans get instantiated
• setters called
• before init Bean Post Processors are called
• initializer called
• after init Bean Post Processors are called (proxies are created by Special BPP's)

3. bean ready for use

1. only called once per xml before bean instantiation!

2. PropertyPlaceholderConfigurer
     = substitutes ${variables} with values from
        .properties files

NEW way with namespace:

<context:property-placeholder location="/WEB-INF/configuration.properties" />

OLD way: 

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location" value="/WEB-INF/configuration.properties" />
</bean>