To summarize, I see two requirements emerge here: 1. If the message is received by a Map(Message)-aware receiver, but not accessed through AXIOM, the AXIOM tree should never be built. 2. The JMS transport should support a representation of the MapMessage as an XML infoset. This transformation should be triggered only on demand and should have minimal overhead.
This indeed rules out the option 1 I presented in the other thread, leaving us with the custom XMLStreamReader option. You said that you would perhaps use it in a slightly modified way. What idea do you have in mind? Andreas On Tue, Nov 4, 2008 at 04:36, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi Andreas, > > On Tue, Nov 4, 2008 at 4:12 AM, Andreas Veithen > <[EMAIL PROTECTED]>wrote: > >> Hi Senaka, >> >> Some quick comments: >> * I sent some comments in the other thread >> (http://markmail.org/message/vcnfattmwvt4jd7i), but I didn't see an >> answer yet. Maybe you missed the post? I think we should first >> concentrate on that part of the code. > > > Yes, I read that mail, but actually forgot to drop in a reply. Well, there > is a necessity to keep the content accessible as a Map, in order to make the > process of manipulating it more efficient. An XML representation is an > optional thing, which would fit in IF NEEDED. Therefore, I believe that > option 1, is not quite fitting. But, I still am doing some research on > option 2, perhaps to use it in a slightly modified way. The XML > representation would be extracted on-demand (or if the content came in as > XML, the Map representation would be extracted on-demand -- this is an > optional thing, and is still a thought). > >> >> * MapMessageInputStream is no longer used; is that correct? If yes, >> please remove it. > > > It is still used in LogAspect (JMS - Tests), but nowhere else, as I last > observed it, will try to get rid of it. > >> >> * Can you try to reduce the amount of duplicate code related to >> MapMessages in JMSSender? That would make it more readable. > > > Yes, will do. The most recent commit, just was an intermediate fix rather, > that would adopt the approach you took in place of what has been there. > >> >> >> Thanks, > > Senaka >
