+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 >
