June 2012 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3708) XsltAction cannot handle org.w3c.dom.Document

by David Tucker (Created) (JIRA)

XsltAction cannot handle org.w3c.dom.Document --------------------------------------------- Key: JBESB-3708 URL: https://issues.jboss.org/browse/JBESB-3708 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.10 Reporter: David Tucker Currently the XsltAction can handle the following objects: String, byte[], Reader, InputStream, File, or Source The output from the XsltAction, when choosing DOM, is an object that implements the interface org.w3c.dom.Document. The action can't accept the document it created to run another transformation on it. While this scenario is remote at best, it is not unlikely that we would want to run a transformation on a Document. I was able to create a custom action that would allow me to put a Document into a DOMSource object. This requires extra work anytime I want to use a Document in an XSLT and the Document interface should be an accepted way of sending a document to be transformed. The following code was all it took in my custom action: DOMSource domSource = new DOMSource(); domSource.setNode(doc.getFirstChild()); //doc is an object implementing org.w3c.dom.Document -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

7
15
0 / 0

[JBoss JIRA] Created: (JBESB-3587) Enabling xslt parameters support in XsltAction

by Eduardo de Vera Toquero (JIRA)

Enabling xslt parameters support in XsltAction ---------------------------------------------- Key: JBESB-3587 URL: https://issues.jboss.org/browse/JBESB-3587 Project: JBoss ESB Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Transformation Service Affects Versions: 4.9 Environment: Linux Reporter: Eduardo de Vera Toquero Priority: Minor Enhancement of xslt parameters in order to be able to pass values to xslt parameters on the xslt action. Ideally, using prefixes, one could chose whether to pass a value located at the configuration file (ConfigTree) or from the ESB Message. Values need to be stringed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
7
0 / 0

[JBoss JIRA] (JBESB-3739) Detect CLIENT_ACKNOWLEDGE mode using jms-provider on non-gateway queues

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3739: ------------------------------------- Summary: Detect CLIENT_ACKNOWLEDGE mode using jms-provider on non-gateway queues Key: JBESB-3739 URL: https://issues.jboss.org/browse/JBESB-3739 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Message Store Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 Description of problem: CLIENT_ACKNOWLEDGE mode is not valid for a non-gateway listener using jms-provider. If using the jms-provider then the message will be retrieved by the JmsCourier and converted into an ESB message, after which there is no longer a reference to the underlying JMS message. The JmsCourier should be detecting this and raising an exception. Version-Release number of selected component (if applicable): JBoss ESB 4.10 How reproducible: Consistently Steps to Reproduce: 1. Modfiy jboss-esb.xml of helloworld quickstart: <jms-provider name="JBossMQ" connection-factory="XAConnectionFactory"> <jms-bus busid="quickstartGwChannel"> <jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_helloworld_Request_gw" transacted="false" acknowledge-mode="CLIENT_ACKNOWLEDGE" /> </jms-bus> <jms-bus busid="quickstartEsbChannel"> <jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_helloworld_Request_esb" transacted="false" acknowledge-mode="CLIENT_ACKNOWLEDGE" /> </jms-bus> </jms-provider> 2. Invoke ant runtest Actual results: Message remains in the non-gateway queue after ESB service has been invoked. Expected results: An exception should be raised indicating that CLIENT_ACKNOWLEDGE mode is not supported on non-gateway queues using jms-listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-3294) NotifyFiles appends a new line character in stringNotification() method to the original content.

by Marek Baluch (JIRA)

NotifyFiles appends a new line character in stringNotification() method to the original content. ------------------------------------------------------------------------------------------------ Key: JBESB-3294 URL: https://jira.jboss.org/jira/browse/JBESB-3294 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.7 CP1, 4.4 CP4 Reporter: Marek Baluch More precisely the stringNotification() method appends the new line character if the string does not end with one. This may be a problem in cases when all we want to do is to save some file content (e.g. received via fs-provider to the esb app) under a different name. -- 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

11 years, 10 months

3
8
0 / 0

[JBoss JIRA] (JBESB-3721) NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute

by Martin Weiler (Created) (JIRA)

NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute ---------------------------------------------------------------------------------------- Key: JBESB-3721 URL: https://issues.jboss.org/browse/JBESB-3721 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment Affects Versions: 4.10 Reporter: Martin Weiler Deploying a service with a schedule-listener using an incorrect value for the scheduleidref attribute results in a NullPointerException: {noformat} ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/data/jboss/work/jboss-soa-p-5.2.0.GA/jboss-as/server/test/deploy/Quickstart_scheduled_services.esb/ state=Create java.lang.RuntimeException: java.lang.NullPointerException at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:185) ... Caused by: java.lang.NullPointerException at org.jboss.soa.esb.listeners.config.mappers.ScheduleMapper.map(ScheduleMapper.java:61) at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.addESBAwareConfig(ESBAwareGenerator.java:216) at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.generate(ESBAwareGenerator.java:102) at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.generateESBAwareConfig(XMLBeansModel.java:441) {noformat} The existence of the referenced schedule-provider should be verified, and if it does not exist, a meaningful exception should be thrown instead of the NullPointerException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-3561) Registry Error When JBOSS bind to 0.0.0.0

