Tag Archive for 'bea'

License change for Spring IDE version 2.0

Starting with the upcoming version 2.0 Spring IDE will be published under the Eclipse Public License version 1.0 instead the Apache 2.0 license.

What’s the reasoning behind switching to a more restrictive license?

Back in time the development of Spring IDE started selecting the corresponding license was a pragmatic approach: Ok, let’s adopt the one from the Spring Framework and its dependent libraries (Apache 2.0). So no worries about bundling differently licensed stuff or any sublicensing issues.

Over time we have learned that choosing the appropriate license for an Open Source project is very important, especially for commercial adoption of a project. Regarding Spring IDE’s commercial adoption our experiences are two-fold:

  • One vendor managed to add value for his commercial offering on top of an unmodified version of Spring IDE and publicly stated within a press release that Spring IDE was “blended”. Other vendors clearly stated the bundling of Spring IDE.This kind of adoption is really appreciated and supported.
  • Another vendor took a different approach of integrating Spring IDE: This vendor bundled a modified version of Spring IDE plugins (with its own plugin ID, version number and provider name “<vendor name> / Spring IDE Team”) within its own distribution and replaced every visual connection to the Spring IDE project (e.g. “Spring IDE” menu labels or documentation, no about dialog with copyright statement and link to Spring IDE’s website). While claiming to provide improvements like “performance enhancements” the vendor has not taken the opportunity to contribute anything back to the Spring IDE project.Although this behaviour is perfectly fine with the terms of the Apache 2.0 license Christian and me don’t feel comfortable with this situation, given the fact that we spent most of our spare time on this project.

Therefore, back in November last year when the development of Spring IDE version 2.0 started, we begun to consider if a license change could help solving this issue without hurting our users and other adopters. In order to keep the competitive advantage of supporting Spring 2.0, AOP and Spring Web Flow we decided to not publish the source code of these enhancements.

Today we finalized the migration to the Eclipse Public License v1.0 (#550) and enabled the public access to Spring IDE’s full source code again.

Implementing JEE with Spring and WebLogic

At JavaOne Interface21 and BEA Systems announced they have jointly developed implementations of key Java EE 5 components on Spring Framework 2.0. They have unveiled an open source project that comprises Spring support for the Java EE 5 Common Annotations (JSR-250), which includes resource injection and EJB 3 (JSR-220) interception. This project is used to implement JEE5 inside the next generation of WebLogic Server, and is also available for use within JSE environments.

package com.cdupuis.ejb3;

import javax.annotation.PostConstruct;
import javax.ejb.Remote;
import javax.ejb.Stateless;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

@Stateless
@Remote(Echo.class)
public class EchoBean implements Echo {

    private static final Log LOG =
        LogFactory.getLog(EchoBean.class);

    private EchoVo echoVo;

    public String echo(String say) {
        return this.echoVo.getEcho() + " " + say;
    }

    @PostConstruct
    public void init() {
        LOG.info("init " + echoVo);
    }

    public void setEchoVo(EchoVo echoVo) {
        LOG.info("setEchoVo called " + echoVo);
        this.echoVo = echoVo;
    }
}

In addition to defining a JavaBean property called echoVo the EJB has a custom init method which is annotated which javax.annotation.PostConstruct. That annotation is defined in JSR-250 and can be used to define certain callback methods at certain lifecycle events.

To actually make Spring aware of that EJB, you need to define a common Spring bean definition which should be called spring-ejb-jar.xml by default. This file needs to be placed in the META-INF directory of your EJB artifact. There are no special beans required in your application context.

For now the id of the Spring Bean should be the name of the EJB that needs to be configured.

<!DOCTYPE beans
    PUBLIC "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
    <bean id="EchoBean">
        <property name="echoVo">
            <bean class="com.cdupuis.ejb3.EchoVo">
                <property name="echo" value="Hello" />
            </bean>
        </property>
    </bean>
</beans>

Now you are ready to deploy the EJB and let Spring handle all the dependency injection and bean lifecycle. It is important to note that the dependency injection happens at first invocation. So make sure that you invoke a business method of your EJB in order to actually see the wiring happening.

Using full power of the Spring AOP

The delivered implementation can do much more then specified within the EBJ 3.0 specification. This is especially interesting in the area of AOP. The EJB 3.0 specification defines little support for method intercepting based on custom annotations. That approach to AOP has been discussed very often recently and is - in my opinion - not something one would use in a real world scenario.

With the integration of Spring 2.0 in the core of WebLogic you can leverage full support for Spring AOP (as well as Spring 2.0’s AspectJ integration) in your application.

The following spring-ejb-jar.xml uses a BeanNameAutoProxyCreator to add a performance interceptor to the EJB defined in the preceding section.

<!DOCTYPE beans
    PUBLIC "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
    <bean
        class="org.sfw…BeanNameAutoProxyCreator">

        <property name="beanNames" value="EchoBean" />
        <property name="interceptorNames"
            value="performanceInterceptor" />

    </bean>

    <bean id="performanceInterceptor"
        class="org.sfw…PerformanceMonitorInterceptor">

        <property name="loggerName" value="com.cdupuis.ejb3" />
    </bean>

    <bean id="EchoBean" />

</beans>

You can even take the AOP magic a little further by using Spring 2.0’s <aop:aspectj-autoproxy /> facility and plug-in your @AspectJ-style Aspects. Here is an example TracingAspect:

package com.cdupuis.ejb3.aspect;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class TracingAspect {

    private static final Log LOG =
        LogFactory.getLog(TracingAspect.class);

    @Before("execution(* *..EchoBean.echo(..))")
    public void before(JoinPoint thisJoinPoint) {
        LOG.info("Before [" + thisJoinPoint.toShortString() + "]");
    }
}

and the corresponding spring-ejb-jar.xml:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd
      http://www.springframework.org/schema/aop
      http://www.springframework.org/schema/aop/spring-aop.xsd"
>

    <aop:aspectj-autoproxy />

    <bean id="tracingAspect"
        class="com.cdupuis.ejb3.aspect.TracingAspect" />

    <bean id="EchoBean" class="com.cdupuis.ejb3.EchoBean">
        <property name="echoVo">
            <bean class="com.cdupuis.ejb3.EchoVo">
                <property name="echo" value="Hello" />
            </bean>
        </property>
    </bean>

</beans>

Conclusion

The integration of Spring into the core of WebLogic delivers a solid solution to JSR-220 and JSR-250. Furthermore it seems to be possible to leverage other Spring features which do not depend on the EJB specification but add much value to your application; for example transaction demarcation based on Spring’s transaction abstraction layer, integration of ACEGI for handling security on your EJB methods and other AOP and DI features. That can increase significantly the portability of your application and help decoupling it from the underlying EJB technology. You can read more details here UsingJsr220inWebContainer.

Please note that the current implementation is a “Tech Preview” and will be subject to changes on its way to a final product. Furthermore you will not get any support for that from BEA right now.