Flex modules and application context loading

[arnoudb]

Nice!

It all works now as far as i can see. I also like the abstraction into a class in lang of the SoftReference.

I am afraid that applicationDomains are read-only... So you'll have to load a module to test. But i understand you want a unit test and not an integration test. I was recently looking at mocking and unit testing in flex. The next stuff looks good:

http://bitbucket.org/loomis/mockito-flex/wiki/Home
http://www.compactcode.com/index.php...-flex-mocking/

I wonder if you can Mock an applicationDomain... On the other hand, why not? Anyway this doesn't look like a usual case and i personally would go for the integration test... Looks easier.

Have a good weekend and thank u very much!

Arnoud

[666shooter]

Hey Arnoud,

you can't believe how relieved I am that things seem to be working now The multi-module/applicationdomain support was a very important feature to me and now that things seem to be running in order I am pretty damned excited Thanks a lot for your time, patience and understanding
I will look into the mocking solutions you posted, but I agree with you that the integration tests would probably be easier to implement.

cheers!

Roland

[arnoudb]

Hi Roland,

I've been testing the module wiring intensively but there seems to be a few things not working entirely right, yet.
But i understand you didn't notice because it's a specific case:

There are 3 issues:

1. In some places the ClassUtils doesn't use application domain in for example the AbstractObjectFactory. This didn't give me direct issues but i think that in the AbstractObjectFactory always should use that second parameter when using ClassUtils.forInstance etc. For example:
   

   // arnoud: added _applicationDomain
   public function getClassForName(className:String):Class {
   	return ClassUtils.forName(className, _applicationDomain);
   }
   	
   // arnoud: added _applicationDomain
   public function getClassForInstance(object:Object):Class {
   	return ClassUtils.forInstance(object, _applicationDomain);
   }

2. When autowiring singleton models into other objects also defined into application context i get null pointers
3. The autowiring of stage components does behave a bit unpredictable in some cases

I made a proof of concept (modification of your module example) in which the last 2 cases cases appear. See picture:



explanation of the picture:

• the autowiring stage component in the empty box right under the application doesn't work (even without the null pointer)
• the null pointer speaks for itself. It only happens sometimes though. If you build the application sometimes it works, sometimes not. I think it's a timing issue. In my bigger application it happens all the time. If the application works for you reload the application a few times (fast) in you browser and the null pointer should show up. It happens in the wire method in which a Property instance of a context object has a type that is null. So property.type.clazz gives a null pointer exception. The funny thing is is that the rest of that property is correctly filled, it's just the type that is null. I have a test application (flash builder 4 project) on the next url for you to try out (it's the same of the picture above): http://www.artim-interactive.nl/arno...module_sas.fxp.
  The issue occurs if:
  
  • in the context objects are wired together
  • the context wiring is byType
  • the scope of the objects to wire together is singleton
  • if the main application and the modules use a context. So if the the same module is loaded in an application and that application doesn't have an own context the problem doesn't seem to occur.

I hope this gives you enough detail about the problems!

I really hope you can give it another look. Although i'm getting pretty deep into the framework it's still a bit daunting and you probably know better what happens under the hood.

Another question completely off topic. Do you know how to compare 2 application domains? ApplicationDomain.currrentDomain == ApplicationDomain.currentDomain returns false
It's not that hi have to directly compare them but i need to identify them uniquely. I cannot find a way to do this. The don't have a unique id etc...

I alreaddy filed a bug but i cannot find an alternative solution in google, and i did search for a long time...

Cheers!

Arnoud, the demolisher

[666shooter]

Hey Arnoud,

thanks a million for doing these tests, too bad some more bugs have crept up
You're actually right that the two getClass* methods in AbstractObjectFactory need to pass their applicationDomain as well. These two methods are overridden in the FlexXMLObjectFactory where they do receieve an applicationDomain though, so I'm pretty confident that the problem lies somewhere else, I'm gonna try anyway of course, just to be certain.

You also point out that some null pointers only happen once in a while, this leads me to suspect the soft-reference to the applicationdomain in the Type class. I have no idea how this pointer can ever become null, but it *seems* like that is happening. Because this circumstance would lead exactly to the aforementioned problem where all of a sudden the type of a property becomes null.
Of course, this is all conjecture and I'm going to have to test this stuff myself. I'm pretty swamped in work right now, so I hope I'll have time for it this evening, I'll do my best.

As for your question about comparing instances, in actionscript if you want to compare two references its best to use the === operator. Which is a strict comparison. (The opposite is !== of course)
I'm pretty sure ApplicationDomain.currrentDomain === ApplicationDomain.currentDomain will yield 'true'.

Anyways, thanks for the demolishing And I'll get back here with my finding as soon as I find the time for them.

cheers!

Roland

[arnoudb]

Hi Roland,

I was playing some more with the module sytem with the debugger.
I cannot find the problem, but i did a extended search on ClassUtils.forName with less than 2 parameters. Enter the next line in the extended search of flex builder in the projects of asCommons and of sptingactionscript (not entirely right but filters out much redundant stuff):

ClassUtils.forName\([^\,\)]*\)

and make sure you search on regular expressions.

I found several potential problematic calls that don't pass in n applicationDomain
The problem may be in one of those, but not sure. But after seeing these calls without applicationDomain i do think the whole reflection system needs another critical look.

cheers!

Arnoud

[666shooter]

Hey Arnoud,

I actually did exactly the same thing after your previous bug report
I think I changed the most serious offenses, I've been refreshing the app for like 20 times and don't get any errors, but I didn't manage to reproduce the exception in the first place, so I'm definitely not sure whether its fixed or not...
Please check update to the latest as3-commons and spring actionscript trunks and try again, I'm still rather busy with my current project, so still not a lot of time for investigating this, but i'd appreciate it if you can give it another go.

