[jitsi-dev] OperationSetPresence deprecated or bug?


#1

Hi,

I am currently looking into implementing IRC private messaging as actual Instant Messaging. As there is no persistent presence on IRC, I need only to implement OperationSetPresence. However, when I try to do this, during the initialization of Jitsi, I encounter the following stack trace. The cause is obvious, since the code assumes that every OperationSetPresence also implements OperationSetPersistentPresence.
  - Is this intended behavior?
  - Maybe OperationSetPresence is deprecated? (although I did not find reference of that in the code)

Thanks,
Danny

Code causing the exception:

         OperationSetPersistentPresence presenceOpSet
             = (OperationSetPersistentPresence)
protocolProvider.getOperationSet(OperationSetPresence.class);

16:12:12.961 SEVERE: [42] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: net.java.sip.communicator.impl.protocol.irc.OperationSetPresenceIrcImpl cannot be cast to net.java.sip.communicator.service.protocol.OperationSetPersistentPresence
java.lang.ClassCastException: net.java.sip.communicator.impl.protocol.irc.OperationSetPresenceIrcImpl cannot be cast to net.java.sip.communicator.service.protocol.OperationSetPersistentPresence
     at net.java.sip.communicator.impl.gui.main.presence.GlobalStatusSelectorBox.addAccount(GlobalStatusSelectorBox.java:198)
     at net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.addAccount(AccountStatusPanel.java:215)
     at net.java.sip.communicator.impl.gui.main.MainFrame.addAccount(MainFrame.java:991)
     at net.java.sip.communicator.impl.gui.main.MainFrame.addProtocolProvider(MainFrame.java:891)
     at net.java.sip.communicator.impl.gui.main.login.LoginRendererSwingImpl.addProtocolProviderUI(LoginRendererSwingImpl.java:37)
     at net.java.sip.communicator.util.account.LoginManager.handleProviderAdded(LoginManager.java:345)
     at net.java.sip.communicator.util.account.LoginManager.addAccountsForProtocolProviderFactory(LoginManager.java:128)
     at net.java.sip.communicator.util.account.LoginManager.runLogin(LoginManager.java:88)
     at net.java.sip.communicator.impl.gui.UIServiceImpl$RunLoginGui.run(UIServiceImpl.java:845)
     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
     at java.awt.EventQueue.access$200(EventQueue.java:103)
     at java.awt.EventQueue$3.run(EventQueue.java:688)
     at java.awt.EventQueue$3.run(EventQueue.java:686)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
     at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


#2

I am currently looking into implementing IRC private messaging as actual
Instant Messaging. As there is no persistent presence on IRC, I need only

to

implement OperationSetPresence. However, when I try to do this, during the
initialization of Jitsi, I encounter the following stack trace. The cause

is

obvious, since the code assumes that every OperationSetPresence also
implements OperationSetPersistentPresence.
- Is this intended behavior?

No, if an OpSet of a specific interface is retrieved, one cannot assume it
implements another class as well. I don't see immediate problems by using
OperationSetPresence only, so I assume it is just a bug. Have you tried to
simply remove the invalid cast?

- Maybe OperationSetPresence is deprecated? (although I did not find
reference of that in the code)

Nope, that is still valid. E.g. SIP might not have persistent presence as
well.

Thanks,
Danny

Ingo


#3

I am currently looking into implementing IRC private messaging as actual
Instant Messaging. As there is no persistent presence on IRC, I need only

to

implement OperationSetPresence. However, when I try to do this, during the
initialization of Jitsi, I encounter the following stack trace. The cause

is

obvious, since the code assumes that every OperationSetPresence also
implements OperationSetPersistentPresence.
- Is this intended behavior?

No, if an OpSet of a specific interface is retrieved, one cannot assume it
implements another class as well. I don't see immediate problems by using
OperationSetPresence only, so I assume it is just a bug. Have you tried to
simply remove the invalid cast?

Most likely yes.

- Maybe OperationSetPresence is deprecated? (although I did not find
reference of that in the code)

Nope, that is still valid. E.g. SIP might not have persistent presence as
well.

That's not actually true. SIP uses persistent presence even when it
doesn't. With time it turned out that difference between the
requirements for a persistent and a non-persistent implementation of
presence isn't exactly where we thought they would be.

If push comes to shove we could probably just make IRC implement that
as well. I don't think it would be such an issues.

Emil

···

On Sun, Feb 9, 2014 at 5:34 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:


#4

Hi,

···

On 02/09/2014 06:02 PM, Emil Ivov wrote:

On Sun, Feb 9, 2014 at 5:34 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

No, if an OpSet of a specific interface is retrieved, one cannot assume it
implements another class as well. I don't see immediate problems by using
OperationSetPresence only, so I assume it is just a bug. Have you tried to
simply remove the invalid cast?

Most likely yes.

- Maybe OperationSetPresence is deprecated? (although I did not find
reference of that in the code)

Nope, that is still valid. E.g. SIP might not have persistent presence as
well.

That's not actually true. SIP uses persistent presence even when it
doesn't. With time it turned out that difference between the
requirements for a persistent and a non-persistent implementation of
presence isn't exactly where we thought they would be.

If push comes to shove we could probably just make IRC implement that
as well. I don't think it would be such an issues.

Right, in that case I will go for OperationSetPersistentPresence then.
It seems that Hristo's earlier feedback is the easiest way to go. Just
haven't gotten the time yet to do the implementation.

Danny