deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cody Lerum <cody.le...@gmail.com>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Tue, 08 May 2012 14:28:35 GMT
+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 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] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>>
>> [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/transaction/TransactionalInterceptor.java
>>
>> [3] https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>

Mime
View raw message