deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Tue, 08 May 2012 11:58:20 GMT
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 = "java:app/ds", lookup="java:app/prod/ds")", but has an alternate annotated
with "@Resource(name = "java:app/ds", lookup="java:app/test/ds")?
> 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.

> Q2. Extensions adding/removing beans.   What happens if a CDI bean is annotated with
"@Resource(name = "java:app/ds", lookup="java:app/prod/ds")" and is vetoed by an Extension?
> 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!
> It's time to start the discussion about our deltaspike-jpa module I think ;)
> a.) where
>  I suggest that we create a ee-modules project with submodules jsf, jpa, etc
> 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?
> 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.
> 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 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.
> 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.
>  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 ...
> 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.
> 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]
> [2]
> [3]

View raw message