external plugin and yahoo registering

HI ALL,

I HAVE SOME ISSUES WITH THE CURRENT CVS AND WAS WONDERING IF
ANYBODY ELSE EXPERIENCES THE SAME BEHAVIOR:

1) WHEN I DEFINE AN EXTERNAL COMPONENT (EG FOR MSN), THE
ORDER OF THE LINES SEEMS TO BE IMPORTANT: USING
   <PLUGIN DJABBERD::PRESENCECHECKER::LOCAL />
   <PLUGIN DJABBERD:ELIVERY:
:LOCAL />
   <PLUGIN DJABBERD:ELIVERY:
:S2S />
   <PLUGIN DJABBERD::PLUGIN::ENTITYTIME />
BEFORE MY SUBDOMAIN:
   <SUBDOMAIN MSN>
      <PLUGIN DJABBERD::COMPONENT::EXTERNAL>
          LISTENPORT 5347
          SECRET XXXX
      </PLUGIN>
   </SUBDOMAIN>
THE SUBDOMAINS FAILS TO FUNCTION CORRECTLY (WHAT I MEAN IN
THIS CASE: THE MSN PLUGIN CONNECTS FINE, BUT THEN I CAN'T
REGISTER OR SEE ANY OF THE POSSIBILITIES THE MSN CONNECTOR
HAS).
IS THIS NORMAL? OR SHOULD THE SUBDOMAINS ALWAYS BE DEFINED
FIRST? IS THE ORDER NOT THAT RELEVANT FOR EG. SQLITE
AUTHENTICATION?

2) WHEN PUTTING THE LINES IN CORRECT ORDER, THE PLUGIN
*SEEMS* TO LOAD AND FUNCTION FINE (I STILL NEED TO REALLY
GET A MSN OR AIM ACCOUNT ...).
BUT: SHUTTING DOWN THE MSN PYTHON SCRIPT AND RELAUNCHING IT,
GIVES ME TROUBLES. I TRIED IT WITH A TELNET TO THE PORT,
CANCEL THE TELNET AND TRYING AGAIN:

DEBUG DJABBERD.COMPONENT.EXTERNAL              ACCEPTING
CONNECTION FROM COMPONENT YAHOO.XXX
DEBUG DJABBERD.CONNECTION.COMPONENTIN          MAKING A
DJABBERD::CONNECTION::COMPONENTIN FOR FD 12
INFO  DJABBERD.COMPONENT.EXTERNAL              SHUTTING DOWN
LISTENER FOR COMPONENT YAHOO.XXX
ERROR DJABBERD.CONNECTION.COMPONENTIN           DISCONNECTED
DJABBERD::CONNECTION::COMPONENTIN=ARRAY(0X9C91C24) BECAUSE:
XML NOT WELL-FORMED IN XMLPARSECHUNK

USE OF UNINITIALIZED VALUE IN CONCATENATION (.) OR STRING AT
/USR/LIB/PERL5/SITE_PERL/5.8.8/DJABBERD/CONNECTION.PM LINE
540.
WARN  DJABBERD.CONNECTION.COMPONENTIN           PARSING
*****
?½?½?½
*******


INFO  DJABBERD.COMPONENT.EXTERNAL              COMPONENT
YAHOO.XXX DISCONNECTED.
INFO  DJABBERD.COMPONENT.EXTERNAL              STARTED
LISTENER FOR COMPONENT YAHOO.XXX ON TCP SOCKET
<127.0.0.1:5350>

AS YOU CAN SEE, DJABBERD STARTS LISTENING AGAIN ON THE PORT,
BUT DOESN'T SEEM TO RESPOND AT ALL ANY MORE TO TRAFFIC ON
THAT PORT.

3) IGNORING THE ABOVE 2 PROBLEMS, THE ONLY THING THAT IS NOT
WORKING IS THE YAHOO PYTHON THINGIE (PYIMT, SEE THE XMPPY
PROJECT ON SOURCEFORGE). ALL OTHER PLUGINS WORK (PYMSN,
PYAIM-T, PYICQ-T). ANYBODY ELSE HAS THAT PROBLEM WITH
PYIMT?

I've had the issue with reconnecting while using the
mu-conference
component.  DJabberd just doesn't allow mu-conference to
reconnect if I
restart mu-conference.  So I have to restart the ENTIRE
thing.
Definitely a Bug in djabberd.

Franky Van Liedekerke wrote:
> Hi all,
> 
> I have some issues with the current CVS and was
wondering if anybody else experiences the same behavior:
> 
> 1) when I define an external component (eg for msn),
the order of the lines seems to be important: using
>    <Plugin DJabberd::PresenceChecker::Local />
>    <Plugin DJabberd:elivery:
:Local />
>    <Plugin DJabberd:elivery:
:S2S />
>    <Plugin DJabberd::Plugin::EntityTime />
> before my subdomain:
>    <Subdomain msn>
>       <Plugin DJabberd::Component::External>
>           ListenPort 5347
>           Secret xxxx
>       </Plugin>
>    </Subdomain>
> the subdomains fails to function correctly (what I mean
in this case: the msn plugin connects fine, but then I can't
register or see any of the possibilities the msn connector
has).
> Is this normal? Or should the subdomains always be
defined first? Is the order not that relevant for eg. sqlite
authentication?
> 
> 2) When putting the lines in correct order, the plugin
*seems* to load and function fine (I still need to really
get a msn or aim account ...).
> But: shutting down the msn python script and
relaunching it, gives me troubles. I tried it with a telnet
to the port, cancel the telnet and trying again:
> 
> DEBUG DJabberd.Component.External             
Accepting connection from component yahoo.xxx
> DEBUG DJabberd.Connection.ComponentIn          Making a
DJabberd::Connection::ComponentIn for fd 12 
> INFO  DJabberd.Component.External              Shutting
down listener for component yahoo.xxx 
> ERROR DJabberd.Connection.ComponentIn          
disconnected
DJabberd::Connection::ComponentIn=ARRAY(0x9c91c24) because:
XML not well-formed in xmlParseChunk
>  
> Use of uninitialized value in concatenation (.) or
string at
/usr/lib/perl5/site_perl/5.8.8/DJabberd/Connection.pm line
540.
> WARN  DJabberd.Connection.ComponentIn           parsing
*****
> ���
> *******
> 
> 
> INFO  DJabberd.Component.External             
Component yahoo.xxx disconnected. 
> INFO  DJabberd.Component.External              Started
listener for component yahoo.xxx on TCP socket
<127.0.0.1:5350> 
> 
> As you can see, djabberd starts listening again on the
port, but doesn't seem to respond at all any more to traffic
on that port.
> 
> 3) Ignoring the above 2 problems, the only thing that
is not working is the yahoo python thingie (PyIMt, see the
xmppy project on sourceforge). All other plugins work
(pymsn, pyaim-t, pyicq-t). Anybody else has that problem
with PyIMt?
> 
> 
> 

