Spring3 Features -TaskExecutor & TaskSchedulor

The Spring Framework provides abstractions for asynchronous execution and scheduling of tasks with the TaskExecutor and TaskScheduler interfaces, respectively.

http://docs.google.com/fileview?id=0B-0gqvlsl_VvNTBlMDdmZmUtYWE4Ni00YmRhLTk0ODAtYWNhYjk4OGM5YTk1&hl=en
[Download - rename from pdf to rar]
[Attached is the sample code for both –with annotations]

1. TaskExecutor

Spring's TaskExecutor interface is identical to the java.util.concurrent.Executor interface.

ConcurrentTaskExecutor : This implementation is a wrapper for a Java 5 java.util.concurrent.Executor.

ThreadPoolTaskExecutor : Spring's TaskExecutor implementation.

[org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor – Namespace: ]

Parametres : corePoolSize,maxPoolSize,queuecapacity,rejection-policy

The executor will first try to use a free thread if the number of active threads is currently less than the core size. If the core size has been reached, then the task will be added to the queue as long as its capacity has not yet been reached. Only then, if the queue's capacity has been reached, will the executor create a new thread beyond the core size. If the max size has also been reached, then the executor will reject the task.

By default, when a task is rejected, a thread pool executor will throw a TaskRejectedException. CallerRunsPolicy. Instead of throwing an exception or discarding tasks, that policy will simply force the thread that is calling the submit method to run the task itself. The idea is that such a caller will be busy while running that task and not able to submit other tasks immediately. Therefore it provides a simple way to throttle the incoming load while maintaining the limits of the thread pool and queue.

2. TaskScheduler

Spring 3.0 introduces a TaskScheduler with a variety of methods for scheduling tasks to run at some point in the future.

- can be associated with a pool size.

Taskschedulor.schedule() takes a trigger expression based on which tasks will be scheduled.

Annotation Support

Both have very easy annotation support.

@Async - This can be marked on any POJO method

@Scheduled- This annotation can be marked on any POJO method

Just add  in the xml and give respective scheduler or executor as properties.

Currently with spring 3 RC2 and Spring Dm 2.0M6 – I could not use namespace support as they were giving some issues. It could be a BUG and I have raised this issue in the forum.

http://forum.springsource.org/showthread.php?t=81676

In the attached sample code instead of using namespace I have used the entire class name.

Namespace should work with Spring 3 RC3 version.

Spring Integration+JMS(JBOSS)+OSGi

I have a POC for spring integration to be used along with JBoss and OSGi in Spring Dm server 2.0M6.

Code Sample
http://docs.google.com/fileview?id=0B-0gqvlsl_VvNzhiMzVmMzgtY2Y4Zi00YjJmLWJmNWQtMTIwMDZjNDViMmJl&hl=en
[Download this pdf - Rename file from pdf to rar and extract]


SwitchBoardBundle – Exposes connection factories as service

Exposes common thread pools as service

[Jboss ip values for connection factories are picked from property files]



Ara Bundle - Start a timertask which puts message into a login channel.

This channel is exposed as a service which is imported by PamClient Channel

Ara bundles defines its own thread pool and receives connectionFactory service from switchboard bundle.



PamClient Bundle - Listens to local events from ara bundle and remote events from Pamserver bundle

Imports login channel service from Ara bundle

Uses common thread pool defined in switchboard bundle

[Property file has values which can point each topic or queue to be hosted on a specific Jboss server]



PamServer Bundle – generates events on regular time intervals which will be put into Jms queue using jms adapters.

Also tested a use case where we could change connection factory without getting down the server

OSGi -Spring - Configuration Admin - Dynamic Property file changes

Normally we have been reading the property files ourselves or used spring property-holder feature or even cm-properties. In all these cases update to the property file are not visible.

You can now use the managed-properties under Configuration Admin and have the values updated in your bean automatically whenever you change the property file. You just drop a property file inside pickup directory and under the bean definition specify the persistent-id as follows:


// Have a property file with name myPropertyFile
<osgix:cm-properties id="config" persistent-id="myPropertyFile"/>

//declare a property place holder config with id of osgi:cm
<context:property-placeholder properties-ref="config"/>

//bean definition using teh property file
<bean id="configTest" class="com.test.ConfigTest">
<osgix:managed-properties persistent-id="myPropertyFile" update-strategy="container-managed" /> <property name="propertyValue" value="${propertyValue}"></property>
</bean>

Now first add the property file to the pick up folder and start the DM server. The setPropertyValue() setter will be called and the value will be initialized when application bundle is dropped.

[There are multiple calls to this setter because of the osgi configuration admin]

Now when the property file in changed in the pickup directory , the setter method will be called and new value will be set into the bean.

Incase you want to manage the updates yourself you can change the update-strategy and provide the update-method in the bean. In this case all the key/values are provided to the method in form of a Map.

<bean id="configTest" class="com.test.ConfigTest">
<osgix:managed-properties persistent-id="myPropertyFile"
update-strategy="bean-managed" update-method="refresh" />
<property name="propertyValue" value="${propertyValue}"></property>
</bean>

The ConfigTest class is as follows

public class ConfigTest {

private int propertyValue;

public void setPropertyValue(int propertyValue) {

System.out.println("setter called for property"+propertyValue);
this.propertyValue = propertyValue;
}


public void refresh(Map <String,String> keyVals)
{
System.out.println("referhs called with value"+keyVals);
}

}

PS:

Do not share the same persistent-id (PID) between multiple bundles or definitions, as only one of them will receive notifications. managed-properties relies on org.osgi.service.cm.ManagedService contract which mandates that each ManagedService instance must be identified with its own unique PID.

Hence the best option in a service model is to have a configuration service reading the property file and giving notifications to required bundles.

Interesting Java Data Structures

Vector & Collections.synchronizedList(new ArrayList()); are similar. They get the lock on the entire object.

So are HashTable and Collections.synchronizedMap(new HashMap());.

Though lock is taken on entire object - during operations like iterations they have to be in a synchronised block.Else parallel access by other thread will lead to a concurrent access exception.

http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html

Solution to these are data structures like CopyOnWrtieArrayList(for list) ConcurrentHashMap(for map).

ConcurrentHashMap doesnt lock the entire object , instead allows parallel reads, when a write operation is on.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html


Similarly with CopyOnWriteArrayList there is no need to lock the entire object during iteration, as the iteration will happen on a copy object.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CopyOnWriteArrayList.html

RentrantReadWriteLock - This helps in taking a lock .So that all other access through this point will wait for the lock to be released. This lock is not resticted to a object and hence can be used in the business logic to get fine thread safety and synchronisation over business objects.This also provided read and write locks which will help in granular control for read and write operations.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html

Synchronizing method against block(object)

When a method is synchronized , the method object is blocked. No other thread can enter into any other synchronized method(non static) on this object.But other threads can enter into a non synchronized block on the same class.

When a block is synchronized - if its synchronised on a object ,two parallel thread can access two synchronized blocks at the same time., since locks are on two different objects.

Class level locks can be obtained by making static methods synchronized.

AOP - AspectJ,Spring - Compile Time ,Load Time ,Run Time(Proxy)

Spring AOP - Runtime - Using Proxy

Steps

1.Spring Application Context - Bean Declarations

For enabling this proxy approach add
<aop:aspectj-autoproxy />

Note :

Do not be misled by the name of the element: using it will result in the creation of Spring AOP proxies. The @AspectJ style of aspect declaration is just being used here, but the AspectJ runtime is not involved

Aspect Declaration
<bean id="myAspect" class="com.test.aop.MyAspect"></bean>

Method where aspect will be applied
<bean id="test" class="com.test.aop.Test" init-method="init" />

Wrapper calling test
<bean id="testB" class="com.test.aop.Wrapper" init-method="init">
<property name="test" ref="test"></property>
</bean>


2. Classes

• Aspect Class

@Aspect
public class MyAspect {

@Before("execution(* com.test.aop.Test.*())")
public void myMethod()
{
System.out.println("calling my before aspect");
}

}

• public class Test {

public void init()
{
System.out.println("init in test method");
}

}

• public class Wrapper {

private Test test;

public void setTest(Test test) {
this.test = test;
}

public void init() {
test.init();
}

}

3. OutPut(In Spring DM)

