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/openejb
> /geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/Geroni
> 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

Reply via email to