March 2012 - esb-issues - Jboss List Archives

[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

12 years, 6 months

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

12 years, 6 months

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

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] (JBESB-3743) Transactional improvement for invm resources

by Kevin Conner (JIRA)

Kevin Conner created JBESB-3743: ----------------------------------- Summary: Transactional improvement for invm resources Key: JBESB-3743 URL: https://issues.jboss.org/browse/JBESB-3743 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.10 CP1 Reporter: Kevin Conner The transactional behaviour of InVM resources associates a single message with each XAResource. If multiple InVM operations occur within the same transaction then multiple XAResources will be enlisted into the transaction, causing the transaction manager to do more work than is necessary. The code needs to change so that there is a single XAResource enlisted with each transaction, representing multiple operations. -- 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

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-3157) Feature request - consistent requirement for URL char encoding between ftp gateway and notifier

by Len DiMaggio (JIRA)

Feature request - consistent requirement for URL char encoding between ftp gateway and notifier ----------------------------------------------------------------------------------------------- Key: JBESB-3157 URL: https://jira.jboss.org/jira/browse/JBESB-3157 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.7 Reporter: Len DiMaggio Priority: Minor We're inconsistent with how we handle special characters between ftp gateway listener definitions and ftp notifier definitions - it would make it simpler for users if we handled these in the same way. For example, to use a directory of "ftp_dir##" and a password of "password##: FTP gateway listener: <ftp-provider hostname="servername.com" name="FTPprovider"> <ftp-bus busid="notifyFTPChannel"> <ftp-message-filter directory="/ftp_dir##" error-delete="false" error-suffix=".HAS_ERROR" input-suffix=".notifiertest" passive="true" password="password##" post-delete="false" post-suffix=".COMPLETE" username="username" work-suffix=".esbWorking" /> </ftp-bus> </ftp-provider> FTP: notifier: <action class="org.jboss.soa.esb.actions.Notifier" name="notify"> <property name="okMethod" value="notifyOK" /> <property name="notification-details"> <NotificationList type="OK"> <target class="NotifyFTP"> <ftp URL="ftp://username:password%23%23@servername.com/ftp_dir%23%23" filename="{jbossesb.message.id}.notifier" passive="true" /> </target> </NotificationList> </property> </action> -- 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

12 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-2315) Remove jBPM SignalFacade from ESB codebase

by Kevin Conner (JIRA)

Remove jBPM SignalFacade from ESB codebase ------------------------------------------ Key: JBESB-2315 URL: https://jira.jboss.org/jira/browse/JBESB-2315 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.4 Reporter: Kevin Conner Fix For: 4.5 This facade is not safe and should not be part of the jBPM/ESB integration. -- 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

12 years, 8 months

3
4
0 / 0

[JBoss JIRA] (JBESB-3734) SOA-P 5 ESB Deployment options prompts are asking for wrong information

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3734: ------------------------------------- Summary: SOA-P 5 ESB Deployment options prompts are asking for wrong information Key: JBESB-3734 URL: https://issues.jboss.org/browse/JBESB-3734 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 Steps to Reproduce: #. Start SOA5 #. From Admin Console (admin-console) expand and select localhost -> JBossAS Servers - JBoss SOA-P 5 (default) -> JBoss ESB -> Deployments #. Click 'Add a new resource' button project_key: SOA When deploying a new ESB using admin-console or JBoss Operations Network, the ESB plug-in is asking for deployment options which are only valid for SOA 4. For example, Deployment Location is asking for a path but in SOA 5 ProfileService is used to deploy managed components meaning that a destination directory can not be selected but instead the user should be selecting whether to deploy farmed or not. -- 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

12 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-3353) EBWS should support Web service generation from a WSDL

by Jeff DeLong (JIRA)

EBWS should support Web service generation from a WSDL ------------------------------------------------------ Key: JBESB-3353 URL: https://jira.jboss.org/browse/JBESB-3353 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.8 Reporter: Jeff DeLong EBWS should be extended to allow the user to specify a WSDL (in lieu of a set of XSDs). The WSDL would be required to conform to certain limitations, in particular only a single operation would be allowed to be specified, and the soap: address in the wsdl:port would be overwritten to match the deployment environment. This would support top-down service development. For example when using JBoss Savara project to generate WSDL documents from a Choregraphy model. -- 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

