Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=It+TRSddDVFacF0gN5CSk96KunPjMaGi5Hc71Y75Yi0Wqgvr4kgDzcwZToRbI+YH+njkj/OHOkHx2F2mujHyXsB+N0CyfIGFFe7jig6QABP/Tj34xNn48UwZ+UnIIYskrKgWGmay0bqo9XkcVeVvIM/WLI/97dBr/+E+rtzn/EM=;
References: <1336161394.18186.YahooMailNeo@web171506.mail.ir2.yahoo.com>
 <CAGJtJfHN4-qxaP9aa=ZfpK8QOh+gqBAM2O4CmLBbRGuG60T3yg@mail.gmail.com>
 <CACLE=7Pz8tPn4qyrkUqrK64rSEJOYL_XU1xhpU5v5zUr=0tueA@mail.gmail.com>
 <CACLE=7PpKNBY3h2EqNCgjg6N1kd1SOVe9iMG6JSu6Cftk+LHhQ@mail.gmail.com>
 <CANH=8OivDUBhy7pNOuMYeNJZyHfh+gHKi5AfG3k=LWZyzu53aA@mail.gmail.com>
 <CACLE=7OGpq4dU3Pbb923CyNhR1NZz9KgfE8KGCmMibT6TK2kxw@mail.gmail.com>
 <1336256074.7979.YahooMailNeo@web171501.mail.ir2.yahoo.com>
 <0CDEF12E-81F5-4AC1-881F-D46EFE359FF3@gmail.com>
 <CACLE=7NbJcSXQo5BLPgcrcEt4GD3=rmZop7vh-3_gBzDuQuJ5w@mail.gmail.com>
 <20120506091455.63736164642@mx01.openknowledge.de>
Message-ID: <1336297074.71396.YahooMailNeo@web171506.mail.ir2.yahoo.com>
Date: Sun, 6 May 2012 10:37:54 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: AW: [DISCUSS] deltaspike-jpa module features
To: "deltaspike-dev@incubator.apache.org"
 <deltaspike-dev@incubator.apache.org>
In-Reply-To: <20120506091455.63736164642@mx01.openknowledge.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Arne!=0A=0AFor your 1. please see the 'PersistenceStrategy' trick we did=
 in the CODI TransactionalInterceptor [1]. Our interceptor is basically a f=
acade which delegates all the work to the injected @Dependent PersistenceSt=
rategy. We would provide 2 different implementations: a resource local and =
a JTA based one.=0A=0A=0AJust to stress that point again: =0A=0A=0A> Config=
urableDataSource needs to be registered in JNDI. In Java-EE-Containers =0A>=
 this can be done with the @DataSourceDefinition annotation.=A0=0AYes, but =
ONLY if you need just one single configuration! =0A=0A=0A> In plain Tomcat =
or =0A> Jetty servers this needs to be configured in a container-specific w=
ay.=0AThe problem with the container specific stuff is that every container=
 serves the xml configured datasource on a different location in JNDI! So y=
ou cannot provide a container independent implementation that way :/=0A=0A=
=0ARest sounds good, I'll think about it the next days!=0A=0ALieGrue,=0Astr=
ub=0A=0A=0A[1] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trun=
k/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/c=
di/jpa/impl/transaction/TransactionalInterceptor.java=0A=0A=0A=0A----- Orig=
inal Message -----=0A> From: Arne Limburg <arne.limburg@openknowledge.de>=
=0A> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.ap=
ache.org>=0A> Cc: =0A> Sent: Sunday, May 6, 2012 11:17 AM=0A> Subject: AW: =
[DISCUSS] deltaspike-jpa module features=0A> =0A> Hi,=0A> I think we have d=
ifferent dimensions here:=0A> 1. Who manages the transaction: JTA vs. RESOU=
RCE_LOCAL (which basically means, =0A> should entityManager.joinTransaction=
() or entityManager.getTransaction().begin() =0A> be used in an @Transactio=
nal interceptor)=0A> 2. From where can the datasource be obtained: From JND=
I or is it defined via the =0A> persistence properties=0A> The third (minor=
) dimension that applies only if the datasource comes from JNDI: =0A> Is it=
 a jta- or non-jta-datasource=0A> =0A> So the first dimension has to be res=