System.out I init in test method
System.out I calling my before aspect
System.out I init in test method

Only when the init method is called through testB bean ,the aspect is bound.

Now when init method of test bean is called , the aspect is still not bound.(init methods cannot be proxied).

This is because the way spring life cycle works :

Spring life cycle

Phase 1 - Validate bean definitions
Phase 2 - Bean definition post processor(replacing property values)
Phase 3 - Bean Instantiation
Phase 4 - Bean post initialization(setters and init methods -in order) & Proxy creation

In the above example bean 'test' first cycles through phase 1,2,3 and 4. Hence after the init method is called, the proxy is created.But when testB is created in its init(phase) call to bean test will call teh aspect (as bean test lifecycle is complete)

One more important thing to note is that Cg lib will be used to create proxy here as teh class doesnt implement any interface.(Else jdk dyanmic proxies would have been used)

Aspect-J Load Time Weaving
(This may have issues with Spring DM
http://forum.springsource.org/showthread.php?t=80504
)

Same code as above except some change in the configurations.

1. Replace <aop:aspectj-autoproxy /> with <context:load-time-weaver/>.

2. Add aop.xml in META-INF directory

<!DOCTYPE aspectj PUBLIC
"-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
<aspectj>

<!--works without this -->
<weaver>
<include within="com.test.aop.*" />
</weaver>

<aspects>
<!-- weave in just this aspect -->
<aspect name="com.test.aop.MyAspect" />
</aspects>

</aspectj>


3. Class to test the application in standlone mode

public class StandAloneLoadTimeWeaving {

public static void main(String args[])
{
ApplicationContext ctx = new ClassPathXmlApplicationContext("config.xml",StandAloneLoadTimeWeaving.class);
Test t =(Test)ctx.getBean("test");
t.init();
}

}

Ref: http://www.springbyexample.org/examples/aspectj-ltw.html
http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw


4. Add the following parameter when running

-javaagent:spring-agent.jar


Aspect J Compile Time Weaving(Build Time)

Same as Loadtime weaving needs aop.xml (but no need to add spring agent while running)

Command to compile the code

java org.aspectj.tools.ajc.Main –inpath <src_code_directory> -outjar <output_jarname.jar>

Ex:java -cp aspectjtools.jar;aspectjrt.jar org.aspectj.tools.ajc.Main -inpath . -outjar test.jar

The output jar will have code which is instrumented by the aspect.

You can download aspectj from this site

http://www.eclipse.org/aspectj/downloads.php

Writing Custom Namespaces in Spring

1. Application context xmls looks as below

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:test="http://www.test.xyz/schema"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.test.xyz/schema http://www.test.xyz/schema-1.0.xsd">

<test:person name="suji"/>
</beans>

Now the xsd mentioned in the schema location should map to something.

2. You shoudl have a spring.schemas file in the META-INF directory

http\://www.test.xyz/schema-1.0.xsd=com/test/test-1.0.xsd

This maps the schema to teh lcoation of teh xsd

3. Xsd looks like

<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.test.xyz/schema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<xsd:element name="person">
<xsd:complexType>
<xsd:annotation>
<xsd:documentation>
Configures all required interactions with the named Control Bus configuration
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Identifies group-name of a Control Bus this configuration defines
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>

</xsd:schema>

We have a single element person with attribute as name which is a string.

4. Now each element in the xsd should map to a resolver.

This can be mentioned in spring.handlers file which is also in the META-INF directory

http\://www.test.xyz/schema=com.test.PersonNamespaceHandler


5. Implementaion of PersonNamespaceHandler

import org.springframework.beans.factory.xml.NamespaceHandlerSupport;

public class PersonNamespaceHandler extends NamespaceHandlerSupport {
public void init() {
registerBeanDefinitionParser("person", new PersonParser());
}

}


6. Parser implementation

public class PersonParser extends AbstractBeanDefinitionParser {
private String beanName;

/* This method gets the parameters mentioned in the custom namespace and helps building
custom logic based on it */


@Override
protected AbstractBeanDefinition parseInternal(Element element,
ParserContext parserContext) {
BeanDefinitionBuilder rootBuilder = BeanDefinitionBuilder
.rootBeanDefinition(Person.class.getName());
beanName = element.getAttribute("name");

//Ensuring name is a compulsary attribute

Assert.hasText(beanName, "'name' must be provided");
rootBuilder.addPropertyValue("name", beanName);
return rootBuilder.getBeanDefinition();
}

protected String resolveId(Element element,
AbstractBeanDefinition definition, ParserContext parserContext)
throws BeanDefinitionStoreException {
return beanName;
}

}


7. Custom classes for Person

public class Person {

private String name;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}


Test case for trying out this

public class PersonParserTest {

public static void main(String[] arg){
ApplicationContext ac = new ClassPathXmlApplicationContext("config.xml", PersonParserTest.class);
Person person = (Person) ac.getBean("suji");
System.out.println("Person: " + person.getName());
}
}

TCCL in OSGi(Spring DM)

In order to better understand how TCCL works in OSGi i have done a sample POC.

I created 3 bundles.

Bundle A - calls Bundle B (imports Bundle B)

Bundle B -calls Bundle C (imports Bundle A)

Bundle C - instantiates class in Bundle A (No imports)

In normal cases Bundle C will fail to instantiate class in Bundle A, but this can be achieved using TCCL as follows.

ITest test=(ITest)Thread.currentThread().getContextClassLoader().loadClass("com.bundleA.external.ActionClass").newInstance();

Conclusion: Spring Dm sets TCCL to the bundle classloader where the thread initiated.

Now what if we want to instantiate class of bundle B in Bundle C , but the thread flow doesnt change. ?

This can be easily done by resetting the TCCL in bundle B's method as follows

Thread.currentThread().setContextClassLoader(Bundle2.class.getClassLoader());

BootClassPath and Sytem ClassPath in OSGI(Spring DM)

System Package

java.* can be directly used without any imports. This is neither part of boot delegation nor system packages as they are part of jdk itself.For loading these fundamental types, the OSGi platform uses parent delegation instead of the networking model; that is, it uses the class loader that started the OSGi framework to load classes instead of an OSGi class space.

None of the other public packages available in the JDK such as the javax.net or javax.xml are parent delegated which means they have to be resolved within the class space that is, bundles need to import the packages (which means there needs to be a provider) since they are not implied. The OSGi spec allows the Framework (through its system bundle) to export
any relevant packages from its parent class loader as system packages using the org.osgi.framework.system.packages property.

As repacking the hosting JDK as a bundle isn't a viable option, one can use this setting to have the system bundle (or the bundle with id 0) export these packages itself.

Extension Bundles

Another possible option is to enhance the system bundle through extension bundles. These act as fragments; they are not bundles of their own but rather are attached to a host.
Extension bundles are a special kind of fragments that get attached only to the System bundle in order to deliver optional parts of the Framework

Boot Delegation

This allows the user to create 'implied' packages that will always be loaded by the framework parent class loader, even if the bundles do not provide the proper imports:

This option is mainly created to accommodate various corner cases especially in the JDK classes that expect parent class loading delegation to always occur or that assume that every class loader on the system has full access to the entire boot path.There are cases where boot delegation is quite handy; a good candidate being instrumentation, such as profiling or code coverage.

Ref:http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/

I have done samples to better understand how classloader comes into picture for loading classes at different levels by printing parent classloaders upto 4 levels.

Class loader for one of the classes of bundle in pick up.

bundle classloader ServerBundleClassLoader: [bundle=ClassPathTest_1.0.0]
bundles parent java.net.URLClassLoader@126e85f
bundles parent sun.misc.Launcher$AppClassLoader@7d772e
bundles parent sun.misc.Launcher$ExtClassLoader@11b86e7


Class loader hierarchy for org.osgi.framework.BundleActivator

**************System bundle 0*******************
bundle classloader java.net.URLClassLoader@126e85f
bundles parent sun.misc.Launcher$AppClassLoader@7d772e
bundles parent sun.misc.Launcher$ExtClassLoader@11b86e7
I bundles parent null


Created a dummy class and added this in the classpath of dm server startup.bin.Also modified to include this java6-server.profile as org.osgi.framework.system.packages = \
(I did import this package in my test bundle)

