WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX Service Pipe procesing for binding ...

>
> Hello Kiran,
>
> thank you for your response.
>
> Attached you will find my test-project. You will need a datasource
> called jdbc/testDB and one table (TABLE1 with two columns from type
> int and string). See class de.afb.test.DB. If you have questions
> concerning the test-project, don’t hesitate to ask me …
>
> You are right, that I currently have a BPEL->JavaEE link. I will now
> try your suggestion…
>
> Best regards
>
> Michael
>
> *Von:* Kiran.Bhumana@... [mailto:Kiran.Bhumana@...]
> *Gesendet:* Dienstag, 8. Juli 2008 20:14
> *An:* dev@...
> *Betreff:* Re: WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist
> entering WS-TX Service Pipe procesing for binding ...
>
> Michael,
>
> By webservice-jar I think you mean the EJB project.
> I am guessing, that it could be because when you added the Webservice
> jar to the comp app, instead of the call going through Http-BC it
> directly (short circuits) goes to the JavaEE SE. HTTP-BC would be the
> one to translate java TX into a WS TX, and because of the short cut
> that step could be missing. What you can do is in your CASA editor you
> can explicitly link the BPEL->HTTP->JavaEE, currently you must have
> BPEL->JavaEE link.
> Is it possible for you to send your project? So that I can run it on
> my environment.
>
> HTH,
> Kiran.
> PS: Sorry for the late reply. I noticed this message only today.
>
> Merker Michael wrote:
>
> Hello,
>
> i have a question concerning transaction behavior, if a BPEL-Process
> calls a webservice.
>
> I have a contract-first webservice with following transaction-policy:
>
> <wsp:Policy wsu:Id="TRANSACTION_REQUIRED">
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsat:ATAlwaysCapability />
>
> <wsat:ATAssertion wsp:Optional="true" xpol:Optional="true" />
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> The namespaces are:
>
> xmlns:wsp="http://www.w3.org/ns/ws-policy"
> <http://www.w3.org/ns/ws-policy>
>
> xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat"
> <http://schemas.xmlsoap.org/ws/2004/10/wsat>
>
> xmlns:xpol="http://schemas.xmlsoap.org/ws/2002/12/policy"
> <http://schemas.xmlsoap.org/ws/2002/12/policy>
>
> And i have a Atomic BPEL-Process that calls this webservice.
>
> If i deploy the webservice and the BPEL-CA seperatly, the transaction
> from the BPEL-Process is correctly passed to the webservice.
>
> But when i add the webservice-jar as a JBI-Module inside the BPEL-CA,
> i get the following error-message every time the BPEL-Process calls
> the webservice:
>
> WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX
> Service Pipe procesing for binding
> '{http://afb.de/testWS}testWSBinding' and operation 'test'. JTA
> Transaction is J2EETransaction: txId=2 nonXAResource=null jtsTx=null
> localTxStatus=0
> syncs=[com.sun.jbi.engine.bpel.core.bpel.util.TxPropagationSynchronization@9d9af]
>
> and a new transaction for the webservice is started. If i remove the
> Policy from the wsdl, then the transaction is passed correctly.
>
> Does anybody have an idea, what goes wrong and why is the transaction
> handling different depending on if i deploy the webservice-jar as a
> JBI-Module or separately?
>
> Thanks
>
> Michael
>
> Michael Merker
>
> Senior Development
>
> afb Application Services AG
>
> Meglingerstrasse 20
>
> 81477 München Germany
>
> Phone +49 (89) 78 000-368
>
> Fax +49 (89) 78 000-511368
>
> E-Mail Merker.Michael@... <mailto:Lane.David@...>
>
> Internet www.afb.de <http://www.afb.de/>
>
> Vorstand: Christian Aechter, Gerolf Dienhold, Jan Ph. Wieners
>
> Vorsitzender des Aufsichtsrats: Ralph G. Werner
>
> Sitz der Gesellschaft: München - Registergericht München, HRB 129 294
>
> Allgemeine Information zur steigenden Zahl von Viren-E-Mails:
>
> Virenbehaftete E-Mails, die bei uns eingehen, werden von der
> afb-Firewall automatisch erkannt und ausselektiert. Bitte beachten
> Sie, dass keine Benachrichtigung an Absender und Empfänger über die
> Nicht-Zustellung dieser E-Mails erfolgt.
>
> General information regarding the growing number of virus emails:
>
> Virus-infected emails received by us are automatically detected by
> afb-Firewall and singled out. Please note that no messages are sent
> either to the sender or recipient regarding the failed delivery of
> such emails.
>
>
>
> --
> Kiran Bhumana
> Open ESB Community (http://open-esb.org)
> This email was Anti Virus checked by afb Security System.
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>  

> My guess would be that this seems like a bug/shortcoming the in the
> Java EE service engine and/or the Metro pipe. Presumably when the
> invocation happens in-memory via the Java EE service engine the thread
> already has the (original) transaction associated; but the Metro pipe
> expects to construct a new transaction that it ties to the WS-AT
> context - and complains when there already is a transaction associated
> with the thread.
>
> Ideally what should happen is that when there is a direct invocation
> via the Java EE SE it would just ignore the WS-AT instructions and
> take the original transaction context.
>
> Sherry/Venu could you follow up on this with the Metro and Java EE SE
> teams? Michael, is it possible for you to file a bug on this?
>
> Andi
>
> Merker Michael wrote:
>>
>> Hello Kiran,
>>
>> thank you for your response.
>>
>> Attached you will find my test-project. You will need a datasource
>> called jdbc/testDB and one table (TABLE1 with two columns from type
>> int and string). See class de.afb.test.DB. If you have questions
>> concerning the test-project, don’t hesitate to ask me …
>>
>> You are right, that I currently have a BPEL->JavaEE link. I will now
>> try your suggestion…
>>
>> Best regards
>>
>> Michael
>>
>> *Von:* Kiran.Bhumana@... [mailto:Kiran.Bhumana@...]
>> *Gesendet:* Dienstag, 8. Juli 2008 20:14
>> *An:* dev@...
>> *Betreff:* Re: WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist
>> entering WS-TX Service Pipe procesing for binding ...
>>
>> Michael,
>>
>> By webservice-jar I think you mean the EJB project.
>> I am guessing, that it could be because when you added the Webservice
>> jar to the comp app, instead of the call going through Http-BC it
>> directly (short circuits) goes to the JavaEE SE. HTTP-BC would be the
>> one to translate java TX into a WS TX, and because of the short cut
>> that step could be missing. What you can do is in your CASA editor
>> you can explicitly link the BPEL->HTTP->JavaEE, currently you must
>> have BPEL->JavaEE link.
>> Is it possible for you to send your project? So that I can run it on
>> my environment.
>>
>> HTH,
>> Kiran.
>> PS: Sorry for the late reply. I noticed this message only today.
>>
>> Merker Michael wrote:
>>
>> Hello,
>>
>> i have a question concerning transaction behavior, if a BPEL-Process
>> calls a webservice.
>>
>> I have a contract-first webservice with following transaction-policy:
>>
>> <wsp:Policy wsu:Id="TRANSACTION_REQUIRED">
>>
>> <wsp:ExactlyOne>
>>
>> <wsp:All>
>>
>> <wsat:ATAlwaysCapability />
>>
>> <wsat:ATAssertion wsp:Optional="true" xpol:Optional="true" />
>>
>> </wsp:All>
>>
>> </wsp:ExactlyOne>
>>
>> </wsp:Policy>
>>
>> The namespaces are:
>>
>> xmlns:wsp="http://www.w3.org/ns/ws-policy"
>> <http://www.w3.org/ns/ws-policy>
>>
>> xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat"
>> <http://schemas.xmlsoap.org/ws/2004/10/wsat>
>>
>> xmlns:xpol="http://schemas.xmlsoap.org/ws/2002/12/policy"
>> <http://schemas.xmlsoap.org/ws/2002/12/policy>
>>
>> And i have a Atomic BPEL-Process that calls this webservice.
>>
>> If i deploy the webservice and the BPEL-CA seperatly, the transaction
>> from the BPEL-Process is correctly passed to the webservice.
>>
>> But when i add the webservice-jar as a JBI-Module inside the BPEL-CA,
>> i get the following error-message every time the BPEL-Process calls
>> the webservice:
>>
>> WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX
>> Service Pipe procesing for binding
>> '{http://afb.de/testWS}testWSBinding' and operation 'test'. JTA
>> Transaction is J2EETransaction: txId=2 nonXAResource=null jtsTx=null
>> localTxStatus=0
>> syncs=[com.sun.jbi.engine.bpel.core.bpel.util.TxPropagationSynchronization@9d9af]
>>
>>
>> and a new transaction for the webservice is started. If i remove the
>> Policy from the wsdl, then the transaction is passed correctly.
>>
>> Does anybody have an idea, what goes wrong and why is the transaction
>> handling different depending on if i deploy the webservice-jar as a
>> JBI-Module or separately?
>>
>> Thanks
>>
>> Michael
>>
>> Michael Merker
>>
>> Senior Development
>>
>> afb Application Services AG
>>
>> Meglingerstrasse 20
>>
>> 81477 München Germany
>>
>> Phone +49 (89) 78 000-368
>>
>> Fax +49 (89) 78 000-511368
>>
>> E-Mail Merker.Michael@... <mailto:Lane.David@...>
>>
>> Internet www.afb.de <http://www.afb.de/>
>>
>> Vorstand: Christian Aechter, Gerolf Dienhold, Jan Ph. Wieners
>>
>> Vorsitzender des Aufsichtsrats: Ralph G. Werner
>>
>> Sitz der Gesellschaft: München - Registergericht München, HRB 129 294
>>
>> Allgemeine Information zur steigenden Zahl von Viren-E-Mails:
>>
>> Virenbehaftete E-Mails, die bei uns eingehen, werden von der
>> afb-Firewall automatisch erkannt und ausselektiert. Bitte beachten
>> Sie, dass keine Benachrichtigung an Absender und Empfänger über die
>> Nicht-Zustellung dieser E-Mails erfolgt.
>>
>> General information regarding the growing number of virus emails:
>>
>> Virus-infected emails received by us are automatically detected by
>> afb-Firewall and singled out. Please note that no messages are sent
>> either to the sender or recipient regarding the failed delivery of
>> such emails.
>>
>>
>>
>> --
>> Kiran Bhumana
>> Open ESB Community (http://open-esb.org)
>> This email was Anti Virus checked by afb Security System.
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

> My guess would be that this seems like a bug/shortcoming the in the
> Java EE service engine and/or the Metro pipe. Presumably when the
> invocation happens in-memory via the Java EE service engine the thread
> already has the (original) transaction associated; but the Metro pipe
> expects to construct a new transaction that it ties to the WS-AT
> context - and complains when there already is a transaction associated
> with the thread.
>
> Ideally what should happen is that when there is a direct invocation
> via the Java EE SE it would just ignore the WS-AT instructions and
> take the original transaction context.
>
> Sherry/Venu could you follow up on this with the Metro and Java EE SE
> teams? Michael, is it possible for you to file a bug on this?
>
> Andi
>
> Merker Michael wrote:
>>
>> Hello Kiran,
>>
>> thank you for your response.
>>
>> Attached you will find my test-project. You will need a datasource
>> called jdbc/testDB and one table (TABLE1 with two columns from type
>> int and string). See class de.afb.test.DB. If you have questions
>> concerning the test-project, don’t hesitate to ask me …
>>
>> You are right, that I currently have a BPEL->JavaEE link. I will now
>> try your suggestion…
>>
>> Best regards
>>
>> Michael
>>
>> *Von:* Kiran.Bhumana@... [mailto:Kiran.Bhumana@...]
>> *Gesendet:* Dienstag, 8. Juli 2008 20:14
>> *An:* dev@...
>> *Betreff:* Re: WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist
>> entering WS-TX Service Pipe procesing for binding ...
>>
>> Michael,
>>
>> By webservice-jar I think you mean the EJB project.
>> I am guessing, that it could be because when you added the Webservice
>> jar to the comp app, instead of the call going through Http-BC it
>> directly (short circuits) goes to the JavaEE SE. HTTP-BC would be the
>> one to translate java TX into a WS TX, and because of the short cut
>> that step could be missing. What you can do is in your CASA editor
>> you can explicitly link the BPEL->HTTP->JavaEE, currently you must
>> have BPEL->JavaEE link.
>> Is it possible for you to send your project? So that I can run it on
>> my environment.
>>
>> HTH,
>> Kiran.
>> PS: Sorry for the late reply. I noticed this message only today.
>>
>> Merker Michael wrote:
>>
>> Hello,
>>
>> i have a question concerning transaction behavior, if a BPEL-Process
>> calls a webservice.
>>
>> I have a contract-first webservice with following transaction-policy:
>>
>> <wsp:Policy wsu:Id="TRANSACTION_REQUIRED">
>>
>> <wsp:ExactlyOne>
>>
>> <wsp:All>
>>
>> <wsat:ATAlwaysCapability />
>>
>> <wsat:ATAssertion wsp:Optional="true" xpol:Optional="true" />
>>
>> </wsp:All>
>>
>> </wsp:ExactlyOne>
>>
>> </wsp:Policy>
>>
>> The namespaces are:
>>
>> xmlns:wsp="http://www.w3.org/ns/ws-policy"
>> <http://www.w3.org/ns/ws-policy>
>>
>> xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat"
>> <http://schemas.xmlsoap.org/ws/2004/10/wsat>
>>
>> xmlns:xpol="http://schemas.xmlsoap.org/ws/2002/12/policy"
>> <http://schemas.xmlsoap.org/ws/2002/12/policy>
>>
>> And i have a Atomic BPEL-Process that calls this webservice.
>>
>> If i deploy the webservice and the BPEL-CA seperatly, the transaction
>> from the BPEL-Process is correctly passed to the webservice.
>>
>> But when i add the webservice-jar as a JBI-Module inside the BPEL-CA,
>> i get the following error-message every time the BPEL-Process calls
>> the webservice:
>>
>> WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX
>> Service Pipe procesing for binding
>> '{http://afb.de/testWS}testWSBinding' and operation 'test'. JTA
>> Transaction is J2EETransaction: txId=2 nonXAResource=null jtsTx=null
>> localTxStatus=0
>> syncs=[com.sun.jbi.engine.bpel.core.bpel.util.TxPropagationSynchronization@9d9af]
>>
>>
>> and a new transaction for the webservice is started. If i remove the
>> Policy from the wsdl, then the transaction is passed correctly.
>>
>> Does anybody have an idea, what goes wrong and why is the transaction
>> handling different depending on if i deploy the webservice-jar as a
>> JBI-Module or separately?
>>
>> Thanks
>>
>> Michael
>>
>> Michael Merker
>>
>> Senior Development
>>
>> afb Application Services AG
>>
>> Meglingerstrasse 20
>>
>> 81477 München Germany
>>
>> Phone +49 (89) 78 000-368
>>
>> Fax +49 (89) 78 000-511368
>>
>> E-Mail Merker.Michael@... <mailto:Lane.David@...>
>>
>> Internet www.afb.de <http://www.afb.de/>
>>
>> Vorstand: Christian Aechter, Gerolf Dienhold, Jan Ph. Wieners
>>
>> Vorsitzender des Aufsichtsrats: Ralph G. Werner
>>
>> Sitz der Gesellschaft: München - Registergericht München, HRB 129 294
>>
>> Allgemeine Information zur steigenden Zahl von Viren-E-Mails:
>>
>> Virenbehaftete E-Mails, die bei uns eingehen, werden von der
>> afb-Firewall automatisch erkannt und ausselektiert. Bitte beachten
>> Sie, dass keine Benachrichtigung an Absender und Empfänger über die
>> Nicht-Zustellung dieser E-Mails erfolgt.
>>
>> General information regarding the growing number of virus emails:
>>
>> Virus-infected emails received by us are automatically detected by
>> afb-Firewall and singled out. Please note that no messages are sent
>> either to the sender or recipient regarding the failed delivery of
>> such emails.
>>
>>
>>
>> --
>> Kiran Bhumana
>> Open ESB Community (http://open-esb.org)
>> This email was Anti Virus checked by afb Security System.
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

> Hi Andi,
> Invoking WS via "sun-javaee-engine" is tested with no "ws-policy"
> elements.  We need to test with other policy elements, prior to that
> we need to define the behavior.
>
> In this scenario user configured for "TRANSACTION_REQUIRED",
> sun-javaee-engine ignore the policy definition, what should be the
> case for TRANSACTION_NEW? and other options?
>
> "sun-javaee-engine" is not propagating security, Pushpa suppose to
> file a bug for this. We may need to how policy definitions influence
> this behavior.
>
> May be with MTOM and other ...
>
> Regards
> Murali
>
> Andreas Egloff wrote:
>> My guess would be that this seems like a bug/shortcoming the in the
>> Java EE service engine and/or the Metro pipe. Presumably when the
>> invocation happens in-memory via the Java EE service engine the
>> thread already has the (original) transaction associated; but the
>> Metro pipe expects to construct a new transaction that it ties to the
>> WS-AT context - and complains when there already is a transaction
>> associated with the thread.
>>
>> Ideally what should happen is that when there is a direct invocation
>> via the Java EE SE it would just ignore the WS-AT instructions and
>> take the original transaction context.
>>
>> Sherry/Venu could you follow up on this with the Metro and Java EE SE
>> teams? Michael, is it possible for you to file a bug on this?
>>
>> Andi
>>
>> Merker Michael wrote:
>>>
>>> Hello Kiran,
>>>
>>> thank you for your response.
>>>
>>> Attached you will find my test-project. You will need a datasource
>>> called jdbc/testDB and one table (TABLE1 with two columns from type
>>> int and string). See class de.afb.test.DB. If you have questions
>>> concerning the test-project, don’t hesitate to ask me …
>>>
>>> You are right, that I currently have a BPEL->JavaEE link. I will now
>>> try your suggestion…
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>> *Von:* Kiran.Bhumana@... [mailto:Kiran.Bhumana@...]
>>> *Gesendet:* Dienstag, 8. Juli 2008 20:14
>>> *An:* dev@...
>>> *Betreff:* Re: WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist
>>> entering WS-TX Service Pipe procesing for binding ...
>>>
>>> Michael,
>>>
>>> By webservice-jar I think you mean the EJB project.
>>> I am guessing, that it could be because when you added the
>>> Webservice jar to the comp app, instead of the call going through
>>> Http-BC it directly (short circuits) goes to the JavaEE SE. HTTP-BC
>>> would be the one to translate java TX into a WS TX, and because of
>>> the short cut that step could be missing. What you can do is in your
>>> CASA editor you can explicitly link the BPEL->HTTP->JavaEE,
>>> currently you must have BPEL->JavaEE link.
>>> Is it possible for you to send your project? So that I can run it on
>>> my environment.
>>>
>>> HTH,
>>> Kiran.
>>> PS: Sorry for the late reply. I noticed this message only today.
>>>
>>> Merker Michael wrote:
>>>
>>> Hello,
>>>
>>> i have a question concerning transaction behavior, if a BPEL-Process
>>> calls a webservice.
>>>
>>> I have a contract-first webservice with following transaction-policy:
>>>
>>> <wsp:Policy wsu:Id="TRANSACTION_REQUIRED">
>>>
>>> <wsp:ExactlyOne>
>>>
>>> <wsp:All>
>>>
>>> <wsat:ATAlwaysCapability />
>>>
>>> <wsat:ATAssertion wsp:Optional="true" xpol:Optional="true" />
>>>
>>> </wsp:All>
>>>
>>> </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> The namespaces are:
>>>
>>> xmlns:wsp="http://www.w3.org/ns/ws-policy"
>>> <http://www.w3.org/ns/ws-policy>
>>>
>>> xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat"
>>> <http://schemas.xmlsoap.org/ws/2004/10/wsat>
>>>
>>> xmlns:xpol="http://schemas.xmlsoap.org/ws/2002/12/policy"
>>> <http://schemas.xmlsoap.org/ws/2002/12/policy>
>>>
>>> And i have a Atomic BPEL-Process that calls this webservice.
>>>
>>> If i deploy the webservice and the BPEL-CA seperatly, the
>>> transaction from the BPEL-Process is correctly passed to the
>>> webservice.
>>>
>>> But when i add the webservice-jar as a JBI-Module inside the
>>> BPEL-CA, i get the following error-message every time the
>>> BPEL-Process calls the webservice:
>>>
>>> WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX
>>> Service Pipe procesing for binding
>>> '{http://afb.de/testWS}testWSBinding' and operation 'test'. JTA
>>> Transaction is J2EETransaction: txId=2 nonXAResource=null jtsTx=null
>>> localTxStatus=0
>>> syncs=[com.sun.jbi.engine.bpel.core.bpel.util.TxPropagationSynchronization@9d9af]
>>>
>>>
>>> and a new transaction for the webservice is started. If i remove the
>>> Policy from the wsdl, then the transaction is passed correctly.
>>>
>>> Does anybody have an idea, what goes wrong and why is the
>>> transaction handling different depending on if i deploy the
>>> webservice-jar as a JBI-Module or separately?
>>>
>>> Thanks
>>>
>>> Michael
>>>
>>> Michael Merker
>>>
>>> Senior Development
>>>
>>> afb Application Services AG
>>>
>>> Meglingerstrasse 20
>>>
>>> 81477 München Germany
>>>
>>> Phone +49 (89) 78 000-368
>>>
>>> Fax +49 (89) 78 000-511368
>>>
>>> E-Mail Merker.Michael@... <mailto:Lane.David@...>
>>>
>>> Internet www.afb.de <http://www.afb.de/>
>>>
>>> Vorstand: Christian Aechter, Gerolf Dienhold, Jan Ph. Wieners
>>>
>>> Vorsitzender des Aufsichtsrats: Ralph G. Werner
>>>
>>> Sitz der Gesellschaft: München - Registergericht München, HRB 129 294
>>>
>>> Allgemeine Information zur steigenden Zahl von Viren-E-Mails:
>>>
>>> Virenbehaftete E-Mails, die bei uns eingehen, werden von der
>>> afb-Firewall automatisch erkannt und ausselektiert. Bitte beachten
>>> Sie, dass keine Benachrichtigung an Absender und Empfänger über die
>>> Nicht-Zustellung dieser E-Mails erfolgt.
>>>
>>> General information regarding the growing number of virus emails:
>>>
>>> Virus-infected emails received by us are automatically detected by
>>> afb-Firewall and singled out. Please note that no messages are sent
>>> either to the sender or recipient regarding the failed delivery of
>>> such emails.
>>>
>>>
>>>
>>> --
>>> Kiran Bhumana
>>> Open ESB Community (http://open-esb.org)
>>> This email was Anti Virus checked by afb Security System.
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>  
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

> I don't think we should take the WS-* policies into account when going
> directly via the Java EE SE; these really should be defining what
> happens when going "over the wire".
>
> Today, the default within the ESB is to propagate the transaction. As
> discussed before I do believe it is desirable to visualize these
> transaction "scopes" and to make them configurable. This declaration
> would then be used to determine if a transaction is propagated or not,
> whether a new one is started or not.
>
> Andi
>
> Murali Pottlapelli wrote:
>> Hi Andi,
>> Invoking WS via "sun-javaee-engine" is tested with no "ws-policy"
>> elements.  We need to test with other policy elements, prior to that
>> we need to define the behavior.
>>
>> In this scenario user configured for "TRANSACTION_REQUIRED",
>> sun-javaee-engine ignore the policy definition, what should be the
>> case for TRANSACTION_NEW? and other options?
>>
>> "sun-javaee-engine" is not propagating security, Pushpa suppose to
>> file a bug for this. We may need to how policy definitions influence
>> this behavior.
>>
>> May be with MTOM and other ...
>>
>> Regards
>> Murali
>>
>> Andreas Egloff wrote:
>>> My guess would be that this seems like a bug/shortcoming the in the
>>> Java EE service engine and/or the Metro pipe. Presumably when the
>>> invocation happens in-memory via the Java EE service engine the
>>> thread already has the (original) transaction associated; but the
>>> Metro pipe expects to construct a new transaction that it ties to
>>> the WS-AT context - and complains when there already is a
>>> transaction associated with the thread.
>>>
>>> Ideally what should happen is that when there is a direct invocation
>>> via the Java EE SE it would just ignore the WS-AT instructions and
>>> take the original transaction context.
>>>
>>> Sherry/Venu could you follow up on this with the Metro and Java EE
>>> SE teams? Michael, is it possible for you to file a bug on this?
>>>
>>> Andi
>>>
>>> Merker Michael wrote:
>>>>
>>>> Hello Kiran,
>>>>
>>>> thank you for your response.
>>>>
>>>> Attached you will find my test-project. You will need a datasource
>>>> called jdbc/testDB and one table (TABLE1 with two columns from type
>>>> int and string). See class de.afb.test.DB. If you have questions
>>>> concerning the test-project, don’t hesitate to ask me …
>>>>
>>>> You are right, that I currently have a BPEL->JavaEE link. I will
>>>> now try your suggestion…
>>>>
>>>> Best regards
>>>>
>>>> Michael
>>>>
>>>> *Von:* Kiran.Bhumana@... [mailto:Kiran.Bhumana@...]
>>>> *Gesendet:* Dienstag, 8. Juli 2008 20:14
>>>> *An:* dev@...
>>>> *Betreff:* Re: WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist
>>>> entering WS-TX Service Pipe procesing for binding ...
&g