Java around the world

Comments(0)

Comments(0)

Comments(0)

My last blog showed how Spring is soaring past EJB. Research by BZ Media and others shows that Apache Tomcat is the leading open source application server with a 64% market penetration. The dominance of Spring and Tomcat is well-known. What people may not know as well is that thousands of organizations are running Spring on Tomcat as their middleware infrastructure. Those organizations want one company to turn to for the products and services they need to be successful.

Today we announced our acquisition of Covalent Technologies. Not only does Covalent bring Apache leadership, but our combined company now has significant leadership on Apache Tomcat and HTTP. Two weeks ago, Sun paid $1bn for the "M" in LAMP. Now that Covalent's outstanding Apache expertise and services are part of SpringSource, we are strong leaders in the “A”. We have always been about technology leadership, so we’re very excited about what we can do together with Covalent. Over the last few years, Covalent has earned a great reputation in the marketplace with its support for Apache projects, including Tomcat and Apache HTTP. Its hundreds of support customers include more than half of the Fortune 500, and household names like Pfizer, Johnson & Johnson, British Telecom (BT), NASA, Intel, Royal Bank of Scotland and Bear Stearns. Our announcement today begins a new phase in the history of our company, and–I believe—the rapidly changing application platform market.

Developers, architects and IT managers love Tomcat, and it's increasingly used in production. They also love Spring, and it's core to more and more mission-critical applications. SpringSource and Covalent are seeing each other all the time in large organizations, hence a marriage to create the de facto provider for Spring and related Apache products and services. At the recent Spring Experience show, this was echoed throughout the hundreds of developers, architects and senior IT managers attending. Ninety-three (93) percent Spring users are also running their applications, many of them mission critical, on Tomcat.

SpringSource is now the leading vendor of support for Apache Tomcat, HTTP and other Apache software projects, as well as for the Spring Portfolio. We have further strengthened our already outstanding engineering and support teams, and have the ability to provide packaged support offerings to our customers spanning the key open source projects they use.

In all cases, our support is backed by core committers on the key project teams. For example, consider Ohloh rankings on Apache HTTPD, showing SpringSource's Bill Rowe as the most active committer, over a period of many years. Ohloh is a tool for ranking activity on open source projects that's a handy resource when choosing the provider of your open source support. You can see whether any of your support dollars are going into developing open source software (and thus helping to ensure that the projects you depend on will be dependable tomorrow), and you can judge whether or not the staff who are paid to solve your problems have the expertise and intimate knowledge of the code to ensure that they can do so quickly, and in the best possible way.

We are excited to deepen our relationship with the Apache Software Foundation (ASF). SpringSource looks forward to playing a large role in contributing to ASF projects and continuing Covalent’s tradition of valuing, promoting and sponsoring the ASF. We will engage with the Apache community across many projects, events and initiatives, and we will provide top quality support on Apache projects for our customers.

There are many reasons that this acquisition is a great strategic fit, and why SpringSource's existing staff and their new colleagues from Covalent are all thrilled about it. As we merge the two organizations, we're discovering more and more synergies, but here are some of the key points:

• Complementary product mix. As Spring and Tomcat becomes the most popular platform for enterprise Java deployment, combining our leadership of Spring with Covalent's deep expertise in Tomcat and other Apache technologies is uniquely compelling.
• Similar culture and values. SpringSource is a company founded by outstanding technologists, and which has hired more and more throughout its history. Covalent employs outstanding engineers and support staff, including ASF Chairman and Apache HTTPD’s longest running active committer, Jim Jagielski, Apache luminary Bill Rowe, and leading Tomcat developer Filip Hanik, among others. We're all excited about working together, and we can learn from each other. I'm honored to have these guys join our team, and very happy that they are enthusiastic about it.
• Credible open source support. We believe that credible open source support can only be provided by companies making a sustained investment in open source development and employing key committers on supported projects.
• Alignment of business goals. We're excited to have Covalent CEO Mark Brewer and COO Ryan Lindsay joining our executive team. They have a deep understanding of open source business gained through years of experience, and they can help us achieve our shared vision.
• Ability to provide the best possible support. As support becomes more and more important to our business, acquiring Covalent's support infrastructure and expertise will allow us to provide the runtime, production support that Covalent is known for. In turn, our global reach will make it easier to provide 24×7 support for Covalent customers.
• Shared commitment to and proven success in satisfying customers. Covalent enjoys a 95% renewal rate among its subscription customers.
• Open source business is partly about critical mass: the creation of a web of relationships around a central pole. SpringSource + Covalent is now the leading provider of support for the enterprise Java open source that matters most.

