Hi Arne! For your 1. please see the 'PersistenceStrategy' trick we did in the CODI TransactionalInterceptor [1]. Our interceptor is basically a facade which delegates all the work to the injected @Dependent PersistenceStrategy. We would provide 2 different implementations: a resource local and a JTA based one.
Just to stress that point again: > ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers > this can be done with the @DataSourceDefinition annotation. Yes, but ONLY if you need just one single configuration! > In plain Tomcat or > Jetty servers this needs to be configured in a container-specific way. The problem with the container specific stuff is that every container serves the xml configured datasource on a different location in JNDI! So you cannot provide a container independent implementation that way :/ Rest sounds good, I'll think about it the next days! LieGrue, strub [1] 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 ----- Original Message ----- > From: Arne Limburg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Sunday, May 6, 2012 11:17 AM > Subject: AW: [DISCUSS] deltaspike-jpa module features > > Hi, > I think we have different dimensions here: > 1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically > means, > should entityManager.joinTransaction() or > entityManager.getTransaction().begin() > be used in an @Transactional interceptor) > 2. From where can the datasource be obtained: From JNDI or is it defined via > the > persistence properties > The third (minor) dimension that applies only if the datasource comes from > JNDI: > Is it a jta- or non-jta-datasource > > So the first dimension has to be respected when talking about > transaction-management > and the second, when talking about datasource-configuration. > > So, as I see, currently we are talking about the second: > Now the question is, how to configure the datasource in both scenarios. And > both > can be done with the ConfigurableDataSource: > First scenario: The datasource is obtained from JNDI: Then the > ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers > this can be done with the @DataSourceDefinition annotation. In plain Tomcat > or > Jetty servers this needs to be configured in a container-specific way. > Second scenario: The datasource is configured via persistence properties. > Then > the ConfigurableDataSource can be configured like described in the CoDI wiki. > > How can deltaspike help people here? First of all we provide the > ConfigurableDataSource and thus enable DataSource configuration via CDI. > In addition, if we provide some kind of EntityManagerProducer, we can > override > the persistence.xml via the additional properties map, that can be handed > over > to the createEntityManagerFactory and createEntityManager methods. > For JNDI, we can register a ConfigurableDataSource with the > @DataSourceDefinition under a deltaspike-specific name and then give this > datasource to JPA by setting the javax.persistence.jtaDataSource or > javax.persistence.nonJtaDataSource property in the map. > For non-JNDI we can change the javax.persistence.jdbc.driver property to > point > to our ConfigurableDataSource. > > We even could provide a mechanism to change from JTA to RESOURCE_LOCAL (i.e. > for > production vs. testing) by specifying the javax.persistence.transactionType > property. > > What do you think about this? > > Cheers, > Arne > > -----Ursprüngliche Nachricht----- > Von: Romain Manni-Bucau [mailto:[email protected]] > Gesendet: Sonntag, 6. Mai 2012 08:09 > An: [email protected] > Betreff: Re: [DISCUSS] deltaspike-jpa module features > > @Mark: today using your own datasource implementation with > @datasourcedefinition > you answer your need. The drawback compared to producers is you need to test > the > env where producers will have stereotypes but it does the job even for > complicated envrt. > > - Romain > Le 6 mai 2012 05:02, "Jason Porter" <[email protected]> a > écrit : > >> Wasn't there another company, Software Mill?, which had some >> persistence stuff we liked during formation? >> >> Sent from my iPhone >> >> On May 5, 2012, at 16:14, Mark Struberg <[email protected]> wrote: >> >> > 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-modu >> les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp >> a/impl/transaction/TransactionalInterceptor.java >> >>>>>>> >> >>>>>>> [3] >> >>>>>>> >> >>>>>> >> >>>> >> >>> >> >> >> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa >> taSource%28sincev1.0.2%29 >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >> >> >