pected when talking about =0A> transaction-management=0A> and the second, w=
hen talking about datasource-configuration.=0A> =0A> So, as I see, currentl=
y we are talking about the second:=0A> Now the question is, how to configur=
e the datasource in both scenarios. And both =0A> can be done with the Conf=
igurableDataSource:=0A> First scenario: The datasource is obtained from JND=
I: Then the =0A> ConfigurableDataSource needs to be registered in JNDI. In =
Java-EE-Containers =0A> this can be done with the @DataSourceDefinition ann=
otation. In plain Tomcat or =0A> Jetty servers this needs to be configured =
in a container-specific way.=0A> Second scenario: The datasource is configu=
red via persistence properties. Then =0A> the ConfigurableDataSource can be=
 configured like described in the CoDI wiki.=0A> =0A> How can deltaspike he=
lp people here? First of all we provide the =0A> ConfigurableDataSource and=
 thus enable DataSource configuration via CDI.=0A> In addition, if we provi=
de some kind of EntityManagerProducer, we can override =0A> the persistence=
.xml via the additional properties map, that can be handed over =0A> to the=
 createEntityManagerFactory and createEntityManager methods.=0A> For JNDI, =
we can register a ConfigurableDataSource with the =0A> @DataSourceDefinitio=
n under a deltaspike-specific name and then give this =0A> datasource to JP=
A by setting the javax.persistence.jtaDataSource or =0A> javax.persistence.=
nonJtaDataSource property in the map.=0A> For non-JNDI we can change the ja=
vax.persistence.jdbc.driver property to point =0A> to our ConfigurableDataS=
ource.=0A> =0A> We even could provide a mechanism to change from JTA to RES=
OURCE_LOCAL (i.e. for =0A> production vs. testing) by specifying the javax.=
persistence.transactionType =0A> property.=0A> =0A> What do you think about=
 this?=0A> =0A> Cheers,=0A> Arne=0A> =0A> -----Urspr=FCngliche Nachricht---=
--=0A> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com] =0A> Gesendet=
: Sonntag, 6. Mai 2012 08:09=0A> An: deltaspike-dev@incubator.apache.org=0A=
> Betreff: Re: [DISCUSS] deltaspike-jpa module features=0A> =0A> @Mark: tod=
ay using your own datasource implementation with @datasourcedefinition =0A>=
 you answer your need. The drawback compared to producers is you need to te=
st the =0A> env where producers will have stereotypes but it does the job e=
ven for =0A> complicated envrt.=0A> =0A> - Romain=0A> Le 6 mai 2012 05:02, =
"Jason Porter" <lightguard.jp@gmail.com> a =0A> =E9crit :=0A> =0A>>  Wasn't=
 there another company, Software Mill?, which had some =0A>>  persistence s=
tuff we liked during formation?=0A>> =0A>>  Sent from my iPhone=0A>> =0A>> =
 On May 5, 2012, at 16:14, Mark Struberg <struberg@yahoo.de> wrote:=0A>> =
=0A>>  > Yes, we should first concentrate on the other 2 things. We can try=
 =0A>>  > to=0A>>  find an even better solution than the ConfigurableDataSo=
urce.=0A>>  >=0A>>  > But I fear the @DataSourceDefinition from EE6 is comp=
letely useless =0A>>  > for=0A>>  most real world apps.=0A>>  > The problem=
 which I see with it that you can only have 1 of it per=0A>>  'real' DataSo=
urce. Of course that would change if there would be a =0A> way =0A>>  to cr=
eate the 'real' DataSource via CDI producers.=0A>>  >=0A>>  > But I have no=
 idea yet how to hand over a CDI produced DataSource to =0A>>  > a=0A>>  JP=
A.=0A>>  >=0A>>  >=0A>>  > LieGrue,=0A>>  > strub=0A>>  >=0A>>  >=0A>>  >=
=0A>>  > ----- Original Message -----=0A>>  >> From: Romain Manni-Bucau <rm=
annibucau@gmail.com>=0A>>  >> To: deltaspike-dev@incubator.apache.org=0A>> =
 >> Cc:=0A>>  >> Sent: Saturday, May 5, 2012 11:29 PM=0A>>  >> Subject: Re:=
 [DISCUSS] deltaspike-jpa module features=0A>>  >>=0A>>  >> With my note on=
 datasourcedefinition i wanted to avoid to add sthg =0A> new.=0A>>  I'd=0A>=
