July 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-3407) Remove hornetq-jms.xml files from quickstarts that don't use them

by Tom Fennelly (JIRA)

Remove hornetq-jms.xml files from quickstarts that don't use them ----------------------------------------------------------------- Key: JBESB-3407 URL: https://jira.jboss.org/browse/JBESB-3407 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Examples Reporter: Tom Fennelly Assignee: Tom Fennelly Priority: Trivial Fix For: 4.9 Added to some of them by accident -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3406) Fix H2 urls in the helloworld_tx_sql_action

by Tom Fennelly (JIRA)

Fix H2 urls in the helloworld_tx_sql_action ------------------------------------------- Key: JBESB-3406 URL: https://jira.jboss.org/browse/JBESB-3406 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Reporter: Tom Fennelly Assignee: Tom Fennelly Fix For: 4.9 required by upgrade to v1.2 of h2 -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3395) Add a "no-service.xml" file to the helloworld_hibernate_action quickstart for hornetq

by Tom Fennelly (JIRA)

Add a "no-service.xml" file to the helloworld_hibernate_action quickstart for hornetq ------------------------------------------------------------------------------------- Key: JBESB-3395 URL: https://jira.jboss.org/browse/JBESB-3395 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Examples Reporter: Tom Fennelly Assignee: Tom Fennelly Fix For: 4.9 -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3376) Provide support for SOAPProcessor to invoke CXF WS Endpoints

by Magesh Kumar B (JIRA)

Provide support for SOAPProcessor to invoke CXF WS Endpoints ------------------------------------------------------------ Key: JBESB-3376 URL: https://jira.jboss.org/browse/JBESB-3376 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.7 Reporter: Magesh Kumar B Assignee: Magesh Kumar B Fix For: 4.9 SOAPProcessor uses JBossWS-SPI to invoke the WS Endpoint. This is not compatible with CXF. java.lang.UnsupportedOperationException: Not yet supported at org.jboss.soa.esb.actions.soap.adapter.SOAPProcessorServletContext.getAttribute(SOAPProcessorServletContext.java:45) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:53) at org.jboss.soa.esb.actions.soap.SOAPProcessor.process(SOAPProcessor.java:187) SOAPProcessor issue is not just with the mock classes. Even if the mock class is fixed to support attributes, the CXF's JBossWS SPI implementation[1] does not handle this well. The reason is that it expects a ServletControllerExt in the ServletContext and we cannot create this by ourselves. It has to be set by CXF somehow inside the RequestHandlerImpl. Using the JBossWS-SPI is not possible on CXF ATM. [1] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/tags/jbossws-cxf-3.3.1.S... -- 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

15 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3402) LHS of rules failing to match on ESB redeploy

by David Ward (JIRA)

LHS of rules failing to match on ESB redeploy --------------------------------------------- Key: JBESB-3402 URL: https://jira.jboss.org/browse/JBESB-3402 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Reporter: David Ward Assignee: David Ward Priority: Critical Fix For: 4.9 It became evident that Drools caches ClassLoaders by default. The problem that showcased this was that on redeploy of the business_rules* quickstarts, none of the LHS of the DRL rules were matching. When we deploy a new ESB archive, there is a new ClassLoader. However Drools was holding onto the old ClassLoader. Because an Object is only ever "equal" to another Object if it came from the same ClassLoader, none of the Objects on the LHS matched the expression. Two things need to happen to fix this problem: 1. KnowledgeBuilderConfigurations need to be created with a Properties argument containing ClassLoaderCacheOption.PROPERTY_NAME="true". 2. KnowledgeBuilderConfigurations need to be created with a ClassLoader argument containing a custom ESB ClassLoader, which under-the-hood uses the LifecycleResource mechanism to associate the original Thread ContextClassLoader (the deployment's ClassLoader) with calls to loadClass(), findResource(), etc. Luckily most of what is needed here already exists in the DroolsRuleAgentHelper code. -- 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

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-3335) Integrate MRG with jBPM inflow

by Kevin Conner (JIRA)

Integrate MRG with jBPM inflow ------------------------------ Key: JBESB-3335 URL: https://jira.jboss.org/browse/JBESB-3335 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.8 Reporter: Kevin Conner Priority: Blocker Fix For: 4.9 We currently provide alternative job executor/timers using inflow capabilities and JBoss Messaging. Need to provide hornetq equivalents. -- 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

15 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-3399) Support MRG JCA inflow when released

by Kevin Conner (JIRA)

Support MRG JCA inflow when released ------------------------------------ Key: JBESB-3399 URL: https://jira.jboss.org/browse/JBESB-3399 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.9 Reporter: Kevin Conner -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-3397) halt()/dispose() race condition in DroolsRuleBaseState

by David Ward (JIRA)

halt()/dispose() race condition in DroolsRuleBaseState ------------------------------------------------------ Key: JBESB-3397 URL: https://jira.jboss.org/browse/JBESB-3397 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Reporter: David Ward Assignee: David Ward Fix For: 4.9 What happens: Thread 1 creates a stateful session and spawns daemon Thread 2 (with the correct TCCL). Thread 2 calls fireUntilHalt() on the stateful session, which suspends that Thread. Thread 3 calls halt() on the stateful session, which will cause Thread 2 to stop *once all the rules have finished firing*, however returns immediately. Thread 3 calls dispose() on the stateful session, *but the rules might not have finished firing*. This could cause unpredictable results. What needs to happen: Thread 1 creates a stateful session and spawns daemon Thread 2 (with the correct TCCL). Thread 2 calls fireUntilHalt() on the stateful session, which suspends that Thread. Thread 3 calls halt() on the stateful session, which will cause Thread 2 to stop once all the rules have finished firing, however returns immediately. Thread 3 calls join() on Thread 2, which will return *once all the rules have finished firing* and Thread 2 is done. Thread 3 calls dispose() on the stateful session safely, as now the rules have finished firing. This means predictable results. -- 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

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-3398) Router "split" methods are deprecated, but still shown normal in docs

by Darrin Mison (JIRA)

Router "split" methods are deprecated, but still shown normal in docs --------------------------------------------------------------------- Key: JBESB-3398 URL: https://jira.jboss.org/browse/JBESB-3398 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.9 Reporter: Darrin Mison The OOTB Actions chapter of the Programmers Guide docs show that there is a "split" method that should be used on StaticRouter, ContentBasedRouter, and StaticWiretap. However, that method appears to now be deprecated [1] since MessageMulticaster is automatically adding aggregation details if the message is routed to more than one recipient. Please see "sendToSubset()" method of MessageMulticaster [2]. We should probably update the Aggregator documentation to explain how the out of the box router actions are automatically "splitting" the message and adding aggregation details if routed to multiple recipients. This also appears in the corresponding sections of the SOA-P docs. [1] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... [2] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-3394) Turn down initialization logging on DroolsRuleAgentHelper

by David Ward (JIRA)

Turn down initialization logging on DroolsRuleAgentHelper --------------------------------------------------------- Key: JBESB-3394 URL: https://jira.jboss.org/browse/JBESB-3394 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 DroolsRuleAgentHelper is outputting the following info log (should be debug)... 14:53:31,886 INFO [DroolsRuleAgentHelper] created ChangeSet XML [ <change-set xmlns="http://drools.org/drools-5.0/change-set" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:schemaLocation="http://drools.org/drools-5.0/change-set drools-change-set-5.0.xsd"> <add> <resource source="file:/home/dward/repos/jbossesb/trunk/product/samples/quickstarts/business_ruleservice_cep/business_ruleservice_cep.drl" type="DRL"/> </add> </change-set> ] -- 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

15 years, 9 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues July 2010