What does this mean to SpringSource customers? We will now be able to provide support for Apache projects, including Tomcat, in addition to Spring. One number to call; a broader technology portfolio of projects that matter. The Spring Portfolio will continue its outstanding record of portability between environments. We'll continue to support customers using all middleware platforms, including WebLogic and WebSphere. You'll soon see additional announcements about SpringSource product initiatives for those platforms.

What does this mean to Covalent customers? The great team you rely on is still in place, but now backed by a larger organization, with worldwide reach. We'll continue to offer all of Covalent's products, but you will also benefit from packaged support spanning the Spring Portfolio. The Covalent engineers will continue their active participation in numerous open source projects and their vital contribution to the life of the ASF.

At SpringSource, we are committed to becoming the defining company in open source enterprise Java. We are building for long-term success, not merely short-term objectives. This means that we need to be able to provide our customers with the best expertise in the infrastructure software they need to be successful, and, as open source becomes more and more important to the enterprise, we need to engage with all the open source communities that matter, over the long haul.

We understand the respect the different ways of developing open source software that have grown and sustained communities and produced quality technology. The three most important to our users are the Spring Portfolio approach, the ASF, and the Eclipse Foundation.

SpringSource created and sustains the Spring Portfolio, and we will increasingly engage with the other two communities as part of our strategy of ensuring that we have deep expertise where customers require it. Looking at what matters in enterprise Java, it's clear that, in addition to the Spring Portfolio, Apache projects are vitally important–notably Tomcat, but several more besides. If you want to create a highly scalable web application, you will put Apache HTTP in front of Java middleware. In development, you are most likely using the Eclipse Platform, and perhaps Mylyn. If you're interested in OSGi and the Spring Dynamic Modules for OSGi Project (which just about every one who attends our events seems to be), you are most likely to use the Equinox OSGi runtime, also from the Eclipse Foundation. And since Spring 2.0, AspectJ, another Eclipse project, has been core to the Spring Portfolio in practice.

We're contributing to all those projects. We now employ key ASF members and committers who are involved in multiple ASF projects, including playing a particularly active role in developing Tomcat and Apache HTTP. We employ the most active AspectJ developers, ensuring the future of that project at Eclipse. Through our partnership with Tasktop Technologies to develop the SpringSource Spring Tool Suite, we are contributing code to the Eclipse ecosystem and Mylyn in particular. Recent hire as Distinguished Engineer Glyn Normington is an Equinox committer.

As the Spring Portfolio has broadened over the last year, Spring has become more than the Spring Framework. While Spring is central to our business, our customers' applications, and the future of enterprise Java, SpringSource as a company is about being the leading partner for success with open source enterprise Java, not just about Spring — a partner that will continue our proud track record of leadership and innovation, and offer deep expertise in and commitment to the open source projects that continue to transform the industry.

Comments(0)

One of the central themes behind Spring 2.5 is comprehensive annotation-based configuration. We've been talking and blogging a lot about @Autowired, about Spring MVC's @RequestMapping and also about the new support for annotated tests written with JUnit4 or TestNG. @Autowired is certainly the central one of Spring 2.5's annotations, being available for use in service components, web components, unit tests - even domain objects when using Spring's @Configurable with AspectJ weaving. Spring MVC's @RequestMapping is equally flexible, supporting many variants of handler method signatures.

Today I'd like to take a different focus, namely on the wide-ranging set of dependency injection annotations supported by Spring. The following list includes the key annotations that can be used within Spring 2.5 beans:

• org.springframework.beans.factory.annotation.Required:
  Identifies bean property setters that must be called (as opposed to optional setters). Supported since Spring 2.0.
• org.springframework.beans.factory.annotation.Autowired:
  Spring 2.5's central injection annotation, applying to constructors, config methods and fields. Performs injection of components by type, with supporting for "qualifier" annotations that narrow the potential set of candidates in case of multiple matches.
• javax.annotation.PostConstruct:
  JSR-250's common annotation for what Spring calls "init methods".
• javax.annotation.PreDestroy:
  JSR-250's common annotation for what Spring calls "destroy methods".
