well daniel,
i do have good news. having the yahoo transport enabled has not caused the CPU to spike to 100% yet ![]()
lol well yes, that is good news =)
I fixed my ldap error but it still does not work. went back to 1.0.2 and all is well.
Tried again - no joy.
I get this logged:
2007.06.01 23:04:53 [org.jivesoftware.util.log.util.CommonsLogFactory$1.error(CommonsLogFactory.jav a:87)
] Line=19 The content of element type "dwr" must match "(init?,allow?,signatures?)".
Interesting. I can''t think of why it would be misbehaving unfortunately. Not sure what to do. Doesn''t sound like there''s any more information to provide =/
thanks for the beta. it seem''s to run quite good.
sometimes i get following NPE (not in 1.0.2):
2007.06.02 12:18:32 org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.java :182) Error occured while processing packet:
java.lang.NullPointerException
at org.jivesoftware.openfire.gateway.BaseTransport.addNewRegistration(BaseTranspor t.java:1345)
at org.jivesoftware.openfire.gateway.BaseTransport.handleIQRegister(BaseTransport. java:706)
at org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.jav a:457)
at org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.jav a:163)
at org.jivesoftware.openfire.component.InternalComponentManager$RoutableComponent. process(InternalComponentManager.java:490)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:250)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:104)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:67)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:11 0)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:67 )
at org.jivesoftware.openfire.multiplex.MultiplexerPacketHandler.route(MultiplexerP acketHandler.java:164)
at org.jivesoftware.openfire.net.MultiplexerStanzaHandler.processRoute(Multiplexer StanzaHandler.java:89)
at org.jivesoftware.openfire.net.MultiplexerStanzaHandler.processUnknowPacket(Mult iplexerStanzaHandler.java:96)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:258)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:153)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:200)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :266)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:326)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Oops =) Thanks! Fixed in SVN,
Oh wow, I was just able to duplicate what you are seeing. Let me see what''s causing it and fix. =)
Bother... ok, I figured out what was going on. I had a reversed logic flaw. Deejay, snowman, please try out the attached plugin, it should fix the issues you two were referring to. notz, the attached plugin also fixes the issue you were running into. Lemme know if it does indeed do the trick!
works for me (well, it logs me into MSN which is more than it did before!).
Will report back properly when I''ve had chance to test it.
MSN custom status''s look really odd.
Mine appear to be out of synch;
I set my status to from available to away, and my message in MSN says available, I set it to busy and MSN shows away etc. Very odd!
Before I do testing, one question, what client are you using? Spark? Psi? Something else?
Also, when you say "MSN shows away", do you mean the icon in your XMPP client related to the MSN transport shows as away, or do you mean you are watching your account from another MSN account and you see it as away?
I''m running an MSN test account along side Spark using the latest gateway.
The MSN client shows an incorrect status message for me (so it''ll show away when I''m away, but the corresponding message will be the one I''d set previously
=/ Man, I just tested it with Psi and with Spark 2.5.3 and I can''t duplicate the behavior you are seeing. I''m watching from a real MSN client and a client attached via XMPP, and dancing through MSN statuses on a third account that''s connected via Spark and I''m not seeing the behavior you are seeing at all. Now I have seen it take upwards of 5 seconds for changes to make it through. (like in my real MSN client I set my status message and it seems to sometimes take 5 seconds to arrive at the gateway or any other MSN client) What version of Spark? If not 2.5.3, mind giving 2.5.3 a quick test to see if it just happens to fix the behavior?
You can ignore that line btw =) (the dwr one)