We Keep Coding

Hibernate Tools. JPA 2.0 without EJB

Hibernate Tools has 2 diffeent configurations regarding this topic.
You got the Console config with the options Hibernate 3.5/3.6/4.0 plus
and Core / (Hibernate) Annotations / JPA Annotations
and later in launch code generator menu we already can select in exporters: Java 5+ and EJB options.
But the behaviour seeems a bit inconsistent for me, as marking JPA annotations without EJB option erases any annotation. So is there any way to make Hibenrate generate non-EJB JPA annotations code (DAO+POJOS)?
THe thing is I don't want to get an injected EntityManager, and I am not using any EJB container but SDK. I am wondering whther there is an smart code generation in that case

Difference between Hibernate library and Hibernate JPA library

In the screen where you can add the Hibernate library to a project, there are two options, Hibernate and Hibernate JPA.
What is the difference between the 2? Googling did not provide an explanation.

I found this to provide a good explanation.
http://elope.wordpress.com/2007/09/06/difference-between-jpa-and-hibernate/
From the above blog:
So if i need to put in Concise words:
a) JPA is Persistence Api which your code should use.
b) JPA Api will pass on the call to actual peristence provider (ex:Hibernate/TopLink) to do the actual work.
c) If you are looking from Performance prespective ,it will be dependent on actual peristence provider (Hibernate/TopLink) and not on JPA as its just a wrapper layer.
d) If you are looking from code dependency prespective ,JPA makes more sense as your code is dependent on standard Java Api.
e) If you have used Hibernate then you will find that certain features are missing in JPA like criteria queries etc.This does not mean that you can’t write criteria query in your application, you need to get Session object from JPA Entity manager and now you are as good as in hibernate project.
But now your code is dependent on Specific impl (Hibernate),going forward you can see more things getting added in JPA (2.0)
f) Should you use JPA: My take is you should ,API is clean and although not everthing you need is their but is a good step forward.

I don't know what "screen" you mean, but in general you can use Hibernate directly (Hibernate API) or as a JPA provider. As JPA is a standard API one can code against this API and switch between implementations (Hibernate, EclipseLink, OpenJPA, ...). When using Hibernate API you are tied to this but you can utilize features that are not standardized by JPA.

Single persistence unit for a modular application (JPA)

I want to create a modular(plugin-like) application that uses JPA as its persistence abstraction, and this application should be extensible by third parties.
The catch is that I want this application and its plugins to be easily portable to other databases/JPA providers, so the third party vendors can't know anything about the used JPA provider(or databases connections), they can only extend the persistence layer by defining new entities to be stored in the main app persistence unit(this would allow one to switch databases without having to reconfigure every module to point to the new db).
Can I do something like that with JPA? I can do it easily with .NET's nHibernate(and probably with Hibernate) but I prefer to program against JPA since I'm in a Java EE environment.

Funnily, I have made exactly this using OSGi, Equinox and EclipseLink, but it's not trivial. Essentially, a custom bundle takes all persistence.xml files from all resolved bundles, merges them into a single persistence.xml that is used to initialize the EclipseLink Persistence Provider. Additionally, there are some custom hooks that allow me to specify f.e. connection options separately for development and deployment.
Drawbacks: say bye-bye to container-managed persistence, but it's still possible to join transactions. Also, some tools react violently to cross-bundle entity references. Also, if you add a new bundle with new entities, you will need to have set up the database with the proper tables, references, indexes & constraints beforehand.
Advantages: Drop in new bundle, see it work at once, dynamically, without restarting the container.

