deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Sat, 19 May 2012 13:51:39 GMT
hi @ all,

i've committed [1] a refactored version of @Transactional as well as
@TransactionScoped (for @Transactional).
i'll add some details to the documentation soon (we can't copy it, because
the new behaviour is a bit different (easier)).
furthermore, i've committed several tests (which represent different
constellations).

regards,
gerhard

[1] http://s.apache.org/wte
[2] https://issues.apache.org/jira/browse/DELTASPIKE-178



2012/5/8 Cody Lerum <cody.lerum@gmail.com>

> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message