MyArchiBook

Archive for the ‘CDI’ Category

Unsatisfied Dependency Exception : CDI 1.1 + Bean Validation + GlassFish 4.0 -> requires jersey-gf-cdi.jar upgrade

with one comment

Recently,  I faced Unsatisfied Dependency Exception, when trying to integrate BeanValidation with CDI 1.1 . Independently (without integration) everything worked fine. Looks like, the present Glassfish version 4.0 doesn’t support CDI 1.1 + Bean Validation together.

To be still clearer, Jersey (reference implementation for JAX-RS)  jar related to CDI  i.e., jersey-gf-cdi.jar in GF-4.0 version, is not supporting this integration .

I made the below changes, for Bean Validation integration with CDI 1.1 in Glassfish 4.0 to work.

Applicaiton Server used : Glassfish 4.0

Technology : JEE-7, CDI 1.1

Exception Trace :

org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=Foo,parent=Foo,qualifiers={@foo()}),position=-1,optional=false,self=false,unqualified=null,350112977)

at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:771)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:790)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$1.inject(CdiComponentProvider.java:316)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)

………………………….

Solution :

  • Download jersey-gf-cdi-2.0.jar . Download specifically 2.0 version for glassfish4.0. If other higher versions 2.10 are used, incompatibilty with other jars (firstly with jersey-server.jar) will arise.

http://repo1.maven.org/maven2/org/glassfish/jersey/containers/glassfish/jersey-gf-cdi/2.0/jersey-gf-cdi-2.0.jar

  • Rename the jar to jersey-gf-cdi.jar
  • Replace it in glassfish4.0/glassfish/modules/
  • Delete osgi-cache folder -> Path : glassfish4.0/glassfish/domains/domain1/osgi-cache
  • Refresh and restart glassfish. New osgi-cache will be created in domain 1 with the latest jersey-gf-cdi.jar. Problem will be solved 🙂

This issue will be resolved in Glassfish-4.0.1 version (not released yet). We’ll have to do the above till GF-4.0.1 is released.

Have a great day 🙂

Reference :
https://java.net/jira/browse/GLASSFISH-20597

Advertisements

CDI – Lifecycle Management by Container

with 3 comments

We know that, CDI Managed Beans are contextual. Their lifecycle management is done by the container. One of its main advantages is type-safe dependency injection.

But how does it do it?
In the below code, during application initialization process, the container checks for Type-Safe Resolution for News bean annotated with @Inject and then instantiates it.

TYPE-SAFE RESOLUTION:

Here the container checks ,

  • if the bean type is equal to the required type(type: News here) at the injection point in Consumer Bean class.
  • if the qualifier of bean is equal to the required qualifier at the injection point.
  • (If no qualifier specified , then default qualifier is @Default)


@Stateless
public class News {
  public String getLatestNews(){
    return "FIFA 2014 WorldCup";
  }
}

@Stateless
@Path(value = "consumer")
public class Consumer {

  @Inject
  private News news;

  @GET
  @Produces(MediaType.APPLICATION_JSON)
  @Path("latestNews")
  public String tweetLatestNews(){
    return news.getLatestNews();
  }
}

Any mismatch will result in unsatisfied or ambiguous dependency problem.

CREATION AND DESTRUCTION BY CONTAINER:

 

Reference:

http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html
http://docs.jboss.org/weld/reference/latest/en-US/html/injection.html
http://docs.jboss.org/cdi/spec/1.0/html/contexts.html
http://docs.jboss.org/cdi/spec/1.0/html/injectionelresolution.html#ambigdependencies