[sip-comm-dev] Fwd: sparke problem (issue 597)


#1

Hi all,

I wanted to start working on the problem with Sparkle on Java 1.6 but I was unable to reproduce it. I talked with my mentor (check below) and it seems that SC uses Java 1.5 even if Java 1.6 is set as default. Is it the case?

Cheers,
Egidijus

···

Begin forwarded message:

Hi Egidijus,

On 2009/07/30, at 14:10, Egidijus Jankauskas wrote:

I switched my 32bit Macbook to my girlfriend's 64bit Macbook Pro, so that I could work on that Sparkle issue. However, I can't reproduce the problem. I have changed the default JVM to 1.6 (java -version shows that the current version is 1.6) and removed the "if= "sparkle" line from macosx-sparkle target to bundle the app with sparkle. When I run it, I can update SIP Communicator without any error messages in console. So what I am doing wrong?

Same here - but it seems that even though I tell the Java preferences application to use java 1.6 by default (and hence I also have the version 1.6 displayed when doing "java -version"), SIP Communicator uses version 1.5 when running: I've added this little piece of code in SC (e.g in the sparkle bundle):

   String version = System.getProperty("java.version");
   logger.error("Java version " + version);

and it gave me that result:

   "Java version 1.5.0_19"

Might be a good idea to ask on the ML whether SC forces the use of Java 1.5 when running.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi all,

It looks like Sparkle fails because the libsparkle_init.dylib library is compiled only for 32 bit architecture and Java 1.6 runs only in 64 bit mode. The simplest solution would be to recompile the library for both i386, and x86_64 architectures, but it is not possible with the currently used version of Sparkle.framework (The one that is in resources/install/macosx/), since it itself is not compiled for x86_64.

So I think that the only solution is to update the Sparkle.framework to a version that supports x86_64 architecture. We can do this by either:

1) using the latest version (1.5b6) of Sparkle, or
2) updating the 1.1 version of the framework to support x86_64

The first option would require a lot of changes to current implementation. There are some big changes in that latest framework version. It now requires to use DSA signatures, or SSL to check that the update really comes from the right place. This would require changes not only to SIP Communicator application, but also to the appcast on the sip-communicator.org. If we decide to use DSA signatures, every update would require to be signed. There are ruby scripts provided for that, but I don't know how they would integrate into the current update building system. If we opt for SSL, then the appcast and the update itself should come over SSL. I don't really know how Sparkle updates over SSL work.

The second option would be a quick fix. I checked the Sparkle source code repository and it looks like introduced the support for x86_64 shortly after 1.1 release. So I downloaded that revision and tried to make it work today. It does work partially, but not completely :slight_smile: It checks for updates when running java 1.6, but gives an error when trying to download it. I guess that is because I got some errors when compiled the framework.

Which option do you think would be better?

Cheers,
Egidijus

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Egidijus,

It looks like Sparkle fails because the libsparkle_init.dylib library is compiled only for 32 bit architecture and Java 1.6 runs only in 64 bit mode. The simplest solution would be to recompile the library for both i386, and x86_64 architectures, but it is not possible with the currently used version of Sparkle.framework (The one that is in resources/install/macosx/), since it itself is not compiled for x86_64.

So I think that the only solution is to update the Sparkle.framework to a version that supports x86_64 architecture. We can do this by either:

1) using the latest version (1.5b6) of Sparkle, or
2) updating the 1.1 version of the framework to support x86_64

I would go for option 1), as we'll certainly keep updating sparkle with time, so it's the good opportunity to switch to the latest version directly. Furthermore, a little bit more security by signing the packages would not hurt.

The first option would require a lot of changes to current implementation. There are some big changes in that latest framework version. It now requires to use DSA signatures, or SSL to check that the update really comes from the right place. This would require changes not only to SIP Communicator application, but also to the appcast on the sip-communicator.org. If we decide to use DSA signatures, every update would require to be signed. There are ruby scripts provided for that, but I don't know how they would integrate into the current update building system.

The current building system is pretty simple. Every time cruisecontrol has a successful buiild, it calls a script that takes care of building the macosx package. We just need to add a line or two into that script to sign the package, I guess.

If we opt for SSL, then the appcast and the update itself should come over SSL. I don't really know how Sparkle updates over SSL work.

The second option would be a quick fix. I checked the Sparkle source code repository and it looks like introduced the support for x86_64 shortly after 1.1 release. So I downloaded that revision and tried to make it work today. It does work partially, but not completely :slight_smile: It checks for updates when running java 1.6, but gives an error when trying to download it. I guess that is because I got some errors when compiled the framework.

Which option do you think would be better?

Option 2) would be interesting if we were in a hurry, but java 6 support in SC is not planned for the next weeks, so we could take the time for option 1). Plus, I don't think option 1 would be such a big change, as we already have all the basic infrastructure for sparkle.

As a side note, I've read the following thread recently. If we move someday to java 6, we'll have to take care of updating the JavaApplicationStub too, or provide both 32-bits/64-bits packages:
http://lists.apple.com/archives/java-dev/2009/Jun/msg00142.html

Cheers,
romain

···

