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

> 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@...
>