*************SYSTEM PATH**************
bundle classloader sun.misc.Launcher$AppClassLoader@7d772e
bundles parent sun.misc.Launcher$ExtClassLoader@11b86e7
bundles parent null
I parent null


Created a dummy class and added this in the classpath of dm server startup.bin.Also modified to include this java6-server.profile as org.osgi.framework.bootdelegation = \
(Did not import this package in my test bundle)


*************BOOT PATH**************

bundle classloader sun.misc.Launcher$AppClassLoader@7d772e
bundles parent sun.misc.Launcher$ExtClassLoader@11b86e7
I bundles parent null
I parent null

Configuring Component based logging in OSGi using Log4j

Initialize reading of the log4j xml in any of the core bundles. Ensure that this bundle doesnt get bounced often.Configure the values to include log4j xml and reload delay.The init method can look something similar to the one below.

public void initialize() {
try {
try {
String logConfig = "D://temp//poc_log_config.xml";
long configReloadDelay = (long) (1 * 30 * 1000);
if (logConfig != null && (new java.io.File(logConfig).exists())) {
if (logConfig.endsWith("xml")) {
org.apache.log4j.xml.DOMConfigurator.configureAndWatch(
logConfig, configReloadDelay);
} else {
org.apache.log4j.PropertyConfigurator
.configureAndWatch(logConfig, configReloadDelay);
}
} else {
org.apache.log4j.BasicConfigurator.configure();
}
} catch (Exception initErr) {
initErr.printStackTrace();
}
} catch (Exception err) {
}

}


The log4j xml will look as follows

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

<appender name="PRODUCT1" class="com.test.anyappender">
<param name="File" value="D:\\temp\\product1\\product1log.log"/>
<param name="MaxFileSize" value="100000000"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss,SSS} - %m%n"/>
</layout>
<param name="Threshold" value="DEBUG"/>
</appender>

<appender name="PRODUCT2" class="com.test.anyAppender">
<param name="File" value="D:\\temp\\product2\\product2.log"/>
<param name="MaxFileSize" value="100000000"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss,SSS} - %m%n"/>
</layout>
<param name="Threshold" value="DEBUG"/>
</appender>

<root>
<level value="OFF" />
</root>

<logger name="test1">
<appender-ref ref="PRODUCT1"/>
<level value="INFO" />
</logger>

<logger name="test2">
<appender-ref ref="PRODUCT2"/>
<level value="DEBUG" />
</logger>

</log4j:configuration>


Now in any bundle code you can access any component logger as follows

static final Logger TEST_LOGGER = Logger.getLogger("test1");

use TEST_LOGGER.debug("any debug message");

By the above approach we can just have a single log4j bundle in the repository and not only avoid issues occuring from static variables but also can take full benefit of log4j API's.

Extending OSGi telnet for custom commands

OSGi telnet command provided by equinox can be easily extended to implement custom commands.

First we need to write a class with which implements the custom commands.the methods should start with _ to be identified as osgi telnet commands.The getHelp command needs to be overwritten ,which will display the command when help is hit on the telnet console.

import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.eclipse.osgi.framework.console.CommandProvider;

public class CustomCommands implements CommandProvider {
@Override
public String getHelp() {
return "***********CUSTOM COMMANDS*******************\n";
}

public void _testcommand(CommandInterpreter ci) {
ci.println("arg 1" + ci.nextArgument());
ci.println("arg 2" + ci.nextArgument());
}
}


Next step is to write a BundleActivator and register the command Provider service.

@Override
public void start(BundleContext ctx) throws Exception {
customCmd = new CustomCommands();
//created a instance of the implementation of our custom commands
ctx.registerService(CommandProvider.class.getName(),customCmd, null);

}

Dont forget to add the bundle activator class to the manifest. Manifest should include the following.

Import-Package: org.eclipse.osgi.framework.console;version="[1.0.0,1.0.0]",
org.osgi.framework;version="[1.4.0,1.4.0]"
Bundle-Activator: com.command.extender.CommandBundleActivator

JMX using Spring

JMX aims to create standard API's for managing and monitoring java applications.

Managing - changing values at runtime.

Monitoring - Reporting certain conditions.

Mbean -is a java bean with a management interface.

Mbean can expose attributes(through getters and setters) or any opertaions.Management interface can be defined statically or at runtime through interfaces.MBean Server acts as a broker between interacting beans or beans and remote clients.

Mbean server maintains a key to all registered means which is called as object name.The default protocol used is RMI , but can be changed to SOAP or Hessian.

Using raw JMX APi's is difficult , spring simplifies this.

Use the following configuration to create a MBeanServer. This will be required normally only if we are running standalone code.Else most of the containers like tomcat or spring dm provide the default MBeanServer which can be used to register the Mbeans.

<bean id="MBeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
<property name="locateExistingServerIfPosssible" value="true">
</bean>

Configuration to register a bean as MBean to MBeanServer.

<bean id="jmsSample" class="com.pg.MonitorService"></bean>

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

By this all methods and attributes of this can be accesed using jconsole. Sometimes this may not be what we want .we would want to control the set of operations which are visible through JMX.

The Spring MbeanExporter allows the following stratergies

1. ObjectnamingStratergy - this will help in identifying the mbean in the jconsole.

• a. KeyNamingStratergy(Default) - key passed will become the name
• b. IdentityNamingStratergy -generates a object name dynamically
• c. MetaDataNamingStratergy - reads object name from source level meta-data (annotations)

2. MBeanInfoAssembler

When we want to control what we are exposing through JMX this is the better approach

• SimpleReflectiveMbeanInfoAssembler -Default -Exposes all public methods and properties
• MethodNameBasedMbeanInfoAssembler Methods can be configured through spring xmls which will be exposed through JMX.
• MetadataMBeanInfoAssembler what needs to be exposed is controlled using source level annotations.
• InterfaceBasedMBeanInfoAssembler

a. Using managed Interfaces property

<bean class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<util:map>
<entry key="service:name=jmsSample" value-ref="jmsSample" />
</util:map>
</property>
<property name="assembler">
<bean
class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
<property name="managedInterfaces">
<value>com.pg.IService</value>
</property>
</bean>
</property>

</bean>

Here the jmsSample bean need not implement teh managedInterface.

b Using interfaceMapping property

<bean class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<util:map>
<entry key="service:name=jmsSample" value-ref="jmsSample" />
</util:map>
</property>
<property name="assembler">
<bean
class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
<property name="interfaceMappings">
<util:map>
<entry key="service:name=jmsSampleService" value="com.pg.IService"></entry>
</util:map>
</property>

</property>

</bean>

Thea bean jmsSample must implement the interface mentioned in interfaceMapping property

This API helps in monitoring application using JMX.

http://jamonapi.sourceforge.net/

Spring Training -Day 6

http://www.infoq.com/presentations/colyer-keynote-springone2gx

Telnet console 2401 – ssh shell -2402 in DM2 .

2.0 release will have both osgi console and dm shell (osgi console will be disabled by default)

Dm Kernel – lightweight – no web profile.

No plans to support EJB

Bundles in usr directory is not exposing service because – not in active state – need to get some code to move it to active state.

Bundles in pick up move to active state by default.

Import – org.osgi.framework – will not work , as jar is in lib directory .Work Around is to copy paste it into repository/bundles/usr.

Spring dm automatically creates a property for service by name – bean name.

Also application context itself is exposed as service – can be verified with osgi console

Logback – for logging in dm 2.0

http://logback.qos.ch/

In JVM failure - can be achieved using ranking attribute

Load time weaving – more complex when many bundles are there , so hardcoded in DM server - just below boot Classloader (this is not possible with aspectj being a bundle)

Require Bundle(used for Split packages)

Require bundle – all exported packages are imported

Deployment pipeline – Like wars and non osgi headers still works under spring DM because –this is processed by DM server to convert it into osgi complaint bundle - End result is visible in work directory

When Dm server starts all bundles are not seen in osgi console – They move to resolved state , only when required(looking to find required imports) they move to resolved state.

Osgi reference has bean name attribute which can be used as default filter.

Bundles have version , services have ranking – Service ranking is part of OSGi spec

Custom osgi commands – implement Command Provider – equinox specific

2.0 modules – has attribute - sticky for service.

Spring integration

Enterprise Integration Pattern –implementers are SI and Camel

