Soul Power

A JAXB (or rather XJC) odyssey

2011-03-23T11:24:25Z

Working on a customer project the last couple of weeks we decided to use JAXB to unmarshal incoming XML data into Java objects. As that undertaking has caused me quite some trouble I complained on Twitter and received some questions https://twitter.com/bdoughan/status/50183691481268224 comments. As 140 characters are not really able to communicate the issues in detail, I though I’d drop a blog post to explain the issues I experienced and the workarounds I took or rather had to take. If there’s anything I oversaw I’d be happy to know :).

Collection wrapper madness

It all starts with an XSD document that is given to a large degree, which means it’s not entirely set in stone but I actually don’t want to touch it just to adhere it to the marshalling technology. I had quite good experience with JAXB in other projects we started using it here as well. The unmarshalled objects should be mapped onto our domain objects using Dozer. Here we stumbled above the first issue already. If you have an XML structure that looks like this:

XJC inevitably generates a Elements wrapper class in the containing element class to contain nothing but the list. So to add an element to the outer element you’ve got to write following:

outer.getElements().getElement().add(new Element());

Concise is different. Even worse, now try mapping this to a domain model that just looks like this:

public class Outer {
  private List elements;
}

Of course you can configure Dozer to map outer.elements.element from the JAXB classes to outer.elements in the domain model. This unfortunately fails on the way back, as Dozer cant traverse outer.elements as elements field is null (as it’s lazily initialized). This issue is probably caused by Dozer as much as by the class structure generated by XJC. But the bottom line is that you’d have to write custom Dozer converters for each and every wrapped collection generated by JAXB. The funny thing here is that there is a JAXB annotation @XmlElementWrapperthat allows getting rid of the wrapper class (which would solve quite a few issues listed here). Ironically there’s no way to configure XJC to generate that except this plugin which in turn is not available in any Maven Repository out there.

If it’s not in a Maven repository, it doesn’t exist

In the REST community there’s a proverb saying “If you can’t link to it, it doesn’t exist”. Bringing that into Java Open Source software it’s

“If it’s not available in a Maven repository, it doesn’t exist”

or the more strict version

“If it’s not in Maven central, it doesn’t exist”

. Anyway…

JavaBean spec? Who cares…

Requirements changed a little and we decided to persist the JAXB generated classes directly. We had chosen a Spring Data Mongo based backend which can persist plain Java objects into JSON documents and in turn pipe ‘em into a Mongo database. The only requirement is that the classes align to the JavaBean spec by default. Of course Spring Data Mongo has mapping facilities via annotations but as the classes persisted are generated ones, I can’t or don’t want to touch them. Now guess what? XJC does not generate valid JavaBeans by default. It generates Boolean isFoo() although the JavaBean spec says the is prefix is only allowed for primitive booleans (thanks to Thomas Einwaller for pointing me to this). Sidenote: java.beans.Inspector thus does not consider the isFo()o method as valid read method in the PropertyDescriptor instances returned. Nevertheless you can manually instantiate a PropertyDescriptor that the in turn contains the isFoo() method as read method. Consistency? See more on that in the ticket I filed against Spring as we're using it's bean introspection mechanism that could mitigate this inconsistency.

This time there's no need use an XJC plugin to get this working as XJC. It simply supports a -enableIntrospection flag that you can pipe to XJC to let it generate spec compliant Boolean getFoo() methods for the Boolean properties. Generally I rather think the spec is broken here as from a beans model perspective it shouldn't make a difference whether I am using boolean or Boolean. Regarding XJC I am not sure if I am the only one who raises his eyebrow using a flag on a software that effectively says "Please do it right".

Subtleties

Something not entirely related to the JavaBean spec but close enough to mention it here is that XJC generates inconsistent field accessor pairs regarding naming. In the XML we had an element similar to FOOBar. The class containing a field now looks something like this:

public class Outer {
  private FOOBar fooBar;

  public FOOBar getFOOBar() {

  }
}

Notice the difference? For the field the first part is lowercased entirely, whereas the method name takes the element name as is. Crucial thing here is that you can't really apply the "get-plus-uppercase-first-letter-plus-rest" heuristics to find the getter for a field or vice versa. This especially becomes important if you want to use field injection for properties. Once again, there's a plugin to fix that (do you really want to use software that uses plugins to fix bugs?), which unfortunately is not available via a Maven repository. So finally we renamed the element to FooBar to get this working. No problem in general but I generally don't like the fact that my model (however questionable the naming structure might be here) has to be tweaked just to get the technology work right.

