[JBoss JIRA] Created: (JBESB-452) Refactor Notifiers
by Kurt Stam (JIRA)
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
These comments are based on the JMS notifiers but will probably apply to the other notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances). Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when running in high load mode.
2. They should get their 'provider' configuration from the configuration, just like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and there shouldn't be a distinction between notifying and sending a message via couriers+listeners. The fact we support different transports (and in different ways) for notifiers than for the "core" ESB is just wrong.
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBESB-537) Tidy up junit test. Several test show errors that are logged as intentional.
by Daniel Bevenius (JIRA)
Tidy up junit test. Several test show errors that are logged as intentional.
----------------------------------------------------------------------------
Key: JBESB-537
URL: http://jira.jboss.com/jira/browse/JBESB-537
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Daniel Bevenius
Assigned To: Mark Little
Priority: Trivial
A few junit test display errors that are not marked as intentional. For example the SqlTableGatewayListenerUnitTest:
[java] [junit] ------------- Standard Error -----------------
[java] [junit] java.lang.NullPointerException
[java] [junit] at java.lang.Class.forName0(Native Method)
[java] [junit] at java.lang.Class.forName(Class.java:242)
[java] [junit] at org.jboss.soa.esb.util.ClassUtil.forName(ClassUtil.java:48)
[java] [junit] at org.jboss.soa.esb.services.registry.RegistryFactory.createRegistry(RegistryFactory.java:65)
[java] [junit] at org.jboss.soa.esb.services.registry.RegistryFactory.getRegistry(RegistryFactory.java:51)
[java] [junit] at org.jboss.soa.esb.listeners.RegistryUtil.getEprs(RegistryUtil.java:206)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.SqlTableGatewayListener.doInitialise(SqlTableGatewayListener.java:112)
[java] [junit] at org.jboss.soa.esb.listeners.gateway.SqlTableGatewayListenerUnitTest.testGateway(SqlTableGatewayListenerUnitTest.java:163)
[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:585)
[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:110)
[java] [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[java] [junit] at junit.framework.TestResult.run(TestResult.java:113)
[java] [junit] at junit.framework.TestCase.run(TestCase.java:120)
[java] [junit] at junit.framework.TestSuite.runTest(TestSuite.java:228)
[java] [junit] at junit.framework.TestSuite.run(TestSuite.java:223)
[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:421)
[java] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[java] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBESB-562) Add additional optional aliases XStreamToObject converter
by Daniel Bevenius (JIRA)
Add additional optional aliases XStreamToObject converter
---------------------------------------------------------
Key: JBESB-562
URL: http://jira.jboss.com/jira/browse/JBESB-562
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Reporter: Daniel Bevenius
Assigned To: Mark Little
Priority: Trivial
I needed the ability to specify extra aliases for XStreamToObject and from what I can see one can only specify one alias, which is for the main object in the xml.
This is a suggestion of what the configuration could look like:
<Action name="doCustomer" processor="XStreamObject">
<property name="class-alias" value="Customer" />
<property name="incoming-type" value="CustomerProcessor" />
<property name="exclude-package" value="false" />
<!-- Optional list of extra aliases to add to XStream -->
<aliases>
<alias name="aliasName" class="className" />
<alias name="aliasName" class="className" />
...
</aliases>
</Action>
I have check in this suggestion here: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/
The classes of interest are:
XStreamToObjectUnitTest
XStreamToObject
/Daniel
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBESB-582) Simple_cbr Quickstart: ReceiveJMSMessage doesn't work
by Bernard Tison (JIRA)
Simple_cbr Quickstart: ReceiveJMSMessage doesn't work
-----------------------------------------------------
Key: JBESB-582
URL: http://jira.jboss.com/jira/browse/JBESB-582
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples
Affects Versions: 4.2 Milestone Release 2
Reporter: Bernard Tison
Assigned To: Mark Little
Priority: Minor
The org.jboss.soa.esb.samples.quickstart.simplecbr.test.ReceiveJMSMessage.java code doesn't work. It creates a new QueueReceiver object every 2 seconds. Also the System.out.println(msg) does not work with JBoss Messaging. It should be System.out.println(msg.getText()).
Attached refactored code. Tested with jbossesb-server-4.2 (using JBoss Messaging) and JBoss AS 4.2 (using JBoss MQ)
--
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
16 years, 10 months