[JBoss JIRA] Created: (JBESB-568) ActionUtils.getTaskObject NullPointerException when message is null
by Daniel Bevenius (JIRA)
ActionUtils.getTaskObject NullPointerException when message is null
-------------------------------------------------------------------
Key: JBESB-568
URL: http://jira.jboss.com/jira/browse/JBESB-568
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Daniel Bevenius
Assigned To: Mark Little
Priority: Minor
Test method:
public void testGetTaskObjectNegative()
{
ActionUtils.getTaskObject( null );
}
ActionUtils :
public static Object getTaskObject(Message message)
{
Object payload = (null==message)? null : message.getBody().get(CURRENT_OBJECT);
if(payload == null) {
payload = message.getBody().getByteArray();
}
return payload;
}
I'm not sure if it is ever possible for the message object passed in to be null but perhaps the code should be modified anyway just in case.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBESB-560) Store the original filename for messages originating on file or FTP gateways
by Derek Adams (JIRA)
Store the original filename for messages originating on file or FTP gateways
----------------------------------------------------------------------------
Key: JBESB-560
URL: http://jira.jboss.com/jira/browse/JBESB-560
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.2 Milestone Release 2
Reporter: Derek Adams
Assigned To: Mark Little
Priority: Minor
Fix For: 4.2
When file and FTP gateways create messages to put on the bus, the original filename should be made available as part of the message. An example use-case for this would be polling a group of files on an FTP server at a given interval, doing some manipulation of the contents inside the ESB, then writing the message back out to FTP with the original file name plus a timestamp to make the file unique.
--
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
18 years, 9 months
[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
18 years, 9 months