January 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1438) JMS Courrier does not support transacted mode

by Jiri Pechanec (JIRA)

JMS Courrier does not support transacted mode --------------------------------------------- Key: JBESB-1438 URL: http://jira.jboss.com/jira/browse/JBESB-1438 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow, Rosetta Affects Versions: 4.2.1 Reporter: Jiri Pechanec Assigned To: Mark Little Priority: Blocker Fix For: 4.2.1 CP1 JMS Courrier (deliver side) operates only with non-transacted queue sessions. This prevents jBPM integration to work correctly. The problem can be sketched this way 1) The message is received via JMS/JCA listener, transaction is started 2) jBPM process is invoked 3) jBPM process sends message (calls service) in non-transacted mode Three situations can happen 1) Exception is thrown later, it means that global transaction is rolled back but another service was already invoked - BUG 2) jBPM process goes to the wait state and waits for response from ESB, global transaction is committed, called service sends back signal to continue process - OK 3) jBPM process goes to the wait state and waits for response from ESB, called service sends back signal to continue process - but the global transaction was not committed yet - BUG This is key feature to have ESB/jBPM integration working safely. -- 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

15 years, 5 months

5
31
0 / 0

[JBoss JIRA] Created: (JBESB-1164) Crash creates multiple EPRs for same service in JUDDI

by Tom Cunningham (JIRA)

Crash creates multiple EPRs for same service in JUDDI ----------------------------------------------------- Key: JBESB-1164 URL: http://jira.jboss.com/jira/browse/JBESB-1164 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.2.1 IR1 Reporter: Tom Cunningham Assigned To: Mark Little If the AS or ESB server crashes or does not cleanly shut down, JUDDI will duplicate EPR records in its database table. For the monitoring/management console, this is a real problem because it depends on the fact that there will be only one EPR for its services per ESB server. Post-crash, every time the console tries to collect data, it is getting back results from multiple EPRs on the same machine, which is causing ConstraintViolations when we try to store results. This is causing JBESB-1139. JUDDI should probably clean up EPR records post-crash. -- 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

15 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (JBESB-668) Integrate with JON for monitoring and management

by Tom Cunningham (JIRA)

Integrate with JON for monitoring and management ------------------------------------------------ Key: JBESB-668 URL: http://jira.jboss.com/jira/browse/JBESB-668 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 3 Reporter: Tom Cunningham Assigned To: Mark Little Fix For: 4.2 I'm splitting the "JON-integration" part of JBESB-544 into its own bug, because this part will go out past MR3. -- 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

15 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBESB-866) jUDDI retains invalid EPRs

by Jiri Pechanec (JIRA)

jUDDI retains invalid EPRs -------------------------- Key: JBESB-866 URL: http://jira.jboss.com/jira/browse/JBESB-866 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.2 Milestone Release 3 Reporter: Jiri Pechanec Assigned To: Mark Little If the ESB is terminated (crashes) it will retain EPRs in the database. Unfortunately when the EPR is changed e.g. by renaming of underlaying queue, both old and new EPRs are stored in jUDDI registry on the next start. Then under heavier load both EPRs are selected with the result of lot error messages related to unavailable EPR. -- 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

15 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-539) Config Generator should normalise all listener, bus, provider name values.

by Tom Fennelly (JIRA)

Config Generator should normalise all listener, bus, provider name values. -------------------------------------------------------------------------- Key: JBESB-539 URL: http://jira.jboss.com/jira/browse/JBESB-539 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.2 Milestone Release 2 Reporter: Tom Fennelly Assigned To: Tom Fennelly Fix For: 4.2 Because these are used as element names in the generated config. If there are invalid chars in there (spaces etc) the generator throws a totaly useless error. Improve the error handling there too :-) -- 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

15 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-1348) Make sure that test > 2000 chars is not inserted into JMXData

by Tom Cunningham (JIRA)

Make sure that test > 2000 chars is not inserted into JMXData ------------------------------------------------------------- Key: JBESB-1348 URL: http://jira.jboss.com/jira/browse/JBESB-1348 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.2.1 Reporter: Tom Cunningham Assigned To: Tom Cunningham Fix For: 4.3 The management console has a JMXData table with a "textvalue" field. There needs to be some check to make sure that nothing greater than the textvalue field length is inserted. -- 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

15 years, 7 months

4
6
0 / 0

[JBoss JIRA] Created: (JBESB-799) HTTP JBoss Remoting Gateway does not support GET

by Burr Sutter (JIRA)

HTTP JBoss Remoting Gateway does not support GET ------------------------------------------------ Key: JBESB-799 URL: http://jira.jboss.com/jira/browse/JBESB-799 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.2 Milestone Release 3 Reporter: Burr Sutter Assigned To: Mark Little Priority: Minor Fix For: 5.0 Milestone Release 1 The JBR/HTTP Gateway does not appear to provide my action with the query string from a GET. POST works properly but not GET. I didn't try PUT & DELETE just yet. -- 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

15 years, 7 months

5
5
0 / 0

[JBoss JIRA] Created: (JBESB-1457) Store original replyTo when invoking jBPM process

by Jiri Pechanec (JIRA)

Store original replyTo when invoking jBPM process ------------------------------------------------- Key: JBESB-1457 URL: http://jira.jboss.com/jira/browse/JBESB-1457 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.2.1 CP1 Reporter: Jiri Pechanec Assigned To: Kurt Stam Priority: Critical Fix For: 4.2.1 CP1 The jBPM process use now be default requires to use async processing. The problem is that there is now no way for the caller how to specify reply address. The replyTo/faultTo headers are used for internal jBPM message sending. I think that there should exist standard mechanism that will store original replayTo/faultTo values and allow to route them final response. This is so common and basic functionality that customer should not be required to invent and implement its own mechanism. -- 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

15 years, 7 months

4
13
0 / 0

[JBoss JIRA] Created: (JBESB-1474) Lots of null string warnings/errors in management code

by Mark Little (JIRA)

Lots of null string warnings/errors in management code ------------------------------------------------------ Key: JBESB-1474 URL: http://jira.jboss.com/jira/browse/JBESB-1474 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.2.1 Reporter: Mark Little Priority: Minor Fix For: 4.3 -- 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

15 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-1166) ESB Message Property setter/getter shortcut

by Burr Sutter (JIRA)

ESB Message Property setter/getter shortcut ------------------------------------------- Key: JBESB-1166 URL: http://jira.jboss.com/jira/browse/JBESB-1166 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 IR1 Reporter: Burr Sutter Assigned To: Mark Little Fix For: 4.2.1 I have noticed that in my code I have a lot of this kind of usage for the properties on the esb message object: esbMessage.getProperties().setProperty("MAIL_SUBJECT",subject); esbMessage.getProperties().setProperty("MAIL_MESSAGE_NUMBER",mailMessage.getMessageNumber()); esbMessage.getProperties().setProperty("MAIL_SENT_DATE",mailMessage.getSentDate()); I propose we create "shortcut" methods on the Message class itself like so: esbMessage.setProperty("MAIL_SUBJECT",subject); esbMessage.setProperty("MAIL_MESSAGE_NUMBER",mailMessage.getMessageNumber()); esbMessage.setProperty("MAIL_SENT_DATE",mailMessage.getSentDate()); The use of the word "property" in the setter/getter should make it obvious what part of the message it is going into. We should also consider the same for header, attachment, etc. -- 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

15 years, 8 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues January 2008