July 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1121) JBoss Web Console integration (message alerter)

by Tom Cunningham (JIRA)

JBoss Web Console integration (message alerter) ----------------------------------------------- Key: JBESB-1121 URL: http://jira.jboss.com/jira/browse/JBESB-1121 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tom Cunningham Assigned To: Tom Cunningham According to their docs, the JBoss Web Console does console-based alerts and email-alerts. It'd be nice if there was also was an ESB option - where based off of a JMX Bean property, a message is sent to whatever ESB service the user specifies in their monitoring XML. -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-1851) JAXRConnectionFactory should not rely on System properties when creating a Connection

by Daniel Bevenius (JIRA)

JAXRConnectionFactory should not rely on System properties when creating a Connection ------------------------------------------------------------------------------------- Key: JBESB-1851 URL: http://jira.jboss.com/jira/browse/JBESB-1851 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples, Registry and Repository Reporter: Daniel Bevenius The quickstarts that use the ServiceInvoker all seem to do this (atleast the ones that I've looked at) : System.setProperty("javax.xml.registry.ConnectionFactoryClass","org.apache.ws.scout.registry.ConnectionFactoryImpl"); Now, we have this property in the jbossesb-properties.xml as: <property name="org.jboss.soa.esb.registry.factoryClass" value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/> This property is read by JAXRConnectionFactory constructor and saved into a Properties object as: props.setProperty("javax.xml.registry.factoryClass", Configuration.getRegistryFactoryClass()); The 'props' are set on the ConnectionFactory object that is created in the getConnection() method: protected Connection getConnection() { Connection connection = null; try { // Create the connection, passing it the configuration properties ConnectionFactory factory = ConnectionFactory.newInstance(); factory.setProperties(props); connection = factory.createConnection(); connection.setCredentials(creds); } catch (JAXRException e) { logger.log(Level.ERROR, "Could not set up a connection to the Registry. " + e.getMessage(), e); } return connection; } Here we can see that ConnectionFactory.newInstance() method will be called prior to the properties getting set on the factory, which is natural. But the problem is that ConnectionFactory.newInstance() method looks like this: private static final String SYS_PROP_NAME = "javax.xml.registry.ConnectionFactoryClass"; public static ConnectionFactory newInstance() throws JAXRException { String factoryName = null; ConnectionFactory factory = null; try { String defaultName = null; factoryName = System.getProperty(SYS_PROP_NAME, defaultName); ClassLoader loader =Thread.currentThread().getContextClassLoader(); Class factoryClass = loader.loadClass(factoryName); factory = (ConnectionFactory) factoryClass.newInstance(); } catch(Throwable e) { throw new JAXRException("Failed to create instance of:"+factoryName, e); } return factory; } We should not be relying on the system properties in order to do this. Our JAXRConnectionFactory should be creating the factory directly and not using ConnectionFactory, this is the real error IMO. If we do this then we will not be affected by anyone else in the AS overriding JAXR. Kev See also this googlegroups thread for more background info: http://groups.google.se/group/jbossesb/browse_frm/thread/3a5ce28b4a0f6bca -- 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
5
0 / 0

[JBoss JIRA] Created: (JBESB-1810) There is no retry limit when using transacted SQL listener

by Jiri Pechanec (JIRA)

There is no retry limit when using transacted SQL listener ---------------------------------------------------------- Key: JBESB-1810 URL: http://jira.jboss.com/jira/browse/JBESB-1810 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.2.1 CP3 Environment: FC8/PostgreSQL Reporter: Jiri Pechanec Assigned To: Kevin Conner Priority: Critical Fix For: 4.2.1 CP4 If the SQL listener is used and set to support transactions and an exception is thrown in pipeline the transaction is rolled back and the message is put back for processing. Unfortunately there is no retry limit so the same message is executed again and again and in case of more messages the performance goes down. There should be something like retry counter that after few unsuccessful execution will put the message to DLQ. -- 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, 4 months

5
19
0 / 0

[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

15 years, 5 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

15 years, 5 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

15 years, 8 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

15 years, 8 months

2
3
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

15 years, 9 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

15 years, 9 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

15 years, 9 months

4
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues July 2008