by Anurag Debnath (JIRA)

Registry Error When JBOSS bind to 0.0.0.0 ----------------------------------------- Key: JBESB-3561 URL: https://issues.jboss.org/browse/JBESB-3561 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss Enterprise SOA Platform 5.0.1 Reporter: Anurag Debnath When the server hosting ESB is started with flag -b 0.0.0.0, the UDDI registry puts services under this address and are thus unreachable by remote ServiceInvokers. Tested by deploying 'HelloWorld' quickstart and examining UDDI through the UDDI console. * Start server with no flags. Examing UDDI registry will show service is bound to '127.0.0.1' * Start server with -b 123.123.123.123. UDDI registry will show service bound to '123.123.123.123' * Start server with -b 0.0.0.0 UDDI registry will show service bound to '0.0.0.0' (unreachable remotely) * Start server with -b 0.0.0.0 -Djboss.esb.bind.address=123.123.123.123 UDDI registry will show service bound to '0.0.0.0' * Start server with -b 0.0.0.0 and JAVA_OPTS including "jboss.esb.bind.address=123.123.123.123" UDDI registry will show service bound to '0.0.0.0' Proposed fix is a system property read by org.jboss.soa.esb.helpers.NamingContextPool that specifies the desired octet to plug into java.naming.provider.url. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-3613) Please remove cruft from bpm_orchestration1 quickstart

by Rick Wagner (JIRA)

Please remove cruft from bpm_orchestration1 quickstart ------------------------------------------------------ Key: JBESB-3613 URL: https://issues.jboss.org/browse/JBESB-3613 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.9 CP1, 4.9 Environment: All JBoss ESB Reporter: Rick Wagner Priority: Minor The BPM1 quickstart includes File System artifacts that appear to be in place for an ESB-aware entry point as well as a Gateway entry point. (This is consistent with the JMS started quickstarts, which normally offer ESB-aware and ESB-unaware start mechanisms.) In this case, there's not an Ant target available to kickstart the non-Gateway mechanism, so the Provider (and associated listener) are not needed. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3489) ProcessLogs that represent changes of process intance that take place within Timer.Execute are not saved in DB

by Kevin Conner (JIRA)

ProcessLogs that represent changes of process intance that take place within Timer.Execute are not saved in DB -------------------------------------------------------------------------------------------------------------- Key: JBESB-3489 URL: https://jira.jboss.org/browse/JBESB-3489 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.9 Reporter: Toshiya Kobayashi Log events won't be saved when they are triggered by Timer. This issue was fixed in JobExecutorThread ( JBPM-1015 ). But regarding SOA integration, only org.jboss.soa.esb.services.jbpm.integration.job.ExecuteJobCommand includes the fix. org.jboss.soa.esb.services.jbpm.integration.job.ExecuteTimerCommand should follow. # Snippet from org.jboss.soa.esb.services.jbpm.integration.job.ExecuteJobCommand // register process instance for automatic save // see https://jira.jboss.org/jira/browse/JBPM-1015 ProcessInstance processInstance = job.getProcessInstance(); jbpmContext.addAutoSaveProcessInstance(processInstance); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-3571) Modify the ESB for IBM MQ to support JCA inbound and outbound

by Len DiMaggio (JIRA)

Modify the ESB for IBM MQ to support JCA inbound and outbound ------------------------------------------------------------- Key: JBESB-3571 URL: https://issues.jboss.org/browse/JBESB-3571 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.9 Reporter: Len DiMaggio See these JIRA for related details: https://issues.jboss.org/browse/SOA-2924 https://issues.jboss.org/browse/SOA-2117 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
1
0 / 0

[JBoss JIRA] (JBESB-3823) Standardise exception behaviour

by Kevin Conner (JIRA)

Kevin Conner created JBESB-3823: ----------------------------------- Summary: Standardise exception behaviour Key: JBESB-3823 URL: https://issues.jboss.org/browse/JBESB-3823 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.11 Reporter: Kevin Conner The JCA inflow handles exception behaviour differently from MessageAwareListener, rolling back transactions *iff* a runtime exception was thrown. MessageAwareListener also allows application exceptions to cause rollbacks. We need to check the JCA inflow, and other uses of the pipeline, to make sure that this behaviour is common. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues June 2012