Franky Van Liedekerke wrote:
> Hi all,
> 
> I have some issues with the current CVS and was
wondering if anybody else experiences the same behavior:
> 
> 1) when I define an external component (eg for msn),
the order of the lines seems to be important: using
>    <Plugin DJabberd::PresenceChecker::Local />
>    <Plugin DJabberd:elivery:
:Local />
>    <Plugin DJabberd:elivery:
:S2S />
>    <Plugin DJabberd::Plugin::EntityTime />
> before my subdomain:
>    <Subdomain msn>
>       <Plugin DJabberd::Component::External>
>           ListenPort 5347
>           Secret xxxx
>       </Plugin>
>    </Subdomain>
> the subdomains fails to function correctly (what I mean
in this case: the msn plugin connects fine, but then I can't
register or see any of the possibilities the msn connector
has).
> Is this normal? Or should the subdomains always be
defined first? Is the order not that relevant for eg. sqlite
authentication?
> 

Internally some of these plugins end up adding handlers to
the delivery 
hook inside the server, so any stanza recieved is passed to
each of 
these in order until one declares that it has delivered it.

In your case, the S2S plugin is probably trying to deliver
the stanza 
externally because it doesn't match the VHost's own domain.

<Subdomain> behind the scenes just creates a new VHost
and uses the 
DJabberd:elivery:
:LocalVHosts plugin to arrange for local delivery, so 
there isn't actually anything special about a subdomain as
far as 
delivery goes.

In general, you should order your plugins by how
"close" they are to the 
current VHost to ensure correct operation:
   * Delivery to the same vhost (DJabberd:elivery:
:Local)
   * Delivery to other local vhosts (DJabberd:elivery:
:LocalVHosts or
   <Subdomain>)
   * Delivery to other servers (DJabberd:elivery:
:S2S)

The other plugins you've used here aren't delivery plugins,
so their 
order is not significant here.

(I realise you probably already figured most of this out,
but I thought 
I'd spell it out in case it is of help to anyone else.)

On Wed, 07 Nov 2007 19:31:57 +0000
Martin Atkins <martdegeneration.co.uk> wrote:

> Franky Van Liedekerke wrote:
> > Hi all,
> > 
> > I have some issues with the current CVS and was
wondering if
> > anybody else experiences the same behavior:
> > 
> > 1) when I define an external component (eg for
msn), the order of
> > the lines seems to be important: using <Plugin
> > DJabberd::PresenceChecker::Local /> <Plugin
> > DJabberd:elivery:
:Local /> <Plugin DJabberd:elivery:
:S2S />
> >    <Plugin DJabberd::Plugin::EntityTime />
> > before my subdomain:
> >    <Subdomain msn>
> >       <Plugin
DJabberd::Component::External>
> >           ListenPort 5347
> >           Secret xxxx
> >       </Plugin>
> >    </Subdomain>
> > the subdomains fails to function correctly (what I
mean in this
> > case: the msn plugin connects fine, but then I
can't register or
> > see any of the possibilities the msn connector
has). Is this
> > normal? Or should the subdomains always be defined
first? Is the
> > order not that relevant for eg. sqlite
authentication?
> > 
> 
> Internally some of these plugins end up adding handlers
to the
> delivery hook inside the server, so any stanza recieved
is passed to
> each of these in order until one declares that it has
delivered it.
> 
> In your case, the S2S plugin is probably trying to
deliver the stanza 
> externally because it doesn't match the VHost's own
domain.
> 
> <Subdomain> behind the scenes just creates a new
VHost and uses the 
> DJabberd:elivery:
:LocalVHosts plugin to arrange for local delivery,
> so there isn't actually anything special about a
subdomain as far as 
> delivery goes.
> 
> In general, you should order your plugins by how
"close" they are to
> the current VHost to ensure correct operation:
>    * Delivery to the same vhost (DJabberd:elivery:
:Local)
>    * Delivery to other local vhosts (DJabberd:elivery:
:LocalVHosts
> or <Subdomain>)
>    * Delivery to other servers (DJabberd:elivery:
:S2S)
> 
> The other plugins you've used here aren't delivery
plugins, so their 
> order is not significant here.
> 
> (I realise you probably already figured most of this
out, but I
> thought I'd spell it out in case it is of help to
anyone else.)

Yes I did 
But maybe a working sample config included in the distro
would be even
more usefull to others ...

Franky
>