[jboss-dev-forums] [Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience

[mark.little@jboss.com]

"tfennelly" wrote : "mark.little at jboss.com" wrote : I think that given the overall Rosetta architecture, what's there now in temrs of Messages is good enough until dispatchers go in to the next release. There are more important areas to concentrate on IMO.
  | 
  | Aye, probably is fine for now alright.  
  | 
  | Just to let people know what it means.... it just means that the Abstract*Processors classes are restricted in their use because the process(File) process(Map) etc methods block the implementing class from accessing the Message.  I noticed this (coupled with the get*Notification methods) as a small problem yesterday when, with the FileToByteArray converter, I wanted to get the original "WorkingFile" instance from inside the get*Notification methods but couldn't because the CURRENT_OBJECT had changed the CURRENT_OBJECT from inside the process(File) method.
  | 

Can you outline the specific use case here (not talking about classes or interfaces at this point)? I want to understand the architectural issue, because from a pipeline perspective, I'd assume that as you progress through the pipeline components, the payload/message content does change and element N in the change of M components won't necessarily be able to see the message as it appeared when N-1 saw it. To do otherwise raises potential security issues and causes information leakage across component boundaries, which is never a good thing. A specific requirement to do this could be done and would normally be part of the contract negotiation between components, but I'd say that was not the default behaviour.

anonymous wrote : 
  | A possible solution to this would have been to bind the WorkingFile instance to some other name on the Message.Body.  However, we couldn't do this because the process(File) method doesn't have access to the Message.
  | 
  | So, if you really need to get around an issue like this, it means implementing an ActionProcessor from scratch i.e. not extending the Abstract implementations.  This is not such a big deal any more beause the ActionProcessors have been completely decoupled from the underlying delivery channel - the Abstract* implementations do close on nothing at this stage.

Before changing I'd like to understand the reasons.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976748#3976748

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976748