I am running a JBoss Seam web application with Hibernate as the persistence provider. I am considering migrating to OSGI to simplify deployment and updates.
I don't have any experience yet with OSGI, so I don't know if this can be done and what the limitations are.
For instance, if I change entity classes and I want Hibernate to drop some tables and create some new ones, will that be possible? Does hibernate need to have hooks into OSGI so it knows to drop table a and create table b?
Walter
I'm not sure I fully grasp your question. If you choose to use OSGi to modularize your application, that choice has no impact on the behavior of Hibernate. You can, of course, make calls into Hibernate's SchemaExport or SchemaUpdate APIs when you activate bundles to manage your schema, but Hibernate won't drive that process for you. You'll have to do it yourself.
Related
Our application is a middle-tier application that provides a dozen or so front-end application with access to a couple dozen databases (and other data sources) on the back end.
We decided on using OSGi to separate the unrelated bits of code into separate bundles. This ensures proper code encapsulation and even allows for hot-swapping of specific bundles.
One advantage of this is that any code speaking to a specific database is isolated to a single bundle. It also allows us to simply drop in a new bundle for a new destination, and seamlessly integrates the new code. It also ensures that if a single back-end data source is down, that requests to other data sources are unaffected. One complication is that each of those bundles is loaded by a separate ClassLoader.
We'd like to start using JPA for our new destinations that we're building. Previously, we have been using JDBC directly to send SQL queries and updates.
We've looked into Hibernate 4, but it seems that it was built on the assumption that everything is loaded using a single ClassLoader. Switching between ClassLoaders for different bundles does not appear to be something it can handle consistently.
While it seems that Hibernate 5 may have corrected that issue, all the tutorials/documentation I've found for it gloss over the complexities of configuration. Most simply assume you are using a single application-level configuration file, which will not suit our needs at all.
So, my questions are:
Does Hibernate 5 properly handle connecting to multiple databases, with the configuration/POJos for each database loaded by a different ClassLoader?
How do we configure Hibernate to connect to multiple databases using multiple ClassLoaders?
Is there another JPA framework that might be better suited to our specific needs?
Hibernate is fine but for OSGi usage you also need an intermediary. In the OSGi specs this is defined by the OSGi JPA service spec. It defines how to connect to a JPA provider in OSGi without a hard reference to it.
This spec is implemented by Aries JPA. It also provides additional support for blueprint and declarative services. There is also Aries transaction control service that takes similar approach to supporting JPA and transactions in OSGi it also uses the core of Aries JPA but is a bit different in usage.
The last part you might need is pax-jdbc which allows to define a XA datasource just with configuration. The examples already use it.
To get started easily you can use Apache Karaf which has features for all of the above.
Aries JPA allows to use different databases in the same OSGi application.
I am working on a Java project for the university and I am trying to learn about framework, technologies and best practices for creating a well structured software that follows software engineering principles. I decided to use Spring (Spring-data-jpa), and Hibernate for the standalone software and now I am having some trouble in understanding how to use the Java Persistence Api to create an abstraction layer above the Hibernate implementation provider. What I am trying to figure out is in which part (configuration file or java class) I can switch from an ORM tool to another one. I saw that I have to use the persistence.xml file to specify the persistence unit and persistence context and also the DB parameters, but it's not clear how the EntityManager bind itself with the underlying ORM tool and in which properties this bind is set. Is the "provider" properties inside persistence.xml file that create this binding? Any link/references/examples or guide will be appreciated, thanks in advance and excuse me for my english ;)
Each persistence unit in he persistence.xml file is associated to a provider. For example, with Hibernate:
<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
If you want to use another provider, you'll specify another value for this element.
Note that this is usually unnecessary, because you typically use only one provider in an application. If a single provider is available in the classpath, JPA will use that one. So switching from Hibernate to EclipseLink for example just consists in having the EclipseLink jars in the classpath rather than the Hibernate jars.
Hibernate works on the JPA API so you don't have to explicitly configure JPA if you are using hibernate. The ORM integration happens in the DAO "Data Access Object" layer of your application.
I'm wanting using JPA in ear project. Development project must be started ASAP so I have not a lot of time to research and investigate. Could you say please JPA API is restricted functionality of Hibernate or no. At this moment I'm using Hibernate directly. For example in future I'm planing to use hibernate-search and maybe hibernare-validate and -shard. Can I be sure that in future I will not have problem with using this.
And one more example - can I use HAR archive and JPA together.
Why JPA? For project will available RESTful service (jersey or resteassy implementation). And as I looked in much case using JPA for this. I'm a newbie in this so it's only my IMHO. May be i mistakes.
Thanks a lot.
Best regards
Artem
JPA is a subset of hibernate, but you're not limited to it. If you need a hibernate specific feature, you can generally use it at the cost of being tied to hibernate. For example, we've mixed in hibernate annotations with JPA ones, including the validater ones, without trouble.
JPA in theory lets you change the persistance provider later.
Sticking to only JPA compatible configuration can cause more trouble that is solved by the dubious promise of seamlessly swapping providers however.
I've been working in Glassfish 3, JPA and Java EE 6. In a web container you can just inject the Entity Manager into an EJB and let that handle your transactions, rollbacks, etc. What do I do in a desktop application. Obviously that does not work. I know I would still use JPA for ORM. But would I create an EntityMangerFactory and then create an Entitymanager from that? Would I have to handle my transactions manually? It would great if I could see some sample applications. Thanks!
EntityManagerFactory entityManagerFactory =
Persistence.createEntityManagerFactory("DS");
em = entityManagerFactory.createEntityManager();
You have to handle transactions, by calling em.getTransaction.begin() and em.getTransaction.commit(), if you don't use the spring-framework or something else.
Well i suggest to try using Spring +JPA, there you do not need a container ,it is just the application context and you can configure transactions there.
You will not take care of the transactions ,just annotate your methods that you want to be #Transactional.
You could use Spring, this will bring you the plesent you know from JEE6 to desktop applications. (Of course it is not 100% the same!)
Another option could be to use so called Embeddable EJB Container. It could provide you same services as injection, CMT etc which you might be accustomed to.
I've built a 2-tier Java Swing client using Hibernate and Swing, and I will never do it again. If I had to rebuild it today, I would use raw JDBC queries, or maybe a very thin ORM mapping framework like iBatis.
The reason that Hibernate (and I assume other JPA implementations, although my experience is only with Hibernate) is so different in a desktop environment is 1) because objects tend to have a much longer lifespan on the desktop, and 2) it's very hard to know when an object will be accessed, so correct transaction handling for lazy loading is problematic.
The web request-response paradigm is fundamentally transactional, so it's very easy to demarcate your transactions there. On the desktop, every keypress, even just a MouseMovedEvent, could potentially trigger a database query or lazy load, so it's much harder to know when to initiate and commit transactions.
Error handling and object refreshing is a big problem, since objects tend to have a much longer life (often for the duration of the application launch). In Hibernate, exceptions are non-recoverable, which means that you're supposed to reload everything from the db. This is fine on the web, but definitely not fine when you have thousands of objects embedded in various models throughout your GUI.
I have entities that required versioning support and from time to time, i will need to retrieve old version of the entity . should i just use
options available
1. http://stackoverflow.com/questions/762405/database-data-versioning
2. jboss envers (can this be used on any web server,tomcat,jetty, appengine) ?
3. any similar library like jboss envers that ease to do versioning?
JBoss Envers can be used always when you're using Hibernate as the persistence provider. It's actually bundled with the new Hibernate 3.5. Envers is a an excellent tool, but I has one drawback - you can version only entities that aggregate versioned entities. This means that if you want to version Entity A and it has fields of types B and C, which are also entities - B and C should be versioned by envers as well - if your entities have a tight coupling(which is bad design, but is fairly possible) you'll have to version the whole project and there is some overhead to that.
We personally opted for a lighter custom versioning solution after we investigated Envers, but if it fits your bill - you should definitely use it. I'm not aware of other tools offering its capabilities.