JAXB2 Commons
There are a few really great XJC plugins flying around that allow generating copy constructors, equals(…) and hashCode(…) methods and the like. Unfortunately googling them is quite a pain as the most popular result, the official Oracle page contains mostly dead links (try everything but the JAXB2 Basic) plugin.

Summary
Maybe I am a bit spoilt but this odyssey leaves me with the impression that esp. XJC is a kludgy piece of software that only works correctly or well enough to be usable if you use quite a handful of plugins. As a lot of them are not available in Maven repositories the average Maven user (which I don't consider to be an exotic thing nowadays) can't use - at least not effectively. This impression was completely contradicting my previous experiences with JAXB, although I have to admit that these former projects rather used the annotations directly and not XJC. So it seems it's rather XJC that needs some serious polishing. Is there a JSR for JAXB 3, already? ;)

Spring, logging and JMX

2010-10-01T14:02:55Z

Pretty much every application out in the wild is using logging to some extend. As applications tend to have bugs (yes, yours as well) it’s a common requirement to alter log levels at runtime. As JMX (Java Management Extensions) is a standard to monitor and manage applications it seems to be a reasonable approach to expose the loggers used in an application via JMX to allow tuning of log levels via a JMX client like jconsole. So let’s take a look on how you enable JMX with Spring

<context:mbean-server /> <context:mbean-export />

The first element from the context namespace sets up a JMX server so that MBeans can be registered. The second element activates automatic export of all Spring beans the either leverage Spring JMX support (annotation based) or Spring beans that satisfy the JMX naming scheme (a class implementing an interface named ${classname}MBean). Fortunately Log4J ships with a LoggerDynamicMBean that exports a Logger instance to the JMX infrastructure. It’s API is not really built with dependency injection in mind but due to the flexibility of the Spring XML configuration language we could register this MBean as follows:

Running this in combination with the XML snippet above now exposes the logger for org.springframework.jmx as JMX MBean.

XML Hell? Go make it clear and nice!

Declaring the MBean for a single logger requires quite an amount of XML and is boilerplate to a large degree. The two things that are unique in this case is that we want to expose a Log4J logger and the logger name of org.springframework.jmx. So what if we could expose the logger with something like this:

<jmx:logger type="Log4J"
  name="org.springframework.jmx" />

We can! I’ve created a small sample project project containing a custom JMX namespace and put it up on Github. The README file contains instructions how to play around with the Sample class, altering the log level via jconsole and see results in the console output. Right now it’s pretty much just a proof of concept and could be improved in a few corners. We should support other logging libraries and we could transparently register and whcih is not the case currently. Feel free to suggest or add extensions!

Enabling Hibernate criteria query statistics with AspectJ

2011-03-23T11:23:27Z

In the #java.de IRC channel someone pointed me to this request for enhancement in Hibernate recently. The bottom line here is that Hibernate’s statistics feature that can be used to capture persistence metrics (information about query executions and execution times and so on) does not include queries triggered through using the criteria API.

This is quite a a reasonable request for enhancement in my opinion and it’s quite surprising that the ticket has been open for over 2 years now, especially as the solution seems to be simply adding a method to CriteriaLoader class, as Chuck May points out. So supposed you want to use tis feature now. The only option seems to be patching Hibernate (sort of doable), building it (a huge magnitude more complex – no offense, building Spring is not trivial either) and the use and maintain that patched version over further releases. Isn’t there another way to get that feature into Hibernate? Of course there is… AspectJ.

As the fix seems to be simply adding a method to an existing class we can leverage AspectJ inter-type declarations to add this special method from the outside. Here’s the aspect code:

public privileged aspect CriteriaStatisticsAspect {
  public String CriteriaLoader.getQueryIdentifier() {
    return "[CRITERIA] " + getSQLString();
  }
}

It’s pretty easy to understand I think as the method declaration only slightly differs from a normal Java one (no pun intended). You actually only have to explicitly mention the type you want to add the method to. To weave this aspect into Hibernate you simply add the Maven AspectJ plugin to your pom.xml and tell it to consider the Hibernate JARs too by adding a weaveDependencies block to the configuration section of the plugin.

To ease the burden of getting started with this approach I have uploaded the sample code to Github, also containing a test case to demonstrate this actually works. Upgrading to another Hibernate versions should work seamlessly as the aspect gets woven into the never version then. As soon as the feature gets actually implemented (let’s hope it won’t take another two years ;) simply throw away the aspect.

Conference autumn 2010

2010-09-10T12:37:21Z

As summer’s fading out more or less, it’s time to take a look at upcoming times. Autumn is usually quite packed with conferences and this seems to continue this year.

I’ll kick off my conference autumn by speaking at WebAppDays in Düsseldorf (Sept. 27th/28th) presenting Roo as rapid java application development framework as well as giving an overview about tcServer, the SpringSource commercial edition of Tomcat. To not make this a marketing talk entirely, I will concentrate on how developers can benefit from tcServer usage during development and in production.

Next stop for me the is GearConf, Düsseldorf (Oct. 11th/12th), a conference dedicated to the more soft topics of software development like processes and teams. This year I’ll be talking about Mylyn and how it can help developers to be more productive and ease context switches.

If you register quickly there’s still the chance to get discount for both of these conferences. As they are rather small ones, it’s quite intensive as hallroom conversations take place pretty much everytime and everywhere so that the knowledge exchange rate is typically quite high.

The main event this autum of course is Devoxx 2010, Antwerp. Personally I’ll be holding the Mylyn talk there but there’s a ton of other speakers and talks to check out. As SpringSource is also official sponsor of the app a lot of my colleagues will also speak there, e.g Jürgen Höller on Spring 3.1, Ben Alex on Roo, Christian Dupuis on tooling for Spring and Grails.

Right in between those events I will promote upcoming Hades 2.0 release at JUG Cologne Nov. 8th. Chances are high that we have published the release then already. I am currently speaking to a few other JUGs as well, so you can be sure Hades will be near your place, too. :)

