administrivia: list shutdown?

The list jso-devel <at> jabberstudio.org appears to be inactive and in the 
near future the jabberstudio.org domain will no longer be supported. 
Therefore as mailman administrator for this server I plan to shut down 
the list in the next few days. If you have any concerns about this 
decision, please contact me directly or reply to this message. If there 
is an alternate list for this project, please let me know.

Thanks.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org
http://mail.jabber.org/mailman/listinfo/jso-devel

about the add a new contact in using jso

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org
http://mail.jabber.org/mailman/listinfo/jso-devel

SASL Help

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org
http://mail.jabber.org/mailman/listinfo/jso-devel

GTalk and JSO?

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org
http://mail.jabber.org/mailman/listinfo/jso-devel

Listening for incoming packets

I'm a little new to XMPP, so I have a pretty fundamental question  
about how JSO works.  I'm curious as to why you need to call  
Stream.process() in an infinite loop in order to continuously process  
incoming packets.  Why not something like:

- Set up your listeners.
- Connect to the server.
- Have the connect method block while waiting for new packets to come  
in, then call the right packet handers as the packets arrive.

Putting the call to process() in a tight infinite loop seems more  
resource intensive than necessary.  Can anyone explain why JSO works  
like this?

Thanks,
Christian

Using JSO for s2s connections

Hi,

I'm trying to write an s2s aware application using JSO and so far I am
failing at the first hurdle, when I receive a dialback request from the
initiating server. As I am returning an invalid response resulting in a
invalid namespace stream error, I believe this is caused by the stream
response not containing the following attribute
"xmlns:db='jabber:server:dialback'".

Therefore I need to hook into the stream negotiation and handle this kind of
request.  Which I currently cannot work out how to do.
1) I've tried to implement an XPathListener to try and catch this event, but
with no success.  However I'm not convinced that I have correctly formed the
XPath filter; watcher = new XPathListener(streamDataFactory,
"stream:stream[ <at> xmlns:db='jabber:server:dialback']") {
   public void packetMatched(PacketEvent evt) {
      Logger      log = obtainLogger();
      if (log.isEnabledFor(Level.INFO))
         log.info("Matched dialback: " + evt);
      }
   };
connection.addPacketListener(PacketEvent.RECEIVED, watcher);

2) I have tried implementing a PacketListener, however this only fires for
the invalid namespace error packet, not for the initial dialback request.
Are stream elements treated as packets?  or is that too early in the
connection?

Am I approaching this in the right manner?  Or have I missed a listening
interface which would allow me to respond to these stream packets?

Any help is appreciated,

Ross

Echo Client Does not report stream features when connecting to the Wildfire XMPP Server and hangs after incoming stream element

Hi,

I compiled and ran the echo client example against a wildfire server
running on my localhost.

the echo client example caught the incoming stream open tag..but the
stream feature handler did not get called and was logger with an error
as just another packet...

is this a bug???

regards
Saurav

--
===============================
"Before you ask someone to save the world, you'd better make sure they
like it the way it is."
Xander Cage (Vin Diesel) in xXx

==============================

Looking For Some Sample Code (Client and Server)

Hi All,

I downloaded the JSO src and bin jars from the site and could not find
any examples / sample code with it.

My search through the archives sprung up some references to Echo
Server / Client but i could not find the source code anywhere in the
distribution or any links on the site...

Could any one point me to the sample code if any is available or a
sort of a implementation tutorial

i appologize if i missed something really obvious and/or if this
question has been asked before

regards
Saurav

--
===============================
"Before you ask someone to save the world, you'd better make sure they
like it the way it is."
Xander Cage (Vin Diesel) in xXx

==============================

Using jso library to build an xmpp server

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org
http://mail.jabber.org/mailman/listinfo/jso-devel

RE: Component: XPathMonitor

I found the problem: the XPathListener makes sure the expression always
starts with a ./ (and appends where necessary) but the sendAndWatch does
not, so the following now works:

Xpath xpath = sdf.createXPath(".//app:presence[ <at> id='blah']", ns)

Cheers
Joe.

-----Original Message-----
From: Mannering, J (Joe) 
Sent: 07 September 2005 11:04
To: 'jso-devel <at> jabberstudio.org'
Subject: Component: XPathMonitor

Hi

I am using JSO to build a component connector

The component needs to be able to create and configure a room, and I am
using XPathMonior.sendAndWatch to send presence and request the
configuration form for rooms

The xmpp server is wrapping all packets with a <route/> element
(including replies to messages sent) which means
PacketMonitor.sendAndWatch does not work as the packets do not match
(??)

Roughly, I do this:

( ns has app set to default namespace. Xpath would be changed to
[id='...'])

Xpath xpath = sdf.createXPath("//app:presence", ns)

XPathMonitor.sendAndWatch(stream, presence packet, xpath, 10000)

The packet is returned (within 10 seconds), and can be trapped by
XPathListener - but not here?

Any ideas?

Or is there a way to unwrap packets and re-dispatch the event?

Many thanks
Joe.
_____________________________________________________________

This email (including any attachments to it) is confidential, legally privileged, subject to copyright
and is sent for the personal attention of the intended recipient only. If you have received this email in
error, please advise us immediately and delete it. You are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this information is strictly
prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this
email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or
attachments. We exclude any liability for the content of this email, or for the consequences of any
actions taken on the basis of the information provided in this email or its attachments, unless that
information is subsequently confirmed in writing. If this email contains an offer, that should be
considered as an invitation to treat.
_____________________________________________________________

Component: XPathMonitor

Hi

I am using JSO to build a component connector

The component needs to be able to create and configure a room, and I am
using XPathMonior.sendAndWatch to send presence and request the
configuration form for rooms

The xmpp server is wrapping all packets with a <route/> element
(including replies to messages sent) which means
PacketMonitor.sendAndWatch does not work as the packets do not match
(??)

Roughly, I do this:

( ns has app set to default namespace. Xpath would be changed to
[id='...'])

Xpath xpath = sdf.createXPath("//app:presence", ns)

XPathMonitor.sendAndWatch(stream, presence packet, xpath, 10000)

The packet is returned (within 10 seconds), and can be trapped by
XPathListener - but not here?

Any ideas?

Or is there a way to unwrap packets and re-dispatch the event?

Many thanks
Joe.
_____________________________________________________________

This email (including any attachments to it) is confidential, legally privileged, subject to copyright
and is sent for the personal attention of the intended recipient only. If you have received this email in
error, please advise us immediately and delete it. You are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this information is strictly
prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this
email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or
attachments. We exclude any liability for the content of this email, or for the consequences of any
actions taken on the basis of the information provided in this email or its attachments, unless that
information is subsequently confirmed in writing. If this email contains an offer, that should be
considered as an invitation to treat.
_____________________________________________________________