Red Hat's Ceylon language is an unneeded tempest in a teapot - JavaWorld

• Red Hat's Ceylon language is an unneeded tempest in a teapot - JavaWorld

  tags: Ceylon

  • 
    • This article is completely clueless. Scala programmers are upset that there is a new language for the JVM that will Eclipse them. Next up Wicket people don't like JSF.

Posted from Diigo. The rest of my favorite links are here.

Daily Dose: CDISource Promotes CDI Use | Javalobby

• Daily Dose: CDISource Promotes CDI Use | Javalobby

  We made the Daily Dose!

  tags: CDI CDISource Andy Gibson Rob Williams Richard Hightower

  • Java Enterprise Edition 6 fans rejoice! CDISource is here. CDISource is a new organization created to promote the use of CDI (JSR 299).  Rick Hightower, co-creator of CDISource, explains the inspiration for CDISource:
    
    

    CDI is the Java standard for dependency injection (DI) and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards and JSRs on top of it. DI and AOP are the foundation of many Java frameworks, and CDI will be the foundation of many future specifications and JSRs.

• Rick's Sleepless in Pleasanton: Announcing CDI Source

  CDI Source announcement from Rick Hightower

  tags: CDI

  • Announcing CDI Source

     

    We decided to create an organization, named CDISource, to promote the use of CDI. This organization is not tied to any vendor nor to Java EE 6.
    
    It did not take too long digging into CDI before I realized that Java Enterprise Edition 6 really nailed it this time. I have been a long time anti-EJB3 proponent. The interception model was flawed. The DI was flawed (or rather missing). CDI looks much better.
    

    
    CDI is the Java standard for dependency injection (DI) and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards and JSRs on top of it. DI and AOP are the foundation of many Java frameworks, and CDI will be the foundation of many future specifications and JSRs.
    
    CDI has merit on its own outside of the EJB and JSF space. Of course you can use CDI with JSF 2 and/or EJB 3.1. However CDI has a much wider scope than just Java EE 6 applications.

• Announcing CDISource | Andy Gibson

  CDISource announcement

  tags: CDI CDISource Andy Gibson

  • n the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at the
  • In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.

• In Relation To...  CDISource

  Gavin King, mentions CDISource in his blog.

  tags: CDISource Gavin King

  • Andy Gibson and Rick Hightower have announced the CDISource project.

• Rick's Sleepless in Pleasanton: Spring meet CDI, CDI meet Spring

  CDI and Spring integration announcement. (Part of CDI Source.)

  tags: CDISource Spring CDI

Posted from Diigo. The rest of my favorite links are here.

The rationale for Ceylon, Red Hat's new programming language

• The rationale for Ceylon, Red Hat's new programming language

  Ceylon has really caught my eye. I am looking for a Strong Typed, slimmed down Java friendly language. I could not agree more about "the lambda calculus used only by theoretical computer scientists". AMEN! 

  tags: Ceylon Scala

  • It also seems like a matter of strong personal preference for King—his slides include a rather trollish dismissal of programming languages that are based on "the lambda calculus used only by theoretical computer scientists."
  • We looked closely at Scala, but we collectively concluded that it wasn't the right thing for us. Personally, I find that Scala's type system is simply more complex than I want or need, with several features I think actually harm understandability/readability, and I find its syntax a bit of a dog's breakfast.
  • 
    • I don't think it is too eccentric. There are language features that Scala provides that just make sense. However, they will never see the light of day for most developers. Scala will never be widely adopted. 

Posted from Diigo. The rest of my favorite links are here.

Comments on new JCache revival JSR wrt Annotations and Interception