Anyway, I’m really looking forward to these events. Hope to see a lot of familiar faces and hopefully also some new ones (chances are not bad). Feel free to get in touch and let’s have a beer (malt for me, whatever you like for you :)

DDD Specifications with Hades

2010-07-15T23:03:46Z

Two weeks ago, I attended Java Forum Stuttgart, a really nice one-day conference to hear interesting talks, meet fellow developers and colleagues. The first talk I attended was held by Adrian Hummel and Mischa Kölliker entitled Rich domain model with JPA 2.0. As I am currently working on the final features for Hades 2.0 which will be based on JPA 2.0, I was eager to see what they were about to present.

One part of their talk was dealing with the specifications concept of the Domain Driven Design book by Eric Evans. Specifications are an abstraction over a statement or requirement you can formulate for an entity. Each of the specifications you can define evaluates to a boolean, so it can be regarded as predicate over the entity. The example Adrian gave in his talk (and also in a blogpost he dropped a few days later) is a soccer player, who can be characterized as “fair player” or as “bonus eligible”.

JPA 2.0 introduces a criteria API, that effectively allows to define queries via a more or less typesafe API. So the typical code you write using this API looks as follows (code originally coined by Adrian):

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Player> q = cb.createQuery(Player.class);
Root<Player> player = q.from(Player.class);

q.where(/** Build your where clause here **/);

return em.createQuery(q).getResultList();

As you see there’s a few lines of boilerplate code that works with the domain class. The part that actually varies from query to query is the where clause you hand to the q.where(…) method. What Adrian and Mischa now proposed is introducing a Specification<T> interface that simply provides a callback method that gets the CriteriaBuilder, CriteriaQuery<T> and Root<T> and reduces that to a JPA Predicate which can be handed to the q.where(…) method then (code originally coined by Adrian):

public interface Specification<T> {

 Predicate toPredicate(CriteriaBuilder cb,
   CriteryQuery<T> q, Root<T> root);
}

Specifications in Hades

To make this available in Hades we simpy add a method readAll(Specification<T> spec) to GenericDao interface and GenericJpaDao implementation and implement it as follows:

