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.
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 currently use Jpa via Hibernate in my application. Since spring security oauth2 provides JdbcTokenStore, I started using it. But the problem with that is, I cannot use cache (which all my entities in the application currently share).
It hits the database in a separate flow.
I am thinking implementing JpaTokenStore thats backed by Jpa & leverage the cache advantages that comes with it.
Did anyone try implementing this/see any downsides using this approach?
In one project I've implmented org.springframework.security.oauth2.client.token.ClientTokenServices with JPA and didn't notice any problems. I was able to use all standard features of JPA including #Transactional for JPAClientTokenServices#saveAccessToken
There is nothing stopping you from doing it, and plenty of people do use JPA for all sorts of things, but IMO JPA is not ideal for handling storage of identity data. JPA is designed and optimized for cacheing data for the duration of a JDBC connection (a transaction basically), while identity data have a typically different and much longer lifetime. If you store long lived data using JPA, you have to deal with the consequences of what happens when you access it outside its normal lifetime, e.g. use DTOs, which ends up negating the benefits of using it in the first place to some extent.
I'm wondering if it is possible to specify SimpleJPA as the persistence provider used by Spring-Data-JPA. I'm not a JPA expert so I hope this question isn't silly. Is it as easy as just specifying SimpleJPA's entity manager factory in the persistence.xml? I have yet to find anywhere online where someone has used Spring-Data-JPA to connect to Amazon's SimpleDB, I would love it if someone could point me in the right direction.
I just found this project and got it working for our Spring Data + SimpleDB needs:
https://github.com/3pillarlabs/spring-data-simpledb
The documentation is pretty good and getting things up and running was pretty straight-forward. I was accessing SimpleDB via Spring Data with about 10 minutes of work.
Generally setting up your persistence provider is just a matter of setting up the EntityManagerFactory through your Spring context (in case you use the Spring container). Thus have a look at how to configure EntityManagerFactory instances in Spring.
There might be the need to implement a custom JpaVendorAdapter to let Spring use the SimpleDB JPA implementation correctly. For some advanced functionality (e.g. using pagination with manually defined queries) we'd have to tweak the Spring Data JPA codebase a bit. If you'd like to see that supported feel free to open a ticket in our JIRA.
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.
want to develop my project on Google App Engine .I want to use google big table as database. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Since you're using Data Nucleus, see their FAQ on JDO vs JPA. http://www.datanucleus.org/products/accessplatform_3_0/jdo_jpa_faq.html
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
A key difference is that JDO support a rich domain model (logic together with data), in fact all persistent classes can have a reference to the current PersistenceManager, issue queries, and, I guess, it's possible not to have fields persistent by default.
JPA does not support such software design. In fact each Entity doesn't have a reference to the PersistenceManager, to have it you have to resort to ThreadLocal variables, which is not a very elegant and robust solution.
Since GAE BigTable is not an RDBMS, JDO is a better choice. There are some detailed comparision articles in Aphache JDO, it is helpful for me.
JPA persists java objects to relational data via ORM, while JDO is more general specification for java object persistence. So using JDO will give you more freedom in storage implementation options for your objects.
JPA is the leading java standard for persistence. So I'll say use JPA if you are using RDBMS and require ORM.
Hibernate is generally used as JPA implementation. If you need some extra features you can use hibernate specific annotations.
This question already looks to be discussed here JDO vs JPA for Java on Google App Engine