CDI injection not working in REST Resource in WAS Liberty with Jersey as JAX-RS implementation - jax-rs

I am using websphere liberty 19.0.0.8 and I wanted to use Jersey instead of default CXF for jax-rs implementation. I removed jaxrs-2.1 feature from server xml and packaged jersey implementation jars in my webapp .war.
<featureManager>
<feature>servlet-4.0</feature>
<feature>jndi-1.0</feature>
<feature>requestTiming-1.0</feature>
<feature>monitor-1.0</feature>
<feature>localConnector-1.0</feature>
<feature>restConnector-2.0</feature>
<!-- Do not add enabled webProfile-8.0 because we want to disable default
REST implementation (Apache-CXF) provided by Liberty. We want to use Jersey
as our REST implementation because it better support multi-part streaming, -->
<!-- <feature>webProfile-8.0</feature> -->
<feature>jsp-2.3</feature>
<feature>cdi-2.0</feature>
<feature>managedBeans-1.0</feature>
<feature>jdbc-4.2</feature>
<!-- <feature>jaxrs-2.1</feature> -->
</featureManager>
Gradle build including jersey implementation
//JxRS Jersey implementation
compile group: 'org.glassfish.jersey.containers', name: 'jersey-container-servlet', version: '2.25.1'
compile group: 'org.glassfish.jersey.media', name: 'jersey-media-json-jackson', version: '2.25.1'
compile group: 'org.glassfish.jersey.media', name: 'jersey-media-multipart', version: '2.25.1'
compile group: 'com.fasterxml.jackson.jaxrs', name: 'jackson-jaxrs-json-provider', version: '2.9.0'
Extended jersey's ResourceConfig to configure my RestApplication
#ApplicationPath("/")
public class RestApplicationConfig extends ResourceConfig {
private static final Logger LOGGER = LoggerFactory.getLogger(RestApplicationConfig.class);
public RestApplicationConfig() {
super();
configureResourcesAndFeatures();
}
private void configureResourcesAndFeatures() {
packages(RestApplicationConfig.class.getPackage().getName());
register(MultiPartFeature.class);
}
}
With all this setup my rest api works and I am able to make use of Jersey's multiple related classes in my code.
Now the problem is with CDI. In my resource class I am able to inject CDI managed resource/classes for example
#ApplicationScoped
#Path("/ping")
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public class PingResource {
private static final Logger LOGGER = LoggerFactory.getLogger(PingResource.class);
#Resource(lookup = "jndi_dpa_iss_rest_url")
private String issRestBaseUrlInResource;
#Inject
private DocumentService documentService;
}
In above class #Resource and #Inject are not able to resolve JNDI resource and managed bean. As soon as I enable jaxrs-2.1 feature in server.xml CDI injection works but then I loose jersey, it uses CXF.
DocumentService and its implementation class is defined as below. Everything is under same package as RestApplicationConfig class or it's sub-packages.
#ApplicationScoped
#Transactional(value = Transactional.TxType.NOT_SUPPORTED)
public class DocumentServiceImpl implements DocumentService {
// some code here
}
What do I need to use CDI in my rest resource classes?

Because there is no jersey extension for CDI 2.0 at the moment, I had to find workaround. Workaround is to manually query CDI container to the the type of bean we are interested in. This way we are manually injecting CDI bean in our resource class but the injected bean is managed bean instance so CDI has taken care of satisfying all its dependecies.
This we we are doing manual injection only in Resource layer but CDI should work fine for layer down.
Working code.
#ApplicationScoped
#Path("/ping")
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public class PingResource {
private DocumentService documentService = CDI.current().select(DocumentService.class).get();
}
Basically instead of #Inject manually query CDI container.

Related

Using constructor injection with CDI in OpenLiberty