• javax.annotation.Resource:
  JSR-250's common annotation for injecting an external component by name. A "resource" in JSR-250 terminology really refers to a middleware component such as a DataSource.
• javax.xml.ws.WebServiceRef:
  @Resource-like, for JAX-WS service lookups, injecting a JAX-WS port proxy.
• javax.ejb.EJB:
  @Resource-like, for EJB Session Bean lookups, injecting an EJB component reference.
• javax.persistence.PersistenceUnit:
  injecting a JPA EntityManagerFactory by persistence unit name. Supported since Spring 2.0.
• javax.persistence.PersistenceContext:
  injecting a JPA EntityManager by persistence unit name. Supported since Spring 2.0.

This set of annotations encompasses all of Java EE 5's common annotations, which means that you may use the same common annotations in e.g. Servlet 2.5 servlets, JSF 1.2 managed beans and Spring managed beans. In other words, if you have some standard JSF 1.2 managed beans with annotation usage, you can take them as-is and move their definitions from faces-config to a Spring application context, without any change in the bean classes! This was an important design goal: Spring 2.5 may serve as straightforward replacement of the standard JSF 1.2 managed bean facility, simply through choosing SpringBeanFacesELResolver as your custom JSF ELResolver.

Configuration-wise, all you need to enable the complete set of annotations above is the following simple configuration element in your Spring application context:

Note that this setting is related to dependency injection only and does not require any parameterization. (For customization, consider defining Spring's individual AnnotationBeanPostProcessors instead, e.g. CommonAnnotationBeanPostProcessor). However, the annotation-config element does not activate any kind of proxying or special exporting. For such purposes, Spring provides more specific configuration elements:

This setting activates processing of transaction annotations, with the following two variants supported out of the box in Spring 2.5:

• org.springframework.transaction.annotation.Transactional:
  Spring's own transaction annotation, as introduced in Spring 1.2. Allows for specifying propagation behavior (REQUIRED, REQUIRES_NEW, etc), read-only flag, custom isolation level (REPEATABLE_READ, SERIALIZABLE, etc) and custom rollback rules on a per-transaction level.
• javax.ejb.TransactionAttribute
  EJB 3.0's transaction annotation. No customization options other than propagation behavior (REQUIRED, REQUIRES_NEW, etc).

Side note: As with all of Spring's support options, the EJB 3.0 TransactionAttribute annotation will only be available if the EJB 3.0 API is actually present in the classpath. Spring automatically adapts to the presence of that API, analogous to the JSR-250 API or the JPA API (as referenced above).

The <tx:annotation-driven> element allows for transaction-specific configuration, e.g. the Spring PlatformTransactionManager to talk to (through the "transaction-manager" attribute) and the mode to operate in:

The explicit AspectJ mode of transaction annotation processing is new in Spring 2.5, allowing to use Spring's AnnotationTransactionAspect instead of traditional AOP proxies. This requires AspectJ compile-time weaving or load-time weaving, modifying the byte code of classes that happen to use the @Transactional annotation. Such weaving allows for supporting the annotation on any kind of method: be it public, protected or private - be it an external call or a call from within the object - the transaction will always kick in as specified by the annotation. This is in sharp contrast to traditional AOP proxies, where annotation-driven transactions are limited to public method calls coming in through the proxy.

If your environment is capable of load-time weaving, then the following configuration is sufficient for enabling AspectJ-style transaction annotation processing. Note that this requires either a runtime environment with built-in weaving support (e.g. WebLogic 10, OC4J 10.1.3.1, Tomcat configured with Spring's TomcatInstrumentableClassLoader) or Spring's VM agent to be specified on JVM startup ("-javaagent:spring-agent.jar").

Finally, Spring 2.5 also provides a convenient configuration element for activating JMX exporting. The default MBeanServer will be autodetected on all common platforms, including the standard Java 5 platform MBeanServer as well as the special MBeanServers exposed by WebLogic 9/10 and WebSphere 6.

Spring-managed beans may then implement standard MBean/MXBean conventions, qualifying as MBean classes according to the JMX specification, or use the following annotations to declare their management signature (as known since Spring 1.2):

• org.springframework.jmx.export.annotation.ManagedResource:
  used at the type level to indicate a JMX-exposed component.
• org.springframework.jmx.export.annotation.ManagedAttribute:
  used at the bean property setter/getter level to indicate an MBean attribute.
• org.springframework.jmx.export.annotation.ManagedOperation:
  used at the public method level to indicate an exporter MBean operation.

This indicates the real power of Spring's annotation configuration model: Different configuration concerns seamlessly merge into a unified whole, with consistent configuration style and unified component lifecycle - it's all still a standard Spring bean underneath, managed by a Spring ApplicationContext!

So much for this brief tour through Spring's core configuration annotations. If you are interested in hearing more about what's new in Spring 2.5 and how it all ties together, let me invite you to this Wednesday's Spring 2.5 webinar where I will be covering all key feature areas in Spring 2.5, ranging from Java 6 support to annotation-based configuration!

Comments(0)

I am glad to report (along side Adrian) that after 3 milestones and 2 release candidates, Spring Dynamic Modules (formerly known as Spring OSGi) 1.0 has been released.

A lot of features have been improved or added since my previous post (about 1.0 M1); I'll talk more about them in future entries (there is also the reference documentation that explains the library at length) so I'll just name a few:

- consistency

We want to provide a powerful, simple and consistent programming model. That's why Spring Dynamic Modules builds on top of Spring and uses its proven concepts, reliability and ubiquity.

- highly non-intrusive nature

The recommended way to use Spring DM is to not use its classes inside your code or have any imports for them inside your bundle manifests. If you are not using Spring inside your code and only for your application configuration, the same rule applies. Spring DM creates the application context for you, so there is no need for you to depend on Spring or Spring DM. And don't worry about things such as custom namespace or XML schemas - we've already covered them.

- OSGi service dynamics life cycle management

This is one of the most important Spring DM features - the ability to interact with OSGi services just as you would with normal beans. You can publish and consume OSGi services without writing any code; we'll deal with the dynamics for you - and you have full control (more about this in the future).

- smarter integration testing framework

Since we used Spring-DM integration testing extensively internally, we improved the defaults, the maven integration and made the automatic manifest generation faster and smarter then before. For example, the framework automatically determines the classes available in the test bundle and will not generated imports for it.

- simple bundle interaction

Andy Piper (blog) added a simple, declaratively way to install/start/stop/update bundles based on the module life cycle and Spring beans dependency.

- managed startup/shutdown context creation

In OSGi applications are broken into various modules (also known as bundles) which rely on each other services. This creates a dependency tree between the module which becomes important during startup and shutdown. Traditionally this can be addressed by installing and starting the bundles based on the dependency order however, this doesn't solve entirely solve the problem. As the OSGi specification recommends, OSGi services that take a long time to initialize (such as connection pools) should rely on a different thread then the one used for starting and stopping the bundle. This means that if a bundle is started, it does not mean its services are. And not every application is ready to wait for its required service during start up - in fact, few do. This means that a bundle will fail since it relied on a service published several milliseconds later (OSGi is, by default, an in-VM platform where things happen really fast).

This behavior is not rare - in fact, it's quite common at startup on multi-core platforms with multiple bundles. Spring DM addresses this problem by determining the dependencies (from the Spring configuration) and waiting for them to become available before creating the application context. A similar process will be used at shutdown, when Spring DM will stop the contexts based on their dependency order so you don't have to worry about starting or stopping your bundles.

- thread-less dependency waiting

I cannot discuss the dependency mechanism without mentioning the 'thread-less' approach used for dependency waiting (sounds a bit like an oxymoron, I know - we're working on a fancy title for it) implemented by Hal Hildebrand (see his blog). Since various services need to be available for a module to properly start some sort of waiting/monitoring is required which traditionally implies using a thread.

However, on an OSGi platform can be (and there will be) multiple modules (several dozens easily) - using a waiting thread per module simply does not scale. One thing which we worked hard on was improve this model and I believe we provided a very nice solution - using no thread at all for the waiting process. This means that no matter if 3 bundles are deployed or 300, no CPU time will be spent unless your modules actually start.

Spring Dynamic Modules is not just about 'spring'-ifying an API but rather dealing with a different runtime environment.

With regard to tooling, Spring IDE supports Spring DM namespaces and (thanks to Christian) also provides Spring-DM specific targets for Eclipse PDE, a features available in Spring IDE nightly builds (more info on installing and using the plug-in is available in the reference documentation).

Future directions

So now that 1.0 has been released, what's next? Plenty of areas to cover:

Web Support

OSGi platforms provides a dedicated Http Service but using it requires coding. Things such as resource loading, JSP generation and deployment can be significantly simplified. This is the main are of focus of the 1.1 release.

Persistence

Modern persistent tools provide advanced features such as lazy-loading which bend the modularity borders enforced by the OSGi environment as they rely on class generation and proxying. We want to address this problem and, just like with web support, provide a smooth experience whether plain JDBC or/and ORM tools are being used.

AOP

Following the persistence problem, we are seeking solutions for doing generic AOP inside OSGi. It's a hard nut to crack and to do it properly, internal OSGi platform support is required. The good news is that projects like Equinox Aspects have already led the way and OSGi Enterprise Expert Group (EEG) have the problem on their radar.

Enough talking

If you want to know more about Spring Dynamic Modules, see the project page and the reference documentation and do use our mailing list (the forum will appear shortly). Moreover, lately we worked on some OSGi/Spring DM screencasts which are available on the Spring DM home page. The first one (composed by two parts), made by yours truly, shows how to quickly create a project to do integration testing with Spring DM.
Why integration testing? Since with Spring DM it's a very simple and fast process and a very effective way to learn about OSGi (especially with regard to modularity).

There will be more screencasts in the future - just let us know what you'd like to see and based on the number of requests, we'll queue them accordingly.

Without further ado, "Using Spring DM for OSGi integration testing":

Comments(0)

Well, it took a lot longer than we initially anticipated, but I'm really pleased to say that the Spring Dynamic Modules project reached its 1.0 milestone today. When I first posted on this topic back in September of 2006 ("Spring OSGi support gaining momentum") the initial specification was just an attachment to an issue against the Spring Framework, and connections to the wider OSGi community were only just beginning to be formed.

Fast forward eighteen months, and Spring Dynamic Modules has become a full-fledged project in the Spring portfolio with committers from SpringSource, BEA, and Oracle. Both BEA and Oracle are using Spring Dynamic Modules to build their own OSGi-based products (see for example "WebLogic Event Server - why we used Spring"), and the Spring Dynamic Modules discussion group has almost 1000 members. The OSGi Alliance itself has formed an Enterprise Expert Group, and SpringSource is an active member.

Whenever we speak about OSGi and Spring Dynamic Modules at conferences, the level of interest is very high. So what's all the fuss about?

The OSGi Service Platform is a proven lightweight runtime that offers a "dynamic module system for Java". It's been used in everything from embedded devices, automotive and telco applications, to the foundation for substantial enterprise middleware products from the likes of IBM, BEA, and Oracle. Spring Dynamic Modules is focused on enabling you to exploit the OSGi Service Platform in the construction of your own enterprise applications. Applications built using Spring Dynamic Modules and running on the OSGi Service Platform are comprised of a set of peer Spring application contexts (one per OSGi bundle) interacting via the OSGi Service Registry. It's a service-oriented architecture, but entirely local within your VM, using regular Java references to access services. The benefits for applications constructed this way include:

• Strong modularity: the internals of each module are kept private, and only the packages and beans (services) that you choose to export outside of the module are publicly available to other modules.
• Dynamic module life cycle: you can install, uninstall, start, stop, and update each module (application context) independently using standard OSGi Service Platform life cycle facilities. Spring Dynamic Modules provides smart management of service references that cross module boundaries so that you can keep working with a constant reference even when the module providing that service is updated in place.
• Support for versioning of modules. It's possible to deploy multiple versions of the same Java packages (and hence libraries) concurrently. The OSGi platform takes care of binding users of those libraries to the appropriate version, and of ensuring that you only see services that implement version-compatible interfaces.
• Operational insight into the installed modules, the services and packages that they import and export, and how the modules are wired together at runtime.

The ability to update a module in-situ while other modules remain up and running can be a real productivity boost during development.

With the 1.0 release we've got a solid solution for module life cycle and service integration. When it comes to using existing (not written to run on OSGi) enterprise libraries on the OSGi Service Platform there are still traps for the unwary relating to class and resource loading and visibility. We believe we've sorted all of these issues for Spring itself in the recently released Spring Framework 2.5. The focus of the next release of Spring Dynamic Modules will be on providing pragmatic solutions for other commonly used enterprise libraries to make it much easier to write Spring-powered web applications that run on OSGi.

Comments(0)

Job listings are a good indicator of the true adoption of technologies. They indicate whether or not companies are spending money, making it possible to distinguish substance from hype; they indicate the importance for developers of gaining and growing the relevant skills (an important element of technology perpetuation); and they provide a good guide to the safety for companies in adopting a particular technology.

Thus the jobtrends site of Indeed.com, a job listing aggregation site, is an important resource. It allows trends in the number of job requirements to be tracked over time, and makes it convenient to compare technologies.

Sometimes these trends can have dramatic implications. Indeed.com shows that in November, 2007, Spring overtook EJB as a skills requirement for Java job listings. As of yesterday, the respective job numbers were 5710 for Spring against 5030 for EJB.

Comparing absolute job numbers, we can see the trend lines and where they cross over:

Given the immense amount of legacy EJB, this is amazing. Presumably, few new projects now use EJB.

The "relative" graph, comparing the respective rates of growth, is even more interesting, showing a stark contrast between the two technologies:

We see that EJB requirements are stagnant or in decline, while Spring requirements are growing at an ever increasing rate.

Of course, Spring and EJB are not mutually exclusive. Using Spring does not prevent you from using EJB, or vice versa. There are cases where EJB provides useful services you might want in an application using Spring. Using any version of EJB without Spring would be to forgo numerous valuable additional capabilities. Indeed, it's largely been the pro-EJB lobby who have (for whatever reason) presented the two technologies as direct competitors.

The overlap between the two technologies is significant and growing, but not at the rate at which Spring requirements are growing:

While it's not an apples-to-apples comparison, it is reasonable to consider Spring and EJB as alternatives for the core component model in enterprise Java applications. And it's clear which is now in the ascendancy.

I must admit to a certain degree of personal satisfaction, given that I've been predicting that EJB would become legacy since early 2003, and arguing that EJB was way overused before that. In J2EE without EJB, I laid out a detailed analysis of the deficiencies of the EJB model and how it failed ot meet its stated goals or the needs of developers and customers. Back then, such statements were highly controversial.

EJB 3.0 improves things somewhat, but it's still too little, too late: the DI capability is less than has proven to be needed for the real world; the interception API recognizes the need for a solution to cross-cutting concerns, but provides the least capable, clunkiest and most error-prone solution yet seen (something I've been meaning to blog on for a while); it's saddled with the baggage of backward compatibility with now irrelevant previous generation technologies; the full EJB contract (which is hundreds of pages longer than the "simplified programming model") dictates a complex runtime with excessive overhead; despite its syntax sugar, it fails to address a number of deficiencies in EJB such as startup actions, singletons and the obsolete threading model. Finally, it's effectively tied to an app server environment, at a time of changing infrastructure.

I could go on and on about these deficiencies, but the job numbers speak of the practical experiences and conclusions of thousands of companies.

Note that I'm talking about session and message beans here; JPA is a separate specification now, is based on modern technology, and is proving its value.

What does the decline of EJB mean to the industry as a whole, and for individual developers?

• The fact that there are plenty of good technical reasons for the decline of EJB is heartening. It's one of many signs that it's harder today to impose solutions that have never been proven in practice than it was when J2EE emerged. This is a Good Thing.
• It's not necessarily a rejection of standards–just a healthy rejection of standards that don't deliver results. As I've long argued, Java EE is more than EJB, and anyone who cares about the platform as a whole should be honest about the relevance and quality of the parts.
• With better technology, business objects become POJOs, dependence on specific component models diminishes and labels become less important.
• Moving away from EJB provides greater architectural flexibility, at a time when requirements are changing, through the rise of SOA and other forces, and companies are increasingly choosing lighter-weight deployment platforms. Although support for various parts of the EJB 3.0 model is available outside a full-blown application server (including in Spring 2.5, which offers the EJB 3.0 DI model in addition to its own, and in Pitchfork, which is used as the basis of WebLogic 10's EJB 3.0 implementation), EJB is a component model fundamentally predicated on deployment to a traditional application server.

Frankly, the EJB era was an aberration. EJB failed to solve the problems of earlier this decade; it's still more inadequate to those of the future. Most of EJB's initial premises are now discredited; the specification's insistence on backward compatibility does not justify the tradeoffs it imposes. Its decline is a natural consequence of moving into a new, more fluid, world, where technologies such as OSGi and the humble Servlet API are proving much more relevant. Of course, as the absolute numbers are still very high, EJB is not going to go away completely any time soon. But the trend lines clearly suggest that it is becoming legacy.

It's timely that this milestone in job requirements occurred just before we announced the SpringSource Spring Certification program. Now that Spring is such an important skill in the market, it's important to both employers and developers that there is a definitive measure for Spring knowledge.

Further proof of Spring's momentum was recently given by statistics on leading industry web sites for 2007. On ServerSide, 2 of the top 5 articles were about Spring, including the top article. On InfoQ, 3 of the top 10 were about Spring, with the top article (my Spring 2.0 Update) getting 4x the page views of the next most popular.

Comments(0)

Spring's dependency injection (DI) mechanism allows configuring beans defined in application context. What if you want to extend the same idea to non-beans? Spring's support for domain object DI utilizes AspectJ weaving to extend DI to any object, even if it is created by, say, a web or an ORM framework. This enables creating domain behavior rich objects, since domain objects can now collaborate with the injected objects. In this blog, I discuss the latest improvements in the Spring framework in this area.

The core idea behind domain object DI is quite simple: An AspectJ-woven aspect selects join points corresponding to creation or deserialization of any object matching certain specification. Advice to those join points inject dependencies into the object being created or deserialized. Of course, the devil is in the details. For example, how do you select join point corresponding to deserialization or how do you inject dependency only once per object? By offering a few pre-written aspects, Spring shields developers from all these details.

Currently, most Spring users use the @Configurable annotation to designate the configurable classes. With latest improvements in upcoming Spring 2.5.2, available starting with nightly build 379, you have a few more options making this feature a lot more powerful. The new improvements follow the "Make simple things simple, complex things possible" principle. Depending on your familiarity with AspectJ and expected design sophistication, one of the options will serve well. Figure 1 shows the new aspect hierarchy that makes a combination of simplicity and flexibility possible.

Figure 1: Inheritance hierarchy for domain object dependency injection aspects.

So what does each of these aspects offer? Let's go bottom up.

Simple things simple: AnnotationBeanConfigurerAspect

AnnotationBeanConfigurerAspect enables domain object DI without any user AspectJ code. Therefore, it is the easiest choice for many developers. With this aspect, you annotate the classes that need dependency injection with the @Configurable annotation. For example, you can have the Order class annotated as follows:

Next, you instruct Spring on how to configure objects of the Order type. The instructions follow the standard bean definition for a prototype bean as follows:

Now upon any Order creation or deserialization, Spring will set the mailSender property of the created object with the externalMailSender bean.

Spring 2.5 features a new annotation-based configuration option that allows eliminating or reducing the attendant XML. The @Configurable annotation-based DI benefits from it as well. For example, you can mark the mailSender property as @Autowired as follows:

You can get rid of even the setter by annotating the field itself, reducing the above code to:

In either case, the attendant XML configuration reduces to the following (note the use of <context:annotation-config/>):

For more details on this domain object DI option, please see Using AspectJ to dependency inject domain objects with Spring.

Complex things possible: AbstractInterfaceDrivenDependencyInjectionAspect

The base aspect of AnnotationBeanConfigurerAspect, AbstractInterfaceDrivenDependencyInjectionAspect, uses an interface instead of annotation to mark a configurable class. While it looks like a rather superficial change, it offers some interesting options such as using domain interfaces and annotations to designate dependency injection, improving performance of injection by bypassing reflection, and utilizing multiple aspects to configure an object.

At the design level, this aspect configures any domain object whose type implements the ConfigurableObject interface. While, having a type implement the ConfigurableObject interface directly is certainly a valid choice, an elegant alternative is to use a declare parents statement in another aspect (a subaspect of AbstractInterfaceDrivenDependencyInjectionAspect would be a logical choice). The statement would declare a configurable class as implementing the ConfigurableObject interface. This keeps your domain classes free from Spring-specific artifacts, while benefiting from the DI mechanism. Let's see an example of such usage.

Consider the Order class from the earlier section. Instead of using the @Configurable, you can let it implement a domain-specific MailSenderClient interface that signifies that it uses a MailSender.

Next you write a subaspect of AbstractInterfaceDrivenDependencyInjectionAspect to inject dependencies into any MailSenderClient objects.

There are two AspectJ constructs used in the aspect:

1. The declare parents statement makes MailSenderClient implement the ConfigurableObject interface, making it eligible for DI through AbstractInterfaceDrivenDependencyInjectionAspect.
2. The inConfigurableBean() selects join points only in the MailSenderClient's subtype, thus restricting aspect's applicability to only the matching types.

The configureBean() method performs injection into the bean by making direct calls to the appropriate setters. Of course, any other logic appropriate for bean configuration such as calling a multi-argument method or calling any initialization methods would work just fine. Note that direct calls used in this way avoid reflection and can yield noticeable performance improvements if the rate of domain object creation is high.

You need to configure the MailClientDependencyInjectionAspect aspect instance itself to inject its dependency–the mailSender property. The Spring way would be to create a bean for the aspect and configure it in application context:

There are a few additional patterns around this aspect:

• Using multiple aspects to configure one object (one per "client" interface, for example).
• Using domain annotation instead of domain interface or the @Configurable annotation to designate a configurable type.
• Using hasmethod()-based type pattern (currently an experimental feature in AspectJ 5 that will become a regular feature in AspectJ 6) to avoid use of DI related types or annotations.
• Using AspectJ-based mixins to provide default implementation for the client interfaces and avoid repeated setters.

However, let's save these ideas for another blog entry.

Flexibility when you need it: AbstractDependencyInjectionAspect

Finally, here is the most flexible base aspect. This aspect requires you to have solid understanding of the AspectJ pointcut language. However, except in extreme customization scenario (such as custom deserialization events), you won't directly create a subaspect of this base aspect. Instead, you will use one of the subaspects we discussed earlier.

The aspect declares six pointcuts that a subaspect may define:

1. beanConstruction(Object bean): Select bean construction. Typical implementation will select object initialization join point.
2. beanDeserialization(Object bean): Select bean deserialization. Typical implementation will select the readResolve() method that must be present in the injected object. If you are using a nonstandard deserialization (that doesn't invoke readResolve()), you would select an appropriate alternative method with this pointcut.
3. inConfigurableBean(): Select join points in bean configurable by the defining aspect. Typical implementation will use a within() pointcut with appropriate type pattern.
4. preConstructionConfiguration(): Select join points for beans that need dependencies injected prior to construction. The default implementation of this pointcut select no join point (beans will have dependencies injected after the constructor has run).
5. mostSpecificSubTypeConstruction(): Select join points corresponding to the most specific subtype. Default implementation uses join point signature to determine if the constructor represents the most specific in a type hierarchy of the bean being injected. This information is then used in conjunction with the preConstructionConfiguration() pointcut to use a before or after advice for injecting dependencies.
6. leastSpecificSuperTypeConstruction(): Select join points corresponding to the least specific supertype.

This aspect also defines an abstract method configureBean(Object bean), whose implementation should specify the logic corresponding to dependency injection.

So there you have all options to enable domain object DI in your application. If you are into DDD or otherwise need DI extended to your domain objects, you have to look at these new set of aspects. Depending on your specific needs and AspectJ knowledge, you will find one of them helpful towards creating an elegant solution.

Comments(0)

Comments(0)

Comments(0)

Comments(0)

Comments(0)

Since I joined SpringSource six months ago as the Director of Training, I have been hearing one consistent request. Based on the growing demand for Spring skills, developers and consultants worldwide are seeking quantifiable ways to demonstrate their Spring expertise. Likewise, the hiring managers behind that demand are asking for a certification program to help identify and hire technologists who have an immediately useful, baseline knowledge of Spring.

Much like the way the Spring project teams respond to the needs of the open source community, we have responded and are pleased to announce the SpringSource Certification Program. This program kicks off this month, January 2008, with the Spring Framework Professional certification.

To become a certified Spring Framework Professional, you must successfully complete a certification exam. A person is eligible to take the certification exam if that person has recently attended the Four Day Core Spring course, is a significant contributor within the Spring community, or can provide a reference to a Spring development effort in which he or she was actively involved. The Spring Framework Professional certification is granted on successful completion of the exam.

To learn more about the SpringSource Certification Program, please attend the short webinar at noon (EST) on 23 January 2008. You can also visit the website at http://www.springsource.com/certification or contact a SpringSource certification coordinator at certification@springsource.com.

Comments(0)

Comments(0)