Re: [uportal-dev] uP3 persistence libraries
I just put the project I've been working in on the uP3 portlet OM & ORM persistence into the sandbox here: http://developer.ja-sig.org/source/browse/jasigsvn/sandbox/uP3OrmTesting/trunk Feel free to poke around and see how things are going, I'm more than happy to hear peoples thoughts on this code or answer questions about it. -Eric Eric Dalquist wrote: I've been playing in a sandbox with Hibernate & JPA+Hibernate. The JPA annotations with Spring's ORM support look quite nice and keeps most of the persistent objects and DAOs free of Hibernate specific code, using the JPA APIs instead. Hibernate would still be used as the underlying persistence layer but JPA would be the standard in the code. Let me know if that sounds inline with the discussion here and if everyone is comfortable with this approach for new DAOs. -Eric [EMAIL PROTECTED] wrote: The Spring Framework has excellent support for JPA, whether you choose to use the JPA templates (similar to JdbcTemplate) or the JPA API directly: http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa In addition, Rod Johnson, founder of both the Spring Framework and Interface21 wrote the forward to the book "Pro EJB 3: Java Persistence API" calling the Java Persistence API the most important advance in the Java EE 5 platform revision and stating that developers should unite to adopt it. -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: I've heard the opposite. Especially the Spring community, who normally would have lots of beefs with JBoss, are more down on JPA. Interface 21 does not recommend JPA for what it's worth. Cris J H [EMAIL PROTECTED] wrote: You may want to write to the JPA specification instead of the Hibernate APIs directly (even if you do end up using Hibernate as the backing implementation). It gives people the flexibility to use what they are comfortable with and in the long term doesn't tie you to a specific implementation. http://java.sun.com/javaee/overview/faq/persistence.jsp -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: There are few 'trends' that "most" in the community seem to agree on. Eclipse was the first I noticed in this community. Hibernate and Spring were the second and third (not sure the order). I don't think you'll find much dissension on using Hibernate. But If you really wanted to open the door and think about all the reasons why or not, to use Hibernate, there is one downside. RedHat/JBoss and Interface 21 do not get along. I get the impression that some people use iBatis not because they think it's better then Hibernate, but because of the riff here and a desire to use something "other" then Hibernate. Personally, I'd use Hibernate. +1. Cris J H Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] uP3 persistence libraries
I've been playing in a sandbox with Hibernate & JPA+Hibernate. The JPA annotations with Spring's ORM support look quite nice and keeps most of the persistent objects and DAOs free of Hibernate specific code, using the JPA APIs instead. Hibernate would still be used as the underlying persistence layer but JPA would be the standard in the code. Let me know if that sounds inline with the discussion here and if everyone is comfortable with this approach for new DAOs. -Eric [EMAIL PROTECTED] wrote: The Spring Framework has excellent support for JPA, whether you choose to use the JPA templates (similar to JdbcTemplate) or the JPA API directly: http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa In addition, Rod Johnson, founder of both the Spring Framework and Interface21 wrote the forward to the book "Pro EJB 3: Java Persistence API" calling the Java Persistence API the most important advance in the Java EE 5 platform revision and stating that developers should unite to adopt it. -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: I've heard the opposite. Especially the Spring community, who normally would have lots of beefs with JBoss, are more down on JPA. Interface 21 does not recommend JPA for what it's worth. Cris J H [EMAIL PROTECTED] wrote: You may want to write to the JPA specification instead of the Hibernate APIs directly (even if you do end up using Hibernate as the backing implementation). It gives people the flexibility to use what they are comfortable with and in the long term doesn't tie you to a specific implementation. http://java.sun.com/javaee/overview/faq/persistence.jsp -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: There are few 'trends' that "most" in the community seem to agree on. Eclipse was the first I noticed in this community. Hibernate and Spring were the second and third (not sure the order). I don't think you'll find much dissension on using Hibernate. But If you really wanted to open the door and think about all the reasons why or not, to use Hibernate, there is one downside. RedHat/JBoss and Interface 21 do not get along. I get the impression that some people use iBatis not because they think it's better then Hibernate, but because of the riff here and a desire to use something "other" then Hibernate. Personally, I'd use Hibernate. +1. Cris J H Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] uP3 persistence libraries
The Spring Framework has excellent support for JPA, whether you choose to use the JPA templates (similar to JdbcTemplate) or the JPA API directly: http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa In addition, Rod Johnson, founder of both the Spring Framework and Interface21 wrote the forward to the book "Pro EJB 3: Java Persistence API" calling the Java Persistence API the most important advance in the Java EE 5 platform revision and stating that developers should unite to adopt it. -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: > I've heard the opposite. Especially the Spring community, who normally > would have lots of beefs with JBoss, are more down on JPA. Interface > 21 does not recommend JPA for what it's worth. > > Cris J H > > [EMAIL PROTECTED] wrote: >> You may want to write to the JPA specification instead of the >> Hibernate APIs directly (even if you do end up using Hibernate as >> the backing implementation). >> >> It gives people the flexibility to use what they are comfortable >> with and in the long term doesn't tie you to a specific >> implementation. >> >> http://java.sun.com/javaee/overview/faq/persistence.jsp >> >> -Scott >> >> >> Quoting Cris J Holdorph <[EMAIL PROTECTED]>: >> >>> There are few 'trends' that "most" in the community seem to agree on. >>> >>> Eclipse was the first I noticed in this community. >>> >>> Hibernate and Spring were the second and third (not sure the order). I >>> don't think you'll find much dissension on using Hibernate. >>> >>> But If you really wanted to open the door and think about all the >>> reasons why or not, to use Hibernate, there is one downside. >>> >>> RedHat/JBoss and Interface 21 do not get along. I get the impression >>> that some people use iBatis not because they think it's better then >>> Hibernate, but because of the riff here and a desire to use something >>> "other" then Hibernate. >>> >>> Personally, I'd use Hibernate. +1. >>> >>> Cris J H >>> >>> Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric >>> -- >>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >>> [EMAIL PROTECTED] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> >> >> > > -- > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > [EMAIL PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uP3 persistence libraries
I've heard the opposite. Especially the Spring community, who normally would have lots of beefs with JBoss, are more down on JPA. Interface 21 does not recommend JPA for what it's worth. Cris J H [EMAIL PROTECTED] wrote: You may want to write to the JPA specification instead of the Hibernate APIs directly (even if you do end up using Hibernate as the backing implementation). It gives people the flexibility to use what they are comfortable with and in the long term doesn't tie you to a specific implementation. http://java.sun.com/javaee/overview/faq/persistence.jsp -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: There are few 'trends' that "most" in the community seem to agree on. Eclipse was the first I noticed in this community. Hibernate and Spring were the second and third (not sure the order). I don't think you'll find much dissension on using Hibernate. But If you really wanted to open the door and think about all the reasons why or not, to use Hibernate, there is one downside. RedHat/JBoss and Interface 21 do not get along. I get the impression that some people use iBatis not because they think it's better then Hibernate, but because of the riff here and a desire to use something "other" then Hibernate. Personally, I'd use Hibernate. +1. Cris J H Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uP3 persistence libraries
You may want to write to the JPA specification instead of the Hibernate APIs directly (even if you do end up using Hibernate as the backing implementation). It gives people the flexibility to use what they are comfortable with and in the long term doesn't tie you to a specific implementation. http://java.sun.com/javaee/overview/faq/persistence.jsp -Scott Quoting Cris J Holdorph <[EMAIL PROTECTED]>: > There are few 'trends' that "most" in the community seem to agree on. > > Eclipse was the first I noticed in this community. > > Hibernate and Spring were the second and third (not sure the order). I > don't think you'll find much dissension on using Hibernate. > > But If you really wanted to open the door and think about all the > reasons why or not, to use Hibernate, there is one downside. > > RedHat/JBoss and Interface 21 do not get along. I get the impression > that some people use iBatis not because they think it's better then > Hibernate, but because of the riff here and a desire to use something > "other" then Hibernate. > > Personally, I'd use Hibernate. +1. > > Cris J H > > Eric Dalquist wrote: >> As I progress with the Pluto 1.1 integration in the trunk I'm >> getting closer to the point of needing to write some new DAOs to >> persist some portlet domain objects. I would like to propose using >> Hibernate 3 for _new_ DAO implementations. Initially this just >> provides an easy way to write DAOs for object persistence, in the >> very long term we could plan on moving all DAOs to Hibernate to >> take advantage of schema creation and cross-database support. For >> 3.0 Hibernate would only be used for new DAOs and all existing data >> access code would remain as is. >> >> -Eric > > -- > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > [EMAIL PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uP3 persistence libraries
There are few 'trends' that "most" in the community seem to agree on. Eclipse was the first I noticed in this community. Hibernate and Spring were the second and third (not sure the order). I don't think you'll find much dissension on using Hibernate. But If you really wanted to open the door and think about all the reasons why or not, to use Hibernate, there is one downside. RedHat/JBoss and Interface 21 do not get along. I get the impression that some people use iBatis not because they think it's better then Hibernate, but because of the riff here and a desire to use something "other" then Hibernate. Personally, I'd use Hibernate. +1. Cris J H Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] uP3 persistence libraries
As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] uP3 persistence libraries
+1 Hibernate-style DAOs will (eventually) make the Import/Export features more straightforward and easier to maintain. drew wills Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- Andrew Wills UNICON, Inc. Office: (480) 558-2476 http://code.google.com/p/cernunnos/ -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uP3 persistence libraries
+1 We've used hibernate pretty extensively on a number of projects, both large and small, overall I've been very pleased with the results. You are likely already aware of this, but the Spring community no longer recommends using the HibernateTemplate and instead prefers a template-less approach since the original reasons for the creation/usage of the HibernateTemplate no longer exist. Here is an article on the subject. http://blog.interface21.com/main/2007/06/26/so-should-you-still-use-springs-hibernatetemplate-andor-jpatemplate/ Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
