[jitsi-users] testing webstart / jnlp


#1

I've been testing the webstart branch

To build it, I needed to make two tweaks, one here:

--- a/web-start/WebStartBuild.xml
+++ b/web-start/WebStartBuild.xml
@@ -17,7 +17,7 @@
        <property name="unpack200.path"
value="${java.jdk.dir}/bin/unpack200" />
        <property name="jarsigner.path"
value="${java.jdk.dir}/bin/jarsigner" />

- <target name="compile-ant-ext">
+ <target name="compile-ant-ext" depends="prepare">
                <javac srcdir="${ant-ext-src.dir}"
destdir="${ant-ext.dir}" incl
        </target>

and in the top level build.xml (line 315), I had to change the Java
version from 1.4 to 1.5 to avoid these errors:

    [javac] Compiling 1 source file to classes
    [javac]
src/net/java/sip/communicator/launcher/SIPCommunicatorJWS.java:34:
for-each loops are not supported in -source 1.4
    [javac] (use -source 5 or higher to enable for-each loops)
    [javac] for (Handler h :
LogManager.getLogManager().getLogger("").getHandlers())
    [javac] ^
    [javac]
src/net/java/sip/communicator/launcher/SIPCommunicatorJWS.java:76:
generics are not supported in -source 1.4
    [javac] (use -source 5 or higher to enable generics)
    [javac] for (Map.Entry<Object, Object> e : pIn.entrySet())
    [javac] ^
    [javac] 2 errors

On startup, exceptions are logged (see below), could there be a
classpath issue?

Can't load log handler "net.java.sip.communicator.util.FileHandler"
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at java.util.logging.LogManager$3.run(LogManager.java:357)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:344)
    at
java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:909)
    at java.util.logging.LogManager.access$900(LogManager.java:128)
    at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:990)
    at
net.java.sip.communicator.launcher.SIPCommunicatorJWS.main(SIPCommunicatorJWS.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.sun.javaws.Launcher.executeApplication(Launcher.java:1809)
    at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1750)
    at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1512)
    at com.sun.javaws.Launcher.run(Launcher.java:130)
    at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
    at
net.java.sip.communicator.plugin.pluginmanager.PluginManagerActivator.start(PluginManagerActivator.java:86)
    at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
    at java.lang.Thread.run(Thread.java:662)


#2

Hey Daniel

I haven't updated the Webstart-branch since I created it after FOSDEM14, so
it is quite outdated.

I don't know what's going on with the logger. Unfortunately I cannot look
into this now, as I don't have a dev-environment with me. If I would guess,
then it could be related to the renaming of SIP-Communicator to Jitsi (and
some corresponding package renamings), as we developed the Webstart code
back in the days of SIPComm.

Don't know anymore about the 1.4/1.5 stuff, I think this is also ancient
stuff for the launcher on Mac. Shouldn't be a problem to even change this to
1.6 now.

As for your pull request: could you please change the format of your new
code so that it corresponds to our coding guidelines (line length, braces)?
https://jitsi.org/Documentation/DeveloperDocumentation#guidelines

HTH and Thanks,
Ingo

···

-----Original Message-----
From: users-bounces@jitsi.org [mailto:users-bounces@jitsi.org] On Behalf Of
Daniel Pocock
Sent: Samstag, 5. Juli 2014 01:27
To: Jitsi Users
Subject: [jitsi-users] testing webstart / jnlp

I've been testing the webstart branch

To build it, I needed to make two tweaks, one here:

--- a/web-start/WebStartBuild.xml
+++ b/web-start/WebStartBuild.xml
@@ -17,7 +17,7 @@
        <property name="unpack200.path"
value="${java.jdk.dir}/bin/unpack200" />
        <property name="jarsigner.path"
value="${java.jdk.dir}/bin/jarsigner" />

- <target name="compile-ant-ext">
+ <target name="compile-ant-ext" depends="prepare">
                <javac srcdir="${ant-ext-src.dir}"
