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