On 2009/08/04, at 17:23, Egidijus Jankauskas wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi all,

I have found a solution to Sparkle issue. It took me much longer than I expected and it is kind of funny because in the end it is just one line of code... So here is a little story:

The initial problem was that Sparkle didn't work on Java 1.6. It didn't work because the dynamic library with the native code couldn't be loaded, and it couldn't be loaded because it was not compiled for x86_64 architecture. The library was not compiled for x86_64 because the Sparkle.framework itself did not support 64 bit architecture.

So we decided to update the Sparkle to the latest version which supports x86_64 and in addition has some major security enhancements. Then it turned out that native code in the Sparkle library doesn't work anymore. Sparkle is normally configured via Info.plist in application bundle and I found out that it actually reads the properties correctly, but still does not start the update checking. I have spent a lot of time trying different ways to trigger the update checking, but with no luck.

Then I noticed that if I remove the checkForUpdatesInBackground method call, the update checking initiated from Menu Bar actually works. But it stopped working as soon as the programatic update checks were reintroduced. At that point I had no choice but to start digging the Sparkle source code for clues.

After reading the source code, I found out that Sparkle uses different "drivers" for different update checks. This suggested me that the one that is used for background checks doesn't work correctly and thus needs some modifications. However, it didn't look that different from the "driver" that was used in user initiated update checks and worked perfectly fine.

These small differences between two drivers really puzzled me because they were only related to UI. So I modified the framework to use the driver that is normally used in background checks for user initiated checks. And after that updating worked just fine! At that point it was clear that the drivers themselves work just fine and the problem is in initiating the update checks programatically in the dylib.

The next step was to track down which piece of code fails when the update check is initiated programmatically. It was the creation of NSURLConnection which did not call some delegate methods that indicate the successful creation of the connection and the data downloading. The class reference for NSURLConnection says that "For the connection to work correctly the calling thread’s run loop must be operating in the default run loop mode." I made some stupid things trying to satisfy this condition :wink: Then I simply changed the asynchronous loading of data to synchronous and the programmatically initiated update checks finally started to work!

However, after a few runs I got several crashes which were caused by threading issues. Crash reports reminded me Apple technical note TN2147 about JNI programming which I read before. After reading "When you make calls to AppKit that may result in a view refresh or some other event-based action, you must make those calls on the main AppKit thread" I had a big "aha!" moment and understood that all I needed to do was to call the checkForUpdatesInBackground method in the dylib on the main thread and do so asynchronously.

So in the end it is just

[suUpdater performSelectorOnMainThread: @selector(checkForUpdatesInBackground) withObject:nil waitUntilDone:NO]

instead of

[suUpdater checkForUpdatesInBackground]

and no modifications to Sparkle.framework.

Cheers,
Egidijus

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Romain,

Hi Egidijus,

So I think that the only solution is to update the Sparkle.framework to a version that supports x86_64 architecture. We can do this by either:

1) using the latest version (1.5b6) of Sparkle, or
2) updating the 1.1 version of the framework to support x86_64

I would go for option 1), as we'll certainly keep updating sparkle with time, so it's the good opportunity to switch to the latest version directly. Furthermore, a little bit more security by signing the packages would not hurt.

I also think that updating to the latest Sparkle framework version is a better way to go. I have been working on this for the last few days (thanks again for your help with a test server), however, it is harder than I thought. The signed updates work, but only if they are manually initiated from Menu.

I see from the comments in the code that you had problems initiating an update check on the startup, and solved it by doing it programmatically. This doesn't work anymore since Sparkle now uses so called "drivers" that are different for each type of update check. For example, the user initiated update checks use SUUserInitiatedUpdateDirver, programmatically initiated checks use SUSheduledUpdateDriver, etc. It looks like the SUSheduledUpdateDriver doesn't work when Sparkle is used from dylib and I don't know why yet. Now I am thinking of doing what I wanted least - to modify the Sparkle.framework source code. I will try to find a problem in the driver that doesn't work, and compile a custom Sparkle.framework.

Cheers,
Egidijus

···

On 5 Aug 2009, at 13:55, Romain KUNTZ wrote:

On 2009/08/04, at 17:23, Egidijus Jankauskas wrote:


#6

Hi Egis,

Thanks for the detailed report. I'm glad to hear you could come up with a solution that works and does not need changes in the sparkle framework.

I've received your patches in the point-to-point mail you sent me. I must admit that I'm quite impressed by your autonomy, it has been a pleasure to work with you the past weeks. I will try to update the SC packages with the new version of Sparkle ASAP.

Cheers,
romain

···

On 2009/08/13, at 16:58, Egidijus Jankauskas wrote:

Hi all,

I have found a solution to Sparkle issue. It took me much longer than I expected and it is kind of funny because in the end it is just one line of code... So here is a little story:

The initial problem was that Sparkle didn't work on Java 1.6. It didn't work because the dynamic library with the native code couldn't be loaded, and it couldn't be loaded because it was not compiled for x86_64 architecture. The library was not compiled for x86_64 because the Sparkle.framework itself did not support 64 bit architecture.