public List<T> readAll(Specification<T> spec) {
  CriteriaBuilder cb = em.getCriteriaBuilder();
  CriteriaQuery<T> q = cb.createQuery(getDomainClass());
  Root<T> player = q.from(getDomainClass());

  q.where(spec.toPredicate(cb, q, root);

  return em.createQuery(q).getResultList();
}

So what this gains you is a possibility to simply add new Specification implementations and thus “extend” the DAO without the need to add finders e.g.

One more thing

The really cool part about the Specifications is, that – as you can concatenate JPA Predicates with and and or – you can do this with some minor effort on the Specifications, too. I added a small class that provides some syntactical sugar to make something like this possible:

playerDao.readBySpecification(
  where(isFair()).and(isEligibleForBonus()));

This probably needs some explaination. First, isFair() and isEligibleForBonus() are static methods on a (for example) PlayerSpecifications class that return a Specification instance creating the JPA Predicate instance. The where(…) method is also a static one on a helper class that pretty much returns itself, implements Specification in turn and and provides the concatenation methods to chain Specifications and build new Specifications on the fly. Thus you can easily implement atomic predicates for the entity and build more complex expression from it – a really cool complement to the finder methods already available in Hades. The feature will be available in upcoming RC3 of Hades 2.0 and can already be used with the current snapshots.

A big thank you to Adrian and Mischa for a huge part of this new feature =).

Hades – standing on the shoulders of giants

2010-07-01T18:56:02Z

In the last few days I have been working on a feature request of Hades that has been after me for quite a long time. Hades has always had built in support for auditing entities, which means it captured the current user of the application and set it as the creator or modifier on the entity whenever you called save on a Hades DAO. This is based on AOP, has always been a nice showcase of AOP applied, hopefully served a few users quite well. So far so good. Unfortunately the way it was implemented had two serious drawbacks:

It only works if you call MyDao.save(…) explicitly
It only works for the root entity you persist, not transitive ones.

These drawbacks have caused Will Jaynes to open up a ticket over a year ago already and I have been thinking about that issue from time to time, sometimes more deeply, sometimes just remembered it was still open. Finally I came up with a solution that not only fixes the two points mentioned above but also acts as a quite nice example of how powerful Spring as a toolbox can be, especially for framework or library developers. Here’s the story…

The right tool for the job

Actually, implementing auditing with AOP was not the right choice in the first place. Well, it’s not that AOP in general is the wrong hammer for this nail but rather how we applied it. Auditing based on a pointcut targeting a repository method is plain wrong if we deal with OR mappers, period. So I do not consider myself extraordinarily stupid so you and I might wonder what took me down that road.

Entity listeners

The core abstraction for reacting on lifecycle events for entities in JPA are so called entity listeners. You can either annotate the entity itself with annotations like @PrePersist or @PreUpdate or use a dedicated class with annotated methods in case you want to implement common hooks you might want to apply to a common set of classes. You activate those entity listeners by either annotating the entity with @EntityListeners or configure them in your orm.xml. The reason they never seemed suitable for me is that they get instantiated by the JPA provider and thus – by default – lack any means of injecting dependencies into them (the AuditorAware instance knowing who is the current user in our case).

@Configurable

Fortunately Spring offers injecting dependencies into classes created with new by adding an @Configurable to the class to be instantiated. You simply have to get a Spring aspect woven into that class then and activate in your apps XML config and Spring will intercept the instantiation of that class and either autowire dependencies or use a blueprint prototype bean to determine what has to be wired how. (For details see a former blogpost or the reference documentation.)

So let’s recap what we have here: I let the aspect be compiled into my AuditingEntityListener and activate as well as a prototype bean of the listener getting a StubAuditorAware injected in my integration tests config file. Hm, doesn’t work… What’s wrong? Here’s the critical part of the reference doc.

Instances of @Configurable objects created before the aspect has been configured will result in a warning being issued to the log and no configuration of the object taking place. An example might be a bean in the Spring configuration that creates domain objects when it is initialized by Spring. In this case you can use the depends-on bean attribute to manually specify that the bean depends on the configuration aspect.

Okay, it seems the aspect is not yet active when my LocalContainerEntityManagerFactoryBean gets instantiated which in turn instantiates my entity listener. The docs recommend (no pun intended) to emphasize the order of the beans by adding a depends-on attribute to the bean that manually instantiates objects (the EntityManagerFactoryBean in our case). First: what bean to depend on since spring-configured has no id. Ah, it turns out Spring registers the aspect under org.springframework.context.config.internalBeanConfigurerAspect. So I’d essentially need something like this to make sure the EntityManagerFactory already sees the DI aspect:

