Yes, we should first concentrate on the other 2 things. We can try to find an even better solution than the ConfigurableDataSource.
But I fear the @DataSourceDefinition from EE6 is completely useless for most real world apps. The problem which I see with it that you can only have 1 of it per 'real' DataSource. Of course that would change if there would be a way to create the 'real' DataSource via CDI producers. But I have no idea yet how to hand over a CDI produced DataSource to a JPA. LieGrue, strub ----- Original Message ----- > From: Romain Manni-Bucau <[email protected]> > To: [email protected] > Cc: > Sent: Saturday, May 5, 2012 11:29 PM > Subject: Re: [DISCUSS] deltaspike-jpa module features > > With my note on datasourcedefinition i wanted to avoid to add sthg new. I'd > prefer to fix existing API/specs. > > Adding sthg new simply creates another mess...no? > > - Romain > Le 5 mai 2012 22:39, "Paul Dijou" <[email protected]> a > écrit : > >> Hi, >> >> Big +1 for all suggestions from Mark. >> >> Also +1 for some util classes for common operations like CRUD and >> pagination. Maybe inspiration from Seam Application Framework (Home, Query, >> Controller) in Seam 2 [1] or from DataValve [2]. >> >> Regards, >> >> Paul. >> >> [1] >> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html >> >> [2] http://www.andygibson.net/blog/projects/datavalve/ >> >> 2012/5/5 Romain Manni-Bucau <[email protected]> >> >> > 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 >> > >> > >> > >> >> > > >> > > >> > >> >
