Atlassian Blogs

Comments (12)

• 

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

  By Alex Panchenko on March 27, 2007 / Reply

• 

  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.

  By Mikael Gueck on March 27, 2007 / Reply

• 

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

  By ct on March 27, 2007 / Reply

• 

  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

  By tmjee on March 27, 2007 / Reply

• 

  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.)

  By Jonathan Nolen on March 27, 2007 / Reply

• 

  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.

  By Matt Ryall on March 27, 2007 / Reply

• 

  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

  By sreeni ananth on March 28, 2007 / Reply

• 

  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.

  By Jon Nermut on March 28, 2007 / Reply

• 

  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.

  By Matt Ryall on March 28, 2007 / Reply

• 

  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.

  By Anonymous on March 28, 2007 / Reply

• 

  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.

  By Patrick Linskey on April 18, 2007 / Reply

• 

  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.

  By Charles Miller on April 18, 2007 / Reply