On Mon, Nov 10, 2008 at 12:32 AM, Andreas Veithen <[EMAIL PROTECTED] > wrote:
> On Fri, Nov 7, 2008 at 19:20, Senaka Fernando <[EMAIL PROTECTED]> wrote: > > 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? > > The LogAspect is only used to dump the message for later inspection. > It's invocation is not even required for successful execution of the > tests. For MapMessages I would simply iterate over the map entries and > output them as key=value pairs. Will have a look into that, and get rid of the MapMessageInputStream. Anyway, this is not a critical issue I believe. > 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? > > > The problem is actually that TransportTestSuiteBuilder is too tightly > coupled to the available message encoders/decoders and that the > adapters are selected at compile time. I have some plans to refactor > this part of the testkit so that the right encoders/decoders are > chosen at runtime. This would then allow to easily add new message > types. In your case this would mean that you could place the whole map > related code into the module/package for the JMS tests without the > necessity to change the testkit itself. Great. For the moment, I can live with the current implementation. Regards, Senaka > > > Regards, > > Andreas >