I'm building a small Java EE 8 application that should run on OpenLiberty.
It has a JAX-RS ContainerResponseFilter that looks like this:
package my.package;
import javax.inject.Inject;
import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.container.ContainerResponseFilter;
import javax.ws.rs.ext.Provider;
#Provider
public class MyFilter implements ContainerResponseFilter {
private final MyService myService;
#Inject
public DiagnosticsFilter(final MyService myService) {
this.myService = myService;
}
#Override
public void filter(final ContainerRequestContext request, final ContainerResponseContext response) {
// Never mind this
}
}
If I write the filter like this and start my app, the myService argument to the constructor is null.
However, if field is annoted with #Inject and the constructor is omitted, the field is being injected correctly.
The MyService class is annotated with #Stateless, and in beans.xml I have set bean-discovery-mode="all".
Any idea what I'm doing wrong? Is this actually supposed to work? The Weld documentation suggests that it should, but I'm not sure it's in the CDI spec as well...
This is a long story...And some people are working to solve the problem: JAX-RS injection != CDI injection
It shoud be solved in JAX-RS 2.2 ad CDI injection should be used in place of JAX-RS injection and JAX-RS v3.0 will totally remove the JAX-RS injection
Read this on the subject:
https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
https://github.com/eclipse-ee4j/jaxrs-api/issues/569
https://github.com/eclipse-ee4j/jaxrs-api/issues/639
https://groups.google.com/forum/#!topic/microprofile/gvj94XBhtvM

Injecting #EJB in OmniFaces #Eager bean causes "Severe: No valid EE environment for injection of org.omnifaces.cdi.eager.EagerBeansRepository"

Using #ApplicationScoped #Named #Eager, my #EJB-injected #Stateless beans are not properly instantiated and evaluate to null.
I had an #ApplicationScoped #ManagedBean(eager=true) that was used to schedule a few jobs. Some #Stateless beans were injected using #EJB annotation, and that worked fine.
In the move to CDI annotations, I added the OmniFaces #Eager annotation as substitute for #ManagedBean(eager=true) which is missing in standard CDI:
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.EJB;
import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import javax.inject.Named;
import org.omnifaces.cdi.Eager;
#Named
#ApplicationScoped
#Eager
public class MyScheduler implements Serializable {
#EJB
private MyService myService;
#Inject
private MyNamedBean myNamedBean;
#PostConstruct
public void init() {
setupSchedulers();
}
#PreDestroy
public void destroy() {
destroySchedulers();
}
//...
}
Using this setup, the #PostConstruct method is correctly called on application startup (though it seems to run even before the context is initialized), but then myService evaluates to null.
In the log, the following warnings appear:
Severe: No valid EE environment for injection of org.omnifaces.cdi.eager.EagerBeansRepository
Severe: No valid EE environment for injection of my.package.MyScheduler
Info: Initializing Mojarra 2.2.8 ( 20140814-1418 https://svn.java.net/svn/mojarra~svn/tags/2.2.8#13507) for context '/tagific'
Since I need to access this bean from other ones, I couldn't use the #Singleton and #Schedule annotations.
How could I properly inject #Stateless beans in an #Named applications scoped bean that would be instantiated on application startup?
This looks like an initialization ordering bug in GlassFish. The #Eager #ApplicationScoped runs in a ServletContextListener. Apparently at that point GlassFish hasn't EJBs ready for injection. This construct works in e.g. WildFly.
However, in CDI's name of unifying various different depency injection approaches throughout Java EE, you can also just use #Inject instead of #EJB. The CDI proxy is capable of delegating further to the right #Stateless instance.
#Inject
private MyService myService;
You can also use #Inject inside EJBs itself, but as of now (Java EE 7) it doesn't yet support self-referencing for e.g. #Asynchronous methods. For that you have still to stick to #EJB.
That said, are you aware that Oracle stopped commercial support on GlassFish and that you'd better not use it for production environments? See also this blog.

#inject does not work with stateless EJB

Hi I have a very simple example. I created a resource in javaee 7 as follows:
#Path("greetings")
public class GreetingsResource {
#Inject
Sample s;
#GET
public JsonObject greetings(){
return Json.createObjectBuilder().add("first","1")
.add("second","2")
.add("third","3")
.add("fourth","4")
.add("helloworld", s.helloWorld())
.build();
}
}
Sample is the following simple EJB:
#Stateless
public class Sample {
public String helloWorld(){
return "Hello World";
}
}
Finally the resource Application class:
#ApplicationPath("resources")
public class RestConfiguration extends Application {
}
I can access the URL: "localhost:8081/jasonandjaxrs/resources/greetings"
The problem is that #Inject gives the following error:
1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=sample,parent=GreetingsResource,qualifiers={}),position=-1,optional=false
But #EJB seems to work. I am trying to understand why #Inject does not work? Thank you.
You can't use CDI (means #Inject) with this setup. CDI only works with beans managed by the container which is not the case for JAX-RS resource classes (your GreetingsResource).
JAX-RS 2.0 does not support injection of EJBs into JAX-RS components
(providers, resources).
If you use #Inject in your case the injection is provided by the HK2 dependency injection framework which isn't aware of normal CDI beans. It even shouldn't work if you use #EJB, I don't know why it works, maybe this has to do with Java EE 7.
As it works for you there should be no problem in using #EJB here, but there are also some alternative approaches in my response to this question.
See also:
Inject a EJB into JAX-RS (RESTfull service)
JERSEY-2040 Add support for injection of EJBs into Jersey-managed providers and resources

