[JBoss JIRA] (JBESB-3779) ServiceInvoker behaviour is inconsistent when used with transactions
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3779:
-------------------------------------
Summary: ServiceInvoker behaviour is inconsistent when used with transactions
Key: JBESB-3779
URL: https://issues.jboss.org/browse/JBESB-3779
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.10
Environment: JBoss SOA 5.2.0 Platform
Reporter: Michael Burman
Fix For: 4.10 CP2
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, 2 months
[JBoss JIRA] (JBESB-3740) Clarify usage of acknowledge-mode on jms-message-filter
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3740:
-------------------------------------
Summary: Clarify usage of acknowledge-mode on jms-message-filter
Key: JBESB-3740
URL: https://issues.jboss.org/browse/JBESB-3740
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Affects Versions: 4.11
Reporter: Tom Cunningham
Fix For: 4.11
Description of problem:
The ESB Programmers Guide [1] only states that CLIENT_ACKNOWLEDGE mode can be
set on the jms-message-filter configuration, but does not talk about the
resulting
behavior, or about any restrictions.
The docs should be more clear about
- the resulting behavior if different ack modes are used
- any restrictions that apply, such as not using CLIENT_ACKNOWLEDGE mode on
non-gateway queues using jms-provider
- which providers these settings apply to (jms-provider, jms-jca-provider)
--
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, 2 months
[JBoss JIRA] Created: (JBESB-3693) Remove connections properties and tests from jbossesb-properties.xml
by Tom Cunningham (JIRA)
Remove connections properties and tests from jbossesb-properties.xml
--------------------------------------------------------------------
Key: JBESB-3693
URL: https://issues.jboss.org/browse/JBESB-3693
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.10
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.10 CP1
The connections part of the jbossesb-properties.xml is obsoleted (found nowhere in code). Remove it from jbossesb-properties.xml files and tests, as well as the "connection" entries in ModulePropertyManager
<properties name="connection">
<property name="min-pool-size" value="5"/>
<property name="max-pool-size" value="10"/>
<property name="blocking-timeout-millis" value="5000"/>
<property name="abandoned-connection-timeout" value="10000"/>
<property name="abandoned-connection-time-interval" value="30000"/>
</properties>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBESB-3128) http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
by Len DiMaggio (JIRA)
http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
------------------------------------------------------------------------------------------------------------------
Key: JBESB-3128
URL: https://jira.jboss.org/jira/browse/JBESB-3128
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.7
Environment: 4.7 GA
Reporter: Len DiMaggio
I'm seeing a very odd problem with the ESB's http_gateway synchronousTimeout property.
Briefly - the timer operates 100% slower than it should - but only the first time the timer is invoked for deployed .esb archive. This is reproducible at will with ESB 4.7 and SOA-P 5.0 ER7.
After experimenting with this - the delay seems to be on a per-service basis - in other words, the first time a service that hits synchronousTimeout, the timeout operates twice as slow as it should. Starting with the second time that a service encounters a synchronousTimeout, the timeout operates as expected.
I'm seeing this with the default synchronousTimeout value, and if the value is defined in the service definition in jboss-esb.xml
========================================
A modified version of the http_gateway quickstart is attached to demonstrate the problem. The modifications are:
* A new action class (my40secAction) is added - this class is identical to myAction, except that it introduces a 40 seconde delay.
* A modified jboss-esb.xml file - the Sales:List service is modified to have a 10 second synchronousTimeout, and the action invokes the My40secAction class - and a second service (SlowSales) is added - this service is a clone of Sales:List:
<service category="Sales" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
<service category="SlowSales" name="SlowList" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="slowsales" busidref="secureFriends" urlPattern="slowsales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
========================================
Here's an example of the behavior I'm seeing:
Test run #1 - approx 20 sec - unexpected as the test is configured for 10 sec timeout
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:52:47 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:07 EST 2010
Then - immediately follows test run #2 - approx 10 seconds - this is what I would have expected
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:53:14 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:25 EST 2010
--
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, 2 months
[JBoss JIRA] (JBESB-3754) Scout 1.2.6 causes JBRIntegratedUnitTest to fail
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3754:
-------------------------------------
Summary: Scout 1.2.6 causes JBRIntegratedUnitTest to fail
Key: JBESB-3754
URL: https://issues.jboss.org/browse/JBESB-3754
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing
Affects Versions: 4.11
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11
Upgrading ESB from scout 1.2.5 -> 1.2.6 causes the second test of JBRIntegratedUnitTest (test_JBESB_1428_02) to fail. The first testcase in this test passes, but once the hsql database for the first test completes, it seems like hsql has a lot of problems creating a database for the second test and running any queries. With no changes, hsql's DatabaseManager thinks the Database state is DATABASE_ONLINE rather than DATABASE_SHUTDOWN, and no hsqldb.properties or hsqldb.log files are created in product/build.
Below is a stack - the HttpClientInvoker call is failing because the services for this example aren't properly registered - hsql cannot create the juddi database, and hsql is throwing SQLExceptions within hibernate with a "java.sql.SQLException: Connection is broken: java.io.EOFException".
[java] -esb.services.internal.integration.test.junit:
[java] [junit] Listening for transport dt_socket at address: 8787
[java] [junit] Running org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest
[java] [junit] Testsuite: org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest
[java] [junit] Listening for transport dt_socket at address: 8787
[java] [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 18.054 sec
[java] [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 18.054 sec
[java] [junit] ------------- Standard Output ---------------
[java] [junit] EMMA: collecting runtime coverage data ...
[java] [junit] ------------- ---------------- ---------------
[java] [junit] ------------- Standard Error -----------------
[java] [junit] java.lang.NullPointerException
[java] [junit] at org.hsqldb.ServerConnection.close(ServerConnection.java:170)
[java] [junit] at org.hsqldb.ServerConnection.run(ServerConnection.java:273)
[java] [junit] at java.lang.Thread.run(Thread.java:662)
[java] [junit] java.lang.NullPointerException
[java] [junit] at org.hsqldb.ServerConnection.close(ServerConnection.java:170)
[java] [junit] at org.hsqldb.ServerConnection.run(ServerConnection.java:273)
[java] [junit] at java.lang.Thread.run(Thread.java:662)
[java] [junit] org.jboss.remoting.CannotConnectException: Can not connect http client invoker. Connection refused.
[java] [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:348)
[java] [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:137)
[java] [junit] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
[java] [junit] at org.jboss.remoting.Client.invoke(Client.java:1634)
[java] [junit] at org.jboss.remoting.Client.invoke(Client.java:548)
[java] [junit] at org.jboss.remoting.Client.invoke(Client.java:536)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.sendMessageToServer(JBRIntegratedUnitTest.java:68)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.access$000(JBRIntegratedUnitTest.java:31)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest$2.test(JBRIntegratedUnitTest.java:53)
[java] [junit] at org.jboss.soa.esb.testutils.AbstractTestRunner.run(AbstractTestRunner.java:84)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.test_JBESB_1428_02(JBRIntegratedUnitTest.java:51)
[java] [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] [junit] at java.lang.reflect.Method.invoke(Method.java:597)
[java] [junit] at junit.framework.TestCase.runTest(TestCase.java:164)
[java] [junit] at junit.framework.TestCase.runBare(TestCase.java:130)
[java] [junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[java] [junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[java] [junit] at junit.framework.TestResult.run(TestResult.java:109)
[java] [junit] at junit.framework.TestCase.run(TestCase.java:120)
[java] [junit] at junit.framework.TestSuite.runTest(TestSuite.java:230)
[java] [junit] at junit.framework.TestSuite.run(TestSuite.java:225)
[java] [junit] at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
[java] [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32)
[java] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:422)
[java] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:931)
[java] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:785)
[java] [junit] Caused by: java.net.ConnectException: Connection refused
[java] [junit] at java.net.PlainSocketImpl.socketConnect(Native Method)
[java] [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
[java] [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
[java] [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
[java] [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
[java] [junit] at java.net.Socket.connect(Socket.java:529)
[java] [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
[java] [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:395)
[java] [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
[java] [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:234)
[java] [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:307)
[java] [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:324)
[java] [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970)
[java] [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911)
[java] [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836)
[java] [junit] at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1014)
[java] [junit] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:277)
[java] [junit] ... 27 more
[java] [junit] java.lang.NullPointerException
[java] [junit] at org.hsqldb.ServerConnection.close(ServerConnection.java:170)
[java] [junit] at org.hsqldb.ServerConnection.run(ServerConnection.java:273)
[java] [junit] at java.lang.Thread.run(Thread.java:662)
[java] [junit] ------------- ---------------- ---------------
[java] [junit]
[java] [junit] Testcase: test_JBESB_1428_01 took 14.685 sec
[java] [junit] Testcase: test_JBESB_1428_02 took 3.022 sec
[java] [junit] FAILED
[java] [junit] Error making JBR Client invocation.
[java] [junit] junit.framework.AssertionFailedError: Error making JBR Client invocation.
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.sendMessageToServer(JBRIntegratedUnitTest.java:71)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.access$000(JBRIntegratedUnitTest.java:31)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest$2.test(JBRIntegratedUnitTest.java:53)
[java] [junit] at org.jboss.soa.esb.testutils.AbstractTestRunner.run(AbstractTestRunner.java:84)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest.test_JBESB_1428_02(JBRIntegratedUnitTest.java:51)
[java] [junit]
[java]
[java] BUILD FAILED
[java] /home/tcunning/src/jbossesb/trunkthree/product/build.xml:217: The following error occurred while executing this line:
[java] /home/tcunning/src/jbossesb/trunkthree/product/rosetta/build.xml:226: The following error occurred while executing this line:
[java] /home/tcunning/src/jbossesb/trunkthree/product/rosetta/tests/build.xml:242: The following error occurred while executing this line:
[java] /home/tcunning/src/jbossesb/trunkthree/product/rosetta/tests/build.xml:281: The following error occurred while executing this line:
[java] /home/tcunning/src/jbossesb/trunkthree/product/rosetta/tests/build.xml:294: Test org.jboss.soa.esb.listeners.gateway.JBRIntegratedUnitTest failed
[java]
[java] Total time: 1 minute 6 seconds
[java] Java Result: 1
--
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, 2 months
[JBoss JIRA] (JBESB-3745) JON event logging / ESB MVEL action
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3745:
-------------------------------------
Summary: JON event logging / ESB MVEL action
Key: JBESB-3745
URL: https://issues.jboss.org/browse/JBESB-3745
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Management
Affects Versions: 4.11
Reporter: Tom Cunningham
Fix For: 4.11
Investigate the creation of a custom log which will then be fed into JON through the event stream. Try to see what sort of filtering and aggregation that JON provides that will allow us to provide a nicer view than just the log entry (i.e. X number of events within the past 3 hours, whether we can trigger notifications off of groups of events, etc).
Possibly add an additional Quickstart around this area.
--
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, 2 months
[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
12 years, 2 months
[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
12 years, 2 months