In reading the intro and chapter 8 of the JSR 107 revised specification (http://tinyurl.com/jsr107-yeah).

It seems if there are annotations for caching, then we need a way to intercept the method calls and process the annotations.

As manik.surtani brings out in the comments on the google doc JSR 107 specification (http://tinyurl.com/jsr107-yeah).

"""
Does the spec also define how these annotations are used? E.g., would implementations need to:

1. Perform annotation scanning on a classpath
2. Intercept method calls that are appropriately annotated
3. Perform cache storage and retrieval accordingly? —
"""

CDI already does classpath scanning and CDI is a standalone JSR. It would seem that the way to do this would be to use CDI (JSR 299).
Weld (the reference implementation of CDI) has standalone support, i.e., it can be used outside of an Java EE 6 container.
Therefore CDI seems to be a natural choice as the "standard" way to provide this support.
Other frameworks, Spring, Guice, et al can provide compatible implementations of annotation scanning and feature weaving.

Also that Weld is standalone is particular nicety covered by Weld it is not in the 1.0 CDI JSR.
It will not be until the CDI 1.1. There should be some collaboration between this JSR and CDI 1.1.
I would hate two see two forms of classpath scanning and annotation processing.
It would be nice if one JSR built on top of the sweat of another.

(You may already have this planned.)

BTW I have written several AOP frameworks that capture annotations and process them for caching.
(Using Spring AOP, and AspectJ)
I am willing, able and deeply interested in developing some proofs of concepts CDI Extension that work with the new JSR 107 as part of the JSR work.

I recently wrote a CDI Extension that bridges the CDI and Spring worlds.
see http://goo.gl/UwJfU and http://goo.gl/C76sp

CDI and Spring living in harmony

CDI and Spring living in harmony

Update: The CDI to Spring bridge works with CANDI, OpenWebBeans and Weld. The Spring to CDI extention works with CANDI and Weld.
The Spring to CDI extention partially works with OpenWebBeans (just the @SpringLookup).

Spring is very popular. CDI is very new. Although CDI is the standard for DI and Interception (light weight AOP), it is not as ubiquitous
and Spring.

Part of CDI success will be probably be indicative on how well it can play and integrate with Spring.

Realizing this, we took a Roo generated application, and fooled around with it until we were able to inject CDI beans into Spring objects. This effort is called the Spring CDI Bridge.
This basically allows you to inject CDI managed beans into Spring. We also had to go the other direction. We need the ability to inject Spring beans into CDI. This effort is called the CDI Spring Extension.

The golden ticket, is to be able to inject Spring beans into CDI beans that are then injected into Spring beans ad infinitum. This is tricky due to the different lifecycles and typing systems involved in Spring and CDI. We have achieved this as well.

Bridging from the CDI World into Spring

In order to bridge from the CDI world into the Spring world, we created a BeanFactoryPostProcessor.
This CdiBeanFactoryPostProcessor looks the CDI BeanManager in JNDI and uses it to find beans in CDI and map them as Spring bean definitions as follows:
applicationContext.xml example configuring a CdiBeanFactoryPostProcessor

 <bean class="org.cdisource.springintegration.CdiBeanFactoryPostProcessor" />

If you do not want to configure a BeanFactoryPostProcessor, you can also use CdiFactoryBean's to individually create bridges to CDI. CdiFactoryBean is similar to JndiObjectFactoryBean. In fact the CdiBeanFactoryPostProcessor configures bean definitions that are really CdiFactoryBean configured to look up a class in CDI.

.
applicationContext.xml example configuring a CdiFactoryBean to lookup a TaskRepository

 <bean class="org.cdisource.springintegration.CdiFactoryBean" name="taskRespository" >
        <property name="beanClass" value="org.cdisource.springapp.TaskRepository"/>
     </bean>

CdiBeanFactoryPostProcessor is fairly powerful. Just install it into Spring and then all of your CDI beans are available to Spring. No fuss. This works with Resin Candi, JBoss Weld, and OpenWebBeans http://openwebbeans.apache.org/owb/index.html.
You can find CdiBeanFactoryPostProcessor at CDI Spring Integration which is part of the CDI Source efforts to advocate the use of CDI. Please review CdiBeanFactoryPostProcessor and the test cases for it and the example roo based application that uses it. We are seeking feedback.

Bridging from the Spring World into CDI

We can also bridge from the Spring world into CDI. To do this we created two annotations: @Spring and @SpringLookup. @SpringLookup is the simpler of the two. It works in all three open source CDI implementations Resin Candi, JBoss Weld, and OpenWebBeans http://openwebbeans.apache.org/owb/index.html. The @Spring annotation is more complex (has more advanced features), and only works in Resin Candi, and JBoss Weld.
(We plan on filing bug reports against OpenWebBeans and trying to work with that team to improve OpenWebBeans so that the Spring annotation can work there as well.)
Examples of using Spring annotation

package org.cdisource.springintegration;

import javax.inject.Inject;

public class CdiBeanThatHasSpringInjection {
 @Inject @Spring(name="fooBar") 
 FooSpringBean springBean;

 @Inject @Spring(name="fooBarnotActuallyThere", required=false)
 FooSpringBean notActuallyThere;
 
 
 @Inject @Spring(type=FooSpringBean2.class) 
 FooSpringBean2 injectByType;

 public void validate () {
  if (springBean==null) {
   throw new IllegalStateException("spring bean was null");
  }
  if (notActuallyThere!=null) {
   throw new IllegalStateException("notActuallyThere should be null");
  }
  if (injectByType==null) {
   throw new IllegalStateException("injectByType should be there");
  }

 }
}

The form
by name

 @Inject @Spring(name="fooBar") 
 FooSpringBean springBean;

will look up the bean in Spring at the appropriate time given the appropriate name. The extension we wrote will create a Bean that has a @Named qualifier when it sees this type of injection. OpenWebBeans rejects this named qualifier. This works in Weld and Resin Candi (4.0.17 and later).
The form

 @Inject @Spring(name="fooBarnotActuallyThere", required=false)
 FooSpringBean notActuallyThere;

If there is a chance the bean will not be there, i.e., the injection is optional, you can specify a required=false. This means if we can't find the bean in Spring, don't throw an exception.
This works in Weld and Resin Candi (4.0.17 and later).
The form
by type

 @Inject @Spring(type=FooSpringBean2.class) 
 FooSpringBean2 injectByType;

The above form will look up the type in the Spring application context by type instead of by name.
FooSpringBean2 can be an interface or a concrete type.

Thus you could have a concreted implementation in Spring as follows:

 <bean name="fooBar3"  class="org.cdisource.springintegration.FooSpringBean2Impl"/>

The form
by type by name

 @Inject @Spring(name="foo2", type=FooSpringBean2.class) 
 FooSpringBean2 injectByType;

This is form will look up bean in the application context uses the name and the type. Spring throws an exemption if the types don't
match.

When developing this injection, using @Spring annotation was the ideal. Then we realized since the implementations did not support all of these
features (OpenWebBeans at this point). This is where the @SpringLookup came into play. In our minds it is not ideal, the implementations
should support the features in the @Spring annotation. @SpringLookup works in all three CDI containers. You use it as follows:

package org.cdisource.springintegration;

import javax.inject.Inject;

public class CdiBeanThatHasSpringLookupInjection {
 @Inject @SpringLookup("fooBar2")
 FooSpringBean springBean;

 @Inject @SpringLookup("fooBar2")
 FooSpringBean springBean2;

 
 public void validate () {
  if (springBean==null) {
   throw new IllegalStateException("spring bean was null");
  }
  if (springBean2==null) {
   throw new IllegalStateException("spring bean2 was null");
  }

 }
}

Using @SpringLookup never uses types and it always required. @Spring and @SpringLookup work with Candi 4.0.17 and Weld.

Background

The SpringBridge (CDI to Spring) always worked on all containers. It worked right out of the bat. I created something similar for Presto a
precursor to Crank. It would ask Hibernate for all of its managed beans and then registers a bunch of DAO, Controllers and Services on
your behalf for CRUD. The SpringBridge works the same way except instead of asking Hibernate for entities, it asks CDI for managed beans.
That part was easy. I had done it before (more or less) and am familiar with Spring after writing two large frameworks that sit on top of
Spring (Spring is my home court).

CDI is not my home court (yet). Here I needed a lot of help. The Weld reference guide to CDI was a big help. You can see the Extention uses
the lessons quite extensively (you may even see a bit of copy and paste in there). Also working with Andy Gibson and Rob Williams has
greatly expanded my CDI knowledge. I am more of a CDI enthusiast than a CDI expert.

Early version of the Spring Extention (Spring to CDI) did not work at all. We have friends on the Resin Candi core engineering team who
pointed us in the right direction. They whiteboarded a solution for us. They helped direct us what to do and then patched Resin Candi
so what we did would actually work with Resin 4.0.17. This would not exist without their help.

Initially, it only worked with Weld not Resin Candi 4.0.16. Then after Resin Candi 4.0.17, it worked better on Candi then Weld.
Then we had to rework it so it worked the same on Weld and Candi. Eseentially, we had to remove uneeded features so it would work with
Weld. Since the feature were uneeded, it was not a big deal (see Occam razor).

As I write this, Mark Struberg and I are on IRC chat #openwebbeans at ircfreenode. Mark is woking on the OpenWebBeans project.
He has forgotten more about CDI than I know and works from half way around the world from me in Austria.
He is going to see what is what with OpenWebBeans and @Spring annotation.
Perhaps @Spring Integration will work with OpenWebBeans really soon.

I guess what I am trying to say is, we could not have done this without a lot of help from a lot of people. Whatever bugs you find are mine,
whatever coolness you find is what we built on top of the shoulders of giants. We are seeking code reviews and feature requests.
What should Spring to CDI integration look like? This is our vision. What is yours?

There are 9 code listings in this article

Spring meet CDI, CDI meet Spring

I got the CDI to Spring Bridge working on Monday.
I got some design help from (Caucho) Resin's core engineering team on Monday to get an initial design and ideas for going from Spring to CDI .
(The other Direction!)
Today I got Spring to CDI integration working with Weld. It should also work with Resin 4.0.17 or Resin 4.0.18.

You can see the code at:

https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/SpringIntegrationExtention.java

The tests are at:


https://github.com/CDISource/cdisource/tree/master/spring/src/test/java/org/cdisource/springintegration

This was really fun to write.

The CDI to Spring Bridge was easy and it was similar to something I wrote before for Presto (a precursor to Crank).
The Spring to CDi was much more difficult. It currently only works with Weld. It will work with Resin in the 4.0.17 release (likely).

This class does the CDI to Spring bridge:

https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/CdiBeanFactoryPostProcessor.java

This class does the Spring to CDI bridge.

https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/SpringIntegrationExtention.java

This roo based webapp/project uses the CDI to Spring Bridge (it runs in Resin and should run in any CDI compliant app server Glassfish, JBoss, etc.):

https://github.com/CDISource/examples/tree/master/spring-integration-example

Come fork it on github!

https://github.com/CDISource/cdisource

Combining Spring With CDI Part II

#summary Strategy for combining Spring and CDI

I added support for discovering all the beans in CDI and registering them all in Spring as bean definitions.

This is a continuations of the last post part 1.

The last step we added a FactoryBean that was tied to the TaskRepository.
The next step is to make this generic.

CdiFactoryBean

package org.cdisource.springintegration;

import javax.enterprise.inject.spi.BeanManager;
import javax.naming.InitialContext;

import org.springframework.beans.factory.FactoryBean;
import org.cdisource.beancontainer.BeanContainer;
import org.cdisource.beancontainer.BeanContainerImpl;
import org.cdisource.beancontainer.BeanContainerInitializationException;

public class CdiFactoryBean implements FactoryBean<Object> {

 private BeanContainer beanContainer = null;
 private final String BEAN_MANAGER_LOCATION = "java:comp/BeanManager";
 
 private Class<?> beanClass;
 
 private boolean singleton = true;

 
 public void setBeanClass(Class<?> beanClass) {
  this.beanClass = beanClass;
 }

 @Override
 public Object getObject() throws Exception {

  if (beanContainer==null) {
   InitialContext ic = new InitialContext();
   Object bean = null;
   try {
    bean = ic.lookup(BEAN_MANAGER_LOCATION);
   } catch (Exception e) {
    throw new BeanContainerInitializationException("Unable to lookup BeanManager instance in JNDI", e);
   }
   if (bean == null) {
    throw new BeanContainerInitializationException(
      "Null value returned when looking up the BeanManager from JNDI");
   }
   if (bean instanceof BeanManager) {
    beanContainer = new BeanContainerImpl((BeanManager)bean);
   } else {
    String msg = "Looked up JNDI Bean is not a BeanManager instance, bean type is " + bean.getClass().getName();
    throw new BeanContainerInitializationException(msg);
   }
  }
  return beanContainer.getBeanByType(beanClass);
 }

 @Override
 public Class<?> getObjectType() {
  return beanClass;
 }

 @Override
 public boolean isSingleton() {
  return singleton;
 }

 public void setSingleton(boolean singleton) {
  this.singleton = singleton;
 }

}

Then you can register this in the applicationContext as follows:
applicationContext.xml

     <bean class="org.cdisource.springintegration.CdiFactoryBean" name="taskRespository" >
      <property name="beanClass" value="org.cdisource.springapp.TaskRepository"/>
     </bean>

Of course, this is a bit of a pain. Do you really want to register every CDI bean in your system so it is available for Spring? Imagine a system with 25 CDI beans or 250 CDI beans. Imagine what the Spring XML file will look like. Yuck.

We need a way to map CDI beans into the spring applicationContext.

The next step is bulk import a bunch of beans from CDI into Spring as follows:

package org.cdisource.springintegration;

import java.lang.annotation.Annotation;
import java.util.Set;

import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;
import javax.inject.Named;
import javax.naming.InitialContext;

import org.cdisource.beancontainer.BeanContainerInitializationException;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.support.BeanDefinitionBuilder;
import org.springframework.beans.factory.support.DefaultListableBeanFactory;

public class CdiBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

 @Override
 public void postProcessBeanFactory(
   ConfigurableListableBeanFactory beanFactory) throws BeansException {
  
  DefaultListableBeanFactory factory = (DefaultListableBeanFactory) beanFactory;
  
  Set<Bean<?>> beans = beanManager().getBeans(Object.class);
  for (Bean bean : beans) {
   BeanDefinitionBuilder definition = BeanDefinitionBuilder.rootBeanDefinition(CdiFactoryBean.class).addPropertyValue("beanClass", bean.getBeanClass()).setLazyInit(true);
   Named named = (Named) bean.getBeanClass().getAnnotation(Named.class);
   String name = named != null ? named.value() : bean.getBeanClass().getSimpleName() + "FactoryBean";
   factory.registerBeanDefinition(name, definition.getBeanDefinition());
  }
 }

 
 private final String BEAN_MANAGER_LOCATION = "java:comp/BeanManager";
 private BeanManager beanManager;

 private BeanManager beanManager() {
  if (beanManager == null) {
   Object bean = null;

   try {
    InitialContext ic = new InitialContext();
    bean = ic.lookup(BEAN_MANAGER_LOCATION);
   } catch (Exception e) {
    throw new BeanContainerInitializationException(
      "Unable to lookup BeanManager instance in JNDI", e);
   }
   if (bean == null) {
    throw new BeanContainerInitializationException(
      "Null value returned when looking up the BeanManager from JNDI");
   }
   if (bean instanceof BeanManager) {
    this.beanManager = (BeanManager) bean;
   } else {
    String msg = "Looked up JNDI Bean is not a BeanManager instance, bean type is "
      + bean.getClass().getName();
    throw new BeanContainerInitializationException(msg);
   }
  }
  return this.beanManager;

 }

}

The heart of the class functionality is here:

  DefaultListableBeanFactory factory = (DefaultListableBeanFactory) beanFactory;
  
  Set<Bean<?>> beans = beanManager().getBeans(Object.class);
  for (Bean bean : beans) {
   BeanDefinitionBuilder definition = BeanDefinitionBuilder
                                .rootBeanDefinition(CdiFactoryBean.class)
                                .addPropertyValue("beanClass", 
                                bean.getBeanClass()).setLazyInit(true);
   Named named = (Named) bean.getBeanClass().getAnnotation(Named.class);
   String name = named != null ? named.value() : bean.getBeanClass().getSimpleName() + "FactoryBean";
   factory.registerBeanDefinition(name, definition.getBeanDefinition());
  }

We iterate through the beans from CDI, create a Spring definition that uses CdiFactoryBean from the last step.

We register the CdiFactoryBean. We use the name from the @Named attribute if possible. If not we generate a name.

There are 4 code listings in this article

Combining Spring With CDI

#summary Combining Spring With CDI

Introduction

Notes on how to combine Spring with CDI

Using Roo to setup the sample project

I created a simple application in Roo that generated one Task entity as follows:

project --topLevelPackage org.cdisource.springapp
persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY --jndiDataSource jdbc/basic
entity --class ~.Task --testAutomatically 
field string --fieldName title --notNull
field boolean --fieldName done 
controller all --package ~.web
perform tests
perform eclipse

Then I re-factored out the AspectJ stuff from the Task and created a new class called TaskRespository as follows:

package org.cdisource.springapp;

import java.util.List;

import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;

@Repository
@Transactional
public class TaskRepository {
 
    @PersistenceContext
    private EntityManager entityManager;

    
    public void persist(Task task) {
        this.entityManager.persist(task);
    }
    
    public void remove(Task task) {
        if (this.entityManager.contains(task)) {
            this.entityManager.remove(task);
        } else {
            Task attached = this.findTask(task.getId());
            this.entityManager.remove(attached);
        }
    }
    
    public void flush() {
        this.entityManager.flush();
    }
    
    public void clear() {
        this.entityManager.clear();
    }
    
    public Task merge(Task task) {
        Task merged = this.entityManager.merge(task);
        this.entityManager.flush();
        return merged;
    }
        
    public  long countTasks() {
        return entityManager.createQuery("select count(o) from Task o", Long.class).getSingleResult();
    }
    
    public  List<Task> findAllTasks() {
        return entityManager.createQuery("select o from Task o", Task.class).getResultList();
    }
    
    public  Task findTask(Long id) {
        if (id == null) return null;
        return entityManager.find(Task.class, id);
    }
    
    public  List<Task> findTaskEntries(int firstResult, int maxResults) {
        return entityManager.createQuery("select o from Task o", Task.class).setFirstResult(firstResult).setMaxResults(maxResults).getResultList();
    }

}

I then changed the Controller (also pushing in the AspectJ stuff into the actual controller) to use the new TaskRepository as follows:

package org.cdisource.springapp.web;

import java.io.UnsupportedEncodingException;
import java.util.Collection;

import javax.servlet.http.HttpServletRequest;
import javax.validation.Valid;

import org.cdisource.springapp.Task;
import org.cdisource.springapp.TaskRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.ModelAttribute;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.util.UriUtils;
import org.springframework.web.util.WebUtils;
import org.springframework.ui.Model;
import org.springframework.validation.BindingResult;

@RequestMapping("/tasks")
@Controller
public class TaskController {

 @Autowired
 TaskRepository repo;

 @RequestMapping(method = RequestMethod.POST)
 public String create(@Valid Task task, BindingResult bindingResult,
   Model uiModel, HttpServletRequest httpServletRequest) {

  if (bindingResult.hasErrors()) {
   uiModel.addAttribute("task", task);
   return "tasks/create";
  }

  System.out.println("HERE 1");
  uiModel.asMap().clear();
  System.out.println("HERE 2");
  task = repo.merge(task);
  System.out.println("HERE 3");

  return "redirect:/tasks/"
    + encodeUrlPathSegment(task.getId().toString(),
      httpServletRequest);

 }

 @RequestMapping(params = "form", method = RequestMethod.GET)
 public String createForm(Model uiModel) {
  uiModel.addAttribute("task", new Task());
  return "tasks/create";
 }

 @RequestMapping(value = "/{id}", method = RequestMethod.GET)
 public String show(@PathVariable("id") Long id, Model uiModel) {
  uiModel.addAttribute("task", repo.findTask(id));
  uiModel.addAttribute("itemId", id);
  return "tasks/show";
 }

 @RequestMapping(method = RequestMethod.GET)
 public String list(
   @RequestParam(value = "page", required = false) Integer page,
   @RequestParam(value = "size", required = false) Integer size,
   Model uiModel) {
  if (page != null || size != null) {
   int sizeNo = size == null ? 10 : size.intValue();
   uiModel.addAttribute("tasks", repo.findTaskEntries(page == null ? 0
     : (page.intValue() - 1) * sizeNo, sizeNo));
   float nrOfPages = (float) repo.countTasks() / sizeNo;
   uiModel.addAttribute(
     "maxPages",
     (int) ((nrOfPages > (int) nrOfPages || nrOfPages == 0.0) ? nrOfPages + 1
       : nrOfPages));
  } else {
   uiModel.addAttribute("tasks", repo.findAllTasks());
  }
  return "tasks/list";
 }

 @RequestMapping(method = RequestMethod.PUT)
 public String update(@Valid Task task, BindingResult bindingResult,
   Model uiModel, HttpServletRequest httpServletRequest) {
  if (bindingResult.hasErrors()) {
   uiModel.addAttribute("task", task);
   return "tasks/update";
  }
  uiModel.asMap().clear();
  repo.merge(task);
  return "redirect:/tasks/"
    + encodeUrlPathSegment(task.getId().toString(),
      httpServletRequest);
 }

 @RequestMapping(value = "/{id}", params = "form", method = RequestMethod.GET)
 public String updateForm(@PathVariable("id") Long id, Model uiModel) {
  uiModel.addAttribute("task", repo.findTask(id));
  return "tasks/update";
 }

 @RequestMapping(value = "/{id}", method = RequestMethod.DELETE)
 public String delete(@PathVariable("id") Long id,
   @RequestParam(value = "page", required = false) Integer page,
   @RequestParam(value = "size", required = false) Integer size,
   Model uiModel) {
  repo.remove(repo.findTask(id));
  uiModel.asMap().clear();
  uiModel.addAttribute("page", (page == null) ? "1" : page.toString());
  uiModel.addAttribute("size", (size == null) ? "10" : size.toString());
  return "redirect:/tasks";
 }

 @ModelAttribute("tasks")
 public Collection<Task> populateTasks() {
  return repo.findAllTasks();
 }

 String encodeUrlPathSegment(String pathSegment,
   HttpServletRequest httpServletRequest) {
  String enc = httpServletRequest.getCharacterEncoding();
  if (enc == null) {
   enc = WebUtils.DEFAULT_CHARACTER_ENCODING;
  }
  try {
   pathSegment = UriUtils.encodePathSegment(pathSegment, enc);
  } catch (UnsupportedEncodingException uee) {
  }
  return pathSegment;
 }
}

Here is the re-factored Task class with the JPA stuff pushed in:

package org.cdisource.springapp;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Version;
import javax.validation.constraints.NotNull;
import org.springframework.beans.factory.annotation.Configurable;

@Configurable
@Entity
public class Task {

    @NotNull
    private String title;

    private Boolean done;
    
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long id;
    
    @Version
    @Column(name = "version")
    private Integer version;

    
    public String getTitle() {
        return this.title;
    }
    
    public void setTitle(String title) {
        this.title = title;
    }
    
    public Boolean getDone() {
        return this.done;
    }
    
    public void setDone(Boolean done) {
        this.done = done;
    }
    
    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("Title: ").append(getTitle()).append(", ");
        sb.append("Done: ").append(getDone());
        return sb.toString();
    }

    
    public Long getId() {
        return this.id;
    }
    
    public void setId(Long id) {
        this.id = id;
    }
    
    public Integer getVersion() {
        return this.version;
    }
    
    public void setVersion(Integer version) {
        this.version = version;
    }
}

