axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen" <>
Subject Re: Comments about the new UnknownContentBuilder (AXIS2-4153)
Date Thu, 18 Dec 2008 15:53:49 GMT
Moving this stuff to Axis2 is something I wanted to propose anyway.
The reason is that it also defines a couple of extension interfaces
that can be optionally implemented by message builders and formatters:

* MessageFormatterEx: Adds a method to get the content of the message
as a DataSource (useful for the mail transport).
* TextMessageBuilder: Defines methods to build a message from a or String (used to handle JMS TextMessages).
ApplicationXMLBuilder and SOAPBuilder should be enhanced to implement
* There should also be a TextMessageFormatter, but this is not yet implemented.

Questions are:

* While TextMessageBuilder and TextMessageFormatter should clearly
remain optional (i.e. they would only be implemented by builders and
formatters that deal with text content), MessageFormatterEx could also
be merged into MessageFormatter. The additional getDataSource method
can easily be implemented (message formatters are already required to
return byte[], so returning a DataSource is not difficult). However
this would break existing MessageFormatter implementations outside of
Axis2. What do you think?
* Is this in scope for Axis2 1.5?


On Thu, Dec 18, 2008 at 15:37, Deepal jayasinghe <> wrote:
> +1, I think that is where it belongs.
> Deepal
>> Can we please move the BinaryBuilder to axis2 with the rest of the
>> message builders?
>> Sanjiva.
>> Thilina Gunarathne wrote:
>>> Hi Andreas,
>>> I'm sorry, I missed this mail.. Saw it only now...
>>> I agree with you regarding the 1. But I guess the solution will need
>>> to address deferred building, which will make it bit complex...
>>> Something like implementing a pushbackInputStream which will directly
>>> give the bytes from the transport inputstream while buffering it to
>>> give it the next time...
>>> Regarding 2, I don't think we can call anything "the" right solution
>>> for this. Normally Axis2 uses OMDataSources to carry native data as
>>> long as it can, so that if an entity which knows how to process the
>>> native data can take advantage of it.. Also using the
>>> OMSourcedElement, clearly distinguish the usage of unknown content
>>> from other messages...
>>> Regarding the 3, my apologies once again... I was not aware of such a
>>> thing when I wrote the above. IMHO builder should live inside Axis2..
>>> I did this (and the mime support) as a solution to the issue raised
>>> in Synapse. Wonder why they did not simply use the impl you
>>> mentioned.... May be I'm missing something.. Let's see how we can
>>> combine these efforts...
>>> thanks,
>>> Thilina.
>>>     1. The class InputStreamDataSource (the one in
>>>     org.apache.axis2.builder.unknowncontent) violates the
>>>     javax.activation.DataSource contract which says for the
>>> getInputStream
>>>     method that "a new InputStream object must be returned each time
>>> this
>>>     method is called, and [that] the stream must be positioned at the
>>>     beginning of the data." The consequence will be that the message
>>>     produced by UnknownContentBuilder can only be read once. This is a
>>>     serious flaw.
>>>     2. The AXIOM tree produced by UnknownContentBuilder has only two
>>>     nodes: an OMElement and an OMText (with a DataHandler). Using an
>>>     OMSourcedElement/OMDataSource is not justified for this and would
>>>     introduce unnecessary complexity and overhead.
>>>     3. The code in UnknownContentBuilder to a large extend duplicates
>>> the
>>>     code in org.apache.axis2.format.BinaryBuilder (in
>>>     axis2-transport-base), which doesn't have problems 1 and 2.
>>>     Could you please make a proposal how to improve this?
>>>     Regards,
>>>     Andreas
>>> --
>>> Thilina Gunarathne  -
> --
> Thank you!

View raw message