>  >> prefer to fix existing API/specs.=0A>>  >>=0A>>  >> Adding sthg new s=
imply creates another mess...no?=0A>>  >>=0A>>  >> - Romain=0A>>  >> Le 5 m=
ai 2012 22:39, "Paul Dijou" =0A> <paul.dijou.dev@gmail.com> a =0A>>  >> =E9=
crit :=0A>>  >>=0A>>  >>> Hi,=0A>>  >>>=0A>>  >>> Big +1 for all suggestion=
s from Mark.=0A>>  >>>=0A>>  >>> Also +1 for some util classes for common o=
perations like CRUD =0A> and =0A>>  >>> pagination. Maybe inspiration from =
Seam Application Framework =0A>>  >>> (Home,=0A>>  Query,=0A>>  >>> Control=
ler) in Seam 2 [1] or from DataValve [2].=0A>>  >>>=0A>>  >>> Regards,=0A>>=
  >>>=0A>>  >>> Paul.=0A>>  >>>=0A>>  >>> [1]=0A>>  >>>=0A>>  http://docs.j=
boss.org/seam/2.2.2.Final/reference/en-US/html/framework.=0A>>  html=0A>>  =
>>>=0A>>  >>> [2] http://www.andygibson.net/blog/projects/datavalve/=0A>>  =
>>>=0A>>  >>> 2012/5/5 Romain Manni-Bucau <rmannibucau@gmail.com>=0A>>  >>>=
=0A>>  >>>> Maybe using a datasource bean managed by cdi as a jpa =0A> data=
source=0A>>  >> source=0A>>  >>> can=0A>>  >>>> be added to jpa or cdi (it =
is always a bit hard to decide =0A> which =0A>>  >>>> specs qhould contain =
a new feature ;))?=0A>>  >>>>=A0  Le 5 mai 2012 00:55, "Romain Manni-Bucau"=
=0A>>  >> <rmannibucau@gmail.com> a=0A>>  >>>> =E9crit :=0A>>  >>>>=0A>>  >=
>>>> Hi,=0A>>  >>>>>=0A>>  >>>>> isn't the ConfigurableDataSource in JEE6?=
=0A>>  >> (datasourceconfiguration by=0A>>  >>>>> annotation or in the web.=
xml)?=0A>>  >>>>>=0A>>  >>>>> a really really big +1 for a pagination solut=
ion =0A> (typically a=0A>>  >> hades=0A>>  >>> light=0A>>  >>>>> is a must =
have!)=0A>>  >>>>>=0A>>  >>>>> - Romain=0A>>  >>>>>=0A>>  >>>>>=0A>>  >>>>>=
 2012/5/4 Gerhard Petracek =0A> <gerhard.petracek@gmail.com>=0A>>  >>>>>=0A=
>>  >>>>>> hi @ all,=0A>>  >>>>>>=0A>>  >>>>>> @ a)=0A>>  >>>>>> +1=0A>>  >=
>>>>>=0A>>  >>>>>> @ b)=0A>>  >>>>>> +1 for the basic concepts, however, @T=
ransactional =0A> and=0A>>  >>>> @TransactionScoped=0A>>  >>>>>> need to be=
 refactored (i'm currently working =0A> on it).=0A>>  >>>>>>=0A>>  >>>>>> f=
urthermore, we should discuss a thin query layer =0A> which=0A>>  >> suppor=
ts e.g.=0A>>  >>>>>> pagination,... easily (we also need it for a =0A> secu=
rity-jpa=0A>>  >> module).=0A>>  >>>>>>=0A>>  >>>>>> regards,=0A>>  >>>>>> =
gerhard=0A>>  >>>>>>=0A>>  >>>>>>=0A>>  >>>>>>=0A>>  >>>>>> 2012/5/4 Mark S=
truberg <struberg@yahoo.de>=0A>>  >>>>>>=0A>>  >>>>>>> Hi!=0A>>  >>>>>>>=0A=
>>  >>>>>>> It's time to start the discussion about =0A> our=0A>>  >> delta=
spike-jpa module I=0A>>  >>>>>> think=0A>>  >>>>>>> ;)=0A>>  >>>>>>>=0A>>  =
>>>>>>> a.) where=0A>>  >>>>>>>=A0  I suggest that we create a ee-modules =
=0A> project with=0A>>  >> submodules jsf,=0A>>  >>>> jpa,=0A>>  >>>>>>> et=
c=0A>>  >>>>>>>=0A>>  >>>>>>> b.) what=0A>>  >>>>>>>=A0  *) @Transactional=
=0A>>  >>>>>>>=A0  *) TransactionalInterceptor with=0A>>  >> SimplePersiste=
nceStrategy,=0A>>  >>>>>>> JtaPersistenceStrategy=0A>>  >>>>>>>=A0  *) Conf=
igurableDataSource, evaluate if we =0A> can make use=0A>>  >> of a special=
=0A>>  >>>>>>> PersistenceUnitInfo for JPA2 providers, but =0A> would that=
=0A>>  >> work in EE=0A>>  >>>>>>> containers as well?=0A>>  >>>>>>>=0A>>  =
>>>>>>> Because I often get asked if we can add this: =0A> I think we=0A>> =
 >> do _not_=0A>>  >>> need=0A>>  >>>>>> to=0A>>  >>>>>>> cover the (imo) b=
