September 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1879) JMS provider transactional support cannot be enabled

by Jiri Pechanec (JIRA)

JMS provider transactional support cannot be enabled ---------------------------------------------------- Key: JBESB-1879 URL: https://jira.jboss.org/jira/browse/JBESB-1879 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.2.1 CP3 Reporter: Jiri Pechanec Assignee: Kevin Conner Fix For: 4.2.1 CP4 It was told that plain jms-provider now supports JTA transactions and according to code it could but there is no transacted attribute available for jms-provider-type in XML schema for jboss-esb.xml file. -- 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

14 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-1540) WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package

by Jiri Pechanec (JIRA)

WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package ------------------------------------------------------------------------------------------- Key: JBESB-1540 URL: http://jira.jboss.com/jira/browse/JBESB-1540 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.2.1 Reporter: Jiri Pechanec Assigned To: Kevin Conner Priority: Minor Attachments: server.log.gz There were multiple packages deployed/undeployed in the test. The deployment of Quickstart_webservice_mtom.esb is started on line 413471. This package starts coyote invoker with hashCode 17a4c54 at the line 413681. The undeploymetn of this package starts on line 414408. The CoyoteInvoker with the given hashCode is stopped at line 414457. The Quickstart_webservice_wsa.esb package deployment starts at line 414599. The CoyotInvoker with hashCode d93db8 is started at line 414806. Then the test message is sent via HTTP/SOAP and this request fails on line 515535 because it was served by the CoyoteInvoker with hashCode 17a4c54 so the one that belongs to previously undeployed package. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
12
0 / 0

[JBoss JIRA] Created: (JBESB-1710) Documentation of Standalone mode in Quickstarts is confusing

by Tom Cunningham (JIRA)

Documentation of Standalone mode in Quickstarts is confusing ------------------------------------------------------------ Key: JBESB-1710 URL: http://jira.jboss.com/jira/browse/JBESB-1710 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation, Examples Affects Versions: 4.2.1 CP2 Reporter: Tom Cunningham In the readme.txt of every QuickStart, we document how to run in standalone mode. Do we really want to do this? Standalone mode seems like an edge case that we support, and listing it in every QS readme.txt is confusing to first time users (see forum post reference). Maybe we should have a standalone guide that describes how to run QS's in standalone mode, and focus the QS readmes on the most common method of running the QS's (running in ESB server or JBossAS+ESB). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

6
7
0 / 0

[JBoss JIRA] Created: (JBESB-1699) Update Chapter 9 of the Programmers Guide ("Configuration")

by Tom Fennelly (JIRA)

Update Chapter 9 of the Programmers Guide ("Configuration") ----------------------------------------------------------- Key: JBESB-1699 URL: http://jira.jboss.com/jira/browse/JBESB-1699 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 CP2 Reporter: Tom Fennelly The Config Model diagram is out of date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-1909) JmsConnectionPool overflows sometimes with JBossMQ

by Pavel Kadlec (JIRA)

JmsConnectionPool overflows sometimes with JBossMQ -------------------------------------------------- Key: JBESB-1909 URL: https://jira.jboss.org/jira/browse/JBESB-1909 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.3 Environment: JBossAS-4.2.2.GA with JBossMQ Reporter: Pavel Kadlec The core reason is that JBossMQ's XAConnectionFactory.createSession always creates XASession (is always transacted and with SESSION_TRANSACTED acknowledgement mode), but JBossMessaging's XAConnectionFactory.createSession creates non-xa Session (transacted or non-transacted and with customized acknowledgement mode). The JmsConnectionPool is intended to be used with JBossMessaging behaviour only. The overflow occurs when caller thread associated with *NO* transaction sends esb message (by jms courier) using *XAConnectionFactory* to the esb service. In this case the connection pool uses XAConnectionFactory.createSession for creating the session. The pool has hashmaps which key is acknowledgement mode. JBossMQ's XAConnectionFactory.createSession always creates Session with SESSION_TRANSACTED acknowledgement mode. But the pool registers the session under customized acknowledgement mode into the maps (eg. AUTO_ACKNOWLEDGE). When session clean is called, the JmsConnectionPool tries to remove the session from the pool, but uses Session.getAcknowledgement to find out what type of session it is. This returns SESSION_TRANSACTED mode, but session was registered under eg. AUTO_ACKNOWLEDGE mode. The pool is not cleaned up correctly and overflows. -- 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

14 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-1965) Poor Exception Message "doesn't define a Message-Aware Listener"

by Burr Sutter (JIRA)

Poor Exception Message "doesn't define a Message-Aware Listener" ---------------------------------------------------------------- Key: JBESB-1965 URL: https://jira.jboss.org/jira/browse/JBESB-1965 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: Burr Sutter Priority: Minor This message should also indicate that an InVM listener can also be used by adding invmScope="GLOBAL" to the service declaration. 12:31:43,355 WARN [ServiceController] Problem starting service jboss.esb:deploy ment=Quickstart_helloworld_http.esb java.lang.RuntimeException: org.jboss.soa.esb.ConfigurationException: Service co nfiguration for Service 'HelloWorld:HelloWorld_HTTP' doesn't define a Message-Aw are Listener (i.e. is-gateway='false'). at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration .java:138) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployment.startService(J Boss4ESBDeployment.java:99) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS upport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB eanSupport.java:245) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch er.java:155) -- 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

14 years, 11 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-1687) Update to bpm_orchestration3 - replace signalling with callback

by Len DiMaggio (JIRA)

Update to bpm_orchestration3 - replace signalling with callback --------------------------------------------------------------- Key: JBESB-1687 URL: http://jira.jboss.com/jira/browse/JBESB-1687 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2.1 CP2 Reporter: Len DiMaggio Priority: Minor Project JIRA for SOA-520 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-1847) jBPM upload authentication is enforced for all quickstarts

by Kevin Conner (JIRA)

jBPM upload authentication is enforced for all quickstarts ---------------------------------------------------------- Key: JBESB-1847 URL: http://jira.jboss.com/jira/browse/JBESB-1847 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2.1 CP3 Reporter: Kevin Conner Fix For: 4.2.1 CP4 The upload credentials should only be enforced for the jBPM quickstarts and not enforced for all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBESB-1774) Messages are returned to client from the wrong service

by Mika Leino (JIRA)

Messages are returned to client from the wrong service ------------------------------------------------------ Key: JBESB-1774 URL: http://jira.jboss.com/jira/browse/JBESB-1774 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.2.1 CP1 Environment: Windows Server 2003 Reporter: Mika Leino Attachments: service_A_jboss-esb.xml, service_B_jboss-esb.xml We have a setup in which a client calls an ESB service (service A) with a webservice interface and this service then calls on another ESB service (service B). Both of the services have their action pipelines set to be "RequestResponse". For some reason the first attempt to handle the client's message always fails as the message is returned to the client from service B. As the message never returns to service A it assumes an unresponsive EPR and resends the message which on the second attempt returns to service A. The first attempt looks like this: client -> service A -> service B -> client And the second like this: (client ->) service A -> service B -> service A -> client Unfortunately the client interpreters the first response as the one it is waiting for and fails as service A has not made the necessary changes to the message. The second attempt produces a valid response but the client is no longer listening for it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

4
11
0 / 0

[JBoss JIRA] Created: (JBESB-1904) The stateful working memory cannot be disposed based on rules processing

by Jiri Pechanec (JIRA)

The stateful working memory cannot be disposed based on rules processing ------------------------------------------------------------------------ Key: JBESB-1904 URL: https://jira.jboss.org/jira/browse/JBESB-1904 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: Jiri Pechanec Fix For: 4.4 CP1 It should be very useful to control disposing of stateful working memory based on outcome of rules execution. Unfortunately this is not possible as the dispose message property is checked before rule execution. -- 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

14 years, 11 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2008