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.
Related
Is it possible to use EclipseLink with QUarkus? Or is Quarkus too hardly coupled with Hibernate?
We are in the process of choosing our MP implementation and we want to stick as close to the reference impls as possible
I am not seeing much information on https://quarkus.io/guides/ or even this very forum to indicate that eclipselink too can be used with Quarkus.
Any pointers on why Quarkus is tied so tightly to a specific impl (if it is) of JPA would also be welcome
TIA
Rahul
You can use EclipseLink by adding it in your classpath as fxrobin mentioned. But it won't work for native image generation, nor will be integrated with the database connection pool, the transaction enlistment etc. Finally the startup time will be much longer.
The reason Quarkus focuses on Hibernate ORM is exactly for these reasons. Making Hibernate ORM work on native, making it do work at build time to speed startup time, smoothly integrating it with other areas takes a lot of time. Someone could make the same for EclipseLink with a few months of work ahead of them.
You can add EclipseLink in a class way as if you were in Java SE. But then you have to manage the transactional behaviour by code but not with annotations.
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.
I have seen some documentation on connecting to more than one database/data source via JPA, but this is not what I want to do exactly. I want to use one database provider for development and a completely different database provider for production (and probably QA). This question would also be applicable to supporting different production environments with different database providers (ie, DB2 for Client 1, Oracle for Client 2, MySQL for Client 3, etc).
In my case, I would like to do the following:
use JPA with Apache Derby for development purposes
use JPA with IBM DB2 for production purposes
We do not use Spring :(
With MyBatis, I could simply provide XML mappings for each database I wanted to support. And map all of results back to the same entities/POJOs.
So far it seems to me, that JPA will require custom everything up to maybe the Service layer (with entities, DAO, sql all being custom per database).
I want to know how you would go about setting up your application to use Derby for development and DB2 for production. Can I get by with using the same entities for both, should I separate the DAO layer into separate projects, can I use one persistence.xml, etc.?
Please let know what approach you would suggest to accommodate this.
This is a pretty common scenario, you don't need to duplicate anything if you are using JPA properly. You can use the same #Entity classes and DAOs.
If you are using Maven you can make the connection settings specific to some Maven profile, e.g. create profile for each environment and then let Maven resource filtering populate properties in your persistence.xml file (see this answer).
As a Java developer new to the web development environment, I was quite excited to find Grail which provides a great framework especially the convenience of abstracting DB operations with ORM. I later learned that it is actually the function of hibernate. At the same time I am delighted to learn about GWT. It is a god send for the project. I can continue building applications with event driven widgets using Java. Yeah!!
The answer seems clear: GWT + Hibernate. Will it work? What do I miss? Why there is much talk about this set up? What is the concern or area of risk? Have anyone tried this before?
Or, how do GWT developers handle the challenge of data persistence? What are the options?
Also I can't seem to find a good tutorial about setting up Hibernate with Eclipse -- the IDE I am familiar with. What are the tools or plug-ins needed?
Hibernate works fine with GWT as long as you keep in mind that the GWT code is actually running on the browser so you can't manipulate Hibernate objects in your client code. The downside to that is you're probably going to have duplicate objects on the client and server side, but you can use course-grained DTOs via the GWT remote procedure calls. On the server side, just create a ServletListener to initialize your Hibernate project and then use normal Hiberate methods to store and retrieve objects.
As far as Hibernate and Eclipse, Hibernate has an Eclipse plugin, but it's not really necessary to develop in Eclipse. It gives you the ability to run HQL and to reverse engineer Java objects from the database or vice versa, which can be useful, but it's not required.
If you want to go the hibernate way, you should have a look at Gilead or its predecessor hibernate4gwt. It works pretty well, but documentation is a bit sparse.
We use EJB2.x entity beans with BMP (bean managed persistence). It appears BMP is not supported in EJB3. We had wanted to stay current and upgrade to EJB3. Does anyone know if there are in fact any BMP options available in 3.0?
From what I can tell, using 3.0, all entity beans have to use JPA and by definition ORM. There are some options to use native SQL but that is still just a way to use JPA to implement ORM.
I wasn't sure if there is another EJB3 approach to achieve the same functionality as with EJB2.x BMP entity beans. We currently use the standard ejbStore method to update the DB through native SQL and the ejbLoad method to lookup all beans and to refresh the bean in the event of a transaction rollback. I thought you might be able to do this with EJB3 session beans but I wasn't sure.
Perhaps instead of migrating to EJB3 beans we should migrate to Spring.
If you really want to code SQL by hand, go for POJOs and raw JDBC DAOs. But this is also maybe an opportunity to rethink the way you're doing things and embrace ORM/JPA.
In the past, I have mixed Hibernate + EJB2 (CMP + BMP) sharing transactional contexts with no issues, using JTA.
This problem is quite similar...
Take a look at https://cwiki.apache.org/GMOxDOC22/developing-bean-managed-persistence-with-jpa.html. You can implement your own EntityManager.
With luck, you may be even able to share transactional contexts.