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.
Related
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.
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.
In a Spring XML configuration, I have the followings:
<bean id="sessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
....
</bean>
and in a Java class, I have
#Autowired
private SessionFactory sessionFactory;
without a setter. That works.
Now, I change the sessionFactory to a Java configuration as the followings.
#Configuration
#EnableTransactionManagement
#PropertySource({ "classpath:jdbc.properties" })
public class PersistenceConfig {
#Bean
public SessionFactory sessionFactory() {
LocalSessionFactoryBuilder lsfb = new LocalSessionFactoryBuilder(dataSource());
lsfb.addAnnotatedClasses(...);
lsfb.setProperties(hibernateProperties());
return lsfb.buildSessionFactory();
}
// ...
}
And I get an error "could not autowire field". Adding a setter doesn't help. Why the sessionFactory can't get autowired with a Java configuration?
BTW, I can work around this problem by having a Java configuration for the DAO as well.
I see that there is no #ComponentScan annotation on your #Configuration class, so probably the problem is in how you import this configuration. Please ensure that all particular beans live in the same context or at least that PersistenceConfig is parent to the context in which you are autowiring SessionFactory
I have added the #ComponentScan annotation and it doesn't solve the problem. The annotation tells Spring to look for any #Components to configure as beans. This problem seems to me is that during the process of creating a bean with #Component, it can't find a bean configured in my Java configuration file which is started in WebAppInitializer.
I have the structure described below, but I cannot make it so MyWebService has its member myService not null. The code of MyWebService is properly executed when I call the webservice. When I look at the JBoss logs, I keep seeing that MyServiceBean has several JNDI bindings allocated to it.
So how do I bind MyServiceBean to MyWebService?
Thanks!
my-ejb.jar:
#Local
public interface MyServiceBeanLocal {
...
}
#Stateless
public class MyServiceBean implements MyServiceBeanLocal {
...
}
my-web.war:
#Webservice(...)
public class MyWebService {
#EJB
MyServiceBeanLocal myService;
...
}
my-ear.ear:
* my-ear.ear
|-* my-web.war
|-* my-ejb.jar
Have you tried using MyServiceBeanLocal as a Remote interface ? You are trying to use dependency injection from a Web module and for a Local Interface .This is not actually suggested. Anyway, At first try to make the interface #Remote . If still it doesn't work try to use`Remote Look up from the Web module for your Remote interface link
I use CXF. CXF is not an EJB container, hence the issues I got.
I had to manually bind the EJBs, using their full name.
I have deployed a war-file, with actionclasses and a facade, and a jar-file with ejb-components (a stateless bean, a couple of entities and a persistence.xml) on glassfish3. My problem is that i cant find my remote interface to the stateless bean from my facade.
My bean and interface looks like:
#Remote
public interface RecordService {...
#Stateless(name="RecordServiceBean", mappedName="ejb/RecordServiceJNDI")
public class RecordServiceImpl implements RecordService {
#PersistenceContext(unitName="record_persistence_ctx")
private EntityManager em;...
and if i look in the server.log the portable jndi looks like:
Portable JNDI names for EJB RecordServiceBean : [java:global/recordEjb/RecordServiceBean, java:global/recordEjb/RecordServiceBean!domain.service.RecordService]|#]
and my facade:
...InitialContext ctx= new InitialContext();
try{
recordService = (RecordService) ctx.lookup("java:global/recordEjb/RecordServiceBean!domain.service.RecordService");
}
catch(Throwable t){
System.out.println("ooops");
try{
recordService = (RecordService)ctx.lookup("java:global/recordEjb/RecordServiceImpl");
}
catch(Throwable t2){
System.out.println("noooo!");
}...
}
and when the facade makes the first call this exception occur:
javax.naming.NamingException: Lookup failed for 'java:global/recordEjb/RecordServiceBean!domain.service.RecordService' in SerialContext [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacedomain.service.RecordService [Root exception is java.lang.ClassNotFoundException: domain.service.RecordService]]
and the second call:
javax.naming.NamingException: Lookup failed for 'java:global/recordEjb/RecordServiceBean' in SerialContext [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacedomain.service.RecordService [Root exception is java.lang.ClassNotFoundException: domain.service.RecordService]]
I have also tested to inject the bean with the #EJB-annotation:
#EJB(name="RecordServiceBean")
private RecordService recordService;
But that doesnt work either. What have i missed? I tried with an ejb-jar.xml but that shouldnt be nessesary. Is there anyone who can tell me how to fix this problem?
I found a sollution to this problem. If i pack the interfacefile in a jarfile and drop that jar in to WEB-INF/lib in the warfile the problem is solved.
When server gets started, the global jndi names of the interfaces are displayed in console.
Use those to lookup interfaces instead of trying to call them by giving names explicitly.
Have you tried commenting out all the ejb related sections of your xml files and then using just
#Stateless
public class RecordServiceImpl implements RecordService {
and then
#EJB
private RecordService recordService;
They've tried to make the process fairly brain dead in EJB 3.1
Also, while JNDI browsing didn't make it into gf 3.0 you can dig up some info with
asadmin list-jndi-entries --context java:global/yourAppName