At this point the webapp runs. You can create tasks and list them.
I also wrote a simplified unit test for the TaskRepository:

package org.cdisource.springapp;


import static org.junit.Assert.assertEquals;

import java.util.List;

import org.cdisource.testing.junit.CdiTestRunner;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Configurable;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.transaction.annotation.Transactional;
import org.junit.runner.RunWith;



@Configurable
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:/META-INF/spring/testApplicationContext.xml")
@Transactional
public class TaskRepositoryTest {

 @Autowired
 private TaskRepository taskRepository;

 @Test
    public void testCrud() {
  Task task = new Task();
  task.setDone(true);
  task.setTitle("love rockets");
  taskRepository.persist(task);
  taskRepository.flush();
  List<Task> findAllTasks = taskRepository.findAllTasks();
  assertEquals(1, findAllTasks.size());
  taskRepository.remove(task);
  taskRepository.flush();
  List<Task> findAllTasks2 = taskRepository.findAllTasks();
  assertEquals(0, findAllTasks2.size());
    }

}

Using CDI for the TaskRepository instead of Spring

I added these to the pom.xml

{projecthome}/pom.xml

...
 <repositories>
        ...
        <repository>
            <id>caucho.maven.repo</id>
            <name>Caucho Repository</name>
            <url>http://caucho.com/m2</url>
        </repository>
        <repository>
            <id>caucho.maven.repo.snapshot</id>
            <name>Caucho Repository</name>
            <url>http://caucho.com/m2-snapshot</url>
        </repository>
        <repository>
   <id>java.net</id>
   <name>java.net Repository</name>
   <url>http://download.java.net/maven/2</url>
  </repository>
    </repositories>
