Good question :-)
So with the code donation we received a year ago, the Message object model had no real concept of a "defaultEntry" on which client code was able to get and set an object on. What it did have though was that elegant ( ;-) ) solution you point to, where these ActionUtil "helper" methods called setTaskObject and getTaskObject used that "CURRENT_OBJECT" string to get and set a "default" payload on the Message.Body.
Since then however, we've added the Message.Body.add(Object) (should really be called Message.Body.set(Object) IMO) and Message.Body.get() methods, but there are still some actions there that use the old "elegant" helper methods ;-)
I've added a JIRA to migrate all actions to use the new model.
Thanks! So basically, use:
Message.getBody().add(Object) and Message.getBody().get()
These messages will create objects with the name "org.jboss.soa.esb.actions.current.after" for backwards compatibility.
At some point, Message.getBody().add(Object) may become deprecated, and Message.getBody().set(Object) will likely replace it.
If you are making these changes, might I suggest using put(Name, Object) rather than add(Name, Object), since it is more Map-like, and Message.Body is pretty much a Map? I know the Name parameter in Map is an Object, while the Name parameter in Body is a String, but .... just an idea!
So, as a follow-up question, if the body is basically a Map, why bother with attachments?
As far as a I can tell, the nice thing about using attachments, as I used them with binary data, is that they aren't printed when you display the contents of a message.
Is there a specific use for attachments that I am not seeing?
At the moment (and I'm fairly sure this is mentioned in the docs), there's not a lot of difference between using attachements or stuffing your content into the Body. However, at some point we'll be treating attachments in the same way SOAP-with-attachments does: you'll be able to define different delivery criteria for them, stream them, etc. So they will be handled differently *eventually*.