Maybe using a datasource bean managed by cdi as a jpa datasource source can be added to jpa or cdi (it is always a bit hard to decide which specs qhould contain a new feature ;))? Le 5 mai 2012 00:55, "Romain Manni-Bucau" <[email protected]> a écrit :
> Hi, > > isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by > annotation or in the web.xml)? > > a really really big +1 for a pagination solution (typically a hades light > is a must have!) > > - Romain > > > 2012/5/4 Gerhard Petracek <[email protected]> > >> hi @ all, >> >> @ a) >> +1 >> >> @ b) >> +1 for the basic concepts, however, @Transactional and @TransactionScoped >> need to be refactored (i'm currently working on it). >> >> furthermore, we should discuss a thin query layer which supports e.g. >> pagination,... easily (we also need it for a security-jpa module). >> >> regards, >> gerhard >> >> >> >> 2012/5/4 Mark Struberg <[email protected]> >> >> > 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 >> > >> > >
