OK. I looked again this further. NotificationManager uses " TransactionService transactionService = webBeansContext.getService(TransactionService.class);" to get transaction service.
You can register your own service via 3 ways 1- Write an extra plugin module( -1 for me, not necessary to add overhead for JTA) 2- DefaultTransactionService implementation in owb-ee with adding openwebbeans.properties into the owb-ee/src/main/resources/META-INF/openwebbeans. If any plugin would like to implement another transaction service, then it has to increase "configuration.ordinal". 3- DefaultTransactionService implementation in owb-ee without adding openwebbeans.properties, then register it yourself via WebBeansContext.getInstance().registerService() in your application. My choice is (2 or 3). ----- Orijinal Mesaj ----- Kimden: Arne Limburg <[email protected]> Kime: "[email protected]" <[email protected]> Kopya: Gönderildiği Tarih: 5 Eylül 2011 11:11 Pazartesi Konu: AW: AW: AW: AW: Transactional events and the TransactionService That's why I proposed to use a separate module. This module then could use the plugin-mechanism, too. @Gurkan: I would prefer a solution where no OWB specific configuration is needed at the client side. 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 10:06 An: [email protected] Betreff: Re: AW: AW: AW: Transactional events and the TransactionService Oki, that's an argument :) Then, we should take a more closer look at how to implement it with using our property system. LieGrue, strub ----- Original Message ----- > From: Arne Limburg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Monday, September 5, 2011 9:59 AM > Subject: AW: AW: AW: Transactional events and the TransactionService > > 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/opene >>> j >>> b >>> >>> /geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/Gero >>> n >>> 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 >> >