Well, wait… of course I could document that this was necessary but that would bloat Hades user’s infrastructure configuration, expose Spring internal bean names and make things unnecessary complex.

Spring container hooks – BeanFactoryPostProcessor

Okay, so what we essentially need to do is transparently add a depends-on="org.springframework.context.config.internalBeanConfigurerAspect" to the chosen EntityManagerFactoryBean bean definition. Fortunately we can do this programatically by using one of the Spring container hooks, the BeanFactoryPostProcessor. So I simply implemented a AuditingBeanFactoryPostProcessor that transparently adds the (additional) depends-on to bean definitions that create an EntityManagerFactory. So the benefit here is that we can leave other user defined beans untouched. Let’s take a look on what we have to configure on the Spring side to get things up and running:

As you can see, there’s a lot of boilerplate XML config here. The only thing really custom is the delaration of the MyAuditorAwareImpl. Now guess what? There’s some Spring for that…

Spring namespaces

As you probably already know (as you might have used Hades already) Spring supports the implementation of custom XML namespaces since 2.5. We already implemented the dao-config element in the Hades namespace so why not add one to activate auditing? So here’s what we end up with:

Quite neat, isn’t it? So let’s summarize what we have gained from the plain auditing feature view:

We get transparent auditing on all JPA managed entities, whether they are the root entity or a transitive one.
No need to call MyDao.save(…) to trigger auditing.

Nice, feature completed ;). Now let’s take another step back an reflect what brought us there:

Spring’s ability to inject dependencies into objects instantiated with new through @Configurable and AOP.
Prevented custom configuration spread around into other beans thorugh Spring’s BeanFactoryPostProcessor container hook.
Reduced the amount of configuration required through a custom namespace to hand an expressive concise configuration language (in our case in form of a single XML element ;) to the user instead of a generic verbose one.

Enough praising here, enjoy auditing with Hades! =)

P.S.: In case you want to take a glance at the sources checkout the commits I’ve done for the feature request.

Hades 2.0.0.RC2 introduces transactional DAOs

2010-06-22T19:11:24Z

Our latest Hades release of the 2.0 branch is introducing transactionality of DAO instances as main new feature. Of course you can read up the reference documentation for some general guidelines but I want to use the chance to give a more detailed look into why we introduce this and how some details work.

These days, some kind of back-to-the-basics approach regarding architecture layering is widely accepted as best practices. Thus you don’t want to introduce a layer just because of some merely technical needs. A typical candidate layer for being obsolete is the service layer. Especially in web applications where you pretty much store entities that are equipped with rich behavior themselves the service layer is quite an artificial one that only demarcates transactions but then delegates to the underlying data access layer. Using Hades in such an application you had needed the additional transaction demarcation somewhere as it didn’t deal with transactions itself out of the box. So the only option to get rid of a service layer was to use e.g. @Transactional at a Spring MVC controller e.g. which is rather a sub-optimal solution.

So actually we were quite reluctant to the idea of applying transactions to Hades DAO instances as there were some crucial points to consider:

Actually a DAO layer might not be at the right level of abstraction. Usually you define transactions on a more business related method than a plain save(…) or findByUsername(…). So if we enable transactions at DAO methods we have to make sure that they seamlessly can be expanded to more coarse grained methods and the DAOs take part in those transactions.
If we apply transactions we don’t want to imply our transaction model to the user’s application. As Spring provides various means to define transactions, we don’t want to take that decision from the developer. So in case she wants to decide for a particular model, she has to be able to do so, no matter what we chose.
Although the transactional behavior that we define for CRUD methods might be okay for 90% of the use cases there has to be a way to override the defaults and replace them by some custom one.
As Spring 3.0 supports multiple transaction managers via @Transactional we have to make sure we participate in the right transaction depending on in which context the DAO is used.
It has to be easy to define transaction configuration for DAO interfaces containing the finder methods.

