Fix toplink by switching to OpenJPA … ?

November 25, 2007

I recently ran into a post where someone said they were dropping TopLikn Essentials in favor of OpenJPA. At the time I was searching for some assistance in fixing some rather impossible to diagnose (mostly due to toplink’s incomprehensible stack traces) ClassNotFoundException. I eventually figured out that toplink’s class loader was broken in some way which I couldn’t fix, and that meant I couldn’t have my entity classes subclass something from some other jar. Or whatever, I haven’t fully diagnosed the problem, and instead decided to spend my time on getting OpenJPA installed.

This turned out to be quite easy – I just downloaded the openjpa binaries and copy the openjpa jar and lib/*.jar from that disitribution into glassfish/domains/domain1/lib, then changed my persistence.xml to specify OpenJPA as the persistence provider:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="db">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>db</jta-data-source>
...

Even though OpenJPA is more strict about not using field accesses when using property-mode fields (even inside the same class, you can’t use this.x) I’m so happy that it told me this with wonderfully clear error messages, it seems worth the effort to fix my code (by right-clicking a lot and picking Refactor > Encapsulate Field).

Thanks go to Sahoo for showing me how to do this:

http://weblogs.java.net/blog/ss141213/archive/2006/07/using_openjpa_a.html


procedural programming, ORM implementations

November 18, 2007

It recently occurred to me that, as a consequence of the way ORMs are implemented currently, I’ve been doing some procedural programming and actually finding it somewhat uncomfortable to have to do so. I think I’ve been doing OO programming for so long, I can’t handle procedural code as well any more.

Maybe you’re wondering what the hell I’m talking about with this “ORMs are making code procedural” idea. It certainly seems like OO code – you have classes and methods and stuff, objects, etc.? Yes, it’s mostly procedural. However, I’ve noticed in both Elixir (a python framework) and the Java Persistence API that when you manage relationships between objects using an ORM, you typically use a centralized object (often called the DAO in Java-land) that persists new objects and removes old objects, as well as ensuring that both sides of the relation are always kept in sync. Although I always start out trying to put all the logic onto the objects (where, theoretically, it belongs) I always run into trouble doing this, and it’s back to using the DAO for pretty much every operation except updating simple fields.

I seem to be forgetting, for the moment, the exact reasons why this is. I know that the first problem I’ve run into has to do with the lack of delete-orphan support in the Java Persistence API. Since rows are not automatically deleted when you remove them from a collection, you need a pointer to the EntityManager when you remove from a relationship. I think I’ve run into other problems, but the details are eluding me temporarily. I’m sure there’s something I’m missing and there’s really a great way around all this, but I don’t know what it is. Maybe the next version of JPA will suck a bit less.