net.javaforge.blog

2. Next create an method interceptor, that will measure the method execution time using Spring's StopWatch class:

public class ProfilingMethodInterceptor implements MethodInterceptor { private static final Logger log = LoggerFactory.getLogger(ProfilingMethodInterceptor.class); @Override public Object invoke(MethodInvocation invocation) throws Throwable { final StopWatch stopWatch = new StopWatch(invocation.getMethod().toGenericString()); stopWatch.start("invocation.proceed()"); try { log.info("~~~~~~~~ START METHOD {} ~~~~~~~~", invocation.getMethod().toGenericString()); return invocation.proceed(); } finally { stopWatch.stop(); log.info(stopWatch.prettyPrint()); log.info("~~~~~~~~ END METHOD {} ~~~~~~~~", invocation.getMethod().toGenericString()); } } }

3. Now we need a PointcutAdvisor implementation, that will match only Spring beans and those methods, marked with the @ProfileExecution annotation:

@Component public class ProfilingAdvisor extends AbstractPointcutAdvisor { private static final long serialVersionUID = 1L; private final StaticMethodMatcherPointcut pointcut = new StaticMethodMatcherPointcut() { @Override public boolean matches(Method method, Class<?> targetClass) { return method.isAnnotationPresent(ProfileExecution.class); } }; @Autowired private ProfilingMethodInterceptor interceptor; @Override public Pointcut getPointcut() { return this.pointcut; } @Override public Advice getAdvice() { return this.interceptor; } }

3. Last but not least is a Spring's application context XML, that will activate the ProfilingMethodInterceptor on all beans, using our annotation (see DefaultAdvisorAutoProxyCreator bean definition):

<?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:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd"> <context:annotation-config/> <context:component-scan base-package="net.javaforge.blog"/> <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"> <property name="proxyTargetClass" value="true"/> </bean> </beans>

That's it.

Now, if we define some example Spring bean like this:

@Component public class Bean { private static final Logger log = LoggerFactory.getLogger(Bean.class); @ProfileExecution public void foo() { log.info("Executing method 'foo'."); } }

and call it's foo()-method, following will be outputed by the logger:

[INFO] ProfilingMethodInterceptor - ~~~~~~~~ START METHOD public void net.javaforge.blog.spring.Bean.foo() ~~~~~~~~ [INFO] Bean - Executing method 'foo'. [INFO] ProfilingMethodInterceptor - StopWatch 'public void net.javaforge.blog.spring.Bean.foo()': running time (millis) = 24 ----------------------------------------- ms % Task name ----------------------------------------- 00024 100% invocation.proceed() [INFO] ProfilingMethodInterceptor - ~~~~~~~~ END METHOD public void net.javaforge.blog.spring.Bean.foo() ~~~~~~~~

To start a new demo project we will use Maven's archetype:generate goal and create a new project skeleton:

mvn archetype:generate \ -DgroupId=net.javaforge.blog \ -DartifactId=sshd-daemon-demo \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DinteractiveMode=false

Now we will put all neccessary dependencies to the project's pom.xml:

<dependency> <groupId>org.apache.sshd</groupId> <artifactId>sshd-core</artifactId> <version>0.9.0</version> </dependency> <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.11</version> </dependency> <!-- not really necessary, just to simplify logging in this demo --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.6.6</version> </dependency>

We want our application shell to be secured by the username and password, thus we will implement SSHD's PasswordAuthenticator interface and accept in this demo all users, those password is equal to the username (surely in the real world application you have to use some user's datastore and only accept users that are allowed to connect your application via ssh).

public class InAppPasswordAuthenticator implements PasswordAuthenticator { @Override public boolean authenticate(String username, String password, ServerSession session) { return username != null && username.equals(password); } }

Next step it to implement the shell environment. To do this we have to create our own Factory implementation, what is able to handle user's I/O. In this example I will use the JLine library for handling console input. It provides out of the box miscellaneous functionalities ("tab"-complition, command history, ..) and is very similar to BSD editline and GNU readline. Our demo shell implementation will support following features:

output welcome banner on ssh session startup

"TAB"-complition support for following commands: quit, exit, version, help

entering "quit" or "exit" command will close the running SSH session

entering "version" command will output some dummy version string

entering "help" command will output "Help is not implemented yet..." string

any other input will be echoed back to the user

