I'm building a simple web app using jsp and servlets. The application is deployed on Glassfish server and use JPA / Hibernate.
I need to create a Quartz Job that work with JPA (select / update...). I've tried to add :
#PersistenceUnit
private EntityManagerFactory emf;
into my Job but it's null. By the way it works for my servlets and ServletContextListener.
I don't see how I can force glassfish to inject the persistence unit.
Any idea ?
THX
Injecting resources works only for container managed classes. Servlets and ServletContextListeners are container managed classes, your Quarz Job is not. Easiest way around is to use JNDI lookup.
Related
I have demo application with JPA 2.1 and weblogic 12.1.3 deployment works fine and am able to get EntityManager which is annotated on the stateless bean.
I have application where I have ejb-jar.xml, on this file we have configured all MDB and session beans, Note: application is not using annotation.
And ejb-jar.xml uses http://java.sun.com/dtd/ejb-jar_2_0.dtd(ejb 2), but our application is running on weblogic 12.1.3. On this configuration, I tried to get EntityManager with the help of annotation in MDB, but am getting null object.
Question.
1. Is it possible to annotate EntityManager, with above configuration.
2. If not possible what are alternative ways. meaning I need to move all the configuration of ejb-jar.xml to annotation.
Thanks
Daya
I've searched for an answer to my problem on google and various forums, but couldn't find a solution. I'm currently trying to modify the persistence.xml at runtime by adding a persistence unit to the file.
The solutions for this question were always "pass a Map of properties when creating an EntityManagerFactory (or EntityManager)" but i need to save the new persistence unit in the persistence.xml, because the application is going to have 100 or even more persistence unit's, one for each tenant that will register to the service, each tenant will have his own database. I'm currently using EclipseLink 2.3.3 as my JPA implementation, EJB 3.1 and jboss 7.1.1.Final as my application server.
Is it possible to modify the persistence.xml at runtime (on the fly)?
The persistence.xml is a deployed artifact, so would be difficult to modify at runtime. I think passing a properties map to createEntityManagerFactory is your best solution, what issue are you having with this?
You may also want to try using the PersistenceProvider API, createContainerEntityManagerFactory() that takes a PersistenceUnitInfo.
Also, consider using EclipseLink's multi-tenant support,
http://www.eclipse.org/eclipselink/documentation/2.5/solutions/multitenancy.htm
I want to test an enterprise java bean (that should later be deployed to a JBoss server) using JUnit. But I don't exactly know how tools I can use for this. Plain JUnit fails because of the missing EJB Container and the caused lack of needed injections.
Googling a bit around lead me to a library called JBoss EJB embedded container, but it seems that it is obsolete. I also couldn't find any source or binary files to download.
So please help, what's a easy way to locally generate a "mock" container that is able to run the JUnit tests on the enterprise beans?
Greetings
Ben
I suggest you to have a look at Arquillian:
Arquillian enables you to test your business logic in a remote or embedded container. Alternatively, it can deploy an archive to the container so the test can interact as a remote client.
There is still a living Embedded JBoss AS. The Seam Framework also provides a testing environment with an embedded JBoss to run component tests (with TestNG) of your application.
openEJB is an embedded EJB container that's a perfect fit for unit testing EJBs. You can test them outside your normal app server. And, it's fast! And, it spins up fast! And, it has an Eclipse plugin for easy management! Gotta love it! It's been around for a while, there are plenty of tutorials on how to set it up and use it, so you shouldn't have problems with it.
You can use a EJB remote client in your JUnit program to test your EJB. Only drawback is that you have to have a running Application Server during testing.
Check out this blog entry for an example on how to invoke a EJB remotely.
It's been awhile, but I always wrote my EJBs as simple wrappers of POJOs. An interface would define the methods, and both the POJO and the EJB (session, of course) would implement that interface.
I could fully test the "business logic" of the POJOs without any container issues. Then if I had the server running, I could run the same tests against the session bean, just by testing against the client instead of the POJO...
Since I did not need the JNDI stuff (e.g. Cannot instantiate class: org.jnp.interfaces.NamingContextFactory) altogether in my DAO (ORM interface) tests it was enough for me to
include the hibernate jars in the classpath
remove/outcomment the <jta-data-source>...</jta-data-source> part in my persistence.xml
inject/assign your own entitymanagerfactory with Persistence.createEntityManagerFactory( "my-persistence-unit-name" )
How do I use a deployed EJB app from a separate JSF application?
I'm attempting to separate the two applications and access the EJB through the remote interface. To do this I have two eclipse projects - one contains the EJB and persistence logic, tested independently and works. I then created a JSF project that references the EJB project (so I gain access to the remote interface), however this fails when attempting to either inject the EJB instance or lookup the JNDI name (I've tried several variants to no avail). This is what my JSF backing bean contains:
#EJB(lookup="java:global/LocEJB/LocalityEJB!com.ame.business.LocalityEJBRemote")
private LocalityEJBRemote locality;
This is on Glassfish, and I am only referencing the EJB project and not packaging it with the JSF project. When I do the latter, I receive error initializing EJB container problems on the JSF project. So, how do I access the remote EJB and does the way I'm approaching this make any sense?
Thanks in advance!
Your JSF application has to know about the EJB interfaces (at least they did on EJB 2.0). You're using the Proxy pattern to hide the fact that this is a remote component from your JSF client.
First of all you can not use Local interface if trying to access outside the container. You must use Remote Interface.
You can define your Remote interface in the sun-web.xml or EJB injection in the bean.
sun-web.xml code:
<ejb-ref>
<ejb-ref-name>com.xxx.session.UserRemote</ejb-ref-name>
<jndi-name>corbaname:iiop:127.0.0.xxx:3700#com.xxx.session.UserRemote</jndi-name>
</ejb-ref>
Another thing you must have Remote interfaces in your classpath.
I'm working on a maven project which uses seam 2.2.0, hibernate 3.5.0-CR-2 as JPA provider, DB2 as database server and Websphere 7 as application server. Now I'm facing de following problem:
In my EJBs that are seen also as SEAM components I want to use the EntityManager from EJB container (#PersistenceContext private EntityManager em) not Seam's EntityManager (#In private EntityManager em). But this is the problem, I cannot obtain an EntityManager using #PersistenceContext.
On server logs it sais that it cannot create an EntityManagerFactory and gets a ClassCastException:
java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence incompatible with javax.persistence.spi.PersistenceProvider
After a lot of debugging and searching on forums I'm assuming that the problem is that Websphere doesn't use the Hibernate JPA provider.
Has anyone faced this problem and has a solution? I configured already WAS class loader order for my application to load the classes with the application class loader first and I\ve packed all necessary jars in application ear as written in: WAS InfoCenter: Features for EJB 3.0 development . If necessary I'll post my persistence.xml, components.xml files and stack trace.
I've found this problem discussed also here:
Websphere EntityManagerFactory creation problem
Hibernate 3.3 fail to create entity manager factory in Websphere 7.0. Please help
Any hint will be useful.
Thanks in advance!
Mihaela
I suspect that you've included the JPA API jar in your EAR. When using "parent last" (also known as "load classes with application class loader first"), your application is loading a second copy of the javax.persistence.spi.PersistenceProvider class, which is incompatible with the copy included in WAS. You need to either remove those classes from your EAR or change back to "parent first" delegation mode.