http://www.ibm.com/developerworks/library/os-ecl-osgiconsole/index.html

Spring Training -Day 5

Create new platform (may be equinox 3.5) – eclipse may be using 3.4

Eclipse takes ini file – which when bundles added to a folder adds it to the file –Eclipse can do it easily.

Uses conflict may be ClassCastExceptions or Linkage Exceptions

http://blog.springsource.com/2008/11/22/diagnosing-osgi-uses-conflicts/

Uses is whatever the bundle is resolved to .(Ex If struts has import;log4j and in any Export blabla;uses log4j – no issues because it will resolves to log4j in applications classpath just forcing us to use the same log4j.. When uses is with version becomes very critical)

Ideally 3rd party guys should not be ideally using uses –unless they want to restrict , but still relaxed using import in struts lib without version – so whatever 3rd party resolves to in our lib.

Import without version no – resolves to latest.

Class loader performance may increase -steps reduced for loading from the conventional model.

Osgi command – packages - searches for the package in all bundles.

BundleContext- used to install/uninstall bundles, deal with events and services programmatically

When multiple services have same ranking – will be solved based on service id – least one – the first one registered.

Extender bundle

Spring extender bundle creates bundle context for bundles which are in ACTIVE state . May be this is the reason bundles in usr lib cannot exposes services.(because they don’t move to active state)

Application context for bundles are created asynchronously when DM server starts up. It can be changed to get a sync behaviour.

When synchronous, it does not spawn a new thread for creating context and waits until context is created.(If any bundle is picked up before by the extender that may run in a separate thread)

Appcontext fails – it uninstalls the bundle – hence cannot verify errors from osgi console.

Service mandatory wait is asynchronous.

Extender Bundle – is like SpringContextLoadListener in web Apps

Extender bundles creates appContext for all bundles which are in ACTIVE state.

Accessing BundleContext – implements BundleContextAware

Either put appcontext file in META-INF / spring or use Spring-Context header in manifest file.

Mandatory Service

Timeout

Cardinality - 1:1 ,0:1, 0:n,1:n – renamed as availability attribute in Dm 2.0

osgi: set and osgi:list

Consumers can listen to bind-unbind events

Publishers can register to register and unregister events.

RFC 124 – Moving towards component and service than spring specific osgi:service and bean .

Spring Training - Day 4

Spring Security

http://blog.springsource.com/2009/01/02/spring-security-customization-part-1-customizing-userdetails-or-extending-grantedauthority/

http://blog.springsource.com/2009/01/02/spring-security-customization-part-2-adjusting-secured-session-in-real-time/

Principal –User,Device or system that performs action

Authentication –Establishing principals credentials are proper.(LDAP ,Database etc)

Authorization –Deciding if a principal is allowed to perform an action.

Secured Item – resource being secured.

Spring security is Portable across containers.

Secure item – method , web page(url) or flow(web flow)

Voters – 2 default- role based and authenticate based

3 types of AccessDecision manager (judges)

1. AffirmativeBased (anyone says yes –it’s a yes) -Default

2. Unanimous based – very conservative – one voter says no – it’s a no

3. Consensus based – based on majority says yes – majority is configurable – all these are configurable



Configuration in Web Application

<security:http> - configures default accessmgr, default filters, voters, security interceptor etc

Configures a servlet filter in web.xml

<security intercept-url pattern=”…” filters=”” acess=””/> can be configured

Spring security Taglibs since spring 2.0

Method Security(based on AOP)

Xml based - point cuts in xml with access role

Configuration based – have to register to get this enabled. , also has JSR specific annotations

Bad to put security constraints inside class – use xml approach over annotations – security is infrastructure

Advanced Security In web –

HttpSessionContextIntegrationFilter – stores context in session - if exists gets it and binds to thread local –way back binds it to session

LogoutFilter –clears security context on logoff

AuthenticationProcessingFilter - If not authenticated then send to login page

ExceptionTranslationFilter – converts exception into http responses and redirects

FilterSecurityInterceptor - authorises web requests based on url patterns

Any of these can be replaced and any can be added in the required order.

So filters for all these purposes are already placed.

Security context can be obtained anywhere in the code using – spring class SecurityContext.getCtx();

Obfuscating – is just setting bean – to avoid knowing technology




Spring Remoting

Consistency across all protocols and flipping from one protocol to another is simple.

Supported Protocols

RMI
HttpInvoker – is a protocol –over http
EJB
Hessian/Burlap(for sending XML over HTTP –Less predictable with complex types)

Hessian –uses binary xml
Burlap –uses textual xml

Spring on Server & Client –Use Http Invoker
Java Env but no Web Server –Use RMI
Interop with other languages Using HTTP – Hessian

Spring JMS

Message,Destination,Connection,Session,MessageProducer,MesageConsumer

Spring JMSTemplate

DynamicDestinationResolver

JMSTemplate – takes connectionFactory,MessageConvertor,DestinationResolver,

Spring JMX

MBean is a standard java bean with an additional management interface – attributes (with getters and setters) and Operations

Rmi is default protocol – can be changed

JVM runs a default MBean server , we can also override this by one given from spring

<context mbean –export>

Default –export everything – mostly a bundle will have only mbeans exposed

Export bean as MBean.

Strategies –

objectNamingStratergy- keyNamingStratergy(Default) , IdetitynamingStratergy(naming by objected from JVM),MetaDataNamingStratergy (annotations) – not recommended

One strategy can be overriden by the other.

MBeanInfoAssembler- by implementations of the MBeanInfoAssembler interface

To run with JMX add -Dcom.sun.management.jmxremote as VM param


OSGI

Single Version mean atleast that version

Resolves to the greatest -

Running in eclipse

Added vm param for clean

In manifest given space for the next line – because its reserved for headers

Import package , not mentioned – binds to the latest

Resolved phase- doesn’t mean classes are loaded

When classloader gets GC’ed - when objects are Gc'ed and all bundles importing from this bundle are refreshed(osgi refresh command)


Using Eclipse to simulate Equinox

Run configurations - > OSGi Configurations – new - Uncheck target platform - In filter search org.eclipse.osgi(any version ) – select it – apply – run

ss will show only equinox bundle.

Change run config as - -Dosgi.clean=true

Create new project – plugin – new plugin project - select run environment as equinox

Can run this new project under equinox with the created run configurations – Run as ...

Spring Training -Day 3

Transaction Management

ACID-Atomic,Consistent,Isolated,Durable

Only way to handle transaction is hold on to the same connection –only way of doing it.

JTA – not good , scalability becomes difficult .

Ex: EBay – develop undo behaviour –compensatory action – 3rd part its the only option- for every method need a undo method.

Can use any datasource – no need to tieing it to spring jdbc datasource

Lots of transaction management – datatSourceTransactionMgr,HibernateTransactionMgr,Jps…,Jta..

Connection pool – use apache DBCP or c3p0

<tx:annotation driven> - registering for annotations

<bean id=”transactionManager” class=”…:> … datasource as property </>

transactionManager – should be the name – else have to explicitly mention in the <tx:annotation ……transaction manger=””.>

@Transactional at class level – all public method(because proxy sees only public method) will be transactional

Can have timeout – default is 60 secs

Datasource , transaction – better use xmls – infrastructure components (Aspects annotation are better)

Xml based approach - define transaction mgr, then define transaction interceptor- <tx:advice… > define pointcut

Tx:advice – is just used for overiding , not required

Xml approach advantage - can take these point cut definition from property files.

Set isolation levels – else though not committed , one thread can see the other

For recursive methods with @transaction – the same transaction context will be used.

Transaction Propagation – Propagation.REQUIRES_New – new one transaction context will be created per transaction.

So for iterative ones – if inner @Transaction is marked for required_new ,inner one will be committed irrespective of the other.

Can avoid rollback –with noRollBack option

Annotations
---------------

@Autowired –field level ,method level and constructor level

<context:annotation-config/>

@Autowired default by Type .-for all auto wired injections including and filed injections.

@Autowired
Test x; though x is name of any bean it will look for type Test.

@Autowired for field injection – Doesnt require setters.

Multiple types or no types will give error.

@Autowired not only for setter – for any method,field,constructor

Autowired for collections – List<Types> - all these types will be autowired into the list.

@Autowired(required=false) – does not fail when no type is found

@Qualifier – filtering when injecting by type – properties have to be mentioned in the bean
[default is name – when no name for bean is mentioned it is taken as id- That is why we say ctx.getBeanByName() and still use id it works]

@Resource –JSR 250 – injection by name – equivalent to ref in xml – not specific to Spring its in JSR 250

@Resource – also for JNDI references

@Component - alternative for writing bean definition in xml can be use with @Scope

@Component can also have bean name-else classname will be taken as bean name with first letter as small letter

<context:component scope> is required to identify components. – no need for annotation config as this is a superset of it.

<context:component scope> - can have filters – includes , excludes etc – without this Component will not work

Component scanner is above annotation processor. – so need to register annotation processor when using component scanner.

@value annotation will work with spring 3.0 – no support in spring 2.5

Both xml and annotation beans - if they have same name xml will override annotations , if the bean names are different 2 instances will be created.

Testing
-----------

Junit 4 – has annotations

Test runner - @Runwith (SpringJunit4ClassRunner.class)

@ContextConfiguration - with location of appContext.xml

Follow naming convention to avoid giving location - <testcasename>-context.xml

In case we need access to applicationCtx beans write private field and write @Autowired over it.

Name of bean if annotated with @Component –same as class name with first letter as small letter

With map it will put key as bean name when autowired.

@autowire with qualifier is very useful

Stubs and Mocks are different

Mock libraries - EasyMock,Jmock ,Mokito

Mockito: http://mockito.org/

Example with mockito – works by proxy- how to ensure method is called n number of times

During db tests – data inserted is automatically deleted , default can override if required.

SpringWeb
------------------

Web Layer should be very thin layer speaking to the backend service layer.

Spring Web Flow - Same url will be used , server maintains a state based on which flow will continue.

ContextLoadListener in web.xml - Root ApplicatonContext

WebApplicationContextLoader - register in servletContext – For WebApplicationContext

Using DispatcherServlet

2 contexts , RootApplicationContext and WebApplicationContext.

Web (DispatcherServlet) context can rootContext but not the other way round.

Spring MVC – annotation suited

WebApplicationContextUtils – static helper for accessing spring beans in web context.

Processing Flow -> Request -> Dispatcher Servlet -> Handler (Controller) -> Result View(send to DispatcherServlet) -> View

@Controller- equivalent to struts actions classes but can have multiple mapping for different url’s per method inside it.

@RequestMapping -for mapng urls

@RequestParam – mapping fields from HttpRequest.

Controller returns View name – default is path to jsp page

If controller returns null – then default view based on request url.

DispatcherServlet delegates to viewResolver to map returned view names to view implementations.

Default View resolver treats view name as Web –App relative path.

View Resolver – can take prefix and suffix as params.

If returned as string from handler – its taken as a view name

Spring Training -Day 2

Bean name will be generated by bean id. Context.getBean(name) hence works by id.

Writing custom annotation – write custom annotation and register pre-processor to add custom logic to it.

BeanPostProcessor- deals with objects – postInit & preInit

Interceptor- aspect with single advice[will be called when bean is created]

isSingleton method inside factory will be called only once if isSingletonMethod() set to true –Doesn’t make sense if factory itself is prototype

Inheritance – bean can be marked as

abstract=true - instance wont be created

Parent – parent=”” – for overriding

PropertyEditors- how properties are converted in xmls which always are mentioned as string ex – toDate,Integer etc –Spring has many of its own

We can register our own propertyeditors - For any type –call our propertyEditor – this is not like set of interceptors instead editor is picked from a map.

Following conventions - put customEditor in same package as code , and name should be <type>+Editor - no need to explicitly register the editor.

Import configuration file - <import resource=”ddsdsd.xml” />

P namespace – allows properties to be set as attributes in bean definition.

Util namespace – loading properties – diff from propertyplaceholder – util :properties , set,list,Map,reading constants

AOP
------

2 technologies

Spring Aop – Runtime –Using Dynamic Proxy

AspectJ- Compile Time OR Load Time –byte code injection

Performance – aspectj build time is best but complex.

For AspectJ : http://www.infoq.com/articles/Orchestration-Oleg-Zhurakousky;jsessionid=E64F684641DCF76CEC10633EFF108059

Spring Aop – uses (hides this complexity)

a. uses JDK dynamic proxy when interface is mentioned

Ref: http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html

Method invocations on an instance of a dynamic proxy class are dispatched to a single method in the instance's invocation handler, and they are encoded with a java.lang.reflect.Method object identifying the method that was invoked and an array of type Object containing the arguments.

b. uses CGlib when no interface is mentioned

CGLIb can be forced in both cases using Proxy-target-class=false in definition.

Creating proxy using APIs - org.springframework.aop.framework.ProxyFactory;

Can add advice to the proxy – which recognizes either annotations or anything else

Adding aspectj weaving adds a context weaving classloader

Hierarchy --- BootClassLoader,Aop Context weaving Classloader,Extension loader,Application loader

The above happens for only Aspectj Based viewing

Hence all classes other than in boot path can be intercepted.

Delegation Of Classloader – first goes to parent if class def is not found and then comes down

When using jdk dynamic proxy –cast to interfaces

CGlib works by extending the class definition and then creating instance of that , old object is GC’ed.

Hence with final classes it throws error

Constructor gets called twice.- because extended.

Internal methods don’t get called.

JdkDynamic uses the same instance

JointPoint- execution context

PointCut - Expression

Advice-method

Aspect- class

Advice -@Before,@Afterreturning,@AfterThrowing,@After,@Around

Spring JDBC
---------------

No checked exception – all run time exceptions –rarely Db exceptions are recoverable

Callback pattern – give ur reference to some to call u at right times

Does from Getting connections, Participating in Transaction, Execution of statement, Processing ResultSet, Handling Exceptions, Closing connection.

Need to provide a datasource along with transactionManager. – Datasource manages the connection pooling

We can use Apache DBCP or C3po for pooling.

JdBCTemplate methos like queryForMap,queryForList

RowMapper – Each Row maps to a Doman Object
RowCallBackHandler – No return value
ResultSetExtractor - Multiple rows map to a single object.

Spring handles all exceptions irrespective of the vendor. It keeps a internal mapping of all error codes specific to the vendor, and gives very descriptive errors.

Spring Training -Day 1

Trainer : Oleg.zhurakousky@springsource.com

Spring deals with plumbing so that we can focus on domain problem.

We analyse what part Is business logic & what’s rest ?

Creation pattern - Strategy Pattern – Dependency Injection – Interface based.

Conventions over configuration – ex maven etc

Annotations – when dependency is mostly static , and also confusion can be solved using conventions.

Generic at compile time Vs runtime – This may be to support old Java runtimes

Implement FactoryBean – the getObject() – will give result whenever the bean is injected.

How to get factory itself - &<beanname> in property field.

FilePathXmlContex(“classpath:dhgadhs.xml”,c:/sdsd/sdsd/asds.xml); - classpath will ensure its searched in classpath for the first xml

Bean Life Cycle

BeanFactoryPostProcessor – just after dependency tree is constructed but before objects are created.Can change definition of any bean here.

One usecase would be propertyplaceholderconfigurer – to replace values with exact properties from file.

once configurer like placeholder is register it will be replaced with property files. - <context:property placeholder/>

<context:annotation-config/> - needs to be registered for annotations.

@Required - throws error if property is not set

Enforcing init method – by implementing initializingBean

Proxy – Decorator pattern

<bean class=”Org.springframework.beasn.factory.config.PropertyPlaceholderConfigurer” >

<property name=”location” value”…”/>

</bean>

With namespace – no need to remember the class

<context:property-placeholder location=””/>

Giving class as part of application context – helps identify where the xml is located

Bean Initilization (3 ways)

@PostConstruct ,init-method,implement interface initializingBean

Bean Post processor example - @Required – have to add contextannotation config

Destroying the application Context

ConfigurableApplicationContext.close()

Bean Destruction(3 ways)

@PreDestory,destroy-method,implement interface DisposableBean

Scopes – request and session makes sense only when they are in a web continer.

Issues with loading Native libraries in OSGi Bundles

The Java virtual machine (JVM) allows only one class loader to load a particular native library.
(which means two bundle cannot load same native library)

There is no application programming interface (API) to unload a native library from a class loader.

Native libraries are unloaded by the JVM when the class loader that found the library is collected from the heap during garbage collection.

If a shared library that is configured with a native library path is associated with an application, whenever the application is restarted or dynamically reloaded the application might fail with an UnsatisfiedLinkError indicating that the library is already loaded. The error occurs because, when the application restarts, it invokes the shared library class to reload the native library. The native library, however, is still loaded in memory because the application class loader which previously loaded the native library has not yet been garbage collected.

A native library is unloaded only when the class loader that loaded it has been garbage collected. When a bundle is uninstalled or updated, any native libraries loaded by the
bundle remain in memory until the bundle's class loader is garbage collected. The garbage collection will not happen until all references to objects in the bundle have been garbage collected, and all bundles importing packages from the updated or uninstalled bundle are refreshed. This implies that native libraries loaded from the system class loader always remain in memory because the system class loader is never garbage collected

Spring forum : http://forum.springsource.org/showthread.php?t=80063

Solution – load this library in a bundle which won’t be refreshed or set a flag which shoudl be checked when reloading any bundle.

The option of changing native code name may result in memory leaks, because multiple native code accumulate in the process space.

Only the JVM class loader can load a dependent native library.

For example, if NativeLib1 is dependent on NativeLib2, then NativeLib2 must be visible to the JVM class loader. The path containing NativeLib2 must be specified on Java library path defined by the LIBPATH environment variable.

If a native library configured in a shared library is dependent on other native libraries, the dependent libraries must be configured on the LIBPATH of the JVM hosting the application server in order for that library to load successfully.

Ref: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tcws_sharedlib_nativelib.html

Garbage Collection - Log Analysis

25646.328 :[GC 325407K->83000K(776768K), 0.2300771 secs]
25646.328 : [GC 325816K->83372K(776768K), 0.2454258 secs]
25646.328 : [Full GC 267628K->83769K(776768K), 1.8479984 secs]


25646.328 –time since JVM started

325407K->83000K :combined size of live objects before and after garbage collection
After minor collections the count includes objects that aren't necessarily alive but can't be reclaimed, either because they are directly alive, or because they are within or referenced from the tenured generation.

(776768K) -> is the total available space, not counting the space in the permanent generation, which is the total heap minus one of the survivor spaces

0.2300771 secs –time taken

Here we see two minor collections and one major one.

Good Link:http://java.ociweb.com/mark/other-presentations/JavaGC.pdf


