[jitsi-dev] classloader issues


#1

I've observed issues where Jitsi is in the same JVM as another Java
graphical application

I'm seeing another exception (below) that seems to co-incide with call
stability problems.

In this case, both applications are deployed together using JNLP, but I
don't think WebStart is a factor in this exception

The other application introduces some look-and-feel UI changes. This
also means that it is receiving some events from the UI, as you can see
where org.example.Foo is in the stack trace below

I'm assuming that what this exception means is that
CallPeerSecurityTimeoutEvent was loaded by Felix but that the other
application code can't use that class because it has a different
classloader outside Felix.

I tried adding some of the following:

- in lib/felix.client.run.properties ,
   adding net.java.sip to org.osgi.framework.system.packages.extra

- in the JNLP, adding
<property name="org.osgi.framework.bootdelegation"
value="net.java.sip.communicator.service.protocol.event"/>

but neither seemed to make any difference.

Has anybody else dealt with issues like this before when integrating
Jitsi or libJitsi?

java.lang.LinkageError: loader constraint violation: loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5)
previously initiated loading for a different type with name
"net/java/sip/communicator/service/protocol/event/CallPeerSecurityTimeoutEvent"
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod(Unknown Source)
        ...
    at org.example.Roo.eventDispatched(Foo.java:221)
    at
java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Unknown Source)
    at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Unknown
Source)
    at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Unknown
Source)
    at java.awt.Toolkit.notifyAWTEventListeners(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.Component.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at javax.swing.JComponent.removeNotify(Unknown Source)
    at javax.swing.JRootPane.removeNotify(Unknown Source)
    at java.awt.Container.removeNotify(Unknown Source)
    at java.awt.Window.removeNotify(Unknown Source)
    at java.awt.Frame.removeNotify(Unknown Source)
    at java.awt.Window$1DisposeAction.run(Unknown Source)
    at java.awt.Window.doDispose(Unknown Source)
    at java.awt.Window.dispose(Unknown Source)
    at
net.java.sip.communicator.plugin.desktoputil.SIPCommFrame.dispose(SIPCommFrame.java:588)
    at
net.java.sip.communicator.impl.gui.main.call.CallDialog.dispose(CallDialog.java:207)
    at
net.java.sip.communicator.impl.gui.main.call.CallDialog$2.actionPerformed(CallDialog.java:184)
    at javax.swing.Timer.fireActionPerformed(Unknown Source)
    at javax.swing.Timer$DoPostEvent.run(Unknown Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$200(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown
Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)


#2

I've observed issues where Jitsi is in the same JVM as another Java
graphical application

I'm seeing another exception (below) that seems to co-incide with call
stability problems.

In this case, both applications are deployed together using JNLP, but I
don't think WebStart is a factor in this exception

The other application introduces some look-and-feel UI changes. This
also means that it is receiving some events from the UI, as you can see
where org.example.Foo is in the stack trace below

I'm assuming that what this exception means is that
CallPeerSecurityTimeoutEvent was loaded by Felix but that the other
application code can't use that class because it has a different
classloader outside Felix.

I tried adding some of the following:

- in lib/felix.client.run.properties ,
   adding net.java.sip to org.osgi.framework.system.packages.extra

AFAIK this property is not a wildcard, so you'd need to add the exact
package(s).

- in the JNLP, adding <property name="org.osgi.framework.bootdelegation"
value="net.java.sip.communicator.service.protocol.event"/>

but neither seemed to make any difference.

Has anybody else dealt with issues like this before when integrating
Jitsi or libJitsi?

I had loads of classloader errors when I started with WebStart, but they all
turned out to be my fault with misconfigured stuff and doing improper
Class.forName calls.

java.lang.LinkageError: loader constraint violation: loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5)
previously initiated loading for a different type with name
"net/java/sip/communicator/service/protocol/event/CallPeerSecurityTimeoutE
ven t"
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod(Unknown Source)
        ...
    at org.example.Roo.eventDispatched(Foo.java:221) at

My guess into the wild here is that the Window-Toolkit does a Class.forName
or maybe even tries to get the Felix classloader and does something wrong at
it. But without looking into the source and debugging... no way I could
possibly pinpoint this. Doing reflection in the event dispatch thread kinda
seems weird as well.

Ingo

···

On 2014-07-30 23:20, Daniel Pocock wrote:


#3

There is definitely a call to something.getClass().getMethod(). It is
in the UI code of the other Java application.

The other application could probably be adapted to check that the class
is from its own class loader before doing stuff like that. Maybe the
other application could also be deployed as a Jitsi "plugin", then it
would be within the OSGi container.

Do you think there is anything that Jitsi itself could do to make it
easier for people attempting integrations like this?

···

On 30/07/14 17:46, Ingo Bauersachs wrote:

java.lang.LinkageError: loader constraint violation: loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5)
previously initiated loading for a different type with name
"net/java/sip/communicator/service/protocol/event/CallPeerSecurityTimeoutE
ven t"
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod(Unknown Source)
        ...
    at org.example.Roo.eventDispatched(Foo.java:221) at

My guess into the wild here is that the Window-Toolkit does a Class.forName
or maybe even tries to get the Felix classloader and does something wrong at
it. But without looking into the source and debugging... no way I could
possibly pinpoint this. Doing reflection in the event dispatch thread kinda
seems weird as well.


#4

java.lang.LinkageError: loader constraint violation: loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5)
previously initiated loading for a different type with name

"net/java/sip/communicator/service/protocol/event/CallPeerSecurityTimeoutE

ven t"
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod0(Unknown Source)
    at java.lang.Class.getMethod(Unknown Source)
        ...
    at org.example.Roo.eventDispatched(Foo.java:221) at

My guess into the wild here is that the Window-Toolkit does a
Class.forName or maybe even tries to get the Felix classloader and does
something wrong at it. But without looking into the source and
debugging... no way I could possibly pinpoint this. Doing reflection in
the event dispatch thread kinda seems weird as well.

There is definitely a call to something.getClass().getMethod(). It is
in the UI code of the other Java application.

Do you know how "something" is obtained?

The other application could probably be adapted to check that the class
is from its own class loader before doing stuff like that. Maybe the
other application could also be deployed as a Jitsi "plugin", then it
would be within the OSGi container.

Do you think there is anything that Jitsi itself could do to make it
easier for people attempting integrations like this?

I think it would be key to understand why this actually happens. Having
another application running in the same VM should not cause this sort of
troubles. Have you seen other such errors or could it be that the ZRTP timer
of Jitsi misbehaves or that your other app cannot deal with some specifics
of that timer?

Ingo

···

On 2014-07-31 20:19, Daniel Pocock wrote:

On 30/07/14 17:46, Ingo Bauersachs wrote: