August 2009 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2434) mep="OneWay" on a published webservice results in a zero-length wsdl returned by <web service URL>?wsdl

by Len DiMaggio (JIRA)

mep="OneWay" on a published webservice results in a zero-length wsdl returned by <web service URL>?wsdl -------------------------------------------------------------------------------------------------------- Key: JBESB-2434 URL: https://jira.jboss.org/jira/browse/JBESB-2434 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.4 CP2 Reporter: Len DiMaggio Project issue for SOA-P platform issue SOA-1186 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-2484) JBM HeuristicMixedException may destabilise the resource used during transactional contexts

by Kevin Conner (JIRA)

JBM HeuristicMixedException may destabilise the resource used during transactional contexts ------------------------------------------------------------------------------------------- Key: JBESB-2484 URL: https://jira.jboss.org/jira/browse/JBESB-2484 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.5 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.6 JBoss Messaging sometimes causes a HeuristicMixedException to be raised by the transaction manager during commit. Once this happens the associated session would appear to be destabilised in that subsequent use does not appear possible The log files contain the following output. On the client side 2009-03-03 07:17:13,137 118839811 ERROR [org.hibernate.transaction.JTATransaction] (JbpmJobExector:<ip addr>:12:) JTA commit failed javax.transaction.HeuristicMixedException at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1414) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87) at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140) at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146) at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:295) at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:253 This exception is sometimes, although not always, paired up with the following exception on the server side. 2009-03-03 07:29:32,752 119400749 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkerThread#7[<ip addr>:35552]:) ConnectionEndpoint[2gw-biv0otrf-1-png68srf-w3rpob-v2p1hs4] sendTransaction [4bz-4vj97urf-1-png68srf-w3rpob-v2p1hs4] javax.jms.IllegalStateException: Cannot find session with id i2y-gk8bttrf-1-png68srf-w3rpob-v2p1hs4 at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.java:835) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:497) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195) at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source) The exceptions are always generated with the same session id which would suggest that there is an underlying issue in the JBoss Messaging codebase. We need to handle this until the issue is resolved within JBM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (JBESB-2779) InVM ReplyTo cleanup code invalid in ServiceInvoker

by Kevin Conner (JIRA)

InVM ReplyTo cleanup code invalid in ServiceInvoker --------------------------------------------------- Key: JBESB-2779 URL: https://jira.jboss.org/jira/browse/JBESB-2779 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.4 CP3 Reporter: Martin Vecera Assignee: Kevin Conner Fix For: 4.4 CP3 I have two services in a single ESB archive. Both have set invmScope="GLOBAL", the first service is accessible via EBWS and routes the message to the second service. The client awaits a response, which should be sent by the second service to a thread that executes EBWS servlet. Instead of this and exception is thrown. 2009-07-22 08:30:43,550 ERROR [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] Failed to send reply to address InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/ >, <wsa:ReferenceProperties jbossesb:passByValue : false/> > ] for message header: [ To: InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/>, <wsa:ReferenceProperties jbossesb :passByValue : false/> > ] From: InVMEpr [ PortReference < <wsa:Address invm://526f757465725465737424242424242424242424242445425753526f757465/false?false#10000/>, <wsa:ReferencePropert ies jbossesb:passByValue : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/invm/> > ] RelatesTo: b013fa7a-18ac-40ef-bac5-7ad3ef2c6c5b ] org.jboss.soa.esb.couriers.CourierException: No deliverAsync courier at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:170) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.messageTo(ActionProcessingPipeline.java:835) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.replyTo(ActionProcessingPipeline.java:757) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:687) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) When an JMS queue is configured in the first service, everything works like a charm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-2777) WS-I: SOAPAction header does not contain the correct string value

by Boris Belovic (JIRA)

WS-I: SOAPAction header does not contain the correct string value ----------------------------------------------------------------- Key: JBESB-2777 URL: https://jira.jboss.org/jira/browse/JBESB-2777 Project: JBoss ESB Issue Type: Bug Components: Web Services Affects Versions: 4.4 Reporter: Boris Belovic We were performing webservice interoperability tests using WS-I test tools. There is a non-empty header SOAPAction in HTTP request message. This header contains "modifyQName" string as a value. According to the Basic Profile, there must be a non-empty soapAction attribute in binding element and this soapAction attribute must contain the same value as SOAPAction header in HTTP request. We find out that is not happening. There is SOAPAction header in HTTP request, but the corresponding soapAction attribute is empty. This is a result from WS-I test tool we use for testing. This output shows non-empty SOAPAction header and an empty soapAction attribute: HTTP headers: POST /WS-I/HelloWorldWS HTTP/1.1 Content-Type: text/xml;charset=UTF-8 SOAPAction: "modifyQName" User-Agent: Jakarta Commons-HttpClient/3.0.1 Host: localhost:65432 Content-Length: 299 soapAction: Element Location: lineNumber=154 And here are two WSDL documents: <definitions name='HelloWorldWSService' targetNamespace='http://ws_i.quickstart.samples.esb.soa.jboss.org/' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:ns1='http://wsi/helloworld' xmlns:ns2='http://wsi/helloworld/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://ws_i.quickstart.samples.esb.soa.jboss.org/' xmlns:xsd='http://www.w3.org/2001/XMLSchema'> <import location='http://localhost:8080/WS-I/imported.jsp' namespace='http://wsi/helloworld'></import> <service name='HelloWorldWSService'> <port binding='ns1:HelloWorldBinding' name='HelloWorldWSPort'> <soap:address location='http://localhost:8080/WS-I/HelloWorldWS'/> </port> </service> </definitions In this WSDL document, down there is operation element with empty soapAction attribute. This attribute must contain the same value as SOAPAction header in a request. <definitions name='HelloWorldWSService' targetNamespace='http://wsi/helloworld' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:ns1='http://wsi/helloworld' xmlns:ns2='http://wsi/helloworld/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://ws_i.quickstart.samples.esb.soa.jboss.org/' xmlns:xsd='http://www.w3.org/2001/XMLSchema'> <types> <xs:schema targetNamespace='http://wsi/helloworld' version='1.0' xmlns:ns1='http://wsi/helloworld/' xmlns:xs='http://www.w3.org/2001/XMLSchema'> <xs:import namespace='http://wsi/helloworld/'/> <xs:element name='modifyQName' nillable='true' type='ns1:modifyQName'/> <xs:element name='modifyQNameResponse' nillable='true' type='ns1:modifyQNameResponse'/> </xs:schema> <xs:schema targetNamespace='http://wsi/helloworld/' version='1.0' xmlns:xs='http://www.w3.org/2001/XMLSchema'> <xs:complexType name='modifyQName'> <xs:sequence> <xs:element minOccurs='0' name='value' type='xs:QName'/> </xs:sequence> </xs:complexType> <xs:complexType name='modifyQNameResponse'> <xs:sequence> <xs:element minOccurs='0' name='return' type='xs:QName'/> </xs:sequence> </xs:complexType> </xs:schema> </types> <message name='HelloWorld_modifyQName'> <part element='ns1:modifyQName' name='modifyQName'></part> </message> <message name='HelloWorld_modifyQNameResponse'> <part element='ns1:modifyQNameResponse' name='modifyQNameResponse'></part> </message> <portType name='HelloWorld'> <operation name='modifyQName' parameterOrder='modifyQName'> <input message='ns1:HelloWorld_modifyQName'></input> <output message='ns1:HelloWorld_modifyQNameResponse'></output> </operation> </portType> <binding name='HelloWorldBinding' type='ns1:HelloWorld'> <soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/> <operation name='modifyQName'> <soap:operation soapAction=''/> <input> <soap:body use='literal'/> </input> <output> <soap:body use='literal'/> </output> </operation> </binding> </definitions> Here are two SOAP message, which are parts of the communication: Request: <?xml version="1.0" encoding="UTF-8" ?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:hel="http://wsi/helloworld"> <soapenv:Header/> <soapenv:Body> <hel:modifyQName>  <value>qname_value</value> </hel:modifyQName> </soapenv:Body> </soapenv:Envelope> Response: <?xml version="1.0" encoding="UTF-8" ?><env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><ns1:modifyQNameResponse xmlns:ns1="http://wsi/helloworld"><return>qname_value_modified</return></ns1:modifyQNameResponse></env:Body></env:Envelope> Here is a link to Test Assertion Document with specified requirement: http://www.ws-i.org/Testing/Tools/2005/01/SSBP10_BP11_TAD_1-0.htm#BP1116 If there are any comments or request for any details please ask us. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-2627) InVM XAResource is not serializable and causes issues in recovery

by Kevin Conner (JIRA)

InVM XAResource is not serializable and causes issues in recovery ----------------------------------------------------------------- Key: JBESB-2627 URL: https://jira.jboss.org/jira/browse/JBESB-2627 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.5 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.6 This causes the following messages to be raised on recovery. Could not find new XAResource to use for recovering non-serializable XAResource -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-2649) Create a transport for HP for co-located registry

by Tom Cunningham (JIRA)

Create a transport for HP for co-located registry ------------------------------------------------- Key: JBESB-2649 URL: https://jira.jboss.org/jira/browse/JBESB-2649 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.6 Create a transport for HP for co-located registry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-2771) JmsCourier should be allowed to overwrite outgoing JMS Message properties.

by Daniel Bevenius (JIRA)

JmsCourier should be allowed to overwrite outgoing JMS Message properties. -------------------------------------------------------------------------- Key: JBESB-2771 URL: https://jira.jboss.org/jira/browse/JBESB-2771 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.6 Reporter: Daniel Bevenius Assignee: Daniel Bevenius Fix For: 4.7 When a JmsCourier is created and is specified to be a sender (isReciever=false), the passed in JMSEPR's message selector is stored in a field (_messageProperties which is a List of KeyValuePairs). When this JmsCourier is going to deliver a JMS Message it will iterate through the properties and set them on the outgoing JMS Message. The problem here is that the current implementation will first check to see if the JMS Message already has a property with the same key set on it, and if it has, will not overwrite the value. This is a problem because before this is done the JMSPropertiesStrategy will have been run and might for example have set the 'jbossESBresponseUUID' causing and old and invalid message selector to be passed through. This can be fixed by letting the JmsCourier have the last say and overwrite message properties. Or an explicit check could be add for 'jbossESBresponseUUID'. This issue was reported by Toshiya Kobayashi who also provided some nice examples that reproduce this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-2770) Support HP registry

by Kevin Conner (JIRA)

Support HP registry ------------------- Key: JBESB-2770 URL: https://jira.jboss.org/jira/browse/JBESB-2770 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.4 CP2 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.4 CP3 Tom Cunningham has already made most of the changes and committed them to the 4.4CP branch, revision is 28823. The build has been failing and I have been looking into it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-2758) ReplyTo header is invalid after static router with InVM

by Martin Vecera (JIRA)

ReplyTo header is invalid after static router with InVM ------------------------------------------------------- Key: JBESB-2758 URL: https://jira.jboss.org/jira/browse/JBESB-2758 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.4 CP3 Reporter: Martin Vecera I have two services in a single ESB archive. Both have set invmScope="GLOBAL", the first service is accessible via EBWS and routes the message to the second service. The client awaits a response, which should be sent by the second service to a thread that executes EBWS servlet. Instead of this and exception is thrown. 2009-07-22 08:30:43,550 ERROR [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] Failed to send reply to address InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/ >, <wsa:ReferenceProperties jbossesb:passByValue : false/> > ] for message header: [ To: InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/>, <wsa:ReferenceProperties jbossesb :passByValue : false/> > ] From: InVMEpr [ PortReference < <wsa:Address invm://526f757465725465737424242424242424242424242445425753526f757465/false?false#10000/>, <wsa:ReferencePropert ies jbossesb:passByValue : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/invm/> > ] RelatesTo: b013fa7a-18ac-40ef-bac5-7ad3ef2c6c5b ] org.jboss.soa.esb.couriers.CourierException: No deliverAsync courier at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:170) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.messageTo(ActionProcessingPipeline.java:835) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.replyTo(ActionProcessingPipeline.java:757) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:687) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) When an JMS queue is configured in the first service, everything works like a charm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
8
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues August 2009