We decided to use @Transactional annotations at the GenericJpaDao implementation class and activate annotation based transactions for the proxies explicitly through the GenericDaoFactoryBean. This means that the CRUD operations of the DAO instances will be transactional if called standalone or participate in a transaction in case there’s already one running for the current transaction manager (read up details on multiple transaction managers here). So it doesn’t matter if you declare your transactional boundaries via @Transactional, too, or use e.g. XML configuration or even TransactionTemplate. This gets us solutions for issues 1 and 2.

Issue 5 is quite easy to solve as you can simply annotate the finder methods of your DAO interface (or the interface itself) with @Transactional and transactions get applied as you are used to with Spring.

The actual tricky part is issue 3. The main idea here is to simply redeclare the CRUD method originally declared in GenericDao inside your concrete DAO interface and reconfigure transactions as you like. So supposed you want to get rid of the readOnly flag at readByPrimaryKey(…) set to true (as we chose to default the transaction configuration to, as this applies some performance optimizations on the persistence provider as well as the JDBC driver), you can do this as follows:

public interface UserDao extends GenericDao<User, Long> {

  @Override
  @Transactional
  User readByPrimaryKey(Long key);
}

Getting this to work needs some reflection magic as we of course still have to delegate the call to that method to the GenericJpaDao instance but according to the Java Reflection API it of course does only implement GenericDao.readByPrimaryKey(…) and not UserDao.readByPrimaryKey(…). Long story short, we can find out the method that has to be invoked so we can hand this reconfiguration model to the user and gain much flexibility on this side.

Issue 4 is not that interesting as we simply have to configure our internal TransactionInterceptor to lookup the appropriate PlatformTransactionManager instance in a lazy-loading-like fashion but that all happens under the covers and you don’t need to take care of this.

So let me quickly summarize what 2.0.0.RC2 brings you in regard of transactions:

Transactional CRUD methods (everything declared in GenericDao) with appropriate defaults (readOnly flag set to true on read-only methods) that automatically take part in more coarse grained transactions if necessary
The ability to use @Transactional for your concrete DAO interfaces
The ability to reconfigure the transactional behavior of the CRUD methods by simply redeclaring a method inside the concrete DAO interface

Changing a project’s artifact id in Sonar

2010-06-02T15:57:07Z

Sonar is a great tool to take care of code quality in your software projects. I use it heavily to monitor the open source projects I am involved with. When working on getting Hades published into Maven central I had to polish it’s pom.xml and felt the need to align the parent project’s artifact to our chosen OSGi compatible package notation for artifacts. So prior to releasing it to Maven central I changed the artifact id from hades-parent to org.synyx.hades.parent. Everything fine until I pushed the metrics of the 1.5.1 release into Sonar.