So we decided to update the Sparkle to the latest version which supports x86_64 and in addition has some major security enhancements. Then it turned out that native code in the Sparkle library doesn't work anymore. Sparkle is normally configured via Info.plist in application bundle and I found out that it actually reads the properties correctly, but still does not start the update checking. I have spent a lot of time trying different ways to trigger the update checking, but with no luck.

Then I noticed that if I remove the checkForUpdatesInBackground method call, the update checking initiated from Menu Bar actually works. But it stopped working as soon as the programatic update checks were reintroduced. At that point I had no choice but to start digging the Sparkle source code for clues.

After reading the source code, I found out that Sparkle uses different "drivers" for different update checks. This suggested me that the one that is used for background checks doesn't work correctly and thus needs some modifications. However, it didn't look that different from the "driver" that was used in user initiated update checks and worked perfectly fine.

These small differences between two drivers really puzzled me because they were only related to UI. So I modified the framework to use the driver that is normally used in background checks for user initiated checks. And after that updating worked just fine! At that point it was clear that the drivers themselves work just fine and the problem is in initiating the update checks programatically in the dylib.

The next step was to track down which piece of code fails when the update check is initiated programmatically. It was the creation of NSURLConnection which did not call some delegate methods that indicate the successful creation of the connection and the data downloading. The class reference for NSURLConnection says that "For the connection to work correctly the calling thread’s run loop must be operating in the default run loop mode." I made some stupid things trying to satisfy this condition :wink: Then I simply changed the asynchronous loading of data to synchronous and the programmatically initiated update checks finally started to work!

However, after a few runs I got several crashes which were caused by threading issues. Crash reports reminded me Apple technical note TN2147 about JNI programming which I read before. After reading "When you make calls to AppKit that may result in a view refresh or some other event-based action, you must make those calls on the main AppKit thread" I had a big "aha!" moment and understood that all I needed to do was to call the checkForUpdatesInBackground method in the dylib on the main thread and do so asynchronously.

So in the end it is just

[suUpdater performSelectorOnMainThread: @selector(checkForUpdatesInBackground) withObject:nil waitUntilDone:NO]

instead of

[suUpdater checkForUpdatesInBackground]

and no modifications to Sparkle.framework.

Cheers,
Egidijus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Egis,

I would go for option 1), as we'll certainly keep updating sparkle with time, so it's the good opportunity to switch to the latest version directly. Furthermore, a little bit more security by signing the packages would not hurt.

I also think that updating to the latest Sparkle framework version is a better way to go. I have been working on this for the last few days (thanks again for your help with a test server), however, it is harder than I thought. The signed updates work, but only if they are manually initiated from Menu.

I see from the comments in the code that you had problems initiating an update check on the startup, and solved it by doing it programmatically.

Yes, I remember I couldn't get the startup check working, so the code force an update check programmatically.

This doesn't work anymore since Sparkle now uses so called "drivers" that are different for each type of update check. For example, the user initiated update checks use SUUserInitiatedUpdateDirver, programmatically initiated checks use SUSheduledUpdateDriver, etc. It looks like the SUSheduledUpdateDriver doesn't work when Sparkle is used from dylib and I don't know why yet.

That's annoying. In any case, I guess a startup check would be enough to start with. If you can concentrate on this one, that would be enough.

Now I am thinking of doing what I wanted least - to modify the Sparkle.framework source code. I will try to find a problem in the driver that doesn't work, and compile a custom Sparkle.framework.

Ok, if this is the way we choose, it might be a good idea to send a patch to the Sparkle community. Maintaining modified framework on our side can be painful on our side.

Cheers,
romain

···

On 2009/08/07, at 21:01, Egidijus Jankauskas wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hello all,

I'm trying to implement a new Effect PlugIn in SC and to register it whit the PlugInManager.
What I'v allready do is:

1. I have created a new package "...impl.media.effect"
2. I have created a new class:
    2.1 GainEffect
Example 6-4from http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/guide/JMFExtending.html

So my question:

How to register the GainEffect?

I have founded the Example 6-6 from the same website. But I don't understand where to implement the code from this example in SC.

What else is important by the implementing of a new Effects?

Thanks and BR.

Nikolay Velichkov


#9

I don't know about Effects but the reference you've provided notes
that Effects are just like Codecs. Did you look at how we register our
Codec implementations in .impl.media.codec.EncodingConfiguration?
Based on the code there, I'd expect the registering of Effect
implementations to be done through PlugInManager#addPlugIn() with a
type of PlugInManager#EFFECT.

···

On Mon, Aug 10, 2009 at 6:34 PM, Nikolay Velichkov<nikipetev@yahoo.de> wrote:

Hello all,

I'm trying to implement a new Effect PlugIn in SC and to register it whit
the PlugInManager.
What I'v allready do is:

1. I have created a new package "...impl.media.effect"
2. I have created a new class:
2.1 GainEffect
Example 6-4 from
http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/guide/JMFExtending.html

So my question:

How to register the GainEffect?

I have founded the Example 6-6 from the same website. But I don't
understand where to implement the code from this example in SC.

What else is important by the implementing of a new Effects?

Thanks and BR.

Nikolay Velichkov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net