...

 <dependencies>
 
  <dependency>
            <groupId>org.cdisource.beancontainer</groupId>
      <artifactId>beancontainer-api</artifactId>
      <version>1.0-SNAPSHOT</version>
  </dependency>

  <dependency>
            <groupId>org.cdisource.beancontainer</groupId>
      <artifactId>beancontainer-resin-impl</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>test</scope>
  </dependency>
        <dependency>
         <groupId>org.cdisource.testing</groupId>
   <artifactId>cdisource-testing-junit</artifactId>
   <version>1.0-SNAPSHOT</version>
         <scope>test</scope>
        </dependency>
...

The beancontainer-resin-impl is not needed at this point.
I was using it in a failed attempt to add a unit test for the new TaskRepository.
The next step is to CDIify the TaskRespository as follows:

package org.cdisource.springapp;

import java.util.List;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class TaskRepository {
 
    @PersistenceContext
    private EntityManager entityManager;

    
    public void persist(Task task) {
        this.entityManager.persist(task);
    }
    
    public void remove(Task task) {
        if (this.entityManager.contains(task)) {
            this.entityManager.remove(task);
        } else {
            Task attached = this.findTask(task.getId());
            this.entityManager.remove(attached);
        }
    }
    
    public void flush() {
        this.entityManager.flush();
    }
    
    public void clear() {
        this.entityManager.clear();
    }
    
    public Task merge(Task task) {
        Task merged = this.entityManager.merge(task);
        this.entityManager.flush();
        return merged;
    }
        
    public  long countTasks() {
        return entityManager.createQuery("select count(o) from Task o", Long.class).getSingleResult();
    }
    
    public  List<Task> findAllTasks() {
        return entityManager.createQuery("select o from Task o", Task.class).getResultList();
    }
    
    public  Task findTask(Long id) {
        if (id == null) return null;
        return entityManager.find(Task.class, id);
    }
    
    public  List<Task> findTaskEntries(int firstResult, int maxResults) {
        return entityManager.createQuery("select o from Task o", Task.class).setFirstResult(firstResult).setMaxResults(maxResults).getResultList();
    }

}