destdir="${ant-ext.dir}" incl
        </target>

and in the top level build.xml (line 315), I had to change the Java version
from 1.4 to 1.5 to avoid these errors:

    [javac] Compiling 1 source file to classes
    [javac]
src/net/java/sip/communicator/launcher/SIPCommunicatorJWS.java:34:
for-each loops are not supported in -source 1.4
    [javac] (use -source 5 or higher to enable for-each loops)
    [javac] for (Handler h :
LogManager.getLogManager().getLogger("").getHandlers())
    [javac] ^
    [javac]
src/net/java/sip/communicator/launcher/SIPCommunicatorJWS.java:76:
generics are not supported in -source 1.4
    [javac] (use -source 5 or higher to enable generics)
    [javac] for (Map.Entry<Object, Object> e : pIn.entrySet())
    [javac] ^
    [javac] 2 errors

On startup, exceptions are logged (see below), could there be a classpath
issue?

Can't load log handler "net.java.sip.communicator.util.FileHandler"
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at java.util.logging.LogManager$3.run(LogManager.java:357)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:344)
    at
java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:909)
    at java.util.logging.LogManager.access$900(LogManager.java:128)
    at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:990)
    at
net.java.sip.communicator.launcher.SIPCommunicatorJWS.main(SIPCommunicatorJW
S.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.sun.javaws.Launcher.executeApplication(Launcher.java:1809)
    at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1750)
    at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1512)
    at com.sun.javaws.Launcher.run(Launcher.java:130)
    at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
    at
net.java.sip.communicator.plugin.pluginmanager.PluginManagerActivator.start(
PluginManagerActivator.java:86)
    at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.jav
a:629)
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
    at java.lang.Thread.run(Thread.java:662)

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

(moved from users@jitsi.org)

Hey Daniel

I haven't updated the Webstart-branch since I created it after FOSDEM14, so
it is quite outdated.

Looking at the branch, your commit in February made one change to the
top-level build.xml:

- <jar compress="false" destfile="${bundles.dest}/protocol-sip.jar"
+ <jar compress="false" destfile="${bundles.dest}/protocol-sip.jar"
duplicate="preserve"

Should this change (and my change for Java version) be applied to master
or should it stay on the branch? Could you remember why it was
necessary, should this jar/@duplicate attribute be added to any other
JARs perhaps?

Once that is on master, could somebody with commit access please merge
the latest master into the branch:

   git checkout webstart && git merge master && git push

and then I'll test and submit my pull request against that.

I don't know what's going on with the logger. Unfortunately I cannot look
into this now, as I don't have a dev-environment with me. If I would guess,
then it could be related to the renaming of SIP-Communicator to Jitsi (and
some corresponding package renamings), as we developed the Webstart code
back in the days of SIPComm.

Maybe the merge from master will fix this - Jitsi seems to work anyway
but it would be nice to make the console output clean.

Don't know anymore about the 1.4/1.5 stuff, I think this is also ancient
stuff for the launcher on Mac. Shouldn't be a problem to even change this to
1.6 now.

It doesn't appear to be something specific to WebStart - should this
build.xml change also be made directly on master?

- source="1.4" target="1.4" memoryMaximumSize="400M" fork="true">
+ source="1.6" target="1.6" memoryMaximumSize="400M" fork="true">

or should that stuff just be ripped out of build.xml completely if it is
not used any more?

As for your pull request: could you please change the format of your new
code so that it corresponds to our coding guidelines (line length, braces)?
https://jitsi.org/Documentation/DeveloperDocumentation#guidelines

Ok, I'm happy to re-submit, but if somebody can just clarify the top
level build.xml changes, apply them on master and sync the branch from
master then let me know so I can test against the latest code.

Regards,

Daniel

···

On 05/07/14 07:13, Ingo Bauersachs wrote: