Hi Andreas, While focusing on what you've mentioned lately, which I'm working on right now, I'd like to ask a few questions. Regarding the question on the ideas that I have on the customized XMLStreamReader: as of now, I can't clearly express any since I've not finished implementing a prototype of this. I'm looking forward to have something decent in a few days, and post it for review. And, as you say, the first option is clearly ruled out. The questions I'd like to ask are:
1. The MapMessageInputStream is required in LogAspect.java, [1], [2]. The beforeSend() involves a use of an output stream in which the MapMessageInputStream is used. Would it better to remove MapMessageInputStream.java and copy the logic to LogAspect's beforeSend() method? or would it be better to have it? 2. I have defined a constant DEFAULT_MAP_WRAPPER in BaseConstants, [3]. This is to identify the default tag that wraps a map message's XML representation. Now, this is JMS Transport specific. But, for the sake of the testkit that is used to test all transports, defining this constant in JMSConstants will require either adding a JMS Transport dependancy, or redefining the way in which JMS Tests are organized. Which is the best route to take? The current, or moving this to JMSConstants? [1] http://svn.apache.org/repos/asf/webservices/commons/trunk/modules/transport/modules/tests/src/test/java/org/apache/axis2/transport/jms/LogAspect.java [2] http://svn.apache.org/repos/asf/webservices/commons/trunk/scratch/senaka/sci-flex/transport/modules/tests/src/test/java/org/apache/axis2/transport/jms/LogAspect.java [3] http://svn.apache.org/repos/asf/webservices/commons/trunk/scratch/senaka/sci-flex/transport/modules/base/src/main/java/org/apache/axis2/transport/base/BaseConstants.java Regards, Senaka On Fri, Nov 7, 2008 at 2:06 AM, Andreas Veithen <[EMAIL PROTECTED]>wrote: > 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 > > >
