Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of cody.lerum@gmail.com designates
 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E34F8505-F249-4809-AA9D-0FAB79CB49C9@redhat.com>
References: <1336161394.18186.YahooMailNeo@web171506.mail.ir2.yahoo.com>
	<E34F8505-F249-4809-AA9D-0FAB79CB49C9@redhat.com>
Date: Tue, 8 May 2012 08:28:35 -0600
Message-ID: 
 <CAN+FrnVoHhMQ412SFkK2QCKnBWNrMxW+QqTyb89a8npDwUg6rw@mail.gmail.com>
Subject: Re: [DISCUSS] deltaspike-jpa module features
From: Cody Lerum <cody.lerum@gmail.com>
To: deltaspike-dev@incubator.apache.org
Cc: Mark Struberg <struberg@yahoo.de>, Stuart Douglas <sdouglas@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 for deferring the CRUD work until a later release. Let's get the
basics right and out in the wild first.

On Tue, May 8, 2012 at 5:58 AM, Pete Muir <pmuir@redhat.com> wrote:
> Following up on all emails sent so far on this thread:
>
> * I like Mark's priorities - @Transactional is definitely the item most r=
equested
> * I like the design of plugging in different persistence strategies
> * Agreed that the standardised stuff for configuring datasources is a mes=
s, we don't recommend it for use in JBoss, as we don't want to compile in t=
his info. Instead we use a xml descriptor you can deploy, or a managed data=
source configured via the management apis (scripted, HTTP, admin console et=
c.)
> * The big issue we have with the Java EE programmatic data source definit=
ion stuff, is that this normally isn't "part of your app" but something you=
 want to provide externally and reference via JNDI. It would have good if w=
e had specified XML as well as annotations for this. I think this is coming=
 in Java EE 7, and then will resolve a lot of this problem, for me. We migh=
t also want to make the configuration a bit simpler.
> * Hopefully Stuart can provide some time on the transactions stuff
> * I think that the CRUD stuff is good for a later phase, getting the basi=
c stuff right first is better
> * Agreed with Mark/Arne, there is no good way with the @DataSourceDefinit=
ion stuff to configure based on "project stage", and this is the critical p=
roblem, not the one about how to configure datasource across containers
>
> Answering David's questions
>
>> Q1. Alternatives and JavaEE Resource annotations. =C2=A0What happens if =
a CDI bean is annotated with "@Resource(name =3D "java:app/ds", lookup=3D"j=
ava:app/prod/ds")", but has an alternate annotated with "@Resource(name =3D=
 "java:app/ds", lookup=3D"java:app/test/ds")?
>>
>> One would hope that either the main bean's JNDI entries *or* the alterna=
te bean's JNDI entries will go into effect, not both. =C2=A0This isn't expl=
icitly covered so I doubt will work. =C2=A0Something we might want to add a=
t the spec level.
>
> It's not specified, and I don't think it works anywhere. We have raised t=
his for Java EE 7, but received push back due to it coupling CDI too tightl=
y into the Java EE core, which, as CDI isn't always on, is something the Ja=
va EE EG/spec leads want to avoid.
>
>>
>> Q2. Extensions adding/removing beans. =C2=A0 What happens if a CDI bean =
is annotated with "@Resource(name =3D "java:app/ds", lookup=3D"java:app/pro=
d/ds")" and is vetoed by an Extension?
>>
>> One would hope that the JNDI entries that would be added by the vetoed b=
ean are also essentially vetoed and the bean does not have an impact on the=
 JNDI namespace. =C2=A0Also not explicitly addressed and something we might=
 want to tackle at the spec level.
>
> As above :-)
>
>
> On 4 May 2012, at 20:56, Mark Struberg wrote:
>
>> Hi!
>>
>> It's time to start the discussion about our deltaspike-jpa module I thin=
k ;)
>>
>> a.) where
>> =C2=A0I suggest that we create a ee-modules project with submodules jsf,=
 jpa, etc
>>
>> b.) what
>> =C2=A0*) @Transactional
>> =C2=A0*) TransactionalInterceptor with SimplePersistenceStrategy, JtaPer=
sistenceStrategy
>> =C2=A0*) ConfigurableDataSource, evaluate if we can make use of a specia=
l PersistenceUnitInfo for JPA2 providers, but would that work in EE contain=
ers as well?
>>
>> Because I often get asked if we can add this: I think we do _not_ need t=
o cover the (imo) broken Exception handling stuff which spring introduced i=
n their transaction interceptor. An Exception is an Exception is an Excepti=
on! Logical return values and Business results must get propagated via stan=
dard java return values or content holder objects.
>>
>> Oki the details:
>>
>> 1.) @Transational
>>
>> I suggest that we temporarily implement the javax.transaction.* stuff of=
 the _new_ Transaction Specification in DeltaSpike. We can take parts from =
OpenEJB, some JBoss api stuff (as far as covered by the grants) and various=
 geronimo spec jars [1]
>> Once the spec is finished, we will move all the transaction-api.jar stuf=
f over to geronimo-specs [1]. Since this all is ALv2 it will be no problem =
for JBoss folks to also just take the code and provide it in the JBossAS pr=
oject once we are finished.
>>
>> 2.) I like the way we implemented the TransactionalInterceptor in CODI [=
2]. Our interceptor basically does exactly ... *nothing* ;)
>> =C2=A0All the work is done via an @Dependent PersistenceStrategy which g=
ets injected into the interceptor. @Dependent because then we don't get any=
 interceptor and it's really fast.
>> =C2=A0The BIG benefit of this little trick is that we are able to provid=
e and use DIFFERENT PersistenceStrategies! A user can use @Alternative, @Sp=
ecializes etc to define which PersistenceStrategy he likes to use in his pr=
oject.
>>
>> =C2=A0By default I'd like to provide the following PersistenceStrategies=
:
>> =C2=A0* SimplePersistenceStrategy: does just flush on all involved Entit=
yManagers and afterwards a commit. Not JTA transaction save, but good enoug=
h for most use cases
>> =C2=A0* JtaPersistenceStrategy: uses a JTA bound @UserTransaction to con=
trol the EntitaManagers. This needs some exploration how we can do it. Davi=
d Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of=
 kind of the features of EJB standard transations, but NOT just for an EJB =
invocation, but @RequestScoped! The first invocation starts the UserTransac=
tion, the @Disposes closes it. Just an idea ...
>>
>>
>> 3.) ConfigurableDataSource
>> =C2=A0You all know the dilemma: you cannot make a JNDI configuration in =
a way that this stuff works with multiple EE servers since the locations wh=
ere you have your DataSource configured will pop up under different locatio=
ns in JNDI (based on which EE server/version you take). Otoh I don't like t=
o hardcode my credentials to the persistence.xml neither.
>>
>> Thus we came up with the ConfigurableDataSource [3]which just moves this=
 information to a CDI bean where you can use @Exclude(ifNotInProjectStage..=
.), @Alternative, @Specializes and even programmatic lookup!. I call this '=
typesafe configuration'...
>>
>>
>>
>> Oki, any other ideas?
>>
>> LieGrue,
>> strub
>>
>>
>> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>>
>> [2] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-mo=
dules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/i=
mpl/transaction/TransactionalInterceptor.java
>>
>> [3] https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-Configurable=
DataSource%28sincev1.0.2%29
>