Hi Shafreen, I would suggest having a single Carbon Message with the option to set different types of data sources as the data source for the message. For that, we might need to go through the existing other message types and think what kind of functionality to be added to carbon message. If our intention is not to extend carbon message, we can make it a final class. If not we have to design it to be extended by other users.
When reading the payload multiple times (building the message) we need to clone messages (since data is represented as a stream). In pass through scenarios, we should avoid cloning the message and use the stream once. IMO we can implement this functionality by way of having package level methods for transport to read from the internal blocking queue and write to the output stream. If we invoke other public methods they will make a clone of the message data and use. This way we avoid unnecessary cloning in a pass-through scenario. And reading from the blocking queue can only be done from the transport. Outside users have to use message data source to read the content, which might clone the data. WDYT? Regards, Asitha On Wed, Jul 5, 2017 at 3:14 PM, Shafreen Anfar <shafr...@wso2.com> wrote: > Hi All, > > It seems there is room to improve the current CarbonMessage > implementation. Following are few main areas where we can improve its > functionality. > > - At the moment there are too many ways to get the message body from > the CarbonMessage > - getMessageBody() > - getInputStream() - This is a http specific impl. > - getMessageDateSource() > > > - There are too many types of CarbonMessages in carbon-messaging that > are only used by a specific transport implementation > - BinaryCarbonMessage > - ControlCarbonMessage > - DefaultCarbonMessage > - MapCarbonMessage > - SerializableCarbonMessage > - StatusCarbonMessage > - StreamingCarbonMessage > - TextCarbonMessage > > > - Most of above CarbonMessages do not adhere to the contract that is > imposed by the CarbonMessage interface. > > Considering these facts, I believe we should refactor CarbonMessage before > others starting using it in their implementations. Please let us know your > thoughts as well :) > > -- > Regards, > *Shafreen* > Software Engineer > WSO2 Inc > Mobile : 077-556-395-1 > -- *Asitha Nanayakkara* <http://asitha.github.io/> Senior Software Engineer WSO2, Inc. <http://wso2.com/> Mob: +94 77 853 0682 [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