cheers,

Roland

[arnoudb]

Hi Roland,

I did an svn update but i dont see changes in the trunk for the reflection api. Did you commit the changes?
If I do de search of my previous post i still see the problematic calls ClassUtils.forName without an application domain as parameter.

ObjectDefinitionScanner --> in scanClass
MXMLObjectDefinition --> in set className and resolveValue
BaseObject --> in doEquals
FieldRetrieivingFactoryObject --> in afterPropertiesSet
AbstractObjectFactory --> in isFactoryObject
InterfacePreprocessor --> lookupImplementingObjects
ClassPropertyEditor --> set text
ApplicationUtils --> get application
Environment --> isFlex

Maybe they are not all problematic but i think these should be checked.

About those application domain comparisons. You suggested to use === instead of == to compare 2 applicationDomains. But that cannot help === is more strict. So if ApplicationDomain.currentDomain === ApplicationDomain.currentDomain gives true than ApplicationDomain.currentDomain == ApplicationDomain.currentDomain will definitely give true. I did a test to prove it. It's at the moment just not possible to compare 2 applicationdomains i'm afraid. Maybe it's a security thing don't know why they implemented it this way. I did file a bug in the Adobe flash player jira. I'll let you know if i get a response.

I'm finding more weird stuff about applicationDomains: If you load the same module twice they share the same applicationDomain. If you add a query string to the url propery of the moduleLoader so that the url is differen they have each their own application domain:

modulea.swf?bla has different application domain than modulea.swf, but if you load modulea.swf twice both without querystring they share the same applicationdomain. The Adobe documentation on ApplicationDomains sucks big time as these things are not documented anywhere....

One more question is it necessary that modules extend BasicSASModule?

I know you are really busy, so no hurries! I'm really happy that you are looking into these issues when you have time. I do think it's important cause it touched the core of the system.

cheers, and keep up the good work! I'll be doing some digging as well!

Arnoud

[666shooter]

Hey Arnoud,

from what I understand now this: ApplicationDomain.currentDomain, always returns a new instance. How and why this is, I have no idea, but that's apparently default behavior.
The list of classutil calls you give is correct, yet this code is not called upon in our module test app, so for now I left these alone. I also want to have a more consistent pattern to pass on the correct applicationDomain throughout the library, I'm debating this with the team, so in time all of these calls will be correct ones with an app domain an extra argument.
Interesting finds by the way, apparently an applicationdomain is tied to the URL that the module was loaded with, I wonder what the reasoning behind this is.
Yet, my other problem also remains, I've imported your test project in flash builder and have just been refreshing the app for at least 25 or 30 times and still I never encountered the run time exceptions that you describe.

And, and about BasicSASmodule, NO WAY, it is absolutely NOT necessary to extend this class, I've only included it as a convenience base class in the case where a module's application context needs to be automatically created with the main application context as its parent.
This kind of automatic injection will probably not end up in the final library anyways, we are now contemplating a sort of module policy system where you as the developer can determine what an app context will do with a module that gets loaded, either it injects it, ignores it, or does something else. Like I say, we're still debating that one. If you have ideas on this subject feel free to share them with us, an extra brain in this discussion is always more than welcome.

So, that's it for now, I'm gonna try some more to reproduce that damned exception...

cheers,

Roland

[arnoudb]

Hi Roland,

Nice that you guys are on it! I think the way you described is the way to go. Let the parent application (the boss) determine how a module is loaded and if or not the main application context can be used by the module. I would suggest a custom module LoaderContext that extends the default LoaderContext with some extra properties like parentApplicationContext and maybe some other restrictions or features that i cannot come up with now.

For the test application that i build: I can't get the damn error either anymore. So save your valuable time on that one. I'll do some more investigation and if i get consistent errors instead of sometimes i'll let you know. It's strange that it wont show up again. But you saw the screendump of the error....

Anyway i still have some problems with a bigger application. I'll try to isolate the bug and try to reproduce it in the simpler test application.

thanx again and have a nice weekend!

Arnoud

NB I'm thinking about becoming a committer for the project (if that's possible) I don't have much time but now and then i could clean up some code, do a little code reviews and bug fixing. Is that possible? I like the framework philosophy and i'm getting into deeper and deeper anyway, so why not contribute a bit instead of just filing bugs/request? Don't mind doing some documentation stuff either... Let me know!

[666shooter]

Hey Arnoud,

we thought about a custom loader context as well, but decided against it in the first place, we'd like to make use of the standard Flex patterns as much as possible. In the future such a loadercontext can still be added, but more in a conveniece type of situation, we wouldn't want to rely on it for functionality.
I definitely believe that you received the error The screendump doesn't lie hehe (or maybe you photoshopped it, hmmmm). I did make some minor changes to the library in between, so I might have caught it accidentally, I really have no idea. If you manage to reliably reproduce it, I'd still be very interested.

As for becoming a committer, YES PLEASE We appreciate all the help we can get, in any manner or capacity. I started out writing all of the documentation, after that I had seen every nook and cranny of the library and was confident enough to start developing new functionality.
So if you'd like to start out doing code reviews, writing unit tests, writing small sample applications, how-to articles, anything really, your help will be welcomed.
If you decide to go for it then contact Christophe Herreman directly through the forum and offer him your services He will be able to send you the appropriate forms to sign and you'll receive commit access after that.
We're an official Spring incubation so you'll have to sign the standard Spring opensource agreement, but you'll see what that entails, its nothing too special really, just a matter of signing some stuff.
In my case it did take a very long time for the forms to be processed though, so I hope in your case it will be quicker.
Anyways, I'd like to have you on board, so please consider joining

cheers,

Roland