How I can register/unregister new entity class (with annotation or ORM XML) at runtime after EMF is initialized and first EntityManager are created.
I know about similar questions, for example:
Adding entity classes dynamically at runtime
The difference in the level of dynamism: we use OSGI plugins that can be installed/uninstalled at runtime and can contatais entity classes for own data.
That functionality already implemented using JDO/DataNucleus and works in production about 3 years. But JDO seems to be dead (at Apache too). DataNucleus has relatively small adoption and only one active (and good) developer (that sad because project very interesting in many ways ).
How to do something similar with popular JPA implementations?
You can not add classes to an existing EntityManagerFactory. What you should do is create one persistence unit per bundle. So when updating the bundle you get a new EntityManagerFactory as a service. Unfortunately current Apache Aries jpa has a known issue with updating bundles that contain a persistence unit.
I am working on code for an Apache Aries jpa 2.0 release that will be able to handle this.
Related
Our application project is an OSGI bundle using JPA with EclipseLink and JTA, and needs single-table multi-tenancy, where tenant ID comes from a REST request. From what I've read and tried, it almost seems that is impossible:
Since tenant ID changes depending on the request, each request with a new tenant ID needs to manually create a new PersistenceContext (EntityManager) with the appropriate property.
But persistence contexts can't be manually created when using JTA (#PersistenceUnit does not get injected and Persistence.createEntityManagerFactory does not work), according to http://tomee.apache.org/jpa-concepts.html.
Am I missing something? Or is this literally impossible to do?
You can set multitenant/discriminator properties in the entity manager for a request. But it is not safe for multi-threading and lazy initialization.
I tried our CMobileCom JPA that supports single-table multitenancy. For each tenant, a new EntityManager should be used. That is, an EntityManager should not be shared to access data for multiple tenants. This is also true for EclipseLink.
Disclaimer: I am a developer of CMobileCom JPA, a light weight JPA implementation for Java and Android.
I would like to add some persistence to save some application data and I feel like I have searched the web for days without any success.
I have found some older links and the eclipse Gemini project. However, I suppose I am too new to understand the implementation or it is just a little dated. Probably, more of my lack of knowledge.
Anyway, is anyone willing to point me to a working example and/or provide me with some assistance offline?
If you want to use H2 with plain JDBC, you won't need the Gemini project. In this case you can wrap the H2.jar with the corresponding JDBC driver in a single bundle (plugin) and implement your db access there.
The Gemini project is for using persistence via JPA, which works with any JDBC capable database.
In either case, be aware that in an OSGi environment like Eclipse RCP, there is one classloader per bundle. This leads to lots of complications. We are using Hibernate as JPA engine within our E4 application and we cannot split the JPA configuration, the JPA engine and the entity beans :-(
We tried using EclipseLink as JPA engine but this doesn't work on all our entities :-(
I found this blog article by Raja Kannappan which briefly explains class loading in OSGi.
You can read more about JPA in The Java EE Tutorials (although JPA is part of Java SE, too).
Hope this helps.
In a Java EE project, I've found a recurrent solution for configuring the application that consists on the use of #Injection of primitives/Strings on managed beans, avoiding external dependencies on that way.
What about #Entity? Is there some "good practice code" for configuring entities using only Java EE (no Spring)?
CDI does not support injection into objects that are not created by the CDI container (more info here). Since entities are created by JPA provider when they are loaded from the DB, CDI would obviously not work.
So, in plain Java EE world your only options are to move the logic depending on the injected resources out of the entities, or to access the resources via static methods from within the entities. Keep in mind the increased complexity when testing the entities if static state/methods are used.
Is it possible to create a DAO in Java EE environment, which uses JPA, but does not need to be a Stateless bean? I am asking because I have a huge number of EJBs, just because I need a few #Resources in the DAOs, i.e. EntityManager and so on.
What would you recommend as a way to simplify DAOs in huge project, it seems to me that having a full EJB (instead of a simple object) for a DAO is eccessive.
DAOs are accessed both from other EJBs and from servlets.
It's possible, but not recommended, to inject an EntityManager into other types of beans (like e.g. CDI managed beans) along with a UserTransaction and then manually manage your transactions.
In Java EE 7, JTA 1.2 contributes CDI compatible extensions for declarative transactions just like EJBs have, but at the moment there's no final release of any Java EE 7 AS yet.
it seems to me that having a full EJB (instead of a simple object) for a DAO is excessive.
Why do you think that? A "full" EJB is probably more lightweight than any other alternative, and almost certainly more lightweight than any home cooked thing you can come up with based on an EntityManager.
Don't forget that EJB beans share their resources automatically and that injection points only get proxies. If you mainly use stateless EJB beans, those proxies are akin to URLs, and not the "real" beans. This makes stateless and local EJB beans incredibly lightweight to inject.
Meaning, if you have a given Service where you inject (say) 10 DAOs, that each have an injected EntityManager, and during a given call 3 DAOs are invoked then only 3 beans are actually used and only 1 EntityManager instance. It really is rather efficient.
You can implement DAO as POJO is you want. But the DAO needs an EntitManager which must come from somewhere. Either
you look it up in the POJO with InitialContext#lookup
you pass it in the constructor of the POJO
You must pay attention that InitialContext#lookup will work only if the parent EJB has declared a dependency to the entity manager, even if it doesn't use it.
Whether it's worth the trouble is a judgment call. Local EJB are very cheap, and having many EJB is not a problem for the app server. It's more a problem of understandability by developpers. (See this other answer of me)
Another question to ask is whether you really need the DAOs. With EJB 3, they become very thin layer of logic, and it's worth pondering the pros and cons
I'm trying to write a Java EE 6 application using JPA but without using Hibernate or Spring. I used Netbeans to generate the JPA classes, and I created the tables in Postgres, but I am not able to run DbUnit tests in those JPA classes.
I have tried to base my test unit on the example described in this site: http://www.roseindia.net/testingtools/DbUnit/gettingstarted.shtml but it does not work. I keep getting a "java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory" even though I added slf4j to the project libraries in the IDE.
One thing that I find rather odd about the roseindia site example is that it does not seem to have a caller object for the test object created. I am not sure if a caller object is even needed (complete n00b in JavaEE programming, and kind of lost still).
If you choose to use entities (java classes annotated with #Entity, representing database records), you have to use some JPA provider. You are not restricted to Hibernate, though.
If you're frightened by JPA, your other option is to use plain JDBC. It is far easier to understand, if it's your learning-exercise application, it might be a good idea to try and see how it works. JPA is built on top of JDBC, so when you think you're ready for it, you'll have a solid knowledge base.