Why do you want migrate to OpenJPA?
Migrating to Hibernate 3.x would be way easier.

Any chance that while you're at it, you could fix the bug http://jira.atlassian.com/browse/CONF-7303 so that organizations with more than a few users could use Confluence without continuous crashes and busylooping? I mean, going to get every single user from the database one at a time just to make a few comparisons you could make in the SELECT doesn't seem like an obvious choice.

Just curious - can you share your thinking behind the decision to use OpenJPA ahead of Hibernate 3 with JPA annotations? Thanks - ct

Hi Matt,

Atlassian is one of the company I look highly upon. If they are evaluating to switch from Hibernate to say JPA, there must be some pretty substaintial reasons. Do you mind sharing it? :-)

Cheers

We've actually been pretty happy with Hibernate, in general. We're investigating a switch not for technical reasons, but for legal ones. Hibernate's LGPL license is becoming an issue for some of our customers, and so we're investigating our options. (That also explains why HIbernate3 won't solve our problems.)

Thanks for the responses.

Part of the reason behind the move is to avoid code licensed under the LGPL. I can't explain the exact issues with the LGPL (because I actually don't understand them), but it's based on legal advice related to redistribution of LGPL code. Hibernate 3 is still LGPL, so using it doesn't fix that problem. That's a shame, because by reputation it's a fairly good JPA implementation and an easy upgrade path from Hibernate 2.

@Mikael: Unfortunately, the solution isn't as easy as you describe because Confluence supports many different user management systems. If you're experiencing crashes and severe performance problems, please raise a support request, and we'll see what we can do until that bug is fixed.

We are using hibernate 3 with mostly JPA annotations. The only place we are forced to use hibernate annotations is when specifying cascade-delete-orphan which JPA doesnt seem to explicitly state in its CascadeType

Cripes, remind me not to upgrade to that version!
I think it would be a big shame to destroy the relative stability of confluence by a big architectural change for the sake of legalese.
Do it on a long lived branch, so that those of us who don't care about it can keep getting new features without the big risk of new defects that the move will undoubtably cause.

Thanks for the comments.

Jon, if we go ahead with this, we'll definitely be working out the least disruptive way to implement it, keeping in mind all our existing customers. A branch is one option, absolutely.

Mikael - The bug you mentioned ( http://jira.atlassian.com/browse/CONF-7303 ) has a fix already available. Migrating to Atlassian user will avoid the slow search problem. As Matt mentioned, if your Confluence instance is unstable, please have it examined via a support request.

Theoretically, it should be possible to implement such an effort in a way that allows the end-user to select between the various JPA implementations supported by Confluence.

Theoretically, yes. Practically no. There are certain things we need that are not included in the JPA standard, such as schema migration. These will require implementation-specific code.