Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Mon, 2 Jul 2012 23:31:26 -0700
Subject: RE: Hibernate
Thread-Topic: Hibernate
Thread-Index: Ac1WHfce3mx45jrFR+OVqs/tmDGp7wAH03DAAKjUVQAAAIg/sA==
Message-ID: 
 <B1DF26ECC0458748AC97CECE2DA98D41012F9DA6AB1C@SJCPMAILBOX01.citrite.net>
References: <F1DC278E-F69A-4409-A1FA-EFB80536B922@gnsa.us>
 <D52B60F166CBB4419763A924815F848A012D080C10FF@SJCPMAILBOX01.citrite.net>
 <96B93665-BBD7-41C3-A1B0-A05ED1E57311@gnsa.us>
 <E30AD5DE-4BC6-4F9A-9810-41920BDBF389@citrix.com>
 <97F4356AEA71904482CD192135C038F9010C3A33BC3A@BANPMAILBOX01.citrite.net>
 <61AE1E2837A06D4A8E98B796183842D401292ED803B1@SJCPMAILBOX01.citrite.net>
 <97F4356AEA71904482CD192135C038F9010C3A4BCD7B@BANPMAILBOX01.citrite.net>
 <CAKprHVZo1g8GpJM0NrRnbUu2=x2ow3dcVne_FsKKx6sR=YYEVw@mail.gmail.com>
 <97F4356AEA71904482CD192135C038F9010C3A4BCDB3@BANPMAILBOX01.citrite.net>
 <CAKprHVbs8Tf8aqysAUHZMYV09AZdNpG0YAGz8TMSjKdsBW10CA@mail.gmail.com>
 <B1DF26ECC0458748AC97CECE2DA98D41012F9DA6A91D@SJCPMAILBOX01.citrite.net>
 <97F4356AEA71904482CD192135C038F9010C3A4BD1CE@BANPMAILBOX01.citrite.net>
In-Reply-To: 
 <97F4356AEA71904482CD192135C038F9010C3A4BD1CE@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Rajesh,

You should use the existing CloudStack DAO framework.  If cloudstack will m=
ove to another ORM framework, it will have to be done in such a fashion tha=
t everything above the DAO layer doesn't have to change and the majority of=
 the current DAO code do not have to change as well.  Which would mean your=
 code should migrate over along with the rest of the changes.

--Alex

> -----Original Message-----
> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> Sent: Monday, July 02, 2012 10:59 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>=20
>=20
>=20
> > -----Original Message-----
> > From: Kelven Yang [mailto:kelven.yang@citrix.com]
> > Sent: Saturday, June 30, 2012 3:31 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> >
> >
> > > -----Original Message-----
> > > From: David Nalley [mailto:david@gnsa.us]
> > > Sent: Friday, June 29, 2012 10:37 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > On Fri, Jun 29, 2012 at 12:13 PM, Rajesh Battala
> > > <rajesh.battala@citrix.com> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: David Nalley [mailto:david@gnsa.us]
> > > >> Sent: Friday, June 29, 2012 8:40 PM
> > > >> To: cloudstack-dev@incubator.apache.org
> > > >> Subject: Re: Hibernate
> > > >>
> > > >> On Fri, Jun 29, 2012 at 9:27 AM, Rajesh Battala
> > > >> <rajesh.battala@citrix.com>
> > > >> wrote:
> > > >> >
> > > >> > Shall I proceed to replace Hibernate Framework with Spring JDBC.
> > > >> >
> > > >>
> > > >> This is not a design decision to take lightly, or rush - as we've
> > > >> talked about replacing the custom ORM that CloudStack uses as
> > > >> well
> > > >> - we'd want to make a decision on something that we are
> > > >> comfortable with
> > > in that role as well.
> > > >>
> > > > [Rajesh Battala]
> > > > So we are planning to implement some ORM framework for CloudStack
> > also?
> > > > If so, then we need to evaluate the available ORM frameworks for
> > > > java
> > > which are based on Apache License?
> > > >
> > >
> > >
> > > I don't want to speak for Alex, but I have heard him mention such a
> > > change number of times, and have seen it in his slides as well.
> > >
> > > But the larger sense is that if we are going to change something in
> > > AWSAPI for communicating to the database, it should be something
> > > that we are comfortable with adopting in the long term for the rest
> > > of CloudStack, otherwise we'll end up with two different ways for
> > > connecting to the database, which is fail.
> >
> > For Rajesh's concern in the short term (to get rid of Hibernate), we
> > basically have following options,
> > 1) Make the project depend on utils.jar in CloudStack and use existing
> > CloudStack persistent layer.
> > 2) Continue to make CloudBridge project independent
> > 	a) use direct JDBC
> > 	b) use Spring JDBC
> > 	c) use ORM framework on Spring (i.e. OpenJPA etc)
> >
> > I vote on 2-b for a short term resolution. For a couple of reasons,
> >
> > The major reason is for adopting Spring, EC2/S3 API in the future may
> > both need to support SOAP based web service API and REST API, Spring
> > comes with support of both, in addition, it provides dependency
> > injection, AOP and pluggable ORM framework, distributed transaction
> management, etc.
> >
> > CloudBridge project has a very simple data model (it has only one
> > table for EC2), original ORM (hibernate) usage is just for convenience
> > (as Alex pointed that it tried to avoid direct SQL manipulation), on
> > the other hand, giving the DAO abstraction, a limited amount of JDBC
> > should not matter too much either. With Spring and already existing
> > DAO abstraction, we can leave bigger ORM decision for the future.
> >
> > In the long term, ORM choice to us seems to be secondary
> > consideration, giving the fact that our current custom ORM
> > implementation serves its purpose well enough in CloudStack. But I do
> > see the needs of more flexible dependency injection or transaction
> > management framework in order to incorporate better integration with
> > external transactional systems like message queue servers. I also see
> > the needs of standardizing AOP patterns used in current CloudStack
> > code base, Spring provides some good answers for that. So there is a
> > possibility that it will be good for CloudStack to adopt it like many
> > other Java communities do, so that we can focus on our own business
> > logic and leave these external concerns to people who are doing it for =
a
> living.
> >
> > Kelven
> >
> >
> > >
> > > --David
> [Rajesh Battala]
>=20
> Please let me know conclusion of the thread.
> I didn't see any reply to Kelven suggestions.
>=20
> Thanks
> Rajesh Battala