Notice the removal of the Spring annotations and the addition of the CDI annotation.
There is only three lines of code difference.
Then to make this bean recognizable by Spring I added the following:

package org.cdisource.springapp;

import javax.enterprise.inject.spi.BeanManager;
import javax.naming.InitialContext;

import org.springframework.beans.factory.FactoryBean;
import org.cdisource.beancontainer.BeanContainer;
import org.cdisource.beancontainer.BeanContainerImpl;
import org.cdisource.beancontainer.BeanContainerInitializationException;

public class TaskRepositoryFactoryBean implements FactoryBean<TaskRepository> {

 private BeanContainer beanContainer = null;
 private final String BEAN_MANAGER_LOCATION = "java:comp/BeanManager";

 
 @Override
 public TaskRepository getObject() throws Exception {

  if (beanContainer==null) {
   InitialContext ic = new InitialContext();
   Object bean = null;
   try {
    bean = ic.lookup(BEAN_MANAGER_LOCATION);
   } catch (Exception e) {
    throw new BeanContainerInitializationException("Unable to lookup BeanManager instance in JNDI", e);
   }
   if (bean == null) {
    throw new BeanContainerInitializationException(
      "Null value returned when looking up the BeanManager from JNDI");
   }
   if (bean instanceof BeanManager) {
    beanContainer = new BeanContainerImpl((BeanManager)bean);
   } else {
    String msg = "Looked up JNDI Bean is not a BeanManager instance, bean type is " + bean.getClass().getName();
    throw new BeanContainerInitializationException(msg);
   }
  }
  return beanContainer.getBeanByType(TaskRepository.class);
 }

