Announcement Announcement Module
Collapse
No announcement yet.
Jabber/XMPP Support Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jabber/XMPP Support

    Hi all,

    In order to propose the jabber transport for Spring WebService, I started a XMPP / Jabber moduleto help to use of the API Smack with Spring.

    In the end, this unit is no longer used in my contribution to limit dependencies.
    I think to put this module on SourceForge, but I was wondering if this one did not belong here?

    The module is very small actually, the principal class is the XmppTemplate that allow to send or receive message.

    The module can not yet manage the chat or file transfer but it is is expected.

    If you want to take a look, you can find the source here :
    http://svn.hikage.be/svn/spring-xmpp/trunk/xmpp-core/

    user : readonly
    password : readonly

  • #2
    Nobody has comments on this project ? If it is not interessting, feel free to say it :-)

    Comment


    • #3
      Cast not really needed, i think ,,,

      Hi hikage,

      i don't know why nobody answer your question. But i have question for you. :-)
      In the sources in DefaultMessageListenerContainer i found this:

      Code:
          /**
           * Method that notify a listener correctly according to its type
           *
           * @param listener the listener to notify
           * @param packet   the arrival packet
           */
          protected void notifyListener(PacketListener listener, Packet packet) {
              if (listener instanceof PacketListener) {
                  if (LOGGER.isTraceEnabled()) LOGGER.trace("Notify a PacketListener");
                  ((PacketListener) listener).onPacket(packet, this.connection);
              }
      
          }
      You put an "PacketListener" as an parameter "listener". Why do you check with "instanceof" the type?
      It is an "PacketListener". And so the cast to "PacketListener" on "listener" is not needed too.
      Did i miss something. Is there a good reason for doing this? It will be a "one-liner".

      Maybe your extension is usefull for the spring community did you go the "right way"?
      There are some processes defined for every new extension.

      You can find further information here:

      http://www.springsource.org/extensions/lifecycle

      and here

      http://www.springsource.org/extensions/proposing

      Thanks in advance and good luck. :-)

      Jörg

      Comment


      • #4
        Hi,

        Thank you for the feedback !

        Regarding your question, the answer is simple. Initially, I introduced two interface:

        OneWayPacketListener - which notifies a Observer the arrival of new message without giving it the possibility to respond
        PacketListener - which provided the XMPP connection to allow a response.

        But I removed the OneWayPacketListener and I forgot to remove the check in the DefaultMessageListener.

        Maybe your extension is usefull for the spring community did you go the "right way"?
        There are some processes defined for every new extension.
        I've not yet followed the process, but I will do it soon.

        Originally posted by bellmann29 View Post
        Hi hikage,

        i don't know why nobody answer your question. But i have question for you. :-)
        In the sources in DefaultMessageListenerContainer i found this:

        Code:
            /**
             * Method that notify a listener correctly according to its type
             *
             * @param listener the listener to notify
             * @param packet   the arrival packet
             */
            protected void notifyListener(PacketListener listener, Packet packet) {
                if (listener instanceof PacketListener) {
                    if (LOGGER.isTraceEnabled()) LOGGER.trace("Notify a PacketListener");
                    ((PacketListener) listener).onPacket(packet, this.connection);
                }
        
            }
        You put an "PacketListener" as an parameter "listener". Why do you check with "instanceof" the type?
        It is an "PacketListener". And so the cast to "PacketListener" on "listener" is not needed too.
        Did i miss something. Is there a good reason for doing this? It will be a "one-liner".

        Maybe your extension is usefull for the spring community did you go the "right way"?
        There are some processes defined for every new extension.

        You can find further information here:

        http://www.springsource.org/extensions/lifecycle

        and here

        http://www.springsource.org/extensions/proposing

        Thanks in advance and good luck. :-)

        Jörg

        Comment


        • #5
          Hi hikage,

          I think that Jörg essentially answered the main questions but one thing I'd like to clarify is that every Spring Extension requires an project lead from the community that can dedicate some of their time to the project.

          It sounds like you may already be too busy to do this? If so, the main hurdle that I can see is finding a member of the community to continue your work as a Spring Extension. Once we have that individual in the frame we can then look to starting the proposal process.

          Best regards,
          Russ Miles
          Lead, Spring Extensions

          Comment


          • #6
            Definitely interested

            Hi hikage, just so you know there is interest, I love this! I downloaded it and got it working no problem (the package needs fixing a bit as it doesnt include the xsd in the jar and it does include the log4j.xml which is just annoying.)

            Comment


            • #7
              Thank you very much!
              After a few difficult months, I finally found a little time.
              I will improve this project very soon.

              Comment


              • #8
                XMPP Remoting ServiceExporter?

                what I would REALLY love is a simple XMPP spring remoting ServiceExporter to add to the hessian/burlap/http exporters already available. the smack library already has a good built in object serialization mechanism with its 'properties', so perhaps with the work done so far by hikage its not a big leap to build this too.

                Comment


                • #9
                  xmpp component

                  actually, even better would be support for xmpp components instead of simple clients which do not scale. perhaps I'll find some time to work on that myself.

                  Comment


                  • #10
                    I would actually propose that XMPP support be done as Spring Integration Channel Adapters. In fact, we have some stuff in the sandbox already:
                    https://src.springframework.org/svn/...egration.xmpp/

                    It would be interesting to see how the implementations relate. One reason that we have not yet moved this out of the sandbox is that the Smack API does not apparently have good support for configurable thread-management (like Spring's TaskExecutor abstraction).

                    The reason it seems that Spring Integration is the right place for this is evident from the use-cases already mentioned above: use with Spring Web Services, provide a service exporter, or implement a template. Since Spring Integration provides a simple MessageChannel abstraction, it should be able to fit all of those needs with a simple pair of inbound/outbound Channel Adapters.

                    Comment


                    • #11
                      The smack library is only really useful for building client apps, as xmpp rosters just dont scale well (more than a few dozen folk in your roster and you're in trouble), but whatever the solution ends up being it should be implemented as both a client and an xmpp component. For me, the template, and ServiceExporter approaches seem more userful, less intrusive, and require a lot less code to use (a ServiceExporter would require no code at all), the springintegration testcases seem very verbose and also seems to require use of a very loose .setHeader("xmpp.to")... style interface, please correct me if I'm wrong.
                      As an aside, I'd also like to see convenience support for servlet style request/session state parameters added to the connection as it can really ease conversation tracking and integration with workflow engines. The smack library has the Chat convenience class which tries to provide a conversation tracking facility, but nothing at all exists in the whack lib.

                      Comment


                      • #12
                        Most likely, even if implemented within Spring Integration (or SI Extensions), we would provide a multi-layered API. At the core, it would provide something like XmppTemplate.

                        Comment


                        • #13
                          @hikage, just wondering if you've done anything more with this? I'm looking at your code and realising that your defaultListener does not allow for filters to be added (and indeed thwarts the smack filtered Listener model by always sending every packet to every listener). I'll create a new one for myself, but wondering if perhaps its already been done?

                          Comment


                          • #14
                            Hi Jason,

                            I've some private problem that avoid me to work on this project.

                            If you are interested, I can put the sources on Google Code in order to share my work, to allow you to improve it ?

                            Comment

                            Working...
                            X