12 years, 9 months

3
4
0 / 0

[JBoss JIRA] (JBESB-3752) ServiceInvoker behaviour is inconsistent when used with transactions

by Michael Burman (JIRA)

Michael Burman created JBESB-3752: ------------------------------------- Summary: ServiceInvoker behaviour is inconsistent when used with transactions Key: JBESB-3752 URL: https://issues.jboss.org/browse/JBESB-3752 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.10 Environment: JBoss SOA 5.2.0 Platform Reporter: Michael Burman The ServiceInvoker behaviour is inconsistent when it comes to XA transactions. If the delivery fails with ServiceInvoker (there's a network timeout or something), the transaction is still committed, because it does not throw a RuntimeException. So instead of rolling back everything you just did in your actions, the staticRouter or such would commit the process and then throw this to DLQ. So when you run it from DLQ, you would again write to the database and so on. With SmooksSplitter this might cause some messages to go through and some not and other weird behaviour. One fix would be to patch ServiceInvoker deliverAsync (as an example, deliverSync should be fixed also): ### Eclipse Workspace Patch 1.0 #P JBossESB Index: rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java =================================================================== --- rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (revision 37896) +++ rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (working copy) @@ -46,9 +46,9 @@ import org.jboss.soa.esb.couriers.Courier; import org.jboss.soa.esb.couriers.CourierException; import org.jboss.soa.esb.couriers.CourierFactory; -import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException; import org.jboss.soa.esb.couriers.CourierServiceBindException; +import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierTransportException; import org.jboss.soa.esb.couriers.CourierUtil; import org.jboss.soa.esb.couriers.FaultMessageException; @@ -57,6 +57,7 @@ import org.jboss.soa.esb.listeners.ha.LoadBalancePolicy; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfo; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfoImpl; +import org.jboss.soa.esb.listeners.jca.JcaGatewayException; import org.jboss.soa.esb.listeners.message.IncompatibleTransactionScopeException; import org.jboss.soa.esb.listeners.message.MessageDeliverException; import org.jboss.soa.esb.listeners.message.MissingServiceException; @@ -253,6 +254,12 @@ try { post(message, new EPRInvoker()); } catch (MessageDeliverException mde) { + + // We want to trigger JCA rollback in case of messagedeliver exception + if(isTransactional()) { + throw new JcaGatewayException(mde); + } + if (message.getProperties().getProperty(RedeliverStore.IS_REDELIVERY)==null && asyncRedelivery(message) && !service.equals(dlqService)) { Here's a quickstart that provides a small example (replace correctBehaviour="true" to get JMS rollbacks), it just tries to call some nonexistant gateway to throw MessageDeliveryException (if there's a proper way to cause timeout in the code, then let me know, but the exception is never the less the same). https://s3-eu-west-1.amazonaws.com/yak/jboss/jms_transacted_fail.zip Once you run it with original settings and it fails, you still end up with lines in the database. -- 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

12 years, 9 months

4
8
0 / 0

[JBoss JIRA] (JBESB-3758) RecordRoute functionality on both service and message basis

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3758: ------------------------------------- Summary: RecordRoute functionality on both service and message basis Key: JBESB-3758 URL: https://issues.jboss.org/browse/JBESB-3758 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.11 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.11 Provide new, optional configuration options for ESB services to specify that the message header should be updated upon service entry and service exit. This allows users to track the history of the message through a set of services to see what path it took. Reasonable default value to capture is the service name. This is not intended to be a routing ticket. Comments: A suggestion would be to include a 'record route' option for a service and message, placing the information within the message context. The information should start with the originator (service, gateway, client) and add other services as the message progresses. We already have the EntryExitTimeFilter and GatewayFilters, I'm sure it would be easy to extend their functionality and link in to the current service information. -- 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

12 years, 9 months

1
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues March 2012