 @Override
 public Class<?> getObjectType() {
  return TaskRepository.class;
 }

 @Override
 public boolean isSingleton() {
  return true;
 }

}

Note that I added a new constructor to the BeanContainerImpl to make the above possible.

package org.cdisource.beancontainer;

import javax.enterprise.inject.spi.BeanManager;
import javax.inject.Inject;

public class BeanContainerImpl extends AbstractBeanContainer {
    @Inject protected BeanManager manager;
    
    public BeanContainerImpl() {
     
    }
    
    public BeanContainerImpl(BeanManager manager) {
     this.manager = manager;
    }

...
}

I thought I had the webapp working at this point, but then realized that I was deploying old classes. I had to go back and rework things a few times to get things going.
At this point, the webapp almost works.
I change the persistence.xml as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="persistenceUnit" >
  <!--  transaction-type="RESOURCE_LOCAL" Took this out. We are managing this in CDI not local.-->
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <jta-data-source>jdbc/basic</jta-data-source>
        <properties>
            <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
            <property name="hibernate.hbm2ddl.auto" value="create"/>
            <property name="hibernate.ejb.naming_strategy" value="org.hibernate.cfg.ImprovedNamingStrategy"/>
            <property name="hibernate.connection.charSet" value="UTF-8"/>
        </properties>
    </persistence-unit>