roken Exception handling =0A> stuff which=0A>>  >> spring=0A>>  >>>> introd=
uced=0A>>  >>>>>> in=0A>>  >>>>>>> their transaction interceptor. An Except=
ion is =0A> an=0A>>  >> Exception is an=0A>>  >>>>>>> Exception! Logical re=
turn values and Business =0A> results=0A>>  >> must get=0A>>  >>>>>> propag=
ated=0A>>  >>>>>>> via standard java return values or content =0A> holder=
=0A>>  >> objects.=0A>>  >>>>>>>=0A>>  >>>>>>> Oki the details:=0A>>  >>>>>=
>>=0A>>  >>>>>>> 1.) @Transational=0A>>  >>>>>>>=0A>>  >>>>>>> I suggest th=
at we temporarily implement the=0A>>  >> javax.transaction.*=0A>>  >>> stuf=
f=0A>>  >>>> of=0A>>  >>>>>>> the _new_ Transaction Specification in =0A> D=
eltaSpike. We=0A>>  >> can take parts=0A>>  >>>>>> from=0A>>  >>>>>>> OpenE=
JB, some JBoss api stuff (as far as =0A> covered by the=0A>>  >> grants) an=
d=0A>>  >>>>>> various=0A>>  >>>>>>> geronimo spec jars [1]=0A>>  >>>>>>> O=
nce the spec is finished, we will move all =0A> the=0A>>  >> transaction-ap=
i.jar=0A>>  >>>>>> stuff=0A>>  >>>>>>> over to geronimo-specs [1]. Since th=
is all is =0A> ALv2 it=0A>>  >> will be no=0A>>  >>>> problem=0A>>  >>>>>>>=
 for JBoss folks to also just take the code and =0A> provide=0A>>  >> it in=
 the=0A>>  >>>> JBossAS=0A>>  >>>>>>> project once we are finished.=0A>>  >=
>>>>>>=0A>>  >>>>>>> 2.) I like the way we implemented the=0A>>  >> Transac=
tionalInterceptor in=0A>>  >>> CODI=0A>>  >>>>>>> [2]. Our interceptor basi=
cally does exactly =0A> ...=0A>>  >> *nothing* ;)=0A>>  >>>>>>>=A0  All the=
 work is done via an @Dependent=0A>>  >> PersistenceStrategy which=0A>>  >>=
> gets=0A>>  >>>>>>> injected into the interceptor. @Dependent =0A> because=
 then=0A>>  >> we don't get=0A>>  >>>> any=0A>>  >>>>>>> interceptor and it=
's really fast.=0A>>  >>>>>>>=A0  The BIG benefit of this little trick is t=
hat =0A> we are=0A>>  >> able to provide=0A>>  >>>> and=0A>>  >>>>>>> use D=
IFFERENT PersistenceStrategies! A user =0A> can use=0A>>  >> @Alternative,=
=0A>>  >>>>>>> @Specializes etc to define which =0A> PersistenceStrategy he=
=0A>>  >> likes to use=0A>>  >>>> in=0A>>  >>>>>> his=0A>>  >>>>>>> project=
.=0A>>  >>>>>>>=0A>>  >>>>>>>=A0  By default I'd like to provide the =0A> f=
ollowing=0A>>  >> PersistenceStrategies:=0A>>  >>>>>>>=A0  * SimplePersiste=
nceStrategy: does just flush =0A> on all=0A>>  >> involved=0A>>  >>>>>>> En=
tityManagers and afterwards a commit. Not =0A> JTA=0A>>  >> transaction sav=
e,=0A>>  >>> but=0A>>  >>>>>> good=0A>>  >>>>>>> enough for most use cases=
=0A>>  >>>>>>>=A0  * JtaPersistenceStrategy: uses a JTA bound=0A>>  >> @Use=
rTransaction to=0A>>  >>>> control=0A>>  >>>>>>> the EntitaManagers. This n=
eeds some =0A> exploration how we=0A>>  >> can do it.=0A>>  >>>> David=0A>>=
  >>>>>>> Blevins and Arne Limburg are pretty good into =0A> this=0A>>  >> =
