Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of pmuir@redhat.com designates
 209.132.183.28 as permitted sender)
Subject: Re: [DISCUSS] deltaspike-jpa module features
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Pete Muir <pmuir@redhat.com>
In-Reply-To: <1336161394.18186.YahooMailNeo@web171506.mail.ir2.yahoo.com>
Date: Tue, 8 May 2012 12:58:20 +0100
Cc: Stuart Douglas <sdouglas@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E34F8505-F249-4809-AA9D-0FAB79CB49C9@redhat.com>
References: <1336161394.18186.YahooMailNeo@web171506.mail.ir2.yahoo.com>
To: deltaspike-dev@incubator.apache.org, Mark Struberg <struberg@yahoo.de>

Following up on all emails sent so far on this thread:

* I like Mark's priorities - @Transactional is definitely the item most =
requested
* I like the design of plugging in different persistence strategies
* Agreed that the standardised stuff for configuring datasources is a =
mess, we don't recommend it for use in JBoss, as we don't want to =
compile in this info. Instead we use a xml descriptor you can deploy, or =
a managed datasource configured via the management apis (scripted, HTTP, =
admin console etc.)
* The big issue we have with the Java EE programmatic data source =
definition 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 we 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 might 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 =
basic stuff right first is better
* Agreed with Mark/Arne, there is no good way with the =
@DataSourceDefinition stuff to configure based on "project stage", and =
this is the critical problem, not the one about how to configure =
datasource across containers

Answering David's questions

> Q1. Alternatives and JavaEE Resource annotations.  What happens if a =
CDI bean is annotated with "@Resource(name =3D "java:app/ds", =
lookup=3D"java:app/prod/ds")", but has an alternate annotated with =
"@Resource(name =3D "java:app/ds", lookup=3D"java:app/test/ds")?
>=20
> One would hope that either the main bean's JNDI entries *or* the =
alternate bean's JNDI entries will go into effect, not both.  This isn't =
explicitly covered so I doubt will work.  Something we might want to add =
at the spec level.

It's not specified, and I don't think it works anywhere. We have raised =
this for Java EE 7, but received push back due to it coupling CDI too =
tightly into the Java EE core, which, as CDI isn't always on, is =
something the Java EE EG/spec leads want to avoid.

>=20
> Q2. Extensions adding/removing beans.   What happens if a CDI bean is =
annotated with "@Resource(name =3D "java:app/ds", =
lookup=3D"java:app/prod/ds")" and is vetoed by an Extension?
>=20
> One would hope that the JNDI entries that would be added by the vetoed =
bean are also essentially vetoed and the bean does not have an impact on =
the JNDI namespace.  Also 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!
>=20
> It's time to start the discussion about our deltaspike-jpa module I =
think ;)
>=20
> a.) where
>  I suggest that we create a ee-modules project with submodules jsf, =
jpa, etc
> =20
> b.) what
>  *) @Transactional
>  *) TransactionalInterceptor with SimplePersistenceStrategy, =
JtaPersistenceStrategy
>  *) ConfigurableDataSource, evaluate if we can make use of a special =
PersistenceUnitInfo for JPA2 providers, but would that work in EE =
containers as well?
>=20
> Because I often get asked if we can add this: I think we do _not_ need =
to cover the (imo) broken Exception handling stuff which spring =
introduced in their transaction interceptor. An Exception is an =
Exception is an Exception! Logical return values and Business results =
must get propagated via standard java return values or content holder =
objects.
>=20
> Oki the details:
>=20
> 1.) @Transational
>=20
> 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 =
stuff 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 project once we are finished.
>=20
> 2.) I like the way we implemented the TransactionalInterceptor in CODI =
[2]. Our interceptor basically does exactly ... *nothing* ;)
>  All the work is done via an @Dependent PersistenceStrategy which gets =
injected into the interceptor. @Dependent because then we don't get any =
interceptor and it's really fast.
>  The BIG benefit of this little trick is that we are able to provide =
and use DIFFERENT PersistenceStrategies! A user can use @Alternative, =
@Specializes etc to define which PersistenceStrategy he likes to use in =
his project.
>=20
>  By default I'd like to provide the following PersistenceStrategies:
>  * SimplePersistenceStrategy: does just flush on all involved =
EntityManagers and afterwards a commit. Not JTA transaction save, but =
good enough for most use cases
>  * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to =
control the EntitaManagers. This needs some exploration how we can do =
it. David 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 UserTransaction, the @Disposes closes it. Just an idea ...
>=20
>=20
> 3.) ConfigurableDataSource
>  You all know the dilemma: you cannot make a JNDI configuration in a =
way that this stuff works with multiple EE servers since the locations =
where you have your DataSource configured will pop up under different =
locations in JNDI (based on which EE server/version you take). Otoh I =
don't like to hardcode my credentials to the persistence.xml neither.
>=20
> 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'...
>=20
>=20
>=20
> Oki, any other ideas?
>=20
> LieGrue,
> strub
>=20
>=20
> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>=20
> [2] =
https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/=
jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/t=
ransaction/TransactionalInterceptor.java
>=20
> [3] =
https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSo=
urce%28sincev1.0.2%29