Mark, I dont see why you find dsdef limited. Le 6 mai 2012 11:38, "Mark Struberg" <[email protected]> a écrit :
> 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 > >> >>>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>> > >> >>> > >> >> > >> > > >
