[JBoss JIRA] Created: (JBMESSAGING-594) Consider having just one post office instance
by Tim Fox (JIRA)
Consider having just one post office instance
---------------------------------------------
Key: JBMESSAGING-594
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-594
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.0.1.CR5
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.2.0.Beta1
We should consider whether it is possible to have just one post office instance per server, instead of the current queue and topic post office.
We currently have two since a queue and a topic can have the same name so we would need to distinguish whether we wanted to rout to a topic or a queue in some other way.
We should also bear in mind that the post office is supposed to be generic and not have any knowledge of what a "topic" is (this is a JMS term).
In the future we will want to do wildcard based routing for topic hierarchies or content based routing, so the routing key cannot just be some "destination" class.
One possibility is to change the PostOffice interface to take a "RoutingKey" type as opposed to a string. We could then subclass or implement this interface for different post office
types.
--
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
19 years, 5 months
[JBoss JIRA] Created: (JBESB-122) Schema needed
by Mark Little (JIRA)
Schema needed
-------------
Key: JBESB-122
URL: http://jira.jboss.com/jira/browse/JBESB-122
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0 Beta 1
Reporter: Mark Little
Assigned To: Mark Little
Fix For: 4.0
XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.
--
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
19 years, 5 months
[JBoss JIRA] Created: (JBESB-192) Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
by Tom Fennelly (JIRA)
Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
--------------------------------------------------------------------------------------------------
Key: JBESB-192
URL: http://jira.jboss.com/jira/browse/JBESB-192
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Priority: Blocker
Fix For: 4.0
I may be missing something here but, I think there's an issue with the Listeners/Action/Messages that probably requires more immediate attention.
The AbstractListener calls the receive method of its implementation (DirectoryPoller etc) in order to get messages from the delivery channel associated with the implementation. At the moment, the receive method returns an Object[] and AbstractListener does the job of converting/wrapping these Objects into Message implementations before pushing the Message instances through the associated pipeline for processing. The AbstractListener also performs the job of triggering "lifecycle" events on the implementation i.e. processingError and processingComplete. In order for these method implementations to perform the appropriate "channel specific" tasks relating to the processing of the message, they need access to "special" info that should be hidden in the message and not accessible to anyone else other than that Listener impl. Hopefully this will make more sense through an example....
The DirectoryPoller listens on the Filesystem for file based message. It manage the lifecycle of these messages as follows:
1. Before it's receive method impl returns the java.io.File associated with the message, it renames the file to "working" so that the file is not picked up for processing again. In fact, it actually returns an extension of java.io.File (WorkingFile) which contains "hidden" info that the Listener uses when message lifecycle events are called (processingError and processingComplete).
2. In response to a call to it's "processingError" implementation, it should get passed the original message object it returned from it's receive method (WorkingFile). WorkingFile is a inner class to DirectoryPoller and it contains a few private methods that only WorkingFile and DirectoryPoller can call. In the case of processingError being called, the DirectoryPoller wants to call the private method "renameToError".
3. In response to a call to it's "processingComplete" implementation, the DirectoryPoller wants to call the private method "renameToDone".
The Issue:
The AbstractListener implementations should be doing the wrapping of the message payload objects in the relevant Message implementations (not the AbstractListener itself as is currently the case). This way, the channel specific listener implementation can add the channel specific info it needs to the message before returning it for pipeline processing (e.g. the rename to error/done file names etc in the case of the DirectoryPoller). This also means that the receive method definition would need to be changed to return a Message[] (instead of an Object[]) and the lifecycle management methods (processingError and processingComplete) changed to take type Message (Vs type Object).
Without making these changes, the lifecycle info will very likely get lost in the pipeline because it's currently being set on the Message body/payload, which will very likely get changed during pipeline processing.
--
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
19 years, 5 months
[JBoss JIRA] Created: (JBESB-224) ESB aware listeners
by Mark Little (JIRA)
ESB aware listeners
-------------------
Key: JBESB-224
URL: http://jira.jboss.com/jira/browse/JBESB-224
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: ESB Core
Reporter: Mark Little
Assigned To: Esteban Schifman
Fix For: 4.0 RC1
We'll leave the old approach to listeners/actionprocessors in place until everything has been converted to the new approach. Ideally we would like to have all old code removed by the RC, but we need a realistic staging to the approach. Therefore, we will take 3 implementations (JMS, file and SQL) and make sure they are converted for the RC and used by the trailblazer. If there is time, we'll look at all of the others too.
--
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
19 years, 5 months