NPE with #Inject in WAR from a JPA utility jar

env: JBoss 7.1.1, jdk 1.7, WELD module upgraded to 1.1.10(just in case)
I have a JPA project that I am adding to the WEB-INF\lib directory. It contains my entities and DAO objects, which has the Entity Manager inject. I'm using custom annotations to qualify the PersistenceContext, which is Produced in a Resources class. I've run Arquillian tests in this project to ensure it works.
I have a beans.xml file in the \META-INF\ directory of the JPA jar and in the \WEB-INF\ directory of the war file. I even printed it out and put it on my desk, still didn't help.
Within my war file I have a class that is injecting a DAO object from the JPA jar. Its not working, its null.
I've found examples from the jboss (without jpa jar) with CDI and it works.
I've looked for examples but cannot find any with a jpa jar. Can anyone point me to where there is an example of a jee6 web app, with a JPA utility jar, that uses annotations to inject something from the JPA jar into the war classes?
Thank you very much for reading this plea.
--------------------additional info-----------------
structure of war file
META-INF
->maven
-->com.xyz
--->web
---->pom.properties
---->pom.xml
->MANIFEST.MF
WEB-INF
->classes
->lib
-->entities.jar
->beans.xml
->faces-config.xml
->web.xml
stack trace:
22:23:12,011 INFO [org.quartz.core.JobRunShell] (DefaultQuartzScheduler_Worker-2) Job DEFAULT.extractDir threw a JobExecutionException: : org.quartz.JobExecutionException: java.lang.NullPointerException [See nested exception: java.lang.NullPointerException]
at com.xyz.asp.commsrv.scheduler.jobs.DirScanJob.execute(DirScanJob.java:149) [classes:]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz-2.1.7.jar:]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz-2.1.7.jar:]
Caused by: java.lang.NullPointerException
at com.xyz.asp.commsrv.scheduler.jobs.DirScanJob.execute(DirScanJob.java:140) [classes:]
... 2 more
This is the class that has the DAO object injected. This is a quartz scheduler job which is started by a ServletContextListener during jboss startup:
#DisallowConcurrentExecution
#PersistJobDataAfterExecution
public class DirScanJob implements Job{
...
#Inject
FiletracksentHome ftsHome;
#Override
public void execute(JobExecutionContext context) throw JobExecutionException{
...
BigDecimal bd = ftsHome.nextId()
}
}
This class resides in entities.jar:
#Stateless
public class FiletracksentHome{
#Inject
#DatabaseEntities
private EntityManager entityManager;
public BigDecimal nextId(){
...
}
}
CDI is available in the ServletContextListener but nothing within the context of the Quartz Scheduler. I didn't want to bother with another library, since CDI wasn't necessary. I injected some properties that I needed using the #Resource annotation within the ServletContextListener implementation ...
#Resource(lookup = "java:app/env/quartzjobdirectory")
private String quartzJobDirectory;
and within the web.xml ...
<env-entry>
<description>Quartz Jobs Directory</description>
<env-entry-name>java:app/env/quartzjobdirectory</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/appl/jboss-as-7.1.1.Final/standalone/configuration/quartz_jobs/</env-entry-value>
</env-entry>
And for the EJB calls within the Quartz Jobs because DI is not available I did some JNDI calls, such as ...
InitialContext ic = new InitialContext();
readyDocs = (ReadyDocumentsLocal) ic.lookup("java:global/commsrv-ear-1.0.0/commsrv-ejb-1.0.0/ReadyDocumentsBean!com.ista.asp.commsrv.ReadyDocumentsLocal");
and the EJB ...
#Stateless
public class ReadyDocumentsBean implements ReadyDocumentsLocal {
...
}
FYI ... jboss as 7.1 will output to the server.log the JNDI bindings for session beans.

