Camel
  1. Camel
  2. CAMEL-3195

Allow camel to send custom xmpp Presence/PubSub packet to a xmpp endpoint

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Future
    • Component/s: camel-xmpp
    • Labels:
      None

      Description

      Claus Ibsen suggested that I should create a ticket for this new feature (http://stackoverflow.com/questions/3645159/can-apache-camel-send-a-xmpp-presence-pubsub-packet-to-an-xmpp-endpoint)

      I need to receive an update published to a JMS topic, convert it to a XMPP packet (Presence packet or PubSub packet) and route it to an XMPP endpoint.

      I am using ActiveMQ as JMS provider and Apache camel as routing engine. given below is my route in Camel (to make things simple I read from system.in instead of a jms topic):

       
           from("stream:in?promptMessage=Enter something:").process( new Processor(){
              public void process(Exchange exchange) throws Exception {
                      System.out.println("sending presence with message: " + exchange.getIn().getBody().toString());
                      Presence p = new Presence(Type.available, exchange.getIn().getBody().toString(), 5, Mode.chat);
                      exchange.getIn().setBody(p);
                  }
                  }).to("xmpp:user1@banl080161?password=pass1");
      

      Idea is that user1@banl080161 should be able to send a custome presence packet having status as given from system.in. I am reading from system.in, making a presence packet, setting this packet in the exchange body and send this presence on behalf of user1@banl080161.

      Problem: nothing gets sent to XMPP server, I use PSI to see packets coming from user1@banl080161, user1@banl080161 comes online for sure but no custom presence message is received.

      1. pubsub-xmpp.patch
        18 kB
        Hugo Freire
      2. Camel-xmpp-pubsub-presence-v3.patch
        23 kB
        Chandra Prakash Joshi
      3. camel-xmpp.patch
        25 kB
        Preben Asmussen

        Activity

        Hide
        Donald Whytock added a comment -

        There are limitations in general to the existing XMPP endpoint. It isn't triggered by presence or pubsub packets on input either. Nor does it set headers on input, so one can't use a single endpoint for receiving from multiple sources. In addition, XMPP recognizes an HTML element in the message body, but the endpoint only supplies the text element.

        I'd like to suggest the following:

        New endpoint parameters:
        presence – boolean – Accept presence packets on input, default is false
        pubsub – boolean – Accept pubsub packets on input, default is false
        doc – boolean – Set a doc header on the IN message containing a Document form of the incoming packet; default is true if presence or pubsub are true, otherwise false

        New input headers:
        from
        type
        doc – Document containing the inbound packet, if presence, pubsub or doc is set; message body still set with text element, if any

        New output headers:
        to
        doc – Document containing the outbound packet; overrides the message, ignores the message body

        Show
        Donald Whytock added a comment - There are limitations in general to the existing XMPP endpoint. It isn't triggered by presence or pubsub packets on input either. Nor does it set headers on input, so one can't use a single endpoint for receiving from multiple sources. In addition, XMPP recognizes an HTML element in the message body, but the endpoint only supplies the text element. I'd like to suggest the following: New endpoint parameters: presence – boolean – Accept presence packets on input, default is false pubsub – boolean – Accept pubsub packets on input, default is false doc – boolean – Set a doc header on the IN message containing a Document form of the incoming packet; default is true if presence or pubsub are true, otherwise false New input headers: from type doc – Document containing the inbound packet, if presence, pubsub or doc is set; message body still set with text element, if any New output headers: to doc – Document containing the outbound packet; overrides the message, ignores the message body
        Hide
        Chandra Prakash Joshi added a comment - - edited

        Donald,

        Thanks for the suggestion. I have attached a patch that serves these requirments:

        • The component gets triggerd by Presence/PubSub on input
        • Set a doc header in IN message When doc bool is set to true on endpoint (and it gets set when either pubsub or presence is true)

        with these changes the below route receives Chat, Presence and PubSub Packets:

         
        from("xmpp:user2@banl080161/user1@banl080161?password=pass2&pubsub=true&presence=true").process( new Processor(){
            public void process(Exchange exchange) throws Exception {
                Packet pk = (Packet)exchange.getIn().getHeader("doc");
                exchange.getIn().setBody(pk.toXML());
            }
        }).to("stream:out");
        

        A pubsub and presence packet can be send like below. camel-xmpp does't take responsibility of creating these packets (we will need too many enpoint parameters for that). Please do let me know if you have a better way to do this.

         
        //Publish to a topic
        from("stream:in?promptMessage=Enter something:").process( new Processor(){
            public void process(Exchange exchange) throws Exception {
                String xmlpayLoad = "<entry xmlns='jabber:x:data'><data>" + exchange.getIn().getBody().toString() + "</data></entry>";
                String NAMESPACE = "http://jabber.org/protocol/pubsub";
                PayloadItem<SimplePayload> item = new PayloadItem<SimplePayload>("itemid1", new SimplePayload("data", NAMESPACE, xmlpayLoad));
                PubSub p = new PubSub();
                p.setTo("pubsub.banl080161");
                p.setType(IQ.Type.SET);
                p.addExtension(new PublishItem<PayloadItem<?>>("topic1", item));
                                
                String str = p.toXML();
                System.out.println("Publishing to node 'topic1' withp this data: " + str);
                exchange.getIn().setBody(p);
            }
            })
        .to("xmpp:user1@banl080161?password=pass1&pubsub=true");
        
         
        //send presence
        from("stream:in?promptMessage=Enter something:").process( new Processor(){
            public void process(Exchange exchange) throws Exception {
                System.out.println("sending presence with message: " + exchange.getIn().getBody().toString());
                Presence p = new Presence(Type.available, exchange.getIn().getBody().toString(), 5, Mode.chat);
                exchange.getIn().setBody(p);
            }
            })
        .to("xmpp:user1@banl080161?password=pass1&presence=true");
        
        Show
        Chandra Prakash Joshi added a comment - - edited Donald, Thanks for the suggestion. I have attached a patch that serves these requirments: The component gets triggerd by Presence/PubSub on input Set a doc header in IN message When doc bool is set to true on endpoint (and it gets set when either pubsub or presence is true) with these changes the below route receives Chat, Presence and PubSub Packets: from( "xmpp:user2@banl080161/user1@banl080161?password=pass2&pubsub= true &presence= true " ).process( new Processor(){ public void process(Exchange exchange) throws Exception { Packet pk = (Packet)exchange.getIn().getHeader( "doc" ); exchange.getIn().setBody(pk.toXML()); } }).to( "stream:out" ); A pubsub and presence packet can be send like below. camel-xmpp does't take responsibility of creating these packets (we will need too many enpoint parameters for that). Please do let me know if you have a better way to do this. //Publish to a topic from( "stream:in?promptMessage=Enter something:" ).process( new Processor(){ public void process(Exchange exchange) throws Exception { String xmlpayLoad = "<entry xmlns='jabber:x:data'><data>" + exchange.getIn().getBody().toString() + "</data></entry>" ; String NAMESPACE = "http: //jabber.org/protocol/pubsub" ; PayloadItem<SimplePayload> item = new PayloadItem<SimplePayload>( "itemid1" , new SimplePayload( "data" , NAMESPACE, xmlpayLoad)); PubSub p = new PubSub(); p.setTo( "pubsub.banl080161" ); p.setType(IQ.Type.SET); p.addExtension( new PublishItem<PayloadItem<?>>( "topic1" , item)); String str = p.toXML(); System .out.println( "Publishing to node 'topic1' withp this data: " + str); exchange.getIn().setBody(p); } }) .to( "xmpp:user1@banl080161?password=pass1&pubsub= true " ); //send presence from( "stream:in?promptMessage=Enter something:" ).process( new Processor(){ public void process(Exchange exchange) throws Exception { System .out.println( "sending presence with message: " + exchange.getIn().getBody().toString()); Presence p = new Presence(Type.available, exchange.getIn().getBody().toString(), 5, Mode.chat); exchange.getIn().setBody(p); } }) .to( "xmpp:user1@banl080161?password=pass1&presence= true " );
        Hide
        Chandra Prakash Joshi added a comment - - edited

        Enhanced camel-xmpp to send/receive pubsub/presence packets.

        Show
        Chandra Prakash Joshi added a comment - - edited Enhanced camel-xmpp to send/receive pubsub/presence packets.
        Hide
        Chandra Prakash Joshi added a comment -
        • All the existing camel tests pass with this patch.
        • Added some new JUnit tests. more to follow.
        • Room based (MUC) and PubSub might not work together on same endpoint.
        Show
        Chandra Prakash Joshi added a comment - All the existing camel tests pass with this patch. Added some new JUnit tests. more to follow. Room based (MUC) and PubSub might not work together on same endpoint.
        Hide
        Claus Ibsen added a comment -

        Chandra the camel-xmpp has been improved since your patch.

        Do you mind taking a look again and provide a new patch against trunk, or the Camel 2.7 release when its out?

        Show
        Claus Ibsen added a comment - Chandra the camel-xmpp has been improved since your patch. Do you mind taking a look again and provide a new patch against trunk, or the Camel 2.7 release when its out?
        Hide
        Chandra Prakash Joshi added a comment - - edited

        Sure Claus, will provide the patch against 2.7 release.

        Show
        Chandra Prakash Joshi added a comment - - edited Sure Claus, will provide the patch against 2.7 release.
        Hide
        Chandra Prakash Joshi added a comment -

        Below is one discussion that I had with Don Whytock about the design and need for this feature (The conversation is sorted in ascending order to provide full context)


        Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Sat, Oct 23, 2010 at 7:42 PM
        To: dwhytock at gmail.com
        Hi Donald,

        I have created a patch for CAMEL-3195(new feature). Can you have a look at it? Your comments/Suggestions are welcome.

        https://issues.apache.org/activemq/browse/CAMEL-3195

        Thanks: _Josh


        Donald Whytock <dwhytock at gmail.com> Mon, Oct 25, 2010 at 10:08 PM
        To: Chandra Prakash Joshi <chandraprakashjoshi at gmail.com>
        Hi Josh,

        I saw your comment on the JIRA, and it looked like exactly what I'd
        hoped for. I'm a little snowed under at the moment, but I'll probably
        be trying it out this week.

        I haven't looked at the component code in detail...Does the XMPP
        connection amount to a singleton, with endpoints actually acting as
        filters? As in, if I were to define one endpoint to listen for
        presence packets and another to accept incoming chat messages, is that
        a single socket connection?

        Don


        chandraprakashjoshi at gmail.com <chandraprakashjoshi at gmail.com> Tue, Oct 26, 2010 at 11:50 AM
        To: Donald Whytock <dwhytock at gmail.com>
        Don,

        Thanks for the response and the willingness for trying out the patch. Answer to your question below:

        "Does the XMPP connection amount to a singleton, with endpoints actually acting as filters?"

        In code, every "XmppEndpoint" contains a "XMPPConnection" (XmppEndpoint class has XMPPConnection as private variable, it's not singleton), so every endpoint will open a difference socket connection to XMPP server.

        _Josh


        Donald Whytock <dwhytock at gmail.com> Tue, Oct 26, 2010 at 8:08 PM
        To: chandraprakashjoshi at gmail.com
        Is that desirable? I'm sure it's easier, but would it take more
        memory and processing to handle two sockets rather than one? Far as I
        know, an XMPP server will send all packets meant for a user to all
        connections the user has open, regardless of what machine they're on.
        So if two sockets are open, one for messages and one for presence
        packets, each socket will get all messages and presence packets. So
        the filtering has to happen on each socket. If there was a single
        socket, the same filtering could be done on a single message rather
        than multiple copies.

        Again, though, I'm speaking out of ignorance regarding the code. Is
        it a lot more work to do sockets as singletons under Camel?

        Don


        Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Wed, Oct 27, 2010 at 11:46 AM
        To: Donald Whytock <dwhytock at gmail.com>
        1. "Is that desirable?"

        I think it is. I am relying on that design to solve a problem that I recently encountered in my project.
        In my project we are supposed to read messages from a JMS queue and publish them to ejabberd XMPP server (we will transform the JMS message to PubSub packet).

        The issue we are facing is that a pubsub packet delivery takes somewhere between 250-300 milliseconds (tested it with smack and tsung), so in a serial manner we can consume 3-4 message/sec from JMS Provider, but our JMS producer will be generating the load of ~50 JMS messages/second (may become high next year).

        The way we solved it right now is to consume messages in parallel, we have 14 threads logging in to XMPP server, getting messages from a JMS queue and publishing to XMPP topics. and are able to consume ~50 messages/sec (The xmpp subscribers receive 50 publishes/sec).

        Once this enhancement (CAMEL-3195) is available in camel, we plan to have 14 routes, each reading from:JMS queue endpoint, convert the message to pubsub packet, publish to:xmpp endpoint.

        2. Is it a lot more work to do sockets as singletons under Camel?
        I suspect it will take long time to make sure we don't break any existing xmpp endpoint use-cases out there in the field (I mean there might be people who rely on the behavior of "every endpoint is a new connection"). Also, we need to change the camel-xmpp design to support "connection per user/resource" rather then "connection per endpoint". If not lot, it's fair amount of work.

        _Josh


        Donald Whytock <dwhytock at gmail.com> Wed, Oct 27, 2010 at 8:21 PM
        To: Chandra Prakash Joshi <chandraprakashjoshi at gmail.com>
        Interesting. So while it might be more efficient to consume XMPP on
        one thread and delegate after consuming, it's more efficient to
        produce XMPP on multiple threads. And that determination can be made
        outside of the endpoint logic.

        Simple looks good.

        Don

        On Wed, Oct 27, 2010 at 2:16 AM, Chandra Prakash Joshi

        Show
        Chandra Prakash Joshi added a comment - Below is one discussion that I had with Don Whytock about the design and need for this feature (The conversation is sorted in ascending order to provide full context) Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Sat, Oct 23, 2010 at 7:42 PM To: dwhytock at gmail.com Hi Donald, I have created a patch for CAMEL-3195 (new feature). Can you have a look at it? Your comments/Suggestions are welcome. https://issues.apache.org/activemq/browse/CAMEL-3195 Thanks: _Josh Donald Whytock <dwhytock at gmail.com> Mon, Oct 25, 2010 at 10:08 PM To: Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Hi Josh, I saw your comment on the JIRA, and it looked like exactly what I'd hoped for. I'm a little snowed under at the moment, but I'll probably be trying it out this week. I haven't looked at the component code in detail...Does the XMPP connection amount to a singleton, with endpoints actually acting as filters? As in, if I were to define one endpoint to listen for presence packets and another to accept incoming chat messages, is that a single socket connection? Don chandraprakashjoshi at gmail.com <chandraprakashjoshi at gmail.com> Tue, Oct 26, 2010 at 11:50 AM To: Donald Whytock <dwhytock at gmail.com> Don, Thanks for the response and the willingness for trying out the patch. Answer to your question below: "Does the XMPP connection amount to a singleton, with endpoints actually acting as filters?" In code, every "XmppEndpoint" contains a "XMPPConnection" (XmppEndpoint class has XMPPConnection as private variable, it's not singleton), so every endpoint will open a difference socket connection to XMPP server. _Josh Donald Whytock <dwhytock at gmail.com> Tue, Oct 26, 2010 at 8:08 PM To: chandraprakashjoshi at gmail.com Is that desirable? I'm sure it's easier, but would it take more memory and processing to handle two sockets rather than one? Far as I know, an XMPP server will send all packets meant for a user to all connections the user has open, regardless of what machine they're on. So if two sockets are open, one for messages and one for presence packets, each socket will get all messages and presence packets. So the filtering has to happen on each socket. If there was a single socket, the same filtering could be done on a single message rather than multiple copies. Again, though, I'm speaking out of ignorance regarding the code. Is it a lot more work to do sockets as singletons under Camel? Don Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Wed, Oct 27, 2010 at 11:46 AM To: Donald Whytock <dwhytock at gmail.com> 1. "Is that desirable?" I think it is. I am relying on that design to solve a problem that I recently encountered in my project. In my project we are supposed to read messages from a JMS queue and publish them to ejabberd XMPP server (we will transform the JMS message to PubSub packet). The issue we are facing is that a pubsub packet delivery takes somewhere between 250-300 milliseconds (tested it with smack and tsung), so in a serial manner we can consume 3-4 message/sec from JMS Provider, but our JMS producer will be generating the load of ~50 JMS messages/second (may become high next year). The way we solved it right now is to consume messages in parallel, we have 14 threads logging in to XMPP server, getting messages from a JMS queue and publishing to XMPP topics. and are able to consume ~50 messages/sec (The xmpp subscribers receive 50 publishes/sec). Once this enhancement ( CAMEL-3195 ) is available in camel, we plan to have 14 routes, each reading from:JMS queue endpoint, convert the message to pubsub packet, publish to:xmpp endpoint. 2. Is it a lot more work to do sockets as singletons under Camel? I suspect it will take long time to make sure we don't break any existing xmpp endpoint use-cases out there in the field (I mean there might be people who rely on the behavior of "every endpoint is a new connection"). Also, we need to change the camel-xmpp design to support "connection per user/resource" rather then "connection per endpoint". If not lot, it's fair amount of work. _Josh Donald Whytock <dwhytock at gmail.com> Wed, Oct 27, 2010 at 8:21 PM To: Chandra Prakash Joshi <chandraprakashjoshi at gmail.com> Interesting. So while it might be more efficient to consume XMPP on one thread and delegate after consuming, it's more efficient to produce XMPP on multiple threads. And that determination can be made outside of the endpoint logic. Simple looks good. Don On Wed, Oct 27, 2010 at 2:16 AM, Chandra Prakash Joshi
        Hide
        Chandra Prakash Joshi added a comment -
        • Patch against 2.7 branch
        • Two headers (XmppConstants.SUBJECT, XmppConstants.THREAD_ID) that are set on inbound message when XMPP packet type is Message (Chat/MUC) will not be present in the message if received/send packet is of type Presence/PubSub, because PubSub/Presence packets don't have a subject or threadid.
        Show
        Chandra Prakash Joshi added a comment - Patch against 2.7 branch Two headers (XmppConstants.SUBJECT, XmppConstants.THREAD_ID) that are set on inbound message when XMPP packet type is Message (Chat/MUC) will not be present in the message if received/send packet is of type Presence/PubSub, because PubSub/Presence packets don't have a subject or threadid.
        Hide
        Claus Ibsen added a comment -

        Chandra.

        Can you check in your pom.xml file where this class exists?

        import org.jivesoftware.smackx.pubsub.packet.PubSub;

        eg I need the maven JAR for smackx

        Show
        Claus Ibsen added a comment - Chandra. Can you check in your pom.xml file where this class exists? import org.jivesoftware.smackx.pubsub.packet.PubSub; eg I need the maven JAR for smackx
        Hide
        Claus Ibsen added a comment -

        Chandra. What version of Smack are you using?

        Show
        Claus Ibsen added a comment - Chandra. What version of Smack are you using?
        Hide
        Preben Asmussen added a comment -

        Igniterealtime has just released a new version of their Smack library 3.2.0 with support for pubsub. Lib is not accasable on global maven repo, but can be downloaded.
        I have started to extended the existing xmpp component to support the pubsub with a new XmppPubSubProducer and XmppPubSubConsumer using the new library.

        Any interest in a patch ?

        Show
        Preben Asmussen added a comment - Igniterealtime has just released a new version of their Smack library 3.2.0 with support for pubsub. Lib is not accasable on global maven repo, but can be downloaded. I have started to extended the existing xmpp component to support the pubsub with a new XmppPubSubProducer and XmppPubSubConsumer using the new library. Any interest in a patch ?
        Hide
        Chandra Prakash Joshi added a comment -

        Claus,
        I picked the smackx 3.1.0 from the IgniteRealTime nightly builds (http://www.igniterealtime.org/builds/smack/dailybuilds/smack_2010-09-04.zip). I had to do this because of an XMPP pubsub bug in original 3.1.0 jar (I will recollect the exact bug and let you know by tomorrow).

        BTW, they have released 3.2.0 now

        _Joshi

        Show
        Chandra Prakash Joshi added a comment - Claus, I picked the smackx 3.1.0 from the IgniteRealTime nightly builds ( http://www.igniterealtime.org/builds/smack/dailybuilds/smack_2010-09-04.zip ). I had to do this because of an XMPP pubsub bug in original 3.1.0 jar (I will recollect the exact bug and let you know by tomorrow). BTW, they have released 3.2.0 now _Joshi
        Hide
        Preben Asmussen added a comment -

        I have created a patch to the camel-xmpp component with a new XmppPubSubProducer and a XmppPubSubConsumer endpoint.
        Besides that there are 2 new properties
        node- and persistItems on the XmppEndpoint.
        node is pubsub node where to publish or listen for events. The persistItems is used when resolving the pubsub node. If it doesn't exist it will be created (true or false) to persistens.
        Example :
        xmpp://draugr.de:5222/cameldemo@draugr.de?user=cameldemo&password=cameldemo&serviceName=draugr.de&node=testnode2

        Consumer can subscribe to node with anonymous login if supported by the xmpp server. Tested on Ejabberd.
        Example:
        xmpp://localhost:5222/anonymous1@localhost?serviceName=localhost&node=unittestnode24

        Requires Smackx 3.2.0 wich has been released.

        There are 3 testcases as examples.
        Should be able to run even if they require online access - account is set up on jabber server. The anonymous testcase will not run since the jabber server doesn't support anonymous login.

        I'm not quite sure how it fits in with this ticket, but anyway i'm attaching a patch so you can have a look.

        /preben

        Show
        Preben Asmussen added a comment - I have created a patch to the camel-xmpp component with a new XmppPubSubProducer and a XmppPubSubConsumer endpoint. Besides that there are 2 new properties node- and persistItems on the XmppEndpoint. node is pubsub node where to publish or listen for events. The persistItems is used when resolving the pubsub node. If it doesn't exist it will be created (true or false) to persistens. Example : xmpp://draugr.de:5222/cameldemo@draugr.de?user=cameldemo&password=cameldemo&serviceName=draugr.de&node=testnode2 Consumer can subscribe to node with anonymous login if supported by the xmpp server. Tested on Ejabberd. Example: xmpp://localhost:5222/anonymous1@localhost?serviceName=localhost&node=unittestnode24 Requires Smackx 3.2.0 wich has been released. There are 3 testcases as examples. Should be able to run even if they require online access - account is set up on jabber server. The anonymous testcase will not run since the jabber server doesn't support anonymous login. I'm not quite sure how it fits in with this ticket, but anyway i'm attaching a patch so you can have a look. /preben
        Hide
        Preben Asmussen added a comment -

        xmpp pubsub patch

        Show
        Preben Asmussen added a comment - xmpp pubsub patch
        Hide
        Chandra Prakash Joshi added a comment -

        @Preben
        A pubsub node based route (that produces for and consumes from "one pubsub node") might be helpful but it poses some problems for below scenario

        • "pubsub node name" might not be available at the time of creating the route, e.g. A JMS-XMPP route (acts as a bridge between JMS & XMPP) receives message from JMS queue, opens the message and then comes to know the pubsub node to which the message should be published.
        Show
        Chandra Prakash Joshi added a comment - @Preben A pubsub node based route (that produces for and consumes from "one pubsub node") might be helpful but it poses some problems for below scenario "pubsub node name" might not be available at the time of creating the route, e.g. A JMS-XMPP route (acts as a bridge between JMS & XMPP) receives message from JMS queue, opens the message and then comes to know the pubsub node to which the message should be published.
        Hide
        Preben Asmussen added a comment -

        @Joshi yes - thats an scenario that isn't coveret, but wouldn't it be hard for clients to subscribe to events, if the nodes are dynamicly created ? How will clients be able to subscribe if they dont know what topic to subscribe to.

        Show
        Preben Asmussen added a comment - @Joshi yes - thats an scenario that isn't coveret, but wouldn't it be hard for clients to subscribe to events, if the nodes are dynamicly created ? How will clients be able to subscribe if they dont know what topic to subscribe to.
        Hide
        Chandra Prakash Joshi added a comment -

        @Preben
        I didn't mean that nodes need to be created dynamically. It's just that the publisher(camel route in this case) doesn't know which node to publish to until he receives a message from JMS queue (this message contains a header where pubsub node id/name is defined).

        If I understand your soultion correctly, one camel route will publish updates only to pubsub node defined in "node" property (e.g. "node=testnode2"). Whereas the situation that I described needs one route that can publish to multiple pubsub nodes

        Show
        Chandra Prakash Joshi added a comment - @Preben I didn't mean that nodes need to be created dynamically. It's just that the publisher(camel route in this case) doesn't know which node to publish to until he receives a message from JMS queue (this message contains a header where pubsub node id/name is defined). If I understand your soultion correctly, one camel route will publish updates only to pubsub node defined in "node" property (e.g. "node=testnode2"). Whereas the situation that I described needs one route that can publish to multiple pubsub nodes
        Hide
        Preben Asmussen added a comment -

        @Joshi
        Ok - see your point where you need to publish to nodes depending on the contend of a message. Maybe I could make the XmppPubSubProducer dynamic and allow to publish to a given node depending on a header value or something like that.

        Show
        Preben Asmussen added a comment - @Joshi Ok - see your point where you need to publish to nodes depending on the contend of a message. Maybe I could make the XmppPubSubProducer dynamic and allow to publish to a given node depending on a header value or something like that.
        Hide
        Chandra Prakash Joshi added a comment -

        @Claus
        As you have already figured, the maven downloaded smackx.jar doesn't support pubsub/presence. I will test camel-xmpp with smack 3.2.0 and let you know.

        Show
        Chandra Prakash Joshi added a comment - @Claus As you have already figured, the maven downloaded smackx.jar doesn't support pubsub/presence. I will test camel-xmpp with smack 3.2.0 and let you know.
        Hide
        Claus Ibsen added a comment -

        Any update on this?

        Show
        Claus Ibsen added a comment - Any update on this?
        Hide
        Bauras added a comment -

        Has anyone used the patch for version 2.8.0? Is it possible to share please?

        Show
        Bauras added a comment - Has anyone used the patch for version 2.8.0? Is it possible to share please?
        Hide
        Claus Ibsen added a comment -

        What is up and down on this ticket now?

        Show
        Claus Ibsen added a comment - What is up and down on this ticket now?
        Hide
        Hugo Freire added a comment -

        I have created a pull request https://github.com/apache/camel/pull/93 with only PubSub capabilities. I will use it in producction in the next months.

        Show
        Hugo Freire added a comment - I have created a pull request https://github.com/apache/camel/pull/93 with only PubSub capabilities. I will use it in producction in the next months.
        Hide
        Hugo Freire added a comment -

        This is the patch with only pubsub if someone is interested

        Show
        Hugo Freire added a comment - This is the patch with only pubsub if someone is interested

          People

          • Assignee:
            Unassigned
            Reporter:
            Chandra Prakash Joshi
          • Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:

              Development