stuff. I'm=0A>>  >>> dreaming=0A>>  >>>>>> of=0A>>  >>>>>>> kind of the fea=
tures of EJB standard =0A> transations, but=0A>>  >> NOT just for=0A>>  >>>=
 an=0A>>  >>>>>> EJB=0A>>  >>>>>>> invocation, but @RequestScoped! The firs=
t =0A> invocation=0A>>  >> starts the=0A>>  >>>>>>> UserTransaction, the @D=
isposes closes it. Just =0A> an idea=0A>>  >> ...=0A>>  >>>>>>>=0A>>  >>>>>=
>>=0A>>  >>>>>>> 3.) ConfigurableDataSource=0A>>  >>>>>>>=A0  You all know =
the dilemma: you cannot make a =0A> JNDI=0A>>  >> configuration in a=0A>>  =
>>>> way=0A>>  >>>>>>> that this stuff works with multiple EE servers =0A> =
since the=0A>>  >> locations=0A>>  >>>> where=0A>>  >>>>>>> you have your D=
ataSource configured will pop =0A> up under=0A>>  >> different=0A>>  >>>>>>=
 locations=0A>>  >>>>>>> in JNDI (based on which EE server/version you =0A>=
 take).=0A>>  >> Otoh I don't=0A>>  >>> like=0A>>  >>>>>> to=0A>>  >>>>>>> =
hardcode my credentials to the persistence.xml =0A> neither.=0A>>  >>>>>>>=
=0A>>  >>>>>>> Thus we came up with the =0A> ConfigurableDataSource [3]whic=
h=0A>>  >> just moves=0A>>  >>>> this=0A>>  >>>>>>> information to a CDI be=
an where you can use =0A>>  >>>>>>> @Exclude(ifNotInProjectStage...), =0A> =
@Alternative,=0A>>  >> @Specializes and=0A>>  >>> even=0A>>  >>>>>>> progra=
mmatic lookup!. I call this =0A> 'typesafe=0A>>  >> configuration'...=0A>> =
 >>>>>>>=0A>>  >>>>>>>=0A>>  >>>>>>>=0A>>  >>>>>>> Oki, any other ideas?=0A=
>>  >>>>>>>=0A>>  >>>>>>> LieGrue,=0A>>  >>>>>>> strub=0A>>  >>>>>>>=0A>>  =
>>>>>>>=0A>>  >>>>>>> [1]=0A>>  >> http://repo1.maven.org/maven2/org/apache=
/geronimo/specs/=0A>>  >>>>>>>=0A>>  >>>>>>> [2]=0A>>  >>>>>>>=0A>>  >>>>>>=
=0A>>  >>>>=0A>>  >>>=0A>>  >>=0A>>  https://svn.apache.org/repos/asf/myfac=
es/extensions/cdi/trunk/jee-modu=0A>>  les/jpa-module/impl/src/main/java/or=
g/apache/myfaces/extensions/cdi/jp=0A>>  a/impl/transaction/TransactionalIn=
terceptor.java=0A>>  >>>>>>>=0A>>  >>>>>>> [3]=0A>>  >>>>>>>=0A>>  >>>>>>=
=0A>>  >>>>=0A>>  >>>=0A>>  >>=0A>>  https://cwiki.apache.org/EXTCDI/jpa-us=
age.html#JPAUsage-ConfigurableDa=0A>>  taSource%28sincev1.0.2%29=0A>>  >>>>=
>>>=0A>>  >>>>>>=0A>>  >>>>>=0A>>  >>>>>=0A>>  >>>>=0A>>  >>>=0A>>  >>=0A>>=
 =0A>