EJB Injection failure on deploy

I've got a problem exxh EJB's.
First of all, my setup: I am using GlassFish & JEE6. I have got a REST-Service packaged as a WAR and a bean packaged as an EJB-Jar. They are not inside an EAR.
The EJB should be used from the REST-WAR via #EJB, but when I try to deploy the WAR, GlassFish shows this error:
Error occurred during deployment:
Exception while deploying the app [exx-upload-1.0] : Cannot resolve reference Local ejb-ref name=com.ex.exx.model.FileUpload/ocr,Local 3.x interface =com.ex.exx.api.IOCRService,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session. Please see server.log for more details.
(The EJB was deployed before without any erros).
I have no clue why. Here is the EJB Code:
Interface:
#Local
public interface IOCRService {
public String performOCRonImage(BufferedImage input);
}
and Implementation:
#Stateless
#LocalBean
public class OCRScanner implements IOCRService {
private Logger logger = Logger.getLogger(this.getClass().getName());
private final static String NOT_RECOGNIZED = "Can not regocnize text";
/**
* Default constructor.
*/
public OCRScanner() {
logger.log(Level.INFO, "### OCR SCANNER BUILD" + this);
}
public String performOCRonImage(BufferedImage input) {
logger.log(Level.INFO, "### OCR SCANNER CALLED" + this);
}
...
And here is the important part in the WAR:
public class FileUpload {
private final File PROPERTIES_FILE = new File(
"fileUploadProperties.properties");
private final String PARAMETER_NAME = "file";
private final Logger logger = Logger.getLogger(this.getClass().getName());
#EJB
private IOCRService ocr;
public Response uploadFile(...) {
// do some stuff
logger.log(Level.INFO, "### EJB" + ocr.toString())
}
Anny suggestions? I can not find my failure here.
Solved this, by replaceing #Local with #Remote.
This works, however, I am not satisfied as I do not understand why.
Basically, given the specs (eg. explained in the tutorial), an application can only access other application's EJB, if they are decorated with #Remote.
Thus, you have 3 options:
decorate your EJB with #Remote (what you have done),
package both together inside an ear (as they would reside in the
same application then). But if you intent to deploy them in seperate
applications or even seperate servers, use 1.)
use CDI with #Inject, but this will still only discover the EJB if
either in the same application, or decorated as #Remote if not.
HTH,
Alex
You should not use #EJB if the target is not an EJB. I guess this is your case because you are trying to inject into a class in your WAR.
Instead use:
#Inject
private IOCRService ocr;
Basically, #Inject is better in most cases, because:
it is more typesafe,
it supports #Alternatives
it is aware of the scope of the injected object.
Another solution it's to add #Stateless(name=""), this worked form