</persistence>

I then had to disable Spring transaction support/JPA support in the web.xml and in the applicationContext.xml.
First in the web.xml as follows:
web.xml

    <!-- Commented this out to get it to work with CDI
    <filter>
        <filter-name>Spring OpenEntityManagerInViewFilter</filter-name>
        <filter-class>org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter</filter-class>
    </filter>
     -->
    <filter-mapping>
        <filter-name>CharacterEncodingFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    
    <filter-mapping>
        <filter-name>HttpMethodFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    
    <!-- Commented this out to get it to work with CDI
    <filter-mapping>
        <filter-name>Spring OpenEntityManagerInViewFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    -->

applicationContext.xml

    <context:spring-configured/>
    <context:component-scan base-package="org.cdisource.springapp">
        <context:exclude-filter expression="org.springframework.stereotype.Controller" type="annotation"/>
    </context:component-scan>


    <!-- 
    
    Spring is no longer managing the transactions.

    <bean class="org.springframework.orm.jpa.JpaTransactionManager" id="transactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>
    
    <tx:annotation-driven mode="aspectj" transaction-manager="transactionManager"/>
     
    <jee:jndi-lookup id="dataSource" jndi-name="jdbc/basic"/>
    <bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory">
        <property name="dataSource" ref="dataSource"/>
    </bean>
    
         -->
    
    
    <bean class="org.cdisource.springapp.TaskRepositoryFactoryBean" name="taskRespository"/>

