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 <[email protected]> > +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 <[email protected]> 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 > > >
