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
Related
I am refactoring a JEE REST (using JAX-RS 2.0) application as a Spring Boot application. My old app is packaged in a .war and has a jar file with entities and the persistence.xml configuration file for JPA. This jar is copied into WEB-INF/lib directory. I know Spring JPA works a different way and I don't use persistence.xml now but I wonder if I can package my JPA entity classes in a jar and include them in my Spring Boot apps just like I am doing now. This way I can easily reuse that jar in different Spring Boot Applications.
I'm pretty certain you can do this since I have done the same on one of my projects very recently. The only thing you need to do is make sure that you add an #EntityScan annotation on your main Spring Boot config class with the base package of your entities in the JAR.
#EntityScan("my.external.jar.entity.package")
Spring Boot doesn't really care whether the JPA entities are packages as a separate jar or included into the application. Its a runtime framework and in runtime classes can be loaded from the jar (it should reside in BOOT-INF/lib or 'directly' from the *.class files in the spring boot artifact.
Now there is a rule in spring boot, that says that it will scan for beans (including entities) only in the package where your "main" class resides or under it. This is done in order to avoid long process of analysis of, say, third-party classes that you might use. These third-party classes are usually not spring aware at all, at certainly do not contain any spring beans.
Example:
Say, you place your "main" class (the one annotated with #SpringBootApplication) in the package: com.mycompany.myapp
In this case, the following packages will be scanned (just a couple of examples):
com.mycompany.myapp
com.mycompany.myapp.web
com.mycompany.myapp.services.bl
com.mycompany.myapp.whatever.doesnt.matter
...
The following packages won't be scanned however (again, examples, not the full list):
com.mycompany
com.anothercompany
org.hibernate
If you want to to "alter" this default rule and place the entities in the package that doesn't adhere this convention, for example com.mycompany.jpa.entities then you should indeed use #EntityScan annotation as our colleagues have already suggested.
You can read about this topic here. You might also need to get familiar with #EnableJpaRepositories if you're using spring data but, while related, its a different topic.
In my case I had this problem, and after importing the library in the application's pom.xml, in the SpringBoot Project Main class, insert an #EntityScan annotation with the first package and *. Like this: #EntityScan ("br.*")
Similar to What to put into jta-data-source of persistence.xml? and How to map jpa datasources in WildFly?
However, I am asking for something that would work on all vendors or at least WildFly, Glassfish/Payara, WebSphere Application Server classic, WebSphere Application Server Liberty, TomEE. I am not looking for something that works in a Java SE Unit test.
So far I found that java:comp/env/jdbc/xxx works in WebSphere Application Server and TomEE. There's a mapping exercise (which is expected) to get it working but I cannot get the same to work on GlassFish/Payara and JBoss/WildFly.
More specifically I do not wish to use default data source because for my scenario I am actually working on two different data sources. E.g. for reference data and another for transactional.
If all of the app servers you work with are Java EE 7 compliant, you can use the default data source, which is required per EE7 spec to be available at:
java:comp/DefaultDataSource
The app server you run on ought to let you customize the configuration of the DefaultDataSource.
Since I'm familiar with WebSphere Liberty, I can point you to this doc for default data sources on Liberty:
Configuring a default data source
If you are using WebSphere traditional, as of v9.0 it supports Java EE 7, and has a default data source available out of the box (under the spec mandated JNDI name).
If you want to use the same JNDI name that works on all servers, it's best to use resource references, as explained in What is resource-ref in web.xml used for?
Basically, you would define an arbitrary JNDI name (ideally without any java:comp prefix or similar, just something like "myDatasource") and then map it to the concrete JNDI name provided by the target server.You would need to define a server-specific descriptor for each server with the mapping the if the server cannot use the JNDI directly (e.g. glassfish-web.xml for GlassFish/Payara, jboss-web.xml for WildFly, ibm-web-bnd.xml for WebSphere Classic and Liberty). TomEE seems to support references without any prefix, so it should be able to configure a datasource without any additional mapping if you choose a name without a prefix.
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" )
I am trying to use Seam to persist my jpa entities, when I reference an entity that is in a jar seam says unknown entity. I don't want to add all classes in persistence.xml I want seam to scan my jars and auto detect entities (as done by spring).
What am I missing?
It actually depends a lot on the environment of your application.
If it's Java SE (for example war packaged application deployed on tomcat), your jars are not scanned for entities that compose your persistence unit. Those classes are seen as normal java classes, entity manager doesn't care about them that much... And you have to point them manually, or switch to Java EE and ear...
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.