This content has been marked as final. Show 8 replies
Hi Thierry. The Fault.rootCause property contains a serialized map of the exception but you can't map the exception to a custom AS class.
First of all, I thank you for your answer.
Something really funny: I tried several times to map my exception before
I realized that even ResultEvent.result didn't map anymore with
my remote result class !
The cause was the following: all the remote service calls were performed within
a library, and it seems that the Flex library compiler does not generate the [RemoteObject]
tag artifacts (unlike the Flex application compiler).
Now, I call the flash.net.registerClassAlias method for each remote class (in a static region) and it works fine.
Last but not least, the exceptions are correctly mapped with my fault events too !
I need you to confirm I ain't drunk !!!!!
If I am right, maybe the documentation could emphasize on that feature ?
Are you sure you've spelled the metadata correctly?
It needs to be: [RemoteClass(alias="...")]
If the compiler encounters metadata it is not familiar with the metadata is simply ignored.
The [RemoteClass...] metadata is a convenience tag. When present, the compiler generates the appropriate call to registerClassAlias() for you and ensures that the call is made before the application starts running and requests instances of this type from the server.
Sorry I spelled incorrectly [RemoteClass(alias="")] in my last post. So it is not the issue.
The fact is that the compiler does not generate the RemoteClass artifacts (i.e registerClassAlias)
while compiling a library . It works fine with an application .
You can join my point of view by creating a library project including a [RemoteClass(alias="")] tag, adding the -keep-generated-actionscript=true compiler option, and finally scanning the generated AS files: no trace
of any registerClassAlias call is found.
That's why I have to do it "manually".
I've finally had the chance to try to repro the library project issue you had and it works fine for me.
1. I created a simple library project with one class in it, Foo.as, that has RemoteClass metadata:
public class Foo
2. I made sure this class was selected to be included in the generated swc (Properties > Flex Library Build Path, Classes tab) and I compiled to generate the swc.
3. I created another simple non-library project and added "-keep" to the compiler command line arguments (Properties > Flex Compiler > Additional compiler arguments), and added the generated swc from the first project (Properties > Flex Build Path, Libary path tab > Add SWC).
4. Here's the simple mxml app:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx=" http://www.adobe.com/2006/mxml" creationComplete="initApp()">
private function initApp():void
var f:Foo = new Foo();
5. And here's the code-gen'ed line in _<appname>_FlexInit-generated.as that corresponds to my RemoteClass metadata:
So in this simple scenario everything worked as expected. You may want to try refreshing your projects, re'adding the swc, etc. to try to identify why this was failing for you.
Thanks for your investigations ; I keep your results in mind.
But I have to apologize because I missed to give you more informations about my project.
The fact is that my library is dynamically loaded (using the Loader class) and are
never included in my application "library path".
Also, with your prototype, what's happen if you decide to link your library as a RSL for instance ?
I imagine the artifacts are not generated too.
I think that only a library "statically" included within an application (i.e with "merged into code" option selected)
can see its binding artifacts generated. Do you agree ?
Things should work correctly if you compile your app using the -compiler.external-library-path and -runtime-shared-libraries options with mxmlc.
When you compile your app and don't give it any knowledge of these classes tagged with [RemoteClass] metadata that you'll be loading at runtime, you're correct that the registerClassAlias() call won't be code-gen'ed.
Sorry I'm replying late to this, Thierry - what you're trying to do is indeed supported in Flex 2. We serialize Throwable types as Beans (although we include read-only properties). If the client does not have a matching ActionScript class registered with a matching alias as the Java exception type, an anonymous Object will be created with properties matching the "bean" properties. It seems you've now worked out what the issue was while talking to Seth.