I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.

Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.

Modules larger than classes with OSGI

Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.

Impact of OSGI on the development process

Let me stress out here how important it is to be able to develop, manage and deploy such modules. The larger your system, the more developers your project involves, the longer you maintain it – you will always face the same problem: Developers concurrently working with party of the system that are directly or transitively connected will run into conflicts. You will have different parts of your system requiring different versions of the same library on the same class path. Changing one part of the system will always affect other parts of the system, most of the times in an unplanned fashion.

Test driven developments helps a lot along the way, but you still have a responsibility problem if there’s one team changing something and this causes a problem in a different part of the system, and dependency issues can be a real mess.

This is where OSGI can play out it’s strengths. Not only does it offer you complete, classloader-based module isolation. I believe the greatest benefit lies in the development process: Concurrent development is a lot easier with OSGI bundles than with a huge pile of tightly interconnected classes. You can have a lot of changes in the bundle, while exposing a relatively stable interface through which other components access your bundle’s services. Separation into OSGI bundles can bring the power of the SOA-Idea into “stand-alone” applications, without the massive overhead of connecting systems or components through, for example web services.

Of course, this concept has quite an impact on your way of thinking, since you will start to add a new level of decomposition: Which classes form tightly coupled components that could be isolated from other components and used as a service through a well-defined, slim and easy-to-use interface?

OSGI about to “break through”

Now, why am i so convinced that OSGI is about to finally become as common as using AOP or dependency injection? Because all the popular technologies are just about to embrace OSGI:

• Craig walls (Spring framework) has just finished his book an modular JAVA with the spring framework, featuring OSGI and Spring, a very powerful combination.
• Doug Clarke and Shaun Smith will hold a presentation on persistence and OSGI with eclipselink (the reference implementation of the JAVA persistence API (JPA)), thus suitable persistence mechanisms for this level of modularization are likely to be close at hand.

And if you look at the schedule for the JAX, Europe’s most important software & development conference, there have never been more OSGI topics featured – at least I would doubt that.

In other words: OSGI will soon be so smoothly integrated with you favorite frameworks, IDE’s and API’s that using it will be a breeze – and a must, if you want to take the quality of your development process and software to the next level.

This is, however, a misunderstanding. mvnDebug is there to enable debugging of the maven process and not of the surefire execution – and disabling forking may have various side effects. One of those is the use of Java agents. When using agents, e.g. for loadtime-weaving in the Spring Framework, one often specifies a -javaagent: as a JVM argument for surefire:

<!-- See http://maven.apache.org/plugins/maven-surefire-plugin/ -->
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<!--
			The following must be within one line of code, line breaks will
			cause surefire execution to fail.
		-->
		<argLine>-javaagent:/path/to/myagent.jar</argLine>
	</configuration>

Java agents however must be provided as an argument to the JVM when it starts – which is exactly what happens when surefire “forks”.
Thus: No forking, no agents, since the tests will be executed in the current jvm used to execute maven itself – and that one was not started with a -javaagent argument. In order to execute surefire tests and use agents, the forkMode must at least be “once” (-DforkMode=once).

Thus, leave the forking as it is, and enable remote debugging as described in the surefire plug-in documentation, i.e. without using mvnDebug:


mvn test -Dmaven.surefire.debug


Which will open a remote debugging port at localhost:5005 for the test execution – and use the agents.

2008-07-12: Comment: It is indeed a lot simpler using spring-security, as Craig Walls demonstrates in this posting in his blog “Spring-Loaded”).

In order to activate the post processing for the @Secured annotations, a spring configuration such as the following is required:

    <!-- Bean post-processor for activating any advisors -->
    <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>

    <!-- The advisor that creates secured proxies for beans using security annotations such as @Secured -->
    <bean class="org.acegisecurity.intercept.method.aopalliance.MethodDefinitionSourceAdvisor">
        <constructor-arg>
            <ref bean="myMethodInterceptor"/>
        </constructor-arg>
    </bean>

Where myMethodInterceptor is a MethodSecurityInterceptor, which may be configured like this:

    <bean id="myMethodInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
        <property name="validateConfigAttributes" value="false"/>
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="accessDecisionManager"/>
        <property name="objectDefinitionSource" ref="objectDefinitionSource"/>
    </bean>

With a suitable AuthenticationManager, AccessDescisionManager and and objectDefinitionSource of type MethodDefinitionSource.

Often it is the case that annotated bean classes must be proxied directly, rather than proxying some implemented interface.

If you get an exception such as

Failed to convert property value of type [$Proxy70] to required type ...
no matching editors or conversion strategy found


Your solution might be to force the proxying of the target class itself using:

    <!-- Bean post-processor for auto-activating all advisors -->
    <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
        <property name="proxyTargetClass" value="true" />
    </bean>


cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element ...


Thus, it is recommended to provide the XSD’s through the applications class path and reference it accordingly in the XML file.
I did this for an activemq configuration as follows:

<?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:amq="http://activemq.org/config/1.0"
       xmlns:jms="http://www.springframework.org/schema/jms"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

           http://activemq.org/config/1.0 activemq-core-5.0.0.xsd
           http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-2.5.xsd">
 ...

In this example, the XML file activemq-core-5.0.0.xsd will be retreived from the classpath (residing in the default package). Putting the XSD into a subpackage on the classpath or using a classpath:// URI has not worked for me in spring 2.5.2 (and other systems). There appear to be a couple of parsers with only very basic classpath resource retreival capabilities.

@Configurable(value = "myBean")
public class MyBean {
   ...
}

Where myBean is the bean id in the spring context.

This approach can be somewhat problematic, though, when used in conjunction with aspect-oriented features.
Say, for example, you also want to use JPA and require a transactional behavior.

You would usually do the following:

@Configurable(value = "myBean")
public class MyBean {
   @Transactional
    public void foo() {
    ...
    }
}

This will not work, but lead to an exception like this:


java.lang.IllegalStateException: Post-processor tried to replace bean instance of type [my.package.MyBean] with (proxy) object of type [my.package.MyBean$$EnhancerByCGLIB$$c029ddbf] - not supported for aspect-configured classes!


The reason is that @Configurable will ask spring to configure the current bean during constructor invokation. During configuration, a number of bean post processors will be invoked on the bean, and one of them, namely the InfrastructureAdvisorAutoProxyCreator will find the @Transactional annotation – which advices the post processor to proxy the bean in order to manage the required transaction’s context.

But you cannot override the expected outcome of a class instanciation with new with a proxy object – since it is not of the same type as the expected object!

Thus, @Configurable and @Transactional – together with any other advice that leads to a proxy object – cannot coexist in your class.

Sehr nützlich!

    <filter>
        <filter-name>springContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>springContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Mehr dazu gibt’s natürlich in der spring-doku!

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

wobei eineWeitereKonfiguration im gleichen Verzeichnis bzw. im gleichen Package erwartet wird.

import kann jedoch noch mehr: Neben relativen Pfadangaben kann auch aus einer statischen Konfiguration ein classpath referenziert werden:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
       ...
       <import resource="classpath:my/package/eineWeitereKonfiguration.xml"/>
       ..
</beans>

Auf diese Weise lässt sich eine Konfiguration mit wenig Aufwand erweitern und sauber in Komponenten trennen.