@Inject not working in Jersey REST webservices in Struts 2

Question

I have created an application for testing the Struts 2 dependency injection ( @Inject ). The injection is working fine in many areas except Jersey REST service class within which I have defined the webservices actions.

I am getting exception like as shown below:

Sep 22, 2014 8:48:50 AM com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
    at usermodules.services.UserModulesServices.userName(UserModulesServices.java:30)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Can anyone please tell me some solution for this?

struts.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
    "http://struts.apache.org/dtds/struts-2.0.dtd">
 
<struts>
<bean class="net.viralpatel.struts2.action.MoreServiceImpl" name="services" />

  <constant name="struts.action.excludePattern" value="/rest/.*" />
    <constant name="struts.enable.DynamicMethodInvocation"
        value="false" />
    <constant name="struts.devMode" value="false" />
    <constant name="struts.custom.i18n.resources"
        value="ApplicationResources" />
  
 
    <package name="default" extends="struts-default" namespace="/">
        <action name="login"
            class="net.viralpatel.struts2.action.LoginAction">
            <result name="success">Welcome.jsp</result>
            <result name="error">Login.jsp</result>
        </action>
    </package>
</struts>

UserModulesServices.java:

import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import net.viralpatel.struts2.action.MoreServiceImpl;

import com.opensymphony.xwork2.inject.Inject;

@Path("/users")
public class UserModulesServices {
    
    @Inject("services")
    public MoreServiceImpl moreServiceImpl;

    public MoreServiceImpl getMoreServiceImpl() {
        return moreServiceImpl;
    }

    public void setMoreServiceImpl(MoreServiceImpl moreServiceImpl) {
        this.moreServiceImpl = moreServiceImpl;
    }
    
    @GET
    @Path("/name/{i}")
    @Produces(MediaType.TEXT_PLAIN)
    public String userName(@PathParam("i") String i) {
        System.out.println("name::::::::" + moreServiceImpl.validate());
        return "{\"name\":\"" + i + "\"}";
    }
}

MoreServiceImpl.java:

package net.viralpatel.struts2.action;

public class MoreServiceImpl implements MoreServices{

    @Override
    public String validate() {
        return "testing";
    }

}

Answer 1

From the official CDI Plugin documentation :

Use the right @Inject

Struts 2 and it's core component XWork use it's own internal dependency injection container. Interestingly, you could name it JSR-330's grandma, since it is an early pre-release version of Google Guice once developed by Crazybob Lee - the same Bob Lee that, together with SpringSource's Rod Johnson, lead the JSR-330 specification.

That said, you will find the @Inject annotation both as com.opensymphony.xwork2.inject.Inject and javax.inject.Inject . Don't mix up those two - javax.inject.Inject is the one you want to use with your Struts 2 CDI plugin and CDI integration in general ! While you could use Struts' internal annotation as well, the effect may be strange to undefined - so check your imports!

Then instead of com.opensymphony.xwork2.inject.Inject
use the correct one: javax.inject.Inject

Answer 2

For this particular question you should provide bean configuration for

<bean class="net.viralpatel.struts2.action.UserModulesServices" name="userModulesServices" />

The injection will work, but it's for internal use,

Internally, the framework uses its own dependency injection container that is very similar to Google Guice.

and you should consider the opportunities for other DI frameworks. See Dependency Injection .