Sonar created a new project, as it cannot know about my refactoring. So what to do? I spoke to Simon Brandhof and apparently there’s no feature in Sonar to change the artifact id via the user interface. So I opened a JIRA issue for it, feel free to vote for it if you like. Meanwhile we could achieve this by manually altering the kee column inside the PROJECTS table. It contains entries of the form ${groupId}:${artifactId}(:${branchName}) for entries of type PRJ (i guess that stands for project. Altering these entries solved the problem.

Thanks to Simon and Verschdl for help!

Upgrade you Roo addons to 1.1.0

2010-06-02T15:58:21Z

Spring Roo 1.1.0 will be based on OSGi and Apache Felix in particular as runtime platform. This of course will affect the already existing addons developed for Roo. The core ones are of course updated by the Spring Roo team but in case you have developed a custom one the steps needed to be taken are not really obvious. However, I took some time studying the core addons and here’s a step by step guide that takes you from a 1.0.x addon to a 1.1.0 one:

Make sure, your project version is a valid OSGi vesionDefault Maven version scheme is invalid for SNAPSHOT versions as the 3rd part of the version has to be purely numeric in OSGi. In case you ignore this, you won’t get the bundle deployed into the Roo OSGi runtime. So you have to stick to something like 0.1.0.BUILD-SNAPSHOT
Change packaging of your project to bundleAs your plugin will result in an OSGi bundle you need to change the packaging from simple jar to bundle. This will cause the Maven bundle plugin creating the necessary metadata for you out of the box.
Change the type of the dependencies to bundleSimilar to the point above you need to reference dependencies as bundles. Again, to let the Maven bundle plugin do its job.
Sync build section of your pom with the one provided in the addon templateWe had to do some changes to them pom.xml created for artifacts so you will need to catch up with them. This is mostly related to the Maven bundle plugin as well as the Maven SCR plugin (see next point for details).
```
project --topLevelPackage com.mycompany.myproject.roo.addon \
  --template ROO_ADDON_SIMPLE
```
The easiest way to do so is simply creating a dummy addon project using the template and copy the plugin configuration into your pom.
Replace @ScopeDevelopment annotations with @Component and @ServiceRoo uses Apache Felix as OSGi runtime and thus uses @Component and @Service annotations in combination with the Maven SCR plugin (for details see Maven SCR plugin documentation) to create descriptors for the OSGi declarative services infrastructure.
```
@Service
@Component
public class MyCommands implements CommandMarker {

  @Reference MyOperations operations;

  // Your code goes here
}
```
So every @ScopeDevelopment annotation you used at your command and operations classes has to be replaced by @Service and @Component. If you had injected other services into your command or operations class you can use @Reference to wire that into your component instance. Note, that your class will have to implement at least one interface Felix can publish the component instance under. As there might be further tweaks necessary, have a closer look at the output the Maven SCR plugin generates. It will log errors in case you still need to change something.

The unknown 2nd Spring triangle

2010-05-09T16:45:54Z

When skimming through Spring presentations explaining the building blocks of the framework you’ll often find a so called Spring triangle consisting of the following 3 parts:

Dependency Injection
Aspect Oriented Programming
Portable Service Abstraction

These 3 principles surround a plain POJO programming model and enable Spring to achieve what it is famous for. Portable and maintainable Java software. Having that said, there is another triangle in my opinion that is touches developers even more when working with Spring. This triangle captures the way Spring can be configured, thus used and – to a larger extend – introduced into a project. But first things first, here’s what I am talking about.

XML configuration
Annotation configuration
Programmatic usage

Especially choosing between the first two approaches to configuration are an often discussed topic. To be honest, I don’t think a Spring project will fail because of this issue. There a few guidelines one can use to decide on that topic but I don’t want to go into that in detail in this post. Let’s take a look at the three styles of usage from a more general perspective and how they enable usage of Spring itself.

XML configuration

This way of using Spring is probably a well known way to users that have worked with Spring for a long period of time already. Admittedly, this approach has several downsides (e.g. verbosity of configuration) but also results in some kind of application blueprint you can gain information about how a module is structured at a quick glance.

Annotation configuration

This style of configuration is gaining more and more of traction these days. Spring’s support for annotations is set up broadly since 2.5. 3.0 extends that support furthermore by supporting standardized annotations for dependency injection like @Inject. Besides that Spring comes up with an annotation configuration style called JavaConfig, where you write dedicated configuration classes and annotate them to define configuration metadata. This solves the problem of configuration of 3rd party classes that you cannot annotate directly anymore (e.g. DataSources etc.) that plain annotation config does not offer a solution for.

Both styles of configuration (XML and annotations) leverage the usage of Spring as framework, defining application and infrastructure components that are managed by Spring at runtime. Besides that there is a 3rd option that is often neglected but a helpful one in certain scenarios.

Programmatic usage of Spring

As all Spring abstractions (transactions, persistence etc.) are programmatically usable, which means you can simply drop the appropriate JAR into your classpath and use the classes as is using Spring as library instead of as framework then. As they are written to support dependency injection the usage of the huge simplyfication of JDBC e.g. can be used by instantiating JdbcTemplate, handing it a DataSource and off you go.

Why do I mention that

First thing is, that contrary to popular believe using Spring does not mean huge XML config files or even starting with the introduction of Dependency Injection into your application. You can use declarative transactions by simply using the AOP and transaction API programatically in your already existing factory classes e.g. You can simplify your existing JDBC code hugely by using JdbcTemplate without bothering with AOP or Dependency Injection at all. Thus there are many possible ways to adopt Spring with your application, it is no “one size has to fit all” approach but rather enables you as developer to make a decision that suits your problem at hand.

There is no silver bullet, more power to the developer!

Second, the 2nd triangle is the actual means to allow exactly what I just described above. It enables developers to use each part of the first triangle and makes Spring the Swiss knife of application frameworks. So why choosing an axe instead? ;)