I had some troubles getting the unit test to work. The web app does work.
The unit test is as follows:

package org.cdisource.springapp;


import static org.junit.Assert.assertEquals;

import java.util.List;

import javax.inject.Inject;

import org.cdisource.testing.junit.CdiTestRunner;
import org.junit.Test;
import org.junit.runner.RunWith;



@RunWith(CdiTestRunner.class)
public class TaskRepositoryTest {

 @Inject
 private TaskRepository taskRepository;

 @Test
    public void testCrud() {
  Task task = new Task();
  task.setDone(true);
  task.setTitle("love rockets");
  taskRepository.persist(task);
  taskRepository.flush();
  List<Task> findAllTasks = taskRepository.findAllTasks();
  assertEquals(1, findAllTasks.size());
  taskRepository.remove(task);
  taskRepository.flush();
  List<Task> findAllTasks2 = taskRepository.findAllTasks();
  assertEquals(0, findAllTasks2.size());
    }

}

There are 13 code listings in this article

CDI Dependency Injection - Tutorial II - Annotation Processing and Plugins | Javalobby

CDI Dependency Injection - Tutorial II - Annotation Processing and Plugins | Javalobby CDI provides a pluggable architecture allowing you to easily process your own annotations. Read this article to understand the inner workings of CDI and why this JSR is so important.

Dependency Injection - An Introductory Tutorial Part 1 | Javalobby

Dependency Injection - An Introductory Tutorial Part 1 | Javalobby Hit nearly 8,000 reads in its first week. This makes it the most popular JavaLobby technical article in the last few months.