CDI Dependency Injection - Tutorial II - Annotation Processing and Plugins - Java EE

Hi,

 Is the something missing from the last example code snippet or how this can work with identical annotation literals?

standardTransport = allTransports.select(new AnnotationLiteral(){}).get();
jsonTransport = allTransports.select(new AnnotationLiteral(){}).get();
soapTransport = allTransports.select(new AnnotationLiteral(){}).get();

Hi Rick!

Good series!  I just like to add a few oftern overlooked gems. Today it's the @Typed Annotation. It can be used to explicitely declare the type of a bean. There are 2 cases where this is reaaaly handy.

Use case 1: 'disabling' a java class as bean

Let's say we have a 

@Typed()
public class Menu {
   private String name;
   private String action;
   private Menu parent;
}

and we have a producer method like

@ApplicationScoped
public class MenuProducer {
  private @Inject menuSvc;
  private @Inject User currentUser;

  public @Produces @SessionScoped Menu menuForUser() {
    Menu menu = menuSvc.getMenuForUser(currentUser);
    return menu;
  }
}

 A Menu is naturally a tree with a 1:n parent menu relationship. So this will just be created via an @ApplicationScoped MenuServiceImpl or such - but never directly as a bean! Annotate the Menu class as @Typed() effectively says: this bean has no Type at all, thus it will not satisfy any injection point. This has almost the same effect as veto() ing a bean in an Extension (via @Observes ProcessAnnotatedType) but without needing to write an Extension. If we wouldn't annotate our Menu class as @Typed(), it would get picked up as @Dependent scoped bean automatically (I personally don't like that, but thats what the spec defines) - leading to an AmbiguousResolutionException.

The 2nd case where @Typed is really handy is if you have subclasses which should not get picked up as the base type:

/** 
 * This menu service will provide 
 * read operations only!
 */
@ApplicationScoped
public class MenuService {
  public Menu getMenuOfUser(User user) {
    ..
  }
}

/** 
 * This will add Administration 
 * functionality to our base MenuService 
 */
@ApplicationScoped
@Typed(MenuAdminService.class)
public class MenuAdminService extends MenuService {
  public addMenuPermission(Menu menuTree, String role) {
   ... }
  public storeMenuTree(Menu menu) {
   ... }
} 

 If I would not use the @Typed annotation at the MenuAdminService, then it would automatically satisfy all the types in it's whole class hierarchy - including the MenuService it extends. So if you would try to

private @Inject MenuService menuSvc; 

 then you would get an AmbiguousResolutionException (remember: both MenuService and MenuAdminService implement the MenuService type!). By adding 

@Typed(MenuAdminService.class)

it will only act as the type in the annotation and not automatically use all the parent types too! 

Might as well add another tip: Beware of the Constructor!

Writing CDI bean initialisation code in Constructors is not a good thingy as you will see weird effects.

Remember - all beans you get injected (except  @Dependent ones) are always 'contextual references' = proxies for their underlying contextual instances! But CDI implementations do not use Java's own reflect proxy (because this one is only able to proxy interfaces) but must use instance proxies.

How goes? The CDI implementations I know (Weld, CanDI and of course OpenWebBeans) create proxies by dynamically subclassing the class which should get proxied. So whenever a proxy gets created, it will naturally also invoke the constructors up in the parent-class chain.

Thus writing the classic reference counter for your bean will give you wrong numbers:

@SessionScoped
public class MyBean implements Serializable {
  private static int refCounter = 0;

  public MyBean() {
    refCounter++;  // <- this will be called too often since the ct will also get called for proxies
  }
  ...
}

 Instead use the @PostConstruct or @Inject annotations on any method:

@SessionScoped
public class MyBean implements Serializable {
  private static int refCounter = 0;

  @Inject
  public void init() {
    refCounter++;  // <- this will be called too often since the ct will also get called for proxies
  }

  @PostConstruct
  pubic void anotherInit() {
  }
  ...
  @PreDestroy // ofc this works as well btw!
  public void cleanup() {
  }
}

> support injection into non-managed beans

Stu (Stuart Douglas) of JBoss fame wrote a portable CDI Extension for exactly that [1]. This Extension basically will dynamically apply annotations to your classes - without having to write them in your code. It will give you the kind of XML config you might know from Spring 2.

 In general: if you are looking for CDI Extensions, then check JBoss Seam3 [2] and  Apache MyFaces CODI [3] first

 LieGrue,
strub

[1] http://docs.jboss.org/seam/3/xml-config/latest/reference/en-US/html_single/

[2] http://docs.jboss.org/seam/3/3.0.0.Final/reference/en-US/html/

[3] http://myfaces.apache.org/extensions/cdi/

PS: <shamelessselfadvert>the Seam3 doc is much better, but CODI is in some areas much more powerful ;) </shamelessselfadvert>

Hi Rogerio!

What I meant is that by using -javaagent alll the classes you need for the transformation will end up getting loaded via the SystemClassLoader. I'm not 100% sure yet about the 'transformed classes' butI think they also get loaded that way.

 You will see this effect if you use those libs with tomcat - they will just refuse to work. The reason is that tomcat implements a security feature to prevent people from overloading classes which got loaded via the SystemClassLoader. I stumbled accross this problem in OpenJPA:

https://issues.apache.org/jira/browse/OPENJPA-1454
https://issues.apache.org/jira/browse/OPENJPA-1410

I haven't yet used the programmatical way to use the javaagent in Java6 of course