I am also researching how to do JPA in a modular way (in the Netbeans module system or in an OSGI container).
One thing you should be aware of is that if you need to build a central, big EntityManagerFactory (by the central persistence module) than you may have some issues if your application is big:
If the persistence module needs to react to module startup/shutdown events, it needs to rebuild the central EntityManagerFactory when a module is added or removed. If the application is big (lots of classes), rebuilding the EntityManagerFactory is slow and costly.
The application needs not storing references to the EntityManagerFactory because if a module is added/removed the old one becomes stale. The application should work with very short-lived EntityManager and always get the EntityManagerFactory.
It may be more flexible to build EntityManagerFactories for every JPA-using module, but that may need more memory and may take up more computing power until all of the EntityManagerFactories are created for every module (although EntityManager factories may be created on-demand by your central JPA service).
Dynamic-JPA (http://www.dynamicjava.org/projects/dynamic-jpa) may help if you work in an OSGI container.

EJB3 with Spring

I have understood that if I use EJB in Spring context, I get all the same benefits as if I was using it in "pure" EJB3 environment, is this true? I have googled but can't find a definitive, clear answer.
For example, let's say I have a session bean that updates some tables in the database and it throws a System Exception. In "pure" EJB3 environment the transaction is rolled back. What if I for example #Autowire this bean using Spring, does Spring take care of the transaction handling same way as does the EJB3 container? Or what? Does it maybe require some specific configuration or is it fully "automatic"?

I have understood that if I use EJB in
Spring context, I get all the same
benefits as if I was using it in
"pure" EJB3 environment, is this true?
You usually use either POJO + Spring or EJB3. I'm a bit confused by what you mean by "EJB in Spring"...
POJO + Spring and EJB3 are quite close now, and have the same facilities when it comes to declarative transaction management.
I don't know all the details about security, but I would say that both technologies are also very similar.
Actually both Spring and EJB3 rely on other specifications. The important ones are: JPA (persistence), JTA (distributed transaction), JMS (messaging), JDBC (data sources). Good support for that exist in the two technology stacks.
Both technologies have become very flexible and you can choose what to use or not. So you can have EJB3 in an app. server and be very light. Or you can use Spring with all modules which is almost as heavy as a full-fledged app. server.
I think the EJB3 model is still a bit richer, with things like remoting, stateful session beans (SFSB), container-managed transactions, and extended persistence context. Plus the possible support of clustering depending on the app. server. But these are advanced features which are use seldom (and IMO require expertise).
See EJB3 vs Spring

spring has many features, one of which is transaction management, which uses a common abstraction accross all different orm implementations (jpa, raw hibernate, jdbc, jdo etc). The default behavior is that in a transactional method, a runtime exception causes a rollback (which is probably what you want), but you can also fine-tune the rollback rules.
However, none of this requires EJB. If you don't use EJBs (stateless, stateful, mdbs), JPA will be enough for that, and the spring jpa support is excellent. In 90% of the cases spring will provide everything you need without EJBs.
EDIT:
read this about Spring EJB integration

You can have Spring handle transactions and roll back accordingly. You have to configure it to do so, but that's also true of EJBs.
Nothing in life is truly "automatic". You have to tell the code what you want sometime.
The real question is: Why do you think you need both EJBs and Spring? Anything you can do with EJBs can be done using POJOs with Spring. What are EJBs buying you here?

I got very good answers with links to articles, and from those I compiled my understanding that yes, the session beans work the same way regardless of if they are used with Spring or without, as long as the beans are defined in the Spring context with <jee:jndi-lookup>. Also found a good, simple article about this: http://java.dzone.com/articles/ejb-30-and-spring-25
However I can't accept just one answer because to me they are all equally good, but none of them exactly in point :) Could be that my question was not clear enough to start with...
(It was suggested that I post this as an answer to my own question)

Mixing EJB 2.x BMP entity beans with Hibernate 3.x

I have a large application that uses EJB 2.x entity beans (BMP). This is well-known to be a horrible persistence strategy (I can elaborate if necessary).
I'd like to start migrating this application to use a much more expressive, transparent, and non-invasive persistence strategy, and given my company's previous experience with it, Hibernate 3.x is the obvious choice.
Migrating to Hibernate is going to take a while, as over 100 tables in the application use entity beans. So I'm looking at a phased approach where the two persistence strategies run in parallel, ideally on the same tables at the same time, if possible.
My question is, what are the pitfalls (if any) of combining these two persistence strategies? Will they get in each other's way?

As said jodonnel, you have to pay attention to caching, because if you use second-level caching in Hibernate and a table is modified outside of Hibernate, then Hibernate has no way to know that its cache entry is stale.
For the transactions, they should both use JTA provided by the container, so for that it should be safe.

I guess the thing to really be careful with is working with the Hibernate sessions. Hibernate caches stuff, and that might get in the way.
Frankly I would recommend that if you adopt Hibernate, drop the Entity beans entirely. Do your Hibernate work within session beans and let the session beans manage your transactions.
Or alternately use EJB 3, which is Hibernate standardized into the Java Persistence API.