Asankha,

I think an October timeframe for a release fits within the constraints of
the project that we're working on. I'd be happy to test an earlier release
to verify that it addresses the issue we have at the moment.

In our scenario, an upstream application will be placing messages on a JMS
queue that will be relayed through a Synapse proxy using a HTTP transport to
a downstream web service. What I need to ensure is that the correlation id
in the JMS header of the response returned by Synapse contains a value that
can be used by the upstream application to match it to the original message
and that the response is placed back on the queue in the reply-to property.

If I understand correctly, Synapse will return the original message id in
the correlation id of the header. Let me know if I've got this wrong.

Many thanks.

Ian.

On 8/23/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
>
> Hi Ian
> > I'm happy to wait now that I know it'll come along in the 1.0.1 release.
> So
> > that I can manage expectations is there a timeframe when this is likely
> to
> > appear?
> >
> We have had to make quite a few changes already (i.e. changing the Axis2
> dependency to version 1.3 from 1.2, support WAR deployment, JMS and
> VFS/File transport enhancements, etc) Thus we may decide to make it a
> 1.1 release probably targeted to end of October - to ensure a good round
> of testing as well. We will be releasing release candidates earlier and
> you could give us feedback to make sure the release would address your
> concerns correctly. Will this work for you?
> > One other question that's related. If a reply destination is specified,
> is
> > the correlation id something that needs to be set or is this managed by
> the
> > endpoint?
> >
> Do you want to provide a custom correlation ID to the request message?
> If you want this could be done.. but usually this will not be a problem
> as the JMS service implementation would use whatever message ID of the
> incoming message as the correlation ID for the response message that it
> will write to the reply destination.
>
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to