Sample GC logs:
25646.328: [GC [PSYoungGen: 53934K->1783K(55744K)] 139043K->86893K(521792K), 0.0091130 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
25650.658: [GC [PSYoungGen: 55735K->2232K(54208K)] 140845K->91675K(520256K), 0.0140890 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
[2009-11-03 10:02:23.092] fs-watcher Processing 'DELETED' event for file 'xxx.jar'. ? Application Undeployed
[2009-11-03 10:02:24.495] fs-watcher Undeployment of ‘xxx' version '0' completed.
[2009-11-03 10:02:48.592] fs-watcher Processing 'CREATED' event for file 'xxx.jar'.
[2009-11-03 10:02:52.915] fs-watcher Deployment of 'xxx' version '0' completed.
25705.888: [Full GC (System) [PSYoungGen: 416K->0K(53632K)] [PSOldGen: 122447K->122819K(466048K)] 122863K->122819K(519680K) [PSPermGen: 56927K->56927K(58496K)], 0.4994360 secs] [Times: user=0.50 sys=0.00, real=0.49 secs]
Total time for which application threads were stopped: 0.5127720 seconds

Approx 2.20 mins later after the redeployment the memory in OldGen starts piling up

33705.323: [Full GC (System) [PSYoungGen: 3584K->0K(51328K)]
[PSOldGen: 162686K->166028K(466048K)]
166270K->166028K(517376K)
[PSPermGen: 61486K->61486K(61824K)], 0.6978710 secs]
[Times: user=0.70 sys=0.00, real=0.70 secs]

33766.045: [Full GC (System)[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor305]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor306]
[PSYoungGen: 3424K->0K(51456K)] [PSOldGen: 175451K->178649K(466048K)] 178875K->178649K(517504K) [PSPermGen: 61487K->61487K(61824K)], 0.7389690 secs] [Times: user=0.73 sys=0.01, real=0.74 secs]
36459.779: [Full GC [PSYoungGen: 41152K->0K(57664K)] [PSOldGen: 554317K->557726K(699072K)] 595469K->557726K(756736K) [PSPermGen: 61442K->61442K(61824K)], 1.6296560 secs] [Times: user=1.62 sys=0.00, real=1.63 secs]
Total time for which application threads were stopped: 1.6310400 seconds
Total time for which application threads were stopped: 0.0011620 seconds

After approx 3hrs 40mins after the redeployment, application starts doing Full GC every 2 secs virtually unable to collect anything. The GC pause times are 2secs. So application is not
running at this point.

38208.203: [Full GC [PSYoungGen: 42047K->40198K(53952K)]
[PSOldGen: 699068K->699068K(699072K)]
741115K->739266K(753024K)
[PSPermGen: 61376K->61376K(61568K)], 2.1202220 secs]

[Times: user=2.16 sys=0.00, real=2.13 secs]
Total time for which application threads were stopped: 2.1220930 seconds
38210.406: [Full GC [PSYoungGen: 42048K->38287K(53952K)] [PSOldGen: 699068K->699072K(699072K)] 741116K->737359K(753024K) [PSPermGen: 61376K->61369K(61568K)], 2.2874650 secs] [Times: user=2.28 sys=0.00, real=2.28 secs]
Total time for which application threads were stopped: 2.2889430 seconds
38213.678: [Full GC [PSYoungGen: 42043K->40523K(53952K)] [PSOldGen: 699072K->699072K(699072K)] 741115K->739595K(753024K) [PSPermGen: 61369K->61369K(61568K)], 2.1083830 secs] [Times: user=2.11 sys=0.01, real=2.11 secs]
756 MB -Xmx

Ref :http://java.sun.com/docs/hotspot/gc1.4.2/

Each blue box represents a collector that is used to collect a generation. The young generation is collected by the blue boxes in the yellow region and the tenured generation is collected by the blue boxes in the gray region.

"Serial" is a stop-the-world, copying collector which uses a single GC thread.

"ParNew" is a stop-the-world, copying collector which uses multiple GC threads. It differs from "Parallel Scavenge" in that it has enhancements that make it usable with CMS. For example, "ParNew" does the synchronization needed so that it can run during the concurrent phases of CMS.

"Parallel Scavenge" is a stop-the-world, copying collector which uses multiple GC threads.

"Serial Old" is a stop-the-world, mark-sweep-compact collector that uses a single GC thread.

"CMS" is a mostly concurrent, low-pause collector.

"Parallel Old" is a compacting collector that uses multiple GC threads.

Using the -XX flags for our collectors for jdk6,

UseSerialGC is "Serial" + "Serial Old"

UseParNewGC is "ParNew" + "Serial Old"

UseConcMarkSweepGC is "ParNew" + "CMS" + "Serial Old". "CMS" is used most of the time to collect the tenured generation. "Serial Old" is used when a concurrent mode failure occurs.

UseParallelGC is "Parallel Scavenge" + "Serial Old"

UseParallelOldGC is "Parallel Scavenge" + "Parallel Old"

Ref : http://blogs.sun.com/jonthecollector/entry/our_collectors



These 2 references clears most of teh doubts pertaining to jvm internals and gc tuning.

http://blogs.sun.com/jonthecollector/entry/our_collectors

http://www.nbl.fi/~nbl97/java/tuning/jvm_internals.pdf

Service Monitoring - OSGI

There are 2 approaches for doing this.


1. Class implementing Service Listener gets all service lifecycle Events .

public class PGServiceListener implements ServiceListener, BundleActivator {
……..

@Override
public void start(BundleContext cntxt) throws Exception {
cntxt.addServiceListener(this);

}

@Override
public void stop(BundleContext cntxt) throws Exception {
// TODO Auto-generated method stub

}

public void serviceChanged(ServiceEvent event) {
-à this is called for every service life cycle event
}


}

Here this class will be mentioned in the manifest file as a bundle Activator

2. Listening to the market Interface . Assuming that all the services implement a interface IService we can have the following listener which get all service related events.

<osgi:list id="listService"

interface="com.partygaming.service.monitor.external.IService"

cardinality="0..N">

<osgi:listener ref="serviceListener1" bind-method="bindService"

unbind-method="unBindService"></osgi:listener>

</osgi:list>



Looks like the second approach is better, as we get only 2 events, service register and unregister which we are interested in .It also gives all the properties of the service which will help us maintain other info like version.

Distibuted OSGi

DOSGi helps in interaction between services which exists in different services in the same way as when they are co-hosted.

Specifications for DOSGi: http://www.osgi.org/Specifications/HomePage

Well Known implementations are

Apache CXF implementation : http://cxf.apache.org/distributed-osgi.html

Eclipse ECF implementation : http://wiki.eclipse.org/Distributed_OSGi_Services_with_ECF

Apache Tuscany implementation


Apache CXF implementation
-------------------------

http://cxf.apache.org/roadmap.html : Nothing more other than web services even in roadmap.

DOSGi Webinar : http://download.progress.com/open/adobe/prc/psc/042809_fuse_osgi_webinar/index.htm

Some answers to the questions on the webinar

http://coderthoughts.blogspot.com/2009/05/questions-from-rfc-119-webinar.html

Exposing service -has to mention the interace which can be remotely invoked.

Based on this Apache CXF creates a wsdl - which can be called by any web service client

(RFC 119) complaint discovery service - http://cxf.apache.org/dosgi-discovery.html
---------------------------------------
If discovery service is present - it will aurmtically detect , else we need to statically configure end points.

To enable automatic hooking of these remote services we need to have Service Registry Hooks -OSGi 4.2 spec(RFC 126)

Service Registry Hook Functionality(RFC 126 -OSGi spec 4.2) -Should be part of OSgi Core

Service Hook Functionalities
----------------------------

1. On Demand Registration of remote Services

2. Limiting Service Visibility

3. Service Proxification




How does it work [Refer Attached Diagram]
-----------------
Interface bundles are present in both the interacting containers.

Both teh containers have RFC 119 complaint discovery service and RFC 126 complaint registry hook

Service implementer registers with teh service with local OSGi container.

If this service has to be remotely accessed it needs to mention the property of remote interface.

Once this interface is mentioned the Discovery Service comes into picture which creates a remote end point for the service

It also register some meta data info with teh discovery service.

On the client side(in another Vm) when it expresses its interest in consuming this service , this information is passed
from the local osgi registry into the Registry hook which consults the discover service.

Now the discovery service will see if any one has remotely registered and if so creates a proxy for this service which will be reffered by the local osgi registry.

Current Apache CXF doesnt have either discovery service nor registry hook , hence end points need to be statically mentioned.

Apache is working on a discovery service under withthe ZooKepper Project

http://hadoop.apache.org/zookeeper/

http://wiki.apache.org/hadoop/ZooKeeper/ProjectDescription


[I think ZooKeeper is an alternative to Jgroups for sharing registry information between two nodes]

Working Demo is present in the link I have mentioned above, but without discovery service or service registry hook and it has a web service based implementaion for communication.

So to use Apache CXF we need minimum of these version - Equinox 3.5 / Felix 1.4.1 or later

Dmversion of equinox currntly- Dm 1.0.2 uses equinox 3 and 2.0 version uses equinox 3.5

Eclipse ECF implementation
----------------------------

http://wiki.eclipse.org/Distributed_OSGi_Services_with_ECF

http://eclipsesource.com/blogs/2008/12/19/rfc-119-and-ecf-part-1/

http://wiki.eclipse.org/Getting_Started_with_ECF%27s_RFC119_Implementation

Here changing the protocol for communication between services in diffrent VM's looks very simple

They claim to support the following protocols

Distribution

* r-OSGi (http) -r-OSGi is based upon a TCP-based protocols
* XMPP
* ECF Generic
* Skype
* Java Messaging Service (JMS)
* JavaGroups

Dynamic registring of the Spring Bean to the Application Context

I have come across use cases where we need to dynamicaly create a bean and register it to the Application Context rather than creating it through xmls during initialization.

This api doc helps to do that

http://static.springsource.org/spring/docs/2.5.6/api/org/springframework/context/support/StaticApplicationContext.html#registerSingleton%28java.lang.String,%20java.lang.Class%29

Usecase Ref:

http://forum.springsource.org/showthread.php?t=76490

Useful Blog

http://www.carlobonamico.com/blog/2008/01/22/how-to-dynamicallyprogrammatically-define-spring-beans/

Spring Integration Router Configuration

Just came across a router config in which based on the header it will route the messages to respective channels-provided both header and channel

l have same names .(No static definition required in application xmls)


1. Configuration where mapping of header values to channels is required

<header-value-router input-channel="routingChannel" header-name="testHeader">

<mapping value="someHeaderValue" channel="channelA" />

<mapping value="someOtherHeaderValue" channel="channelB" />

</header-value-router>


2. Configuration where mapping of header values is not required if header values themselves represent the channel names

<header-value-router input-channel="routingChannel" header-name="testHeader"/>

Ways to get Spring ApplicationContext -In Spring DM

Couple of other ways to get hold of ApplicationContext (rather than doing new ClasspathXmlApplicationContext()).

1. Create a bean which is ApplicationContextAware


MessageChannel msgCh = (MessageChannel)ApplicationContextHolder.getApplicationContext().getBean("eventChannel");

msgCh.send(msg);


public class ApplicationContextHolder implements ApplicationContextAware {

private static ApplicationContext appContext;

public void setApplicationContext(ApplicationContext ctx)

throws BeansException {

System.out.println("*** ApplicationContextHolder::setApplicationContext()...");

ApplicationContextHolder.appContext = ctx;

}

public static ApplicationContext getApplicationContext() {

return appContext;

}

}


This one is in the case of Spring DM

2. Accessing the ApplicationContext from BundleContext (By default every bundle publishes the Application Context as a Service).



public static ApplicationContext getApplicationContext() {

if (appCtx == null) {

try {

ServiceReference[] svcRef = bundleContext.getAllServiceReferences("org.springframework.context.ApplicationContext", "(org.springframework.context.service.name=ContextInClass)"); // Service name is the Bundle Symbolic Name

ServiceReference ref = svcRef[0];

appCtx = (ApplicationContext) bundleContext.getService(ref);

} catch (Exception e) {

e.printStackTrace();

}

}

return appCtx;

}

This is the preferred approach if you wish to use the Application Context from another bundle.

Java Monitoring Guidelines

Use the following command which gives the process size.

ps auxwww | grep java

Process size - Max size is 3 Gb on unix and 4 gb on solaris

[process size includes stacks,native code,therads created etc]

user 6451 180 30.2 [1416444-->process_size] 626888 ?

A check on the process size is critical because when there are leaks this gradually increases and finally the server crashes.

Command to get the Memory Details

jmap -dump:live,format=b,file=histo.bin . this creates a file with name histo.bin

Command to generate Report Using JHat

jhat -J-mx256m histo.bin [histo.bin can be pscp'ed to windows machine and this command can be executed]

This starts a server gives a port number at the command line. using this url the details can be viewed through a explorer

Consequently the following command can be used to get the current memory picture in the JVM.

jmap -histo:live [process-id] > [filename].txt

The following command is also useful to understand the java heap and the GC behavior

jstat -gcutil 2361 1s

UseFull Vm parametres

-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-verbose:gc
-XX:ErrorFile=/location/error.log
-XX:HeapDumpPath=/location/heap_dump.hprof

jstack [process_id] or kill -3 [process_id] can be used to get the thread dump of the process.

Thread Context ClassLoader / Buddy ClassLoading in OSGi.

Bundles like Struts,hibernate,Spring need to instantiate classes in custom application bundle.In normal cases this can be directly done because there is a single class space(single class loader).

Consider a case where there are more than one class loaders .Lets take a simple case in which the struts/spring jar is kept under tomcat common lib and your application classes are under the web-inf lib. These two are jars now are loaded by two different classloaders.
Tomcat common lib class loader being the parent of tomcat web-inf/lib class loader.Also classloader of struts jar cannot see application classes in web-inf lib.

Now how can struts/spring see application classes ?

To solve such problems java Java came up with a solution called Thread Context Class Loader(TCCL). Thread context class loader was introduced in Java 2 to enable frameworks running in application servers to access the "right" application class loader for loading application classes.

This is accessed using Thread.getCurentThread.getContextClassloader().Its as simple as, It is the classloader associated with each thread.There are setter methods which can be called to set this TCCL.

By the definition in tomcat the TCCL is set to the context class loader from where the thread begins.So TCCL has the classloader visibity of web-inf lib,solving our problem.

Now since the thread started from that application ,these third party jars can use TCCL to instantiate application classes. The control starts from our application bundle and then flow moves to some third party bundle like struts or hibernate,which internally in their
source code use TCCL to instantiate our classes.

TCCL becomes slightly more complicated in the case of OSGI.

I have a small POC for the Reflection based Class loading using TCCL.

Source Code : http://www.4shared.com/file/123739699/3b6dd30e/TCCLosgi.html

Bundle 3(Core bundle) – has reflection code to instantiate application classes. Uses TCCL to instantiate classes.

Bundle 2 (Service) –Using the core bundle to instantiate its classes (imports bundle 3 classes directly)

Bundle 1 (Application) – uses the OSGi service provided by bundle 2.


Control Flow:

Bundle 1 makes a OSGi service call to bundle 2.

Bundle 2 now uses core to instantiate its(bundle 2) classes.

Result: ClassNotFoundException

Reason:

Bundle 2 is able to instantiate classes only in Bundle 3 and not in Bundle.

This is because TCCL has visibility only to class loader from where the thread started.

Solution:

1. PAR(Spring DM solution)

Spring Dm comes with a concept of PAR,which is grouping of bundles.All bundles inside the PAR will contribute together to form a synthetic context.And hence bundles inside it have visibility to all others exisiting inside it.

http://blog.springsource.com/2008/05/02/running-spring-applications-on-osgi-with-the-springsource-application-platform/

2.Buddy Class Loading (this is equinox specific solution and not part of OSGi spec)

http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Class_Loading


Now bundle 3, that is the core bundle can be a buddy to bundle 2 (service bundle).

Syntax

In bundle 3 manifest we need to mention Buddy-Policy :registered

In bundle 2 manifest we mention Eclipse-RegisterBuddy : bundle symbolic name


Now at run time we can add new slots(Bundle 4) which registers itself as a buddy to bundle 2(core) ,without affecting any other bundles.

3. We can set the TCCL in bundle 2 to bundle class loader when the deligation goes through it.I guess TCCL may not be the right approach(not good to tamper the class loader prior to making calls across bundles).

We can choose a solution based on the requirement.

Cyclic Dependency in OSGi & Dynamic Imports

Since in OSGi we have multiple class loaders as compared to single Class Loader case ,there may be occur the problem of cyclic dependency.

This cyclic dependency may not be compile type instead most of the cases its runtime. Some piece of code may try to instantiate classes in another bundle using reflection.

Consider such a example

Bundle A requires Bundle B at runtime and vice versa.

Bundle A has to mention import in its manifest for bundle B classes and Bundle B has to do the same for Bundle A classes.

Now in such case when Bundle A is deployed it says class not found for Bundle B classes,hence to solve this we need to write

Import Package : package-from-BundleB;resolution=optional

Now Bundle A doesn't give error . Follow with deployment of Bundle B. Later when bundle A tries to access classes in Bundle B it says ClassNotFoundException.

This is because when we mentioned resolution=optional , it doesn't try to link again when class is requested. And the linking happens only initial time.

To solve this we need to use Dynamic imports in such cases.

This cyclic dependency in most of the cases can be solved using Thread Context Class Loader or Eclipse Buddy Class Loading(refer next blog for details),and there will rarely occur a case to use dynamic imports.

Example:Spring Integration + Spring DM OSGi + Spring JMS(JBoss MQ)

I have come up with a sample for spring jms with spring integration.It shows how easy is it to configure adaptors for jms using spring integration.

Source Code Download:http://www.4shared.com/dir/18401908/5d14c8a6/springintosgijms.html

I basically have three bundles

Jms Exchange - where jms input/output channels and apapters are declared

Jms-Sender - bundle publishing message into the queue

Jms-Receiver - bundle receiving message from the queue

Jms Exchange
------------------

Publishing channel will put the message into this channel
<!-- channel for jms In message -->
<integration:channel id="jmsInChannel" />


Wrapping the channel using gateway , so that bundle publishing into teh channel is unaware of spring integration apis.

<!-- gateway which puts message into channel -->
<integration:gateway id="jmsSendProxy"
default-request-channel="jmsInChannel" service-interface="com.jms.exchange.IJmsEvent" />


Publishing the gateway as OSGi service for sender to put messages into the cahnnel.

<osgi:service id="jmsSendService" interface="com.jms.exchange.IJmsEvent" ref="jmsSendProxy"></osgi:service>



Jms outbound adaptor which picks the message from channel and puts it into the defined jms queue.

<!-- adapter which puts message from channel to jms queue -->
<jms:outbound-channel-adapter id="jmsin"
destination="sendDestination" channel="jmsInChannel" />


JNDI template required for jms communication on JBoss MQ

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop key="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory
</prop>
<prop key="java.naming.provider.url">jnp://10.1.64.232</prop>
<prop key="java.naming.factory.url.pkgs">org.jnp.interfaces:org.jboss.naming
</prop>
</props>
</property>
</bean>


Connection Factory definition

<bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate">
<ref bean="jndiTemplate" />
</property>
<property name="jndiName">
<value>java:ConnectionFactory</value>
</property>

</bean>


Queue details for sending message

<bean id="sendDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate">
<ref bean="jndiTemplate" />
</property>
<property name="jndiName">
<value>queue/RequestQueue</value>
</property>
</bean>



JMS message driven channel adaptor which picks the message as soon as it on the JMS queue and puts it into
the given channel.

<!-- adapter which pulls message from queue into channel -->
<jms:message-driven-channel-adapter
id="jmsout" destination="sendDestination" channel="jmsOutChannel" />


Channel defined for putting the message from queue to channel.

<!-- channel for jms Out message -->
<integration:channel id="jmsOutChannel" />


Publishing the channel as OSGi service for receiver to pick the mssage from channel.

<osgi:service id="jmsListenChannel" ref="jmsOutChannel"
interface="org.springframework.integration.channel.SubscribableChannel" />


Jms Sender
--------------


Osgi referece in to teh gateway for publishing the message into the channel.

<osgi:reference id="jmsSendProxy" interface="com.jms.exchange.IJmsEvent" ></osgi:reference>


JMS Sender using the gateway to put messages into the channel.

<!-- POJO calling gateway -->
<bean id="sender" class="com.jms.sender.Sender">
<property name="jmsSendProxy" ref="jmsSendProxy"></property>
</bean>


public class Sender extends TimerTask{

private IJmsEvent jmsSendProxy;

public void setJmsSendProxy(IJmsEvent jmsSendProxy) {
System.out.println("SETTER CALLED");
this.jmsSendProxy = jmsSendProxy;
}

@Override
public void run() {
System.out.println("TIMER TASK");
jmsSendProxy.send("TEST MESSAGE");

}
}


Spring Time Task which puts the message into the channel periodically.


<bean id="senderTask" class="org.springframework.scheduling.timer.ScheduledTimerTask">
<property name="period" value="10000" />
<property name="timerTask" ref="sender" />
</bean>

<bean id="timerFactory" class="org.springframework.scheduling.timer.TimerFactoryBean">
<property name="scheduledTimerTasks">
<list>
<ref bean="senderTask" />
</list>
</property>
</bean>






Jms receiver
-----------------

OSGi reference into the channel for listening the messages in the channel.

<osgi:reference id="jmsListenChannel"
interface="org.springframework.integration.channel.SubscribableChannel" />


Service Activator which has a calls a dummy method when a jms message is received.

<!-- service activator for listening to jms messages on channel -->
<integration:service-activator
input-channel="jmsListenChannel" ref="jmsreceiver" method="receive" />

<bean id="jmsreceiver" class="com.jms.receiver.Receiver">



public class Receiver {

public void receive(String arg)
{
System.out.println("Jms response recevived"+arg);
}

}