I'm excited to announce the 2nd milestone release of Reactor on our way toward 1.0! Maven artifacts for Reactor 1.0.0.M2 are available in the usual milestone repository.

What is Reactor?

Reactor is a foundational framework for building high-throughput, asynchronous, reactive applications on the JVM. It provides Selector-style topic matching for event routing, dynamic Consumer assignment, an uber-fast task processor, and reactive Stream and Promise APIs for working with data asynchronously and coordinating asynchronous tasks. It comes with comprehensive Groovy language support by providing langauge extensions to make writing Reactor applications in Groovy pretty darned Groovy! It also has easy-to-use Spring support that automagically wires annotated POJOs to Reactors.

What's in this Release?

This 2nd milestone includes a number of bugfixes and some really exciting new features. Reactor now includes a Processor abstraction, which is a highly-optimized task processor based on the LMAX Disruptor RingBuffer. It uses the common abstractions from Reactor to configure a RingBuffer and allows you to use Reactor's common API instead of the Disruptor-specific API. It also by design skips the Selector matching and dynamic Consumer assignment provided by a Reactor in order to wring every last drop of throughput it can. Anecdotal benchmarks on a MacBook Pro show the Processor can pump around 100,000,000 events per second through the pipeline. Yes, you read that right: 100 million per second!

1.0.0.M2 also includes a small, but significant new feature in the Reactor API which optimizes event publishing in a Reactor to get about 30-50% higher throughput. It won't suit every situation since it prepares an optimized list of Consumers from the Reactor, but for an extra 10 million events per second in throughput, it's a great new feature.

Optimized Publish

One of the powerful aspects of Reactor is the Selector matching topic(ish) pub/sub. It allows you to easily assign handlers to events using topics, anonymous objects, assignable type hierarchies, URI path matching, or regular expressions (or any other type of Selector matching if you implement your own, domain-specific Selectors). But many applications can assign their handlers at startup, which means the path to those Consumers can be optimized for efficient event publication. The new Reactor method prepare(Object) allows you to pre-select the Consumers for a key. It returns a Consumer itself that event publishers can use to efficiently notify about new events.

// Create Environment in which Reactors operate
Environment env = new Environment();
Reactor reactor = Reactors.reactor().env(env).get();

reactor.on($("say.hello"), new Consumer<Event<String>>() {
	public void accept(Event<String> ev) {
		System.out.println("Hello " + ev.getData() + "!");
	}
});

Consumer<Event<String>> sayHello = reactor.prepare("say.hello");
for(String name : listOfNames) {
	sayHello.accept(name);
}

RingBuffer Task Processor

Reactor 1.0.0.M2 includes the Processor abstraction. It is a simple task processor backed by the LMAX Disruptor RingBuffer and is designed to integrate it seamlessly into the reactive APIs used in Reactor, so it uses common abstractions like Supplier and Consumer. A fully-configured Processor can be created in a single expression and using Java 8 lambdas is more succinct yet:

Processor<Message> proc = new ProcessorSpec<Message>()
	.dataSupplier({ return new Message(); })
	.consume({ msg -> // handle the updated Message object…

It is with great pleasure that I am announcing the release of Spring LDAP 1.3.2. This release contains lots of bug fixes and will provide a solid foundation for a Spring LDAP 2.0 release.

I'd like to thank Mattias Arthursson from 261 Consulting for all his hard work on this release.

Today we are pleased to announce the first milestone release towards Spring Batch 3.0 (download). With this release we take our first steps towards implementing the JSR-352 Java Batch specification. Spring Batch is a lightweight, comprehensive framework for the development of robust batch applications.

JSR-352

JSR-352 is billed as the standardization of batch processing for the java platform. As part of that standardization, this JSR has included three main pieces:

• A XML based DSL for configuring jobs
• An API for creating job related components (readers/writers/etc)
• An API and description of behavior for a supporting classes and concepts

Spring has invested a large amount of time and resources in our contribution to this spec. Our collaboration with the other industry experts via the JCP, JSR-352 validates that the batch patterns that Spring Batch has implemented and battle tested over the past five years in countless production environments is the best approach for building mission critical batch applications.

Features in Milestone 1

This release is the first step towards Spring Batch being compliant with the JSR. Out of the 155 SE tests in the JSR-352 TCK, this release passes 70. The specific features implemented within this release are:

• JobOperator implementation
• Basic Job configuration via XML
• batch.xml support

JobOperator

The JSR defines a JobOperator interface that is a combination of Spring Batch's JobOperator and JobExplorer interfaces. For the spec, this interface serves as the entry point for a batch application to both interact with the job itself (start/stop/restart/etc) as well as the job repository (providing the ability to query for previously run JobExecutions for example). Because of this, the JobOperator needs to provide a level of services out of the box. The JsrJobOperator (the Spring implementation of javax.batch.operations.JobOperator) bootstraps a Spring context similar to that of @EnableBatchProcessing. Out of the box, it includes a JobRepository, JobLauncher, JobOperator, JobExplorer, DataSource, TransactionManager, ParametersConverter, JobRegistry, and a PlaceholderPropertiesConfigurer. All of these can be overridden at runtime by overriding the default beans via the context provided when starting or restarting a job. By default, the JobRepository utilizes HSQLDB in an in-memory configuration.

Per the JSR, to launch a job is actually very easy:

JobOperator jobOperator = BatchRuntime.getJobOperator();
JobExecution jobExecution = jobOperator.start("jsrJob", new Properties());

The above two lines will bootstrap the previously defined base context (this occurs only once), then loads the batch.xml file from /META-INF (if it exists) and the context as defined at jsrJob.xml in /META-INF/batch-jobs. jsrJob.xml can be one of two configurations. It can be a standard Spring context configuration that defines any batch artifacts as Spring Beans and the job via the JSR-352 DSL, or it can be just the job definition as defined by the JSR. Per JSR-352, only one job can be defined within the jsrJob.xml context. The rest of the JsrJobOperator's functionality is virtually a direct wrapping of the existing JobOperator and JobExplorer's functionality (hence their inclusion in the base application context).

Basic Job configuration via XML

JSR-352 defines an XML based DSL that any Spring Batch user will immediately find familiar. Consisting of jobs, steps, readers and writers, most of the concepts that are found in the Spring Batch namespace are accounted for within JSR-352. As part of this release, developers will be able to configure basic jobs using the JSR defined DSL. Basic jobs include the following:

• <job>
• <step>
• <chunk>
• <batchlet>
• <reader>
• <processor>
• <writer>
• <decision>
• <listeners>/<listener>
• <properties>/<property>
• <skippable-exception-classes> and related children
• <retryable-exception-classes> and related children
• <checkpoint-algorithm>
• <next>/<end>//<code><fail>

<job id="data" xmlns="http://www.springframework.org/schema/batch">
    <step id="import" next="report">
        <tasklet>
            <chunk commit-interval="100"
                   reader="itemReader"
                   writer="dataWriter" />
        </tasklet>
    </step>
    <step id="report…

UPDATE

<http ...>
    ...
    <headers />
</http>

<p>The remainder of this post will discuss each of the default headers in more detail:</p>
<ul>
<li><a href="#cache-control">Cache Control</a></li>
<li><a href="#content-type-options">Content Type Options</a></li>
<li><a href="#hsts">HTTP Strict Transport Security</a…

Dear Spring Community,