I am writing an Android API level 10 application which captures videos and then uploads them to our Kaltura site. It should be straight forward because Kaltura provides a Java client library (here), and they say to use the Java client library in their document titled the “Kaltura Android SDK Reference Application Implementation Guide.” (here)
Well, after writing a preliminary Kaltura uploading class that is identical to the Java client library example Kaltura shows (on the first link,) including all of the build references included in the Java client library “libs” folder to my project, EXCEPT for JUnit because Android already has it’s own JUnit (including their JUnit causes the build to fail), the app throws a java.lang.VerifyError during the construction of a new KalturaClient Object:
W/dalvikvm(8232): VFY: array-length on non-array
W/dalvikvm(8232): VFY: rejecting opcode 0x21 at 0x000a
W/dalvikvm(8232): VFY: rejected Lorg/apache/log4j/config/PropertySetter;.getPropertyDescriptor (Ljava/lang/String;)Ljava/beans/PropertyDescriptor;
W/dalvikvm(8232): Verifier rejected class Lorg/apache/log4j/config/PropertySetter;
W/dalvikvm(8232): Exception Ljava/lang/VerifyError; thrown while initializing Lorg/apache/log4j/LogManager;
W/dalvikvm(8232): Exception Ljava/lang/ExceptionInInitializerError; thrown while initializing Lcom/kaltura/client/KalturaClientBase;
D/AndroidRuntime(8232): Shutting down VM
W/dalvikvm(8232): threadid=1: thread exiting with uncaught exception (group=0x40015560)
E/AndroidRuntime(8232): FATAL EXCEPTION: main
E/AndroidRuntime(8232): java.lang.ExceptionInInitializerError
E/AndroidRuntime(8232): at com.mysite.myapp.kaltura.KalturaUploader.<init>(KalturaUploader.java:32)
E/AndroidRuntime(8232): at com.mysite.myapp.storage.LoginActivity.invokeKaltura(LoginActivity.java:105)
E/AndroidRuntime(8232): at com.mysite.myapp.storage.LoginActivity.access$2(LoginActivity.java:102)
E/AndroidRuntime(8232): at com.mysite.myapp.storage.LoginActivity$3.onClick(LoginActivity.java:81)
E/AndroidRuntime(8232): at android.view.View.performClick(View.java:2506)
E/AndroidRuntime(8232): at android.view.View$PerformClick.run(View.java:9112)
E/AndroidRuntime(8232): at android.os.Handler.handleCallback(Handler.java:587)
E/AndroidRuntime(8232): at android.os.Handler.dispatchMessage(Handler.java:92)
E/AndroidRuntime(8232): at android.os.Looper.loop(Looper.java:130)
E/AndroidRuntime(8232): at android.app.ActivityThread.main(ActivityThread.java:3835)
E/AndroidRuntime(8232): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(8232): at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime(8232): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:864)
E/AndroidRuntime(8232): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:622)
E/AndroidRuntime(8232): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime(8232): Caused by: java.lang.ExceptionInInitializerError
E/AndroidRuntime(8232): at org.apache.log4j.Logger.getLogger(Logger.java:118)
E/AndroidRuntime(8232): at com.kaltura.client.KalturaClientBase.<clinit>(KalturaClientBase.java:45)
E/AndroidRuntime(8232): ... 15 more
E/AndroidRuntime(8232): Caused by: java.lang.VerifyError: org.apache.log4j.config.PropertySetter
E/AndroidRuntime(8232): at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:684)
E/AndroidRuntime(8232): at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:647)
E/AndroidRuntime(8232): at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:544)
E/AndroidRuntime(8232): at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:440)
E/AndroidRuntime(8232): at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:476)
E/AndroidRuntime(8232): at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471)
E/AndroidRuntime(8232): at org.apache.log4j.LogManager.<clinit>(LogManager.java:125)
E/AndroidRuntime(8232): ... 17 more
I/Process(8232): Sending signal. PID: 8232 SIG: 9
So I’m guessing the above happened because Log4J doesn’t exactly work on Android without additional wrapper classes (code.google.com/p/android-logging-log4j), so why not just modify Kaltura to use Android’s logging facilities?
Because I’ve read (in Kaltura’s documentation) that the Java client is not written but instead is generated, so I feel that manually editing the code to support android-logging-log4j would be naive. Furthermore, when I open up the Kaltura Java Client source in Eclipse, there are a few classes which are missing from my build path. The first I noticed was sun.misc.BASE64Encoder…Android does have it’s own Base64Encoder, would it be compatible?
Does anybody have any suggestions as to what I should do? Has anybody gotten the Kaltura Java Client Library running on Android? Where is the sample application described in the second link?
As a side note, I also see many of these messages in my Eclipse console when I build the project, including the provided JAR’s in my build path:
[2012-07-18 22:44:37 - MyApp] Dx warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
Thanks in advance for the help!
Edit: Browsing the Kaltura code, I found some scary stuff that must be a result of this generated library…
// ===================================================================================================
// _ __ _ _
// | |/ /__ _| | |_ _ _ _ _ __ _
// | ' </ _` | | _| || | '_/ _` |
// |_|\_\__,_|_|\__|\_,_|_| \__,_|
//
// This file is part of the Kaltura Collaborative Media Suite which allows users
// to do with audio, video, and animation what Wiki platfroms allow them to do with
// text.
//
// Copyright (C) 2006-2011 Kaltura Inc.
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU Affero General Public License as
// published by the Free Software Foundation, either version 3 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU Affero General Public License for more details.
//
// You should have received a copy of the GNU Affero General Public License
// along with this program. If not, see <http://www.gnu.org/licenses/>.
//
// @ignore
// ===================================================================================================
package com.kaltura.client.enums;
/**
* This class was generated using generate.php
* against an XML schema provided by Kaltura.
* @date Wed, 18 Jul 12 07:10:33 -0400
*
* MANUAL CHANGES TO THIS CLASS WILL BE OVERWRITTEN.
*/
public enum KalturaFlavorReadyBehaviorType implements KalturaEnumAsInt {
NO_IMPACT (0),
REQUIRED (1),
OPTIONAL (2),
INHERIT_FLAVOR_PARAMS (0);
public int hashCode;
KalturaFlavorReadyBehaviorType(int hashCode) {
this.hashCode = hashCode;
}
public int getHashCode() {
return this.hashCode;
}
public static KalturaFlavorReadyBehaviorType get(int hashCode) {
switch(hashCode) {
case 0: return NO_IMPACT;
case 1: return REQUIRED;
case 2: return OPTIONAL;
case 0: return INHERIT_FLAVOR_PARAMS;
default: return NO_IMPACT;
}
}
}
How did they ever compile this code? It’s not even legal Java. There are maybe a hundred classes, most of them have the “this was auto-generated” notice at the top. Other classes have silly problems like this too (KalturaNullableBoolean).
For now I’m going to pretend the Java client library does not exist. A Ruby client library exists, and I’ve had great success with JRuby on Android in the past, and our application only uploads big files which take a long time anyway, so the overhead increase shouldn’t be terribly noticeable..if it all works. We’ll just have to accept the .APK being huge thanks to the included JRuby JAR…
Not to mention they crammed everything into 2 Ruby scripts instead of hundreds of Java classes…all the easier to strip out incompatible functionality, if there is any, and at least my Eclipse project won’t be a jungle of Kaltura Java source files anymore. 😀
Thanks for reading.
The client is indeed automatically generated, as Kaltura’s API gets updated, the server generates new clients every update to provide for the latest functionality in the clients.
You can read more about Kaltura’s Client Libs generator here:
http://knowledge.kaltura.com/adding-new-kaltura-api-client-library-generator
Any patches or modifications that you think will improve the client libraries are welcome, feel free to attach it here or to an issue thread on Kaltura.org.
The current Java Client is not yet Android friendly, it’s geared for pure Java use.
There is work to adapt and create an Android specific version, and any suggestions or patches for improvement are greatly appreciated.