RSL Error 1001

cxf02Author

Participating Frequently

Okay Darrell,

Your file worked. I was able to run with ,45, after uploading it to the server. I believe I understand why this was happening. You can tell me if I’m wrong, if it matters. Below version ,115, the player RSL’s are not signed and the player loads the swc file, not the swz file.

This became apparent to me when I saw that on the FLEX Build Path-->Library Path Tab, there existed a build path library of:

framework.swc.

Expanding this library revealed an RSL URL property with the signed library -- framework_3.0.189825.swz – as the value.
Underneath the RSL URL as an attached property is listed the Failover RSL URL with a value of -- framework_3.0.189825.swf --.

I’m a simple man, so I’ll just put it this way… When the player can’t make sense of an swz file because it can’t load signed files, it looks for the swf file. Since the swf is not signed, it has a digest that links it with the application to provide security protection. For some reason the framework_3.0.189825.swf library that came with the sdk and by default was being used by my application was not linked properly. By the way, this happened on a new install to a virgin machine.

Okay, I used the ant file, and had to modify it to get it to work. For one, it’s not well formed, missing a /java end tag. Second, and this is what I need you to verify for me, I don’t know why the line

OpenElementTag--arg line="--digest.rsl-file @{rsl-dir}/@{swc-name}.swf --digest.swc-path @{swc-dir}/@{swc-name}.swc" --CloseElementTag

would work because the swc-name needs to be framework in order for the optimizer to output it with the correct name (at least to stay within the naming conventions we are using). So what happens is the argument line --digest.rsl-file @{rsl-dir}/@{swc-name}.swf cannot find the swf that was created by the optimizer since the swc-name variable does not match the name that was created with the optimizer (--output '@{rsl-dir}/@{swc-name}_3.0.${build.number}.swf' = framework_3.0.189825.swf). I tried to use the ${build.number} again, but it must be getting assigned from the metadata of the optimizer, I can’t quite figure it out. I finally got it to work, by hard coding the name in like so…

OpenElementTag--arg line="--digest.rsl-file @{rsl-dir}/framework_3.0.189825.swf --digest.swc-path @{swc-dir}/@{swc-name}.swc"--CloseElementTag

I’ll get back into my Ant documentation and see if I can figure out how to code for that.

I am attaching the build file I created. Place it in the root\sdks\3.0.0\frameworks directory and it should work right out of the box. It is setup to use the standard directories. This is a windows installation, but it should work on Linux.

I hope we can put this to rest. Please correct me if I have misunderstood what is happening. You have my heartfelt thanks for your assistance and if you're at the 360 conference, let me know and I'll buy you a draft.

Sincerely,

Inspiring

Your right about how signed RSLs will failover to unsigned RSLs. Both the signed and unsigned RSLs have a digests for security. The problem with framework_3.0.189825.swf is that it was not packaged in the sdk when it should of been and you ended up with a bad one (either thru your efforts to create one or Flex Builder created an unoptimized one for you). I'm sorry this error has caused you so much grief but I'm glad you kept working with me to get to the bottom of the problem. The missing RSL was a one time mistake and shouldn't happen again.

In regards to the Ant task. Your right the output of the optimizer does not match the input of the digest tool. My mistake, sorry about that. To fix the problem I would change the --output argument of the optimizer by removing the _3.0.${build.number} from the name. This change would make the --output argument look like this --output '@{rsl-dir}/@{swc-name}.swf'.

The ant task in the tutorial was not supposed to add the build number to RSLs like the ones in the SDK. It was for folks to roll their own RSLs. Since you were wondering about the where the {build.number} comes from, it's defined as an argument to ant on the command line.

>ant -Dbuild.number=189825

cxf02Author

Participating Frequently

Darrell,

I just backed out of ,115, and used the archives of Flash player to load ,45,. The RSL error appeared after 50% showed loaded on the progress bar.

I then upgraded to ,47, and the error appeared immediately without any progress bar load showing. The PG bar showed up at the same time as the error.

I then upgraded to ,115, and the site loaded without errors.

Tracy, why don't you upgrade and see if you get the same results?

Darrell, I can give you full access to my linux server if this will help you. You can use an FTP client to pull the files down and examine them. Just send me an email at -- curtis dot fisher at procontent dot net --- and I'll create a temp account for you.

Thank you,

Inspiring

Curtis and Tracy,

You both seem to be having the same problem. I think you are both using Flex Builder. Note that when you upgrade Flex Builder you will get a new sdk build. The RSLs of a new sdk build will change so you will need to edit your existing project properties for the Flex Build Path so the RSL URLs for framework.swc match the new rsls that are in sdk directory. Please see the tutorial link below for an example of how to modify RSL information in Flex Builder.

It sound like you are using sdk 3.0.189925 because the RSL signed by Adobe, framework_3.0.189825.swz, is loading correctly when you use a Player that knows how to load signed RSLs (version 9,0,115,0 and higher). If you are not using sdk 3.0.189925 then disregard the rest of my instructions here. The solution is to fix either framework_3.0.189825.swf (may not be created correctly) or framework.swc (may have the wrong digest).

First let's verify framework.swc. framework.swc contains a file called catalog.xml. In catalog.xml there is a piece of xml that contains the expected digest of framework_3.0.189825.swf. See the attached code for it should look like. If your catalog.xml contains the same digests, then your framework.swc is correct. If it is not correct then get another copy of the flex3 beta3 sdk (version 3.0.189825) replace framework.swc.

Now to framework_3.0.189825.swf. I have created one that has the correct digest. Send me your email address and I will send it to you. If both of these are correct there should be no digest errors.

See this tutorial

cxf02Author

Participating Frequently

Geez, me offering you advice... That's rich. I use Eclipse and the FLEX build is 3.0.190133. Is this correct? Do I need to look somewhere else for version numbers?

I also tried recreating the library as I stated at the begining of this thread, and it did not make any difference (although I don't know If i did it correctly). I'm really confused now. If there isn't a difference between players concerning the RSL error message, then why did the error go away when I upgraded the player to 9,0,115,0?

Not to be arm waving, but why does Mac state that the ,115, player is necessary to display beta 3 properly? He may be talking about other issues, but this is certainly an issue even if it is brought on by misconfigured libraries. I'm pretty sure I did it correctly because i did it 3 times, but I'm not sure if the instructions were correct in the first place. If it is as you state, a library issue, then can someone post an explicit set of instructions for resolution (step 1, step 2, and go slow...) so that we don't have to find a solution on a Chinese web site?

Thanks for your patience. I appreciate your help with this.

cxf02Author

Participating Frequently

I'm sorry for the miscommunication on my part Darrell. This is Windows XP, not Linux, and only after I upgraded to 9.0.115.0 did the issue go away. I was assuming that the issue was the same on both operating systems since it only began after i installed the latest 3.0 beta, compiled and redeployed. I really don't know all the details of signed and unsigned swf's, swz's and I haven't read up on the differences between .45 and .115.

If this is an issue because signed files are now being loaded into the player for beta phase III, where in beta 3 phase II (I can't think of the actual version) they weren't, AND the only error that shows between the two players is the RSL Error, then there will be problems with users who are running an earlier versoin of the player. Take a look at the thread on the subject from a FLEX Team Developer, Mac: http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=651&threadid=1335562&enterthread=y

Anyway, sorry about the misunderstanding. Try upgrading and see if it goes away. Let us know if it doesn't fix it. We're coming down to the wire and I for one, don't need these kind of surprises! I'm hoping the default html has a sniffer that gets the user to download a new player. I don't know what edfrk from the other post will do besides push out a new policy to the 10K+ users, but a more better browser sniffer will have to be part of the solution.

Thanks again...

Inspiring

I also work on the Flex team. I implemented the RSL feature for Flex 3.

Just to be clear, Flash Player 9,0,115,0 is NOT required to avoid the digest mismatch error . I think the problem is either the RSL, framework_3.0.189825.swf, was not created correctly or the framework.swc's digest information was incorrectly changed.

cxf02Author

Participating Frequently

Thank you very much Darrell, the issue is that the Plugin 9,0,45,0 was installed. I needed to upgrade to 9,0,115,0. I predict this is an error that most users will not be able to recover from without a high degree of mistrust with Flash.

If the community begins releasing applications compilied with 3.0, and with all the 9.0.x.x plugins out there, if there is no prompt other than this RSL issue popping up, it will create a negative stir that many users will carry on about for far too long. No doubt I'll hear about it for weeks after deployment, and I don't have the bandwidth to deal with it.

I confess that the simple is usually the most overlooked, but unless there is something we can do with the html wrapper for browser sniffing the .x version on the final 3.0 Gold release (I know it can be done, I'm thinking I shouldn't have to do it!) , this will give me concern for deploying my almost completed application out to 1000's of internet users.

Inspiring

Flayer Player 9,0,45 should be fine. You should NOT need to install Flash Player 9,0,115,0 to load unsigned RSLs (swf files). Version 9,0,115,0 is only needed to load signed RSLs (swz files).

If upgrading to Player 9,0,115,0 solved your problems on Linux then that means you are now loading the signed RSLs and not having to deal with the unsigned RSL that was failing before. I suspect the framework_3.0.189825.swf deployed on the server is does not have correct digest, but I would really like to know if installing Player 9,0,45 on Windows causes it to display the digest mismatch error or this this problem is isolated to Linux.

Inspiring

One thing to try to trouble shoot the issue on Windows is to run the application with a Flash Player below version 9,0,60. This will force the signed RSL, framework_3.0.189925.swz to be skipped and force the loading of framework_3.0.189825.swf. When you do this are you getting a digest mismatch error? If not, double check the player log to verify the swz file was skipped and you failed over to the swf file. If the swf file works on Windows, then you know the digest is correct and it's a Linux issue. The only platform issue I'm aware of is that the Player does not support 64-bit Suse.

A

Anonymous

Hi Darrell

I did this test as you suggested, from Windows, running our app with Flash Player 9.0.16 installed.
We got the RSL error:
Flex Error #1001: Digest mismatch with RSL framework_3.0.189825.swf. Redeploy the matching RSL or relink your application with the matching library.

What does this mean? Is it a Flex issue, is it a library issue within our application? Is there any solution?

Cheers
Tracy

cxf02Author

Participating Frequently

Come on sombody, help us out. This too may happen to others when they deploy. It doesn't occur if you run it on the development machine.

A

Anonymous

Hi

We are experiencing the same problem. Also using Flex3B3 with framework_3.0.189825.
Our app runs fine on Windows, but running it from a Linux machine gives us the RSL error.
I have tried every permutation of the fix mentioned in the link:
http://www.duzengqiang.com/blog/article.asp?id=681
... from merge / not merge, include framework / rpc. swf /swz as an RSL
I have tried with downloading the latest SDK (3.0.0.409) and still get the same RSL error on Linux.
I also tested with & without our charting components, even tried moving the framework.swc up in the list above datavisualization.swc as advised in this link (bottom of page):
http://labs.adobe.com/wiki/index.php/Flex_3:Release_Notes
I've also moved the framework.swc to the top of the list.
It all works fine if I merge everything into code, but as soon as I set framework.swc to an RSL I get the error.

We desperately need this fix for linux users of our app that's in production.

Also, is there any chance I may have corrupted my framework.swc after attempting the optimizer / digest processes discussed in the possible fix?

Cheers
Tracy

Inspiring

I'm surprised your getting the same RSL failure with 3.0.0.409. That build comes with framework_3.0.0.409.swf in the frameworks/rsls directory of the sdk. Are you using Flex Builder to create the application or the command line?