public class InAppShellFactory implements Factory { public Command create() { return new InAppShell(); } private static class InAppShell implements Command, Runnable { private static final Logger log = LoggerFactory.getLogger(InAppShell.class); public static final boolean IS_MAC_OSX = System.getProperty("os.name").startsWith("Mac OS X"); private static final String SHELL_THREAD_NAME = "InAppShell"; private static final String SHELL_PROMPT = "app> "; private static final String SHELL_CMD_QUIT = "quit"; private static final String SHELL_CMD_EXIT = "exit"; private static final String SHELL_CMD_VERSION = "version"; private static final String SHELL_CMD_HELP = "help"; private InputStream in; private OutputStream out; private OutputStream err; private ExitCallback callback; private Environment environment; private Thread thread; private ConsoleReader reader; private PrintWriter writer; public InputStream getIn() { return in; } public OutputStream getOut() { return out; } public OutputStream getErr() { return err; } public Environment getEnvironment() { return environment; } public void setInputStream(InputStream in) { this.in = in; } public void setOutputStream(OutputStream out) { this.out = out; } public void setErrorStream(OutputStream err) { this.err = err; } public void setExitCallback(ExitCallback callback) { this.callback = callback; } public void start(Environment env) throws IOException { environment = env; thread = new Thread(this, SHELL_THREAD_NAME); thread.start(); } public void destroy() { if (reader != null) reader.shutdown(); thread.interrupt(); } @Override public void run() { try { reader = new ConsoleReader(in, new FilterOutputStream(out) { @Override public void write(final int i) throws IOException { super.write(i); // workaround for MacOSX!! reset line after CR.. if (IS_MAC_OSX && i == ConsoleReader.CR.toCharArray()[0]) { super.write(ConsoleReader.RESET_LINE); } } }); reader.setPrompt(SHELL_PROMPT); reader.addCompleter(new StringsCompleter(SHELL_CMD_QUIT, SHELL_CMD_EXIT, SHELL_CMD_VERSION, SHELL_CMD_HELP)); writer = new PrintWriter(reader.getOutput()); // output welcome banner on ssh session startup writer.println("****************************************************"); writer.println("* Welcome to Application Shell. *"); writer.println("****************************************************"); writer.flush(); String line; while ((line = reader.readLine()) != null) { handleUserInput(line.trim()); } } catch (InterruptedIOException e) { // Ignore } catch (Exception e) { log.error("Error executing InAppShell...", e); } finally { callback.onExit(0); } } private void handleUserInput(String line) throws InterruptedIOException { if (line.equalsIgnoreCase(SHELL_CMD_QUIT) || line.equalsIgnoreCase(SHELL_CMD_EXIT)) throw new InterruptedIOException(); String response; if (line.equalsIgnoreCase(SHELL_CMD_VERSION)) response = "InApp version 1.0.0"; else if (line.equalsIgnoreCase(SHELL_CMD_HELP)) response = "Help is not implemented yet..."; else response = "======> \"" + line + "\""; writer.println(response); writer.flush(); } } }

Last but not least is to combine all this things together and start the embedded SSH server daemon on desired port (5222 in our demo):

public class App { public static void main(String[] args) throws Throwable { SshServer sshd = SshServer.setUpDefaultServer(); sshd.setPort(5222); sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider("hostkey.ser")); sshd.setPasswordAuthenticator(new InAppPasswordAuthenticator()); sshd.setShellFactory(new InAppShellFactory()); sshd.start(); } }

The KeyPairProvider above is used on the server side to provide the host key.

Now after starting our SSH daemon we can connect it using ordinary SSH client. Find below a screenshot of my session with the InAppShell:

First, let's define our demo filesystem structure. We have 2 incoming folders "headers" and "data", where the "headers"-folder contains the "header"-files and the "data"-folder the "data"-files respectively.

../in/headers

header-001.txt header-002.txt header-003.txt header-004.txt header-005.txt

../in/data

data-001.txt data-002.txt data-003.txt data-004.txt data-005.txt

For the sake of convenience each "header"-file contain only one row with the name of the corresponding "data"-file. Something like this:

header-001.txt

data-001.txt

The first step is to create the route that polls the "headers"-folder, logs the "header"-file found, reads it's content as string and sends it as the message body to the subsequent node.

from("file:target/in/headers") .to("log:net.javaforge.blog.file.header?level=INFO") .transform(body(String.class)) .to("mock:out");

From now on the outgoing message body contains the content of the "header"-file, namely the name of the associated "data"-file. Next step is to implement a processor, that consumes the "data"-file and send it as a new exchange forward to the subsequent recipient. This is where I end up:

class HeaderFileBodyProcessor implements Processor { private String dataFileFolderURI; private String recipientEndpointURI; private int dataFileReadTimeout; HeaderFileBodyProcessor(String dataFileFolderURI, String recipientEndpointURI, int dataFileReadTimeout) { this.dataFileFolderURI = dataFileFolderURI; this.recipientEndpointURI = recipientEndpointURI; this.dataFileReadTimeout = dataFileReadTimeout; } @Override public void process(Exchange exchange) throws Exception { Exchange data = this.receiveBodyFile(exchange); this.sendToNextEndpoint(exchange, data); } private Exchange receiveBodyFile(Exchange originalExchange) throws Exception { String filename = originalExchange.getIn().getBody(String.class); ConsumerTemplate consumer = originalExchange.getContext().createConsumerTemplate(); try { return consumer.receive(this.dataFileFolderURI + "?fileName=" + filename, dataFileReadTimeout); } finally { // stop the consumer as it does not need to poll for files anymore consumer.stop(); } } private void sendToNextEndpoint(Exchange originalExchange, Exchange dataFileExchange) throws Exception { if (dataFileExchange != null) { ProducerTemplate prod = originalExchange.getContext().createProducerTemplate(); try { prod.send(this.recipientEndpointURI, dataFileExchange); } finally { prod.stop(); } } else { // rollback if no body file... throw new CamelExchangeException("Cannot find the body file " + originalExchange.getIn().getBody(String.class), originalExchange); } } }

For each incoming "data"-file name the processor creates a new file consumer, that tries to read the data-file within the specified timeout intervall. After the data file was read, the consumer will be explicitly stopped, since it does not need to poll for files anymore. In case, the data-file was found, it will be send as a new exchange to the next recipient, otherwise the CamelExchangeException will be thrown. This exception forces Apache Camel to rollback the incoming "header"-file Exchange and poll it againg later. Extended camel route looks now like this:

from("file:target/in/headers") .to("log:net.javaforge.blog.file.header?level=INFO") .transform(body(String.class)) .process(new HeaderFileBodyProcessor("file://target/in/data", "direct:data", 60 * 1000)) .to("mock:out");

Thus found data-files will end up in the "direct:data" endpoint. Last step is to read and process them from the "direct:data":

from("direct:data") .to("log:net.javaforge.blog.file.body?level=INFO") .process(new DataFileProcessor()) .to("mock:data");

class DataFileProcessor implements Processor { private static final Logger log = LoggerFactory.getLogger(DataFileProcessor.class); @Override public void process(Exchange exchange) throws Exception { log.info("processing incoming data file exchange: {}", exchange); } }

Due to Apache Camel's default behavior of the "file"-component all successfully processed files will end up in the particular ".camel"-subfolder:

../in/headers/.camel

../in/data/.camel

This can be improved using file-component's options... For example:

from("file:target/in/headers?move=done/${date:now:yyyyMMddhhmmss}/${file:name}")

There is only one thing that is still not really good enough in our route definition. It is blocking. On each incoming "header"-file the processing will wait for max. timeout period for the assocciated "data"-file, even if other "header"- and "data"-files are awailable and can be processed in parallel.

Fixing this is simple just by adding multi-threading possibilities to our route definition:

from("file:target/in/headers") .to("log:net.javaforge.blog.file.header?level=INFO") .transform(body(String.class)) .threads(10) .process(new HeaderFileBodyProcessor("file://target/in/data", "direct:data", 60 * 1000)) .to("mock:out");

The source code of the project discussed in this article can be found on GitHub: https://github.com/bigpuritz/javaforge-blog/blob/master/camel-rnd

First of all, let's define the URI scheme our component will provide:

rnd:someName?options

Notice here:

rnd: - an unique URI prefix, that identifies our component

someName - any string to uniquely identify the endpoint

options - query options in the following format, ?option=value&option=value&... In this way you can customize the component behavior.

Now let's start.

1. Using Maven and camel-archetype-component create a new project

mvn archetype:generate \ -DarchetypeGroupId=org.apache.camel.archetypes \ -DarchetypeArtifactId=camel-archetype-component \ -DarchetypeVersion=2.12.1 \ -DgroupId=net.javaforge.blog.camel \ -DartifactId=camel-rnd \ -Dname=Rnd \ -Dscheme=rnd

This call will generate a new maven project containing following files:

META-INF/services/org/apache/camel/component/rnd - file to suppport auto-discovery of your component, where rnd is the URI scheme for your component and any related endpoints created on the fly. This file contains an one-line definition of the component class, that looks like this:

class=net.javaforge.blog.camel.rnd.RndComponent

RndComponent.java - the component class responsible for creaing an appropriate "rnd"-endpoint

RndEndpoint.java - is the Endpoint implementation, that will be referred in the DSL via its URI ("rnd:" in our case). Endpoints are responsible for creating Producer and Consumer instances, associated with it.

RndProducer.java - the Producer implementation for sending message exchanges to the endpoint.

RndConsumer.java - the Consumer implementation for consuming message exchanges from the endpoint.

2. Before we start with the Apache Camel specific implementation, let's first create the RndGenerator class, that can generate random character sequences. In this example I'll just use the pre-implemented random string generation functionality from commons-lang3 library and provide a random generator implemented as an enumeration supporting 5 generation types: RANDOM, ALPHABETIC, ALPHANUMERIC, NUMERIC and ASCII.

Add commons-lang3 dependency to the pom.xml:

<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.1</version> </dependency>

and create the RndGenerator class:

public enum RndGenerator { RANDOM { @Override public String generate() { if (chars != null) return RandomStringUtils.random(length, chars); else return RandomStringUtils.random(length, start, end, letters, numbers); } }, ALPHABETIC { @Override public String generate() { return RandomStringUtils.randomAlphabetic(length); } }, ALPHANUMERIC { @Override public String generate() { return RandomStringUtils.randomAlphanumeric(length); } }, NUMERIC { @Override public String generate() { return RandomStringUtils.randomNumeric(length); } }, ASCII { @Override public String generate() { return RandomStringUtils.randomAscii(length); } }; int length; String chars; boolean letters = false; boolean numbers = false; int start = 0; int end = 0; private RndGenerator() { this(10); } private RndGenerator(int length) { this.length = length; } public RndGenerator chars(String chars) { this.chars = chars; return this; } public RndGenerator letters(boolean letters) { this.letters = letters; return this; } public RndGenerator numbers(boolean numbers) { this.numbers = numbers; return this; } public RndGenerator length(int length) { this.length = length; return this; } public RndGenerator start(int start) { this.start = start; return this; } public RndGenerator end(int end) { this.end = end; return this; } /** * Generates random string sequence... * * @return random string */ public abstract String generate(); }

3. Now it is time to implement the RndEnpoint. Since we want our endpoint repeatedly generates random strings, it is easier to inherit from Camel's ScheduledPollEndpoint. It automatically provides support for endpoints which create polling consumers and can recognize "polling"-specific options like pollStrategy, initialDelay, delay and many others (for further details see http://camel.apache.org/polling-consumer.html).

Furthermore this class defines all component specific properties (generator, length,...), that we want to offer as URI options. Last but not least, an endpoint implementation shouled provide a producer and consumer, associated with it. In our special case, there is no need in producer implementation, since we only consume polling events from the endpoint and on each event send a random character sequence to the next processor in the route. Find below the brief endpoint implementation. For further details please consult the GitHub repository:

@UriEndpoint(scheme = "rnd") public class RndEndpoint extends ScheduledPollEndpoint { @UriParam private RndGenerator generator = RndGenerator.RANDOM; @UriParam private int length = 10; @UriParam private String chars = null; @UriParam private boolean letters = false; @UriParam private boolean numbers = false; @UriParam private int start = 0; @UriParam private int end = 0; public RndEndpoint() { } public RndEndpoint(String uri, RndComponent component) { super(uri, component); } public Producer createProducer() throws Exception { throw new RuntimeCamelException("Cannot produce to a RndEndpoint: " + getEndpointUri()); } public Consumer createConsumer(Processor processor) throws Exception { RndConsumer consumer = new RndConsumer(this, processor); configureConsumer(consumer); return consumer; } public boolean isSingleton() { return true; } // getter/setter skipped }

4. Remaining step is the consumer implementation, that is very straight forward in our case:

public class RndConsumer extends ScheduledPollConsumer { private final RndEndpoint endpoint; public RndConsumer(RndEndpoint endpoint, Processor processor) { super(endpoint, processor); this.endpoint = endpoint; } @Override protected int poll() throws Exception { Exchange exchange = endpoint.createExchange(); // create a message body exchange.getIn().setBody(generateRandomSequence()); try { // send message to next processor in the route getProcessor().process(exchange); return 1; // number of messages polled } finally { // log exception if an exception occurred and was not handled if (exchange.getException() != null) { getExceptionHandler().handleException( "Error processing exchange", exchange, exchange.getException()); } } } private String generateRandomSequence() { RndGenerator generator = endpoint.getGenerator(); ObjectHelper.notNull(generator, "generator"); return generator.length(endpoint.getLength()) .chars(endpoint.getChars()).letters(endpoint.isLetters()) .numbers(endpoint.isNumbers()).start(endpoint.getStart()) .end(endpoint.getEnd()).generate(); } }

That's it.. Now we are able to use our new custom component in the following fashion: Repeatedly generate random alphabetic character sequences each 5 characters long and send them to the console output stream:

from("rnd:foo?generator=alphabetic&length=30").to("stream:out");

Every 50ms generate random alphanumeric character sequences each 10 characters long, aggregate them to the lists of 5 elements and send each list as a new message to the subsequent log component:

from("rnd:foo?generator=alphanumeric&initialDelay=0&delay=50&length=10") .setHeader("foo", constant("bar")) .aggregate(header("foo"), new ListAggregationStrategy()) .completionSize(5) .to("log:net.javaforge.blog.camel?level=INFO"); private static class ListAggregationStrategy implements AggregationStrategy { @SuppressWarnings("unchecked") @Override public Exchange aggregate(Exchange oldExchange, Exchange newExchange) { Object newBody = newExchange.getIn().getBody(); List<Object> list; if (oldExchange == null) { list = new ArrayList<Object>(); list.add(newBody); newExchange.getIn().setBody(list); return newExchange; } else { list = oldExchange.getIn().getBody(List.class); list.add(newBody); return oldExchange; } } }

Repeatedly (every 10ms) generate random alphanumeric character sequences each 50 characters long and append them to the existing file out.txt:

from("rnd:foo?generator=alphanumeric&delay=10&length=50) .process(new Processor() { @Override public void process(Exchange exchange) throws Exception { exchange.getIn().setBody(exchange.getIn().getBody() + "\n"); } }) .to("file:target?fileName=out.txt&fileExist=Append")

Generate random string sequences of length 30 containing only characters a,b and c:

from("rnd:foo?initialDelay=0&generator=random&chars=abc&length=30").to("stream:out");

First, depending on what output format you aim to produce, there are 3 possible renderer to use: PDFRenderer, HTMLRenderer and RTFRenderer.

Each renderer requires a Docbook XML resource as input. Optionally you can specify a XSL stylesheet and (only in case of HTMLRenderer) an optional CSS stylesheet to use.

As result each renderer produces an InputStream instance containing generated docbook output in appropriate format.

Note! As resource definition docbook4j supports all filesystem types supported by commons-vfs2 (see http://commons.apache.org/vfs/filesystems.html).

Following few examples demonstrate how docbook4j can be used.

Generate PDF input stream using specified Docbook XML (located within zip archive) and default Docbook XSL:

String xml = "zip:path/to/my/zip/docs.zip!document.xml"; PDFRenderer pdfRenderer = PDFRenderer.create(xml); InputStream in = pdfRenderer.render();

Generate PDF input stream using specified Docbook XML (located within classpath) and custom Docbook XSL (located within external zip archive):

String xml = "res:classpath/to/my/xml/document.xml"; String xsl = = "zip:path/to/my/xsl/zip/xsls.zip!styles.xsl"; PDFRenderer pdfRenderer = PDFRenderer.create(xml, xsl); InputStream in = pdfRenderer.render();

Generate HTML input stream using specified Docbook XML (located in filesystem) and custom CSS:

String xml = "file:///home/someuser/somedir/document.xml"; String css = "file:///home/someuser/somedir/other/my.css"; HTMLRenderer htmlRenderer = HTMLRenderer.create(xml).css(css). InputStream in = htmlRenderer.render();

Additionally some advanced docbook4j features and notes:

While writing a custom Docbook XSL, you usually want to import a default docbook XSL in your stylesheet. With docbook4j just use following xsl import definition:

<xsl:import href="res:xsl/docbook/fo/docbook.xsl" />

Docbook4j supports XInclude-s out of the box. Just use an xi:include element in you docbook xml file as usual and you are done:

<?xml version="1.0" encoding="UTF-8"?> <book version="5.0" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:db="http://docbook.org/ns/docbook"> ... <chapter> <title>This is a chapter</title> <xi:include href="section0.inc.xml" /> <xi:include href="section1.inc.xml" /> </chapter> </book>

With docbook4j you are able to use MVEL or OGNL to evaluate dynamic expressions at generation time. Following example gives a brief overview how to use this feature.  Note! To be able to use this feature, you have to add MVEL of OGNL library expicitely to your classpath. Assume we have some Java Bean defining 3 properties: inceptionYear, name and version:

public class Project { private String inceptionYear; private String version; private String name; // getter / setter goes here }

Furthermore there is a docbook document, referencing this properties via MVEL expressions:

<?xml version="1.0" encoding="UTF-8"?> <book version="5.0" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:db="http://docbook.org/ns/docbook"> ... <copyright> <year><?mvel project.inceptionYear?></year> <holder>Company Inc. [COMPANY, INC.]. All Rights Reserved.</holder> </copyright> <abstract> <para> This is a documentation example generated with Docbook for project <?mvel project.name?> (v.<?mvel project.version?>). </para> </abstract> ... </book>

To be able to render such a document, we have to specify a variable, that will be used by the appropriate renderer to evaluate the expressions:

Project project = new Project(....); String xml = "...."; // xml document source PDFRenderer renderer = PDFRenderer.create(xml).variable("project", project); InputStream in = renderer.render();

Add following test-scoped dependencies to the pom.xml:

<dependencies> <dependency> <!-- only necessary since we're using H2 as our demonstration database --> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>1.3.168</version> <scope>test</scope> </dependency> <dependency> <groupId>org.liquibase</groupId> <artifactId>liquibase-core</artifactId> <version>2.0.5</version> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> <scope>test</scope> </dependency> </dependencies>

In the next step we'll create a skeleton for our testcase, that will put the test data into the database only once on startup and remove it on teardown after all tests are executed.

public class TestWithLiquibase { private static Connection conn; private static Liquibase liquibase; @BeforeClass public static void createTestData() throws SQLException, ClassNotFoundException, LiquibaseException { Class.forName("org.h2.Driver"); conn = DriverManager.getConnection("jdbc:h2:liquibase-sample", "sa", "sa"); Database database = DatabaseFactory.getInstance() .findCorrectDatabaseImplementation(new JdbcConnection(conn)); liquibase = new Liquibase("db/testdata/db.testdata.xml", new FileSystemResourceAccessor(), database); liquibase.update(null); } @AfterClass public static void removeTestData() throws LiquibaseException, SQLException { liquibase.rollback(1000, null); conn.close(); } }

Now, writing a database-driven unit tests is quite simple. Following few tests just giving an idea, how to do this:

@Test public void testUsers() throws SQLException { PreparedStatement stmt = null; ResultSet rs = null; try { stmt = conn.prepareStatement("select count(*) as numberOfUsers from t_user"); rs = stmt.executeQuery(); rs.next(); int numberOfUsers = rs.getInt("numberOfUsers"); Assert.assertEquals(3, numberOfUsers); } finally { rs.close(); stmt.close(); } } @Test public void testRoles() throws SQLException { PreparedStatement stmt = null; ResultSet rs = null; try { stmt = conn.prepareStatement("select count(*) as numberOfRoles from t_role"); rs = stmt.executeQuery(); rs.next(); int numberOfUsers = rs.getInt("numberOfRoles"); Assert.assertEquals(3, numberOfUsers); } finally { rs.close(); stmt.close(); } }

Done.

pom.xml

<build> <plugins> ... <plugin> <groupId>org.liquibase</groupId> <artifactId>liquibase-maven-plugin</artifactId> <version>2.0.5</version> <configuration> <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase> <propertyFile>db/liquibase.properties</propertyFile> </configuration> </plugin> ... </plugins> </build>

liquibase.properties

promptOnNonLocalDatabase=false changeLogFile=db/ddl/db.changelog-master.xml driver=org.h2.Driver url=jdbc:h2:liquibase-sample username=sa password=sa

Since we are using H2 database for demonstation purpose, we have to add it as a dependency to the pom.xml too:

<dependencies> ... <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>1.3.168</version> <scope>test</scope> </dependency> ... </dependencies>

As you may note, liquibase.properties file references the db.changelog-master.xml file. This file is an entry point for Liquibase and contains all our database changes.

In our sample project it has include definitions, referencing to the changes affecting the major versions only (1.x, 2.x etc):

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"> <preConditions> <dbms type="h2" /> </preConditions> <include file="1.x/db.changelog-1.x.xml" relativeToChangelogFile="true" /> <!-- <include file="2.x/db.changelog-2.x.xml" relativeToChangelogFile="true" /> <include file="3.x/db.changelog-3.x.xml" relativeToChangelogFile="true" /> .... --> </databaseChangeLog>

The folder structure we will create for our change management through this tutorial is demonstrated in the screenshot below:

Now let's start with the database management for the version 1.x.

Step 1. 

Assume we have started with the completely new project and our first database change will have the version 1.0. 

In the first version we'll apply following changes to the database:

change set 1.0_1

create a new table t_user with the columns id, name, active

change set 1.0_2

rename the t_user column name to the username

create a new table t_role with two columns name and description

add a new column role to the t_user table

create a foreign key that references t_role(name) and t_user(role)

change set 1.0_3

create a new index indx_t_user_0003 on t_user(username)

create a view v_user joining t_user and t_role tables

change set 1.0_4

tag the database with a tag 1.0

First we have to add an appropriate include to the db.changelog-1.x.xml file:

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"> <include file="1.0/db.changelog-1.0.xml" relativeToChangelogFile="true" /> </databaseChangeLog>

And to write the db.changelog-1.0.xml itself:

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"> <changeSet id="1.0_1" author="mk"> <createTable tableName="t_user"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false" /> </column> <column name="name" type="varchar(50)"> <constraints nullable="false" /> </column> <column name="active" type="boolean" defaultValueBoolean="true" /> </createTable> </changeSet> <changeSet id="1.0_2" author="mk"> <renameColumn tableName="t_user" oldColumnName="name" newColumnName="username" /> <createTable tableName="t_role"> <column name="name" type="varchar2(50)"> <constraints primaryKey="true" nullable="false" /> </column> <column name="description" type="varchar2(250)" /> </createTable> <addColumn tableName="t_user"> <column name="role" type="varchar2(50)"> <constraints nullable="false" /> </column> </addColumn> <addForeignKeyConstraint constraintName="fk_user_role" baseTableName="t_user" baseColumnNames="role" referencedTableName="t_role" referencedColumnNames="name" /> </changeSet> <changeSet id="1.0_3" author="xyz"> <createIndex tableName="t_user" indexName="indx_t_user_0003"> <column name="username" /> </createIndex> <createView viewName="v_user"> <![CDATA[ select u.id, u.username, r.name from t_user u join t_role r on u.role = r.name ]]> </createView> </changeSet> <changeSet id="1.0_4" author="foobar"> <tagDatabase tag="1.0" /> </changeSet> </databaseChangeLog>

Now we are ready to apply our changes against the database. To do this, just execute the following maven command:

mvn liquibase:update

After execution you'll see, that following database objects were created by the Liquibase:

As you may note, Liquibase additionaly created two special tables DATABASECHANGELOG and DATABASECHANGELOGLOCK containing metadata required by the Liquibase at runtime.

Below is a contents of the DATABASECHANGELOG table after executing our first database changelog:

Note! If you don't want to apply the changes directly to the database, but to generate a sql sciprt instead, run the following maven command:

mvn liquibase:updateSQL

This will generate a migration sql script migrate.sql into the target/liquibase folder. For our first database changelog this script looks like this:

-- ********************************************************************* -- Update Database Script -- ********************************************************************* -- Change Log: db/ddl/db.changelog-master.xml -- Ran at: 06/11/12 09:23 -- Against: SA@jdbc:h2:liquibase-sample -- Liquibase version: 2.0.5 -- ********************************************************************* -- Create Database Lock Table CREATE TABLE DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID)); INSERT INTO DATABASECHANGELOGLOCK (ID, LOCKED) VALUES (1, FALSE); -- Lock Database -- Create Database Change Log Table CREATE TABLE DATABASECHANGELOG (ID VARCHAR(63) NOT NULL, AUTHOR VARCHAR(63) NOT NULL, FILENAME VARCHAR(200) NOT NULL, DATEEXECUTED TIMESTAMP NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONSTRAINT PK_DATABASECHANGELOG PRIMARY KEY (ID, AUTHOR, FILENAME)); -- Changeset db/ddl/1.x/1.0/db.changelog-1.0.xml::1.0_1::mk::(Checksum: 3:f5d02804c70da7f8eda3e5eda3c987b3) CREATE TABLE t_user (id INT NOT NULL, name VARCHAR(50) NOT NULL, active BOOLEAN DEFAULT TRUE, CONSTRAINT PK_T_USER PRIMARY KEY (id)); INSERT INTO DATABASECHANGELOG (AUTHOR, COMMENTS, DATEEXECUTED, DESCRIPTION, EXECTYPE, FILENAME, ID, LIQUIBASE, MD5SUM, ORDEREXECUTED) VALUES ('mk', '', NOW(), 'Create Table', 'EXECUTED', 'db/ddl/1.x/1.0/db.changelog-1.0.xml', '1.0_1', '2.0.5', '3:f5d02804c70da7f8eda3e5eda3c987b3', 1); -- Changeset db/ddl/1.x/1.0/db.changelog-1.0.xml::1.0_2::mk::(Checksum: 3:55092b96f60bb8379f251b553c7ddc1e) ALTER TABLE t_user ALTER COLUMN name RENAME TO username; CREATE TABLE t_role (name varchar2(50) NOT NULL, description varchar2(250), CONSTRAINT PK_T_ROLE PRIMARY KEY (name)); ALTER TABLE t_user ADD role varchar2(50) NOT NULL; ALTER TABLE t_user ADD CONSTRAINT fk_user_role FOREIGN KEY (role) REFERENCES t_role (name); INSERT INTO DATABASECHANGELOG (AUTHOR, COMMENTS, DATEEXECUTED, DESCRIPTION, EXECTYPE, FILENAME, ID, LIQUIBASE, MD5SUM, ORDEREXECUTED) VALUES ('mk', '', NOW(), 'Rename Column, Create Table, Add Column, Add Foreign Key Constraint', 'EXECUTED', 'db/ddl/1.x/1.0/db.changelog-1.0.xml', '1.0_2', '2.0.5', '3:55092b96f60bb8379f251b553c7ddc1e', 2); -- Changeset db/ddl/1.x/1.0/db.changelog-1.0.xml::1.0_3::xyz::(Checksum: 3:b97854eff530d4d96b3fe096b308e239) CREATE INDEX indx_t_user_0003 ON t_user(username); CREATE VIEW v_user AS select u.id, u.username, r.name from t_user u join t_role r on u.role = r.name; INSERT INTO DATABASECHANGELOG (AUTHOR, COMMENTS, DATEEXECUTED, DESCRIPTION, EXECTYPE, FILENAME, ID, LIQUIBASE, MD5SUM, ORDEREXECUTED) VALUES ('xyz', '', NOW(), 'Create Index, Create View', 'EXECUTED', 'db/ddl/1.x/1.0/db.changelog-1.0.xml', '1.0_3', '2.0.5', '3:b97854eff530d4d96b3fe096b308e239', 3); -- Changeset db/ddl/1.x/1.0/db.changelog-1.0.xml::1.0_4::foobar::(Checksum: 3:2436467c358c5141a858c2705374d989) UPDATE DATABASECHANGELOG SET TAG = '1.0' WHERE DATEEXECUTED = (SELECT MAX(DATEEXECUTED) FROM DATABASECHANGELOG); INSERT INTO DATABASECHANGELOG (AUTHOR, COMMENTS, DATEEXECUTED, DESCRIPTION, EXECTYPE, FILENAME, ID, LIQUIBASE, MD5SUM, ORDEREXECUTED, TAG) VALUES ('foobar', '', NOW(), 'Tag Database', 'EXECUTED', 'db/ddl/1.x/1.0/db.changelog-1.0.xml', '1.0_4', '2.0.5', '3:2436467c358c5141a858c2705374d989', 4, '1.0');

And one more remark:

To rollback the applyed changes, simply run:

mvn liquibase:rollback

Step 2.

Now assume we are done with the version 1.0 and starting to develop a new version 1.1. This contains some database changes too, so we have to create a new changelog file and reference it within db.changelog-1.x.xml:

<include file="1.1/db.changelog-1.1.xml" relativeToChangelogFile="true" />

Version 1.1 specifies only one changeset 1.1_1 containing following changes:

create a new table t_address with the columns id, street, house_no, zipcode, city

tag the database with a tag 1.1

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"> <changeSet id="1.1_1" author="mk"> <createTable tableName="t_address"> <column name="id" type="int" autoIncrement="true"> <constraints primaryKey="true" nullable="false" /> </column> <column name="street" type="varchar(50)"> <constraints nullable="true" /> </column> <column name="house_no" type="varchar(10)"> <constraints nullable="true" /> </column> <column name="zipcode" type="varchar(50)"> <constraints nullable="true" /> </column> <column name="city" type="varchar(50)"> <constraints nullable="true" /> </column> </createTable> </changeSet> <changeSet id="1.1_2" author="foobar"> <tagDatabase tag="1.1" /> </changeSet> </databaseChangeLog>

Once again to apply the changes, just run mvn liquibase:update. This time Liquibase recognizes, that the changes from db.changelog-1.0.xml were already applyed to the databse (remember the DATABASECHANGELOG table!) and applies only outstanding changes from db.changelog-1.1.xml.

Step 3.

Analog to the step 2 it specifies new changes for the next development version 1.2:

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"> <changeSet id="1.2_1" author="xyz"> <createIndex tableName="t_address" indexName="indx_t_address_001"> <column name="street" /> </createIndex> <createIndex tableName="t_address" indexName="indx_t_address_002" unique="true"> <column name="street" /> <column name="house_no" /> <column name="city" /> </createIndex> <createIndex tableName="t_address" indexName="indx_t_address_003"> <column name="city" /> </createIndex> </changeSet> <changeSet id="1.2_2" author="foobar"> <tagDatabase tag="1.2" /> </changeSet> </databaseChangeLog>

To execute it, run again mvn liquibase:update (or mvn liquibase:updateSQL).

Further procedure is straightforward and similar to the previous steps. 

Sign up for an account by Boxcar.IO with your email address

Download and install free Boxcar App: http://itunes.apple.com/app/boxcar/id321493542?ign-mpt=uo%3D6&mt=8

Send a SUBSCRIBE request via Boxcar to your iPhone to activate one of the generic providers.

  curl -d "[email protected]" http://boxcar.io/devices/providers/MH0S7xOFSwVLNvNhTpiC/notifications/subscribe  

       Send a dummy CREATE request to your iPhone to test if everything was properly configured.

  curl -d "[email protected]&notification[from_screen_name]=Hello&notification[message]=This+is+an+example" http://boxcar.io/devices/providers/MH0S7xOFSwVLNvNhTpiC/notifications  

Now we are able to send push notifications to our iOS device through Boxcar.

Next step is to create Apache Camel routes by implementing following scenario:

If somebody drops a new file into the predefined folder location, new iOS push notification should be sent.

If somebody sends a HTTP request to our application with the request parameter "msg", its value will be taken as a message and sent as an iOS push notification.

We'll start with the Maven dependencies required to fulfill the task above:

<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-core</artifactId> <version>2.10.1</version> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-http</artifactId> <version>2.10.1</version> </dependency>

Next we have to define our 2 route by subclassing Camel's RouteBuilder:

public class BoxcarRouteBuilder extends RouteBuilder { private static final String BOXCAR_QUERY_PREFIX = "[email protected]&notification[from_screen_name]=Javaforge Blog&notification[message]="; @Override public void configure() throws Exception { from("jetty:http://0.0.0.0:8888/messages") .setBody(simple(BOXCAR_QUERY_PREFIX + "${in.headers.msg}")) .to("log:net.javaforge.blog.camel.LOG") .to("http://boxcar.io/devices/providers/MH0S7xOFSwVLNvNhTpiC/notifications?bridgeEndpoint=true") .transform().constant("OK"); from("file:target/inbox?noop=true") .setBody(simple(BOXCAR_QUERY_PREFIX + "File added: ${file:path}")) .to("log:net.javaforge.blog.camel.LOG") .to("http://boxcar.io/devices/providers/MH0S7xOFSwVLNvNhTpiC/notifications"); } }

Some explanations:

First route definition listens for incoming HTTP requests on port 8888, reads the value of the request parameter "msg", rewrites the message body to the format required by Boxcar and forwards it to the Boxcar's generic provider. See Apache Camel's Jetty component for further details: http://camel.apache.org/jetty.html

Second route definition monitors "target/inbox" folder. Once new file is added to it, new message body with the name of the added file will be created and forwarded to the Boxcar. See Apache Camel's File component for further details: http://camel.apache.org/file2.html

Last step is to start Apache Camel in standalone mode and to provide BoxcarRouteBuilder to it:

public class BoxcarRunner { public static void main(String[] args) throws Exception { Main main = new Main(); // enable hangup support so you can press ctrl + c to terminate the JVM main.enableHangupSupport(); // add routes main.addRouteBuilder(new BoxcarRouteBuilder()); // run until you terminate the JVM System.out.println("Starting Camel. Use ctrl + c to terminate the JVM.\n"); main.run(); } }

Now we can either drop some files into the "target/inbox" folder or send HTTP requests to the localhost:8888/messages like this:

  curl -d "msg=Hello Iphone" http://localhost:8888/messages  

Here are some screenshots taken on iPhone after it was bombed with the push notifications :)

To start a project following maven dependency is required in your pom.xml:

<dependency> <groupId>org.atmosphere</groupId> <artifactId>atmosphere-runtime</artifactId> <version>1.0.0</version> </dependency>

Next we have to a create a HttpSessionListener implementation, instantiating new atmosphere broadcaster with a unique name each time a new http session is created and removing it, once this session will be destroyed by the container.

public class BroadcasterCreater implements HttpSessionListener { private static final Logger LOG = LoggerFactory.getLogger(BroadcasterCreater.class); public static final String BROADCASTER_ID_KEY = "net.javaforge.blog.atmosphere.broadcasterId"; @Override public void sessionCreated(HttpSessionEvent se) { HttpSession session = se.getSession(); String broadcasterId = "/broadcaster/" + session.getId(); LOG.info("Creating broadcaster: {}", broadcasterId); BroadcasterFactory.getDefault().lookup(broadcasterId, true); session.setAttribute(BROADCASTER_ID_KEY, broadcasterId); } @Override public void sessionDestroyed(HttpSessionEvent se) { HttpSession session = se.getSession(); String broadcasterId = (String) session.getAttribute(BROADCASTER_ID_KEY); LOG.info("Removing broadcaster: {}", broadcasterId); BroadcasterFactory.getDefault().remove(broadcasterId); } }

Once new http session is created by the server, new atmosphere broadcaster will be instantiated by calling #lookup(..) method on the default BroadcasterFactory. Furthemore the identifier of the created broadcaster will be put into the http session as attribute under the BROADCASTER_ID_KEY key.

Next step is to implement an Atmosphere Handler, that opens our "communication channel" and responds to the incoming requests or pushes some messages to the client. In this example we'll create just a "dummy" handler, that responds to the client with the same message it receives.

@AtmosphereHandlerService public class UserSessionAwareAtmosphereHandler extends AbstractReflectorAtmosphereHandler { private static final Logger LOG = LoggerFactory.getLogger(UserSessionAwareAtmosphereHandler.class); @Override public void onRequest(AtmosphereResource resource) throws IOException { suspendAtmosphereResourceIfNecessary(resource); if ("POST".equalsIgnoreCase(resource.getRequest().getMethod())) { doBroadcast(resource); } } private void doBroadcast(AtmosphereResource resource) throws IOException { AtmosphereRequest req = resource.getRequest(); String incomingMessage = req.getReader().readLine(); LOG.info("Incoming message: '{}'", incomingMessage); Broadcaster broadcaster = null; if (incomingMessage.startsWith("@/broadcaster/")) { String broadcasterId = incomingMessage.substring(1, incomingMessage.indexOf(" ")); broadcaster = lookupBroadcaster(broadcasterId); } else { broadcaster = lookupBroadcaster(req); } LOG.info("Broadcasting message with broadcaster = {}", broadcaster.getID()); broadcaster.broadcast("ACK! Sent message was: <strong>" + incomingMessage + "</strong>"); } private void suspendAtmosphereResourceIfNecessary( AtmosphereResource resource) { AtmosphereRequest req = resource.getRequest(); AtmosphereResponse resp = resource.getResponse(); String method = req.getMethod(); if ("GET".equalsIgnoreCase(method)) { LOG.info("GET request detected, suspending broadcaster..."); // Log all events on the console, including WebSocket events. resource.addEventListener(new WebSocketEventListenerAdapter()); resp.setContentType("text/html;charset=ISO-8859-1"); Broadcaster b = lookupBroadcaster(req); resource.setBroadcaster(b); if (req.getHeader(HeaderConfig.X_ATMOSPHERE_TRANSPORT) .equalsIgnoreCase(HeaderConfig.LONG_POLLING_TRANSPORT)) { req.setAttribute(ApplicationConfig.RESUME_ON_BROADCAST, Boolean.TRUE); resource.suspend(-1, false); } else { resource.suspend(-1); } LOG.info("Broadcasting notification message to all connected users..."); MetaBroadcaster.getDefault().broadcastTo( "/broadcaster/*", "new broadcaster connected: <strong>" + b.getID() + "</strong>"); } } @Override public void destroy() { } private Broadcaster lookupBroadcaster(AtmosphereRequest req) { String broadcasterId = (String) req.getSession().getAttribute(BroadcasterCreater.BROADCASTER_ID_KEY); return lookupBroadcaster(broadcasterId); } private Broadcaster lookupBroadcaster(String broadcasterId) { LOG.info("Looking up for broadcaster: {}", broadcasterId); Broadcaster broadcaster = BroadcasterFactory.getDefault().lookup(broadcasterId); LOG.info("Broadcaster found : {}", broadcaster.getID()); return broadcaster; } }

Some explanations:

lookupBroadcaster(..) method scans BroadcasterFactory and returns a broadcaster instance with the requested identifier. This broadcaster definitely exists already, because it was created by out http session listener one step earlier.

suspendAtmosphereResourceIfNecessary(..) method implements a typical Atmosphere way to handle the first incoming GET request. It initiates hierby a durable communication channel. Furthermore note the usage of the Atmosphere's MetaBroadcaster, sending notification to all connected broadcasters using "/broadcaster/*" pattern.

doBroadcast(..) method investigates the incoming message. If it starts with a  special "@/broadcaster/" prefix, then the handler responds to the broadcater explicitly mentioned in the message (this way you can send messages to other connected broadcasters/http sessions). Otherwise it responds to the broadcaster associated with the current http session.

Note! Atmosphere is not only able to respond to the incoming message. Due the durable communication channel between server and client you can push  messages to the client every time you want using Broadcaster.broadcast(..) method.

Next step is to connect all this things together by specifying them in the web.xml:

<?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:j2ee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2.5.xsd"> <listener> <listener-class>net.javaforge.blog.atmosphere.BroadcasterCreater</listener-class> </listener> <servlet> <description>AtmosphereServlet</description> <servlet-name>AtmosphereServlet</servlet-name> <servlet-class>org.atmosphere.cpr.AtmosphereServlet</servlet-class> <init-param> <param-name>org.atmosphere.cpr.AtmosphereHandler</param-name> <param-value>net.javaforge.blog.atmosphere.UserSessionAwareAtmosphereHandler </param-value> </init-param> <init-param> <param-name>org.atmosphere.useNative</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>org.atmosphere.cpr.sessionSupport</param-name> <param-value>true</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AtmosphereServlet</servlet-name> <url-pattern>/atmosphere/*</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>

The only thing that needs to be demonstrated, is the message processing on the clientside. This can be done by adding  the jquery and the jquery.atmosphere.js libraries to your clientside code and by writing some javascript handling the communication.

Javascript snippet below briefly demonstrates how the clientside code can be implemented:

$(document).ready( function() { function subscribe() { var request = { url : document.location.toString() + 'atmosphere/<%=broadcasterId%>', transport : 'websocket' }; request.onMessage = function(response) { // handle incoming message detectedTransport = response.transport; if (response.status == 200) { var data = response.responseBody; if (data.length > 0) { // do something with the data.... } } }; subSocket = socket.subscribe(request); } function unsubscribe() { socket.unsubscribe(); } function connect() { unsubscribe(); subscribe(); } function sendMessage(){ var msg = .... ; // message to send subSocket.push({ data : msg ? msg : "<null>" }); } });

Now you are able to support a durable per-session connection in your web application.

Please consult the GitHub for the complete working example: https://github.com/bigpuritz/javaforge-blog/tree/master/atmosphere-per-session-broadcaster