Christian Gossart

Ranch Hand
+ Follow
since Mar 13, 2008
Paris, France
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Gossart

Hi Ali,

I don't think there is any EJB 2 to 3 migration tool, as Jeanne said. The general concepts remain the same, but EJB 3.x is a great step toward simplification and ease of development.
If your only concern is to upgrade your J2EE application server to a JEE5/JEE6 application server, you should not have to change anything: the EJB 3.1 specification supports backward compatibility.
On the other hand, if you're up for a full EJB 3.x migration of your application, I advise you to read Adam Bien's Real World Java EE Patterns Rethinking Best Practices. This book covers the changes between the core J2EE patterns and the way they can be rethought/removed using the new JEE programming style. It also provides a EJB 2 Integration and Migration strategy that can help you estimate the cost of your migration (the persistence layer will be the hardest) and choose between a EJB 2 to EJB 3 migration and a full rewrite of your application, provided you have access to the business needs and specification documents.
Special use case, indeed

Mine was a standalone application too, with only two databases, but I had to persist data in both within the same transaction, so I ended up using Atomikos to get a JTA transaction manager and XA transactions. In that case, the persistence unit are declared with transaction-type="JTA" (the "resource-local" type can only be used when the transaction is managed explicitly by the application).

I've also read on the Spring jira that some people tried to solve this kind of problem using custom annotation with @Transactional as meta-annotation, and 2 tx:annotation-driven declaration, one with a specific transaction manager, the other without the attribute, letting Spring fallback to the default one. But as you said, this can only be used if you have access to the source code of the classes to annotate them.
8 years ago
@Jagdish: could you detail why you need only 1 EMF?
@Jayesh: your solution is interesting, but maybe a little complex. When I end up extending core classes of a framework (here HibernatePersistenceProvider and DataSource), I stop myself because it often means I'm going the wrong way: there has to be a solution using the framework as is. After all, those Hibernate/Spring/whateverframeworkyouuse guys have read and implemented the spec and my use case certainly fits in

For information, here is an extract of the JPA 2.0 specification (chapter 7.3) that deals with the multiple databases case:

Each entity manager factory provides entity manager instances that are all configured in the same man
ner (e.g., configured to connect to the same database, use the same initial settings as defined by th
implementation, etc.)
More than one entity manager factory instance may be available simultaneously in the JVM. [75]

[75] This may be the case when using multiple databases, since in a typical configuration a single entity manager only communicates
with a single database. There is only one entity manager factory per persistence unit, however.

8 years ago
Well, just try the injection with annotations as you already have coded it. If it's OK, no need to use the Spring configuration for it. Otherwise you can use some abstract DAO classes with a @PersistenceContext to factorize the injection and just declare these beans in the Spring conf.
8 years ago
I struggled a lot for this months ago, so I'll try to sum up what worked for me (I admit such a use case should be described in the Spring reference documentation):

- use a PersistenceUnitManager to manage the multiple PUs
- use multiple LocalContainerEntityManagerFactoryBean beans to build your EMF and reference the PUM in it.
- specify the PU name for each EMF
- use JTA if you want a global transaction around your work on the 2 (or more) databases and use databases and drivers that support XA transactions in that case (I had some tricky problems with MySQL for example)
- inject the EM into your DAOs via the Spring configuration (@PersistenceContext(unitName="xxx") was commented in my code, but I don't remember if it should work, and I cannot test the full project for now)

You'll find below a configuration sample (I removed anything that is business specific) for 2 databases (one local, one remote) using:
- Spring 3.0 (I believe it's also usable with Spring 2.5.6),
- EclipseLink as a JPA provider (replace the specifics with Hibernate in your case),
- MySQL (or any database)
- Atomikos for a standalone JTA transaction manager (I didn't put the whole config, please refer to if needed, or use another JTA provider)

Hope this helps you, and maybe others to configure properly multiple databases access through JPA and Spring.
8 years ago
If your funcB() call from funcA() is on the same object (like you could use this.funcB() in your code), the EJB container has no way to intercept the call and provide the transaction mechanism around funcB().
The EJB specification says somewhere that transaction annotations (and all interceptors I think) are processed only for calls using an "EJB reference", not for pojo internal calls. That's what you observe using the local interface of your bean.
I really lost hours of debugging on a problem of this kind (REQUIRED_NEW that did not create a new transaction), so now I never forget this

Was just editing a reply...

Dieter is right, both codes will produce the same SQL query in the end, and the second is quicker to use assuming you don't have generated the metamodel.

Also I never had to use the JPA Metamodel, I only know it exists, and I didn't try the code samples from Beginning Java EE 6 after reading it.
For an example with metamodel generation, please refer to Criteria API with EclipseLink from the same author.

And feel free to post an errata at Beginning Java EE 6 or at Antonio's web site.

Good luck on your JPA learning,
Should be if the goal is to use the Criteria metamodel API (new in JPA 2.0).

It's equivalent to
I'll check my own copy of Antonio's book

Using Eclipse, there are several plugins to generate JPA entities from an existing database. I would add Dali to those listed by Arun.
AFAIK, these tools will produce a one-shot reverse of your database. If your need is to reverse a changing database using bottom-up strategy, you'll have to be careful to any change you add manually to the generated entities: they will be lost each time you reverse the schema.

Paul you're right.

But I've seen clients deployment policies to be "one application per application server", and I also remember struggling with a Weblogic instance to have my specific version of a lib to be first in the classpath (that lib was used by WL too, and putting it in the EAR lib directory was clearly not enough).

Sure, if there are several application deployed in the same AS or domain, this solution can't work, as you'll probably mess with the other application lib dependencies, and if you change your dependencies versions at every build, it's not good either. But it's a proposition I'd consider while asking my client why 80 MB is too heavy


I don't know of a maximum size either (and it seems the JEE spec does not address this).
If your Ear is the only application deployed in the target server, and if your libraries do not change much (a fixed version for each lib for example), you can propose to add them in the server classpath.
That way, you only have to deploy the Ear with an empty lib directory, which will reduce its size.

Are both of your entities participating in the same persistence unit?
If this persistence unit is defined in one jar, did you import the other with a <jar-file> element in the persistence.xml ?
If you activate logging during the persistence unit creation, do you see the two entities in the list of mapped classes? (I know EclipseLink and Hibernate log this kind of information)
If you define your query as a named query with @NamedQuery, is it accepted by the persistence provider?
Hi Lee,

I would recommand Adam Bien's Real World Java EE Patterns . I really enjoyed this book, it's a pragmatic view of how J2EE "classic" or "old-school" patterns can be rethinked to architecture a JEE application: which ones are still needed, which ones must be adapted or abandonned due to the evolution of the EE plateform.
Adam also leads a really informative blog at Adam's blog .

Hello Rafael,

You can unit test EJB using the embedded container, which is a new feature in JEE 6. Your EJBs will be deployed, as a real JEE module, and DI will be managed by the container.
You'll find Junit setup information in this CodeRanch post Junit Embedded Glassfish and in this blog Unit testing EJB with Embedded Glassfish. I use this approach for a real world JEE 6 Maven multi-modules project, with continuous integration and testing. I believe EJB 3.0 can be tested as well, because containers are retro compatible. Afaik, some EJB features like JMS/MDB are not fully supported by Glassfish Embedded 3.0.1, but for standard session beans it's the way to go.

There is also Ejb3Unit , a framework I used some years ago, before JEE 6. It's an extension of the Junit framework to ease the test of EJB 3.0.

Hope this helps.



Concerning JSR303, I cannot think of better tutorials than those of Emmanuel Bernard, who is the spec leader of this JSR. You can find them at Bean Validation Tutorials.
Also, the Java EE tutorial has a chapter on Bean Validation: Java EE tutorial.

JSR303 annotations can be part of your JPA entities, and bean validation can be triggered at any layer of your application, from the presentation layer to the data access layer.

Good reading