Hi Mark, your suggestion won't work since the existing implementations are not using openwebbeans.properties to configure their TransactionService. Instead of that they are using the Plugin-mechanism.
Cheers, Arne -- Arne Limburg - Enterprise Architekt open knowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 [email protected] http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann -----Ursprüngliche Nachricht----- Von: Mark Struberg [mailto:[email protected]] Gesendet: Montag, 5. September 2011 09:54 An: [email protected] Betreff: Re: AW: AW: Transactional events and the TransactionService This can easily be tweaked by using a proper configuration.ordinal in our openwebbeans.properties. The common ee plugin must have a lower ordinal than the more special plugins. owb-core ^ owb-ee ^ owb-openejb, etc We should be able to keep this perfectly compatible imo. LieGrue, strub ----- Original Message ----- > From: Arne Limburg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Monday, September 5, 2011 9:12 AM > Subject: AW: AW: Transactional events and the TransactionService > > Hi Gurkan, > > Placing the DefaultTransactionService in the ee-module and > instantiating it with openwebbeans.properties would place an > incompatibility between version 1.1(.1) and version 1.2 of OWB, since > the services defined in openwebbeans.properties take precedence over > the services defined in plugins. Current implementations of the > TransactionService (openEJB, Geronimo, ...) all are defined within > plugins and would be ignored with 1.2 of OWB. If this is no problem, I > agree, that the service should go into the ee-module. BTW the > Geronimo-implementation of our TransactionService would be obsolete > anyway with my default-implementation and I can change the > openEJB-implementation on the way. Are there any other implementations of the > TransactionService we know of? > > Cheers, > Arne > > -- > > Arne Limburg - Enterprise Architekt > open knowledge GmbH, Oldenburg > Bismarckstraße 13, 26122 Oldenburg > Mobil: +49 (0) 151 108 22 942 > Tel: +49 (0) 441 - 4082-0 > Fax: +49 (0) 441 - 4082-111 > [email protected] > http://www.openknowledge.de > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > Geschäftsführer: Lars Röwekamp, Jens Schumann > > -----Ursprüngliche Nachricht----- > Von: Gurkan Erdogdu [mailto:[email protected]] > Gesendet: Sonntag, 4. September 2011 20:23 > An: [email protected] > Betreff: İlt: AW: Transactional events and the TransactionService > > Hello Arne, > > > Great work! > > > I think that It is not necessary to add a new module for JTA > integration. There is openwebbean-ee module that you can add > TransactionService implementation with a name > DefaultTransactionService. If anyone wants to use other implementation, they > can do it via openwebbeans.properties file. > > Thanks > > > Gurkan > > ________________________________ > Kimden: Arne Limburg <[email protected]> > Kime: "[email protected]" > <[email protected]> Gönderildiği Tarih: 4 Eylül 2011 11:06 > Pazar > Konu: AW: İlt: AW: Transactional events and the TransactionService > > OK, I pick this up again :-) > > Yes, Mark, the main goal is to provide JTA support for scenarios that > are no full Java EE server. But such general solution could also be > used by Java EE server developers to integrate OWB. When I take a look > at the Geronimo implementation of the TransactionService, I must > admit, that a general solution would look very similar. > > I already have implemented such solution and if we all agree that this > should go into a separate module webbeans-jta, then I would commit it. > With that separate module we would avoid conflicts with existing > implementations of the TransactionService (like i.e. Geronimo). > > Cheers, > Arne > > -- > > Arne Limburg - Enterprise Architekt > open knowledge GmbH, Oldenburg > Bismarckstraße 13, 26122 Oldenburg > Mobil: +49 (0) 151 108 22 942 > Tel: +49 (0) 441 - 4082-0 > Fax: +49 (0) 441 - 4082-111 > [email protected] > http://www.openknowledge.de > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > -----Ursprüngliche Nachricht----- > Von: Mark Struberg [mailto:[email protected]] > Gesendet: Sonntag, 28. August 2011 11:27 > An: [email protected] > Betreff: Re: İlt: AW: Transactional events and the TransactionService > > To pick this up again: > > This discussion is about having JTA but without a fully blown EE > server. All agree on this? > > Currently the only impl for the TransactionService is the one for > OpenEJB. But we could easily provide one which is impl agnostic > (beside the typical problem with the JNDI namespaces - did I ever > mention that JNDI sucks? ;) > > So also a +1 for option 2 (configuring the JNDI names via > openwebbeans.properties). > > LieGrue, > strub > > --- On Tue, 8/23/11, Gurkan Erdogdu <[email protected]> wrote: > >> From: Gurkan Erdogdu <[email protected]> >> Subject: İlt: AW: Transactional events and the TransactionService >> To: "[email protected]" > <[email protected]> >> Date: Tuesday, August 23, 2011, 11:00 AM >> >> >> >> ----- İletilen Mesaj ----- >> Kimden: Gurkan Erdogdu <[email protected]> >> Kime: Arne Limburg <[email protected]> Gönderildiği > Tarih: >> 23 Ağustos 2011 14:00 Salı >> Konu: Yan: AW: Transactional events and the TransactionService >> >> >> >>>because of the missing implementation of the TransactionService, >> this problem will occur in EE-environments, >> >> >> Yes, currently only OpenEJB plugin supports it. If you want another, >> has to implement how Geronimo does. >> >> >> https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/openej >> b >> /geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/Geron >> i >> moTransactionService.java >> >> For common TransactionService implementation, my choice is number 2 >> >> Gurkan >> >> >> >> ________________________________ >> Kimden: Arne Limburg <[email protected]> >> Kime: "[email protected]" >> <[email protected]>; >> Gurkan Erdogdu <[email protected]> Gönderildiği Tarih: 23 >> Ağustos 2011 10:32 Salı >> Konu: AW: Transactional events and the TransactionService >> >> Hi Gurkan, >> >> aktually I think > OWB is violating Section 10.4.4 of the >> spec. In the environment I am talking about, a JTA transaction is >> active, but the events are fired directly as if it were not. The >> reason is simply, that OWB does not recognize the active >> transaction, because of the missing TransactionService. Also the >> environment I am talking about is non EE, because of the missing >> implementation of the TransactionService, this problem will occur in >> EE-environments, >> too. What I am saying is, that currently OWB will not use >> transactional events, even when running in JBoss or Glassfish (I'll >> confirm this...). >> >> I discussed another (less invasive) option to solve this off this >> list with Mark and Jens Schumann: >> Our problem is: How can OWB recognize that there is an active JTA >> transaction? >> 1. My solution (which is in alignment with the JTA >> > standard) would be to use the standardized location of the >> TransactionSynchronizationRegistry in JNDI. >> 2. The solution proposed by Mark and Jens is to write a general >> TransactionService that does a JNDI-lookup to get the >> TransactionManager. Since the JNDI-location of the >> TransactionManager is not standardized by the JTA spec, we would >> make this location configurable via openwebbeans.properties. With >> this solution the work to integrate a new application server would >> be just to specify the JNDI-location of the >> TransactionManager. >> >> Regards, >> Arne >> >> -----Ursprüngliche Nachricht----- >> Von: Gurkan Erdogdu [mailto:[email protected]] >> >> Gesendet: Dienstag, 23. August 2011 09:04 >> An: [email protected] >> Betreff: Yan: Transactional events and the TransactionService >> >> Hello Arne, >> >> I do not see any reason to implement a new TransactionService >> implementation for your non-JavaEE environment (if there is a chance >> to get Transaction and TM from your environment) and use it. >> >> Spec talks about JTA transactions. See Spec Section 10.4.4, >> Transactional observer methods >> >> Your idea is related to introduce a new spec requirement :) This is >> another story..... >> >> >> Gurkan >> >> >> >> ________________________________ >> Kimden: Arne Limburg >> <[email protected]> >> Kime: "[email protected]" >> <[email protected]> >> Gönderildiği Tarih: 22 Ağustos 2011 12:08 Pazartesi >> Konu: Transactional events and the TransactionService >> >> Hi, >> >> I am working in a non-java-ee-environment where I need transactional >> CDI events. >> The org.apache.webbeans.spi.TransactionService is needed to support >> transactional events in OWB. I recognized, that the only >> implementation of this service in the OWB code base is the >> OpenEJBTransactionService. >> Imho it is desirable to implement a more general approach that works >> out of the box in > ee-environments (without >> OpenEJB) and can be >> configured in non-ee-environments. >> Unfortunately this is not as easy as it sounds, since our >> TransactionService needs access to the javax.transaction.Transaction >> and the javax.transaction.TransactionManager and there currently is >> no standardized way to access this in Java EE (i.e. no standardized >> JNDI name). >> However there is a standardized way to access a >> javax.transaction.TransactionSynchronizationRegistry via JNDI, which >> is recommended by the JTA spec and would suffice our needs. >> Now I wonder how this could be integrated into OWB >> smoothly: >> Currently the TransactionalEventNotifier uses the >> TransactionService to obtain a javax.transaction.Transaction and do >> the synchronization with it. To achieve a more general approach here >> it should access a >> > javax.transaction.TransactionSynchronizationRegistry here >> instead. But where to get such registry from? >> >> 1. The TransactionalEventNotifer directly searches the >> TransactionSynchronizationRegistry via JNDI. Easiest solution that >> is at the same time the least flexible >> solution: If someone would like to provide the >> TransactionSynchronizationRegistry via another way, this simply >> would not be possible. So to me this seems to be a bad solution >> >> 2. Add getTransactionSynchronizationRegistry() to our >> TransactionService interface. Two drawbacks here: First this has to >> be done with a minor version update (no big problem, we could do >> this with OWB 1.2). Second problem: We are still not able to >> implement a generic approach since such generic TransactionService >> would also have to > implement >> getTransactionManager() and getTransaction() which cannot be >> accessed in a generic approach. >> >> 3. We add a complete new SPI, something like >> TransactionSynchronizationService, which specifies the method >> registerTransactionSynchronization and deprecate that method in the >> TransactionService. >> We then could implement an implementation for that service that >> looks up the TransactionSynchronizationRegistry from JNDI. Drawback: >> It feels somewhat strange to me to separate this concerns. >> >> 4. We add the TransactionSynchronizationService from 2. and >> specify it as a superinterface of the TransactionService. We then >> would not have to deprecate that method in the TransactionService and >> could add a generic implementation of the >> TransactionSynchronizationService that does not > implement the TransactionService. Drawback: We >> currently have to inheritance in the SPIs and would have to add some >> code to handle this. >> Any more ideas on this? >> >> Imho we should go with either 3. or 4. What do you think? >> >> Regards, >> Arne >> >> -- >> Arne Limburg - Enterprise Architekt >> open knowledge GmbH, Oldenburg >> Bismarckstraße 13, 26122 Oldenburg >> Mobil: +49 (0) 151 108 22 942 >> Tel: +49 (0) 441 - 4082-0 >> Fax: +49 (0) 441 - >> 4082-111 >> [email protected] >> http://www.openknowledge.de >> >> Registergericht: Amtsgericht Oldenburg, HRB 4670 >> Geschäftsführer: Lars Röwekamp, Jens Schumann >
