Jabber/XMPP Support

[hikage]

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

[hikage]

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

[bellmann29]

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:

    /**
     * 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

[hikage]

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.

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:

    /**
     * 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

[rmiles]

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

[jasone]

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.)

[hikage]

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

[jasone]

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.

[jasone]

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.

[Mark Fisher]

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.