You may need to dig into some code. Are you talking about the CorrelationId?
If so, it's basically:
If the request context has a JMSMessageHeadersType object on it that has a
correlation ID on it, that is used. Thus, you can control it on a per invoke
basis.
Beyond that, it's basically:
if (!jmsConfig.isSetConduitSelectorPrefix()
&& (!jmsConfig.isSetUseConduitIdSelector()
|| !jmsConfig.isUseConduitIdSelector())) {
messageIdPattern = true;
} else {
if (jmsConfig.isUseConduitIdSelector()) {
correlationId = JMSUtils.createCorrelationId(jmsConfig
.getConduitSelectorPrefix()
+ conduitId,
messageCount
.incrementAndGet());
} else {
correlationId = JMSUtils.createCorrelationId(jmsConfig
.getConduitSelectorPrefix(),
messageCount.incrementAndGet());
}
}
If the messageIdPattern is true, it ends up just being the result of
jmsMessage.getJMSMessageID();
Not sure if that helps at all.
Dan
On Fri December 11 2009 1:32:14 pm James Carr wrote:
> Sorry, accidentally sent while typing. My question is:
>
> How are clientIDs assigned when you leave the parameter out when you
> set up a conduit?
>
> Thansks,
> James
>
> On Fri, Dec 11, 2009 at 12:31 PM, James Carr <[email protected]> wrote:
> > Maybe I phrased my question wrong.. .so let me try again. :)
> >
> > How are clientIDs assigned to subscribers? I noticed you're not req
> >
> > On Tue, Dec 8, 2009 at 9:36 PM, James Carr <[email protected]> wrote:
> >> Hi All,
> >>
> >> I have been using CXF to implement SOAP over JMS (mostly configured
> >> through
> >> http://cwiki.apache.org/CXF20DOC/using-the-jmsconfigfeature.html) and
> >> had great success, however I have a setup where the application is
> >> running on a cluster on different nodes, and I publishing to a JMS topic
> >> to replicate some specific information across all the nodes. Is there a
> >> way to set it up so that the implementation classes (which are the
> >> subscribers) have uniquely generated clientIDs so they get invoked on
> >> each node when I publish to a topic by call the client proxy?
> >>
> >>
> >> Thanks,
> >> James
>
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
