Hey Alex, I think just nailed this one :) > > Right now, I think I want to know why that one test fails when run as the > > full set and passes on the failures run. So the failed test that is being run again is not the same test that was throwing the exception. The test that throws the exception is: ResourceManager_Methods_findResourceBundleWithResource RTL_ResourceManager_Method_findResourceBundleWithResource_1LocaleChainItem_InvalidLocale Specifically an exception is thrown at ResourceManager_Methods_findResourceBundleWithResource.mxml line 137. But because the exception dialog is visible this causes a different test which started earlier to timeout. Specifically this one: resources/ResourceManager/Integration/ResourceManager_Integration_UIComponent_resourcesChanged ResourceManager_Integration_UIComponent_resourcesChanged_localeChain
And in the end the process gets clobbered. This means that if you ran again using the -failures, then it will run the one that timed out, and not the one that had the exception. Since there is no exception dialog causing it to timeout again, it will pass. Considering the RTL_ResourceManager_Method_findResourceBundleWithResource_1LocaleChainItem_InvalidLocale test had an exception means it was unable to "cleanly fail" and add it's entry into the failures.txt file. So in summary. The issue the entire time was that we were intentionally not loading the fr_FR locale as it was part of the test. So we should not have the .compile file. See from my previous email: > I did take out the exception throw and got only 4 failures. Then I decided > to take out the .compile file as I noted that for the tests we are building > up custom bundles and are not using the ones in the sdk locale folder. And > now I can pass all 417 tests without any issues. So having the .compile file does cause other case tests that use the German local to fail. This new exception was being thrown so we were unable to properly proceed with the RTL_ResourceManager_Method_findResourceBundleWithResource_1LocaleChainItem_InvalidLocale test case (and two others later on). The exception dialog causes a previous test that we started earlier to timeout and get added to the failures.txt file. Two options I see right now are to either rollback the adding of the exception to ResourceManagerImpl.as, or simply obsolete tests that reference an unloaded locale (three in total). I'm inclined to remove the exception so the SDK will behave has it had prior to 4.10.0. I didn't see any tickets related to this change, and nothing in the RELEASE_NOTES for 4.10.0 to give more information about the change. As always, open to other ideas on how to get this going again. Super excited to have nailed this one down :D Chris > From: chrsm...@outlook.com > To: dev@flex.apache.org > Subject: RE: Could not find compiled locale with mustella ResourceManager > tests > Date: Fri, 12 Dec 2014 00:18:16 -0700 > > Sure! I too am curious why it fails in the group but passes when we run it by > itself. The exception throw didn't go anywhere. > > I did take out the exception throw and got only 4 failures. Then I decided > to take out the .compile file as I noted that for the tests we are building > up custom bundles and are not using the ones in the locale folder. And now I > can pass all 417 tests without any issues. > > I think first i'm going to add in a test case for FLEX-25045[1] and make sure > it clears now that I got a clean test pass. That and I'd like to get that > fix in for 4.14.0 ;) > > Then i'll put back in the exception throw and try to figure out what is going > on. Oddly enough i'm still having issues with the file being created in the > C:\tmp folder. I can create a file there myself, through my console window, > so I'm not sure why the script cannot. > > Chris > > [1] https://issues.apache.org/jira/browse/FLEX-25045 > > From: aha...@adobe.com > > To: dev@flex.apache.org > > Subject: Re: Could not find compiled locale with mustella ResourceManager > > tests > > Date: Fri, 12 Dec 2014 06:43:56 +0000 > > > > Hi Chris, > > > > Right now, I think I want to know why that one test fails when run as the > > full set and passes on the failures run. I think if it had failed on the > > failures run then we’d have looked deeper earlier and realized we broke > > the ‘missing bundle’ case for findResourceBundleWithResource(). We might > > need to think about reverting the code that throws an exception when a > > bundle isn’t found, or at least making that particular API work like it > > used to. Are you interested in looking into that? > > > > Thanks, > > -Alex > > > > On 12/11/14, 9:52 PM, "Chris Martin" <chrsm...@outlook.com> wrote: > > > > >Hey Alex, > > > > > >Yeah I see what you mean. I think I figured out what happened. We have > > >a commit made to ResourceManagerImpl.as[1] which I believe now obsoletes > > >those types of tests because we now throw an exception if it was unable > > >to find the locale. So really we cannot get ourselves into that > > >situation anymore. > > > > > >Should I just comment out those tests? > > > > > >BTW, I did comment out the first two tests to see if they were mucking up > > >the ResourceManager, and I still got the same error. That lead me to dig > > >deeper > > > > > >Chris > > > > > >[1] > > >https://github.com/apache/flex-sdk/commit/ae28ab34c558957927471d54ce2a0ca6 > > >aace6207 > > > > > >> From: aha...@adobe.com > > >> To: dev@flex.apache.org > > >> Subject: Re: Could not find compiled locale with mustella > > >>ResourceManager tests > > >> Date: Fri, 12 Dec 2014 00:57:52 +0000 > > >> > > >> OK, I dug into it and have a better guess why it fails in the full set > > >>and > > >> passes on its own. I added a .compile file (just the -locale, the > > >>library > > >> path should already be set) and verified the fr_FR bundle was in the > > >>app. > > >> > > >> However, in looking at these tests, you aren’t supposed to have a fr_FR > > >> locale in the test. Some of the tests are testing code paths for > > >>missing > > >> locales. Then, to add to the problem, the exception seems to be thrown > > >> from 3rd test case, but I think the first two test cases are leaving the > > >> ResourceManager in a bad state, which is why the test passes on its own. > > >> > > >> So, if you want to get all of this to run on the full pass, you may have > > >> to reset the ResourceManager in the setup of each test so each test can > > >> run independently and tests that run before it don’t affect subsequent > > >> tests. > > >> > > >> Of course, I could be wrong. > > >> > > >> -Alex > > >> > > >> On 12/11/14, 4:28 PM, "Chris Martin" <chrsm...@outlook.com> wrote: > > >> > > >> >This is odd. I also tried to change the locale reference from fr_FR to > > >> >en_US just to see if I can get a little further along, and I still get > > >> >same error, but it references not being able to find it for 'en_US'. > > >>Do > > >> >you think this suggests a deeper issue than a .compile file? > > >> > > > >> >Chris > > >> > > > >> >> From: chrsm...@outlook.com > > >> >> To: dev@flex.apache.org > > >> >> Subject: RE: Could not find compiled locale with mustella > > >> >>ResourceManager tests > > >> >> Date: Thu, 11 Dec 2014 16:44:57 -0700 > > >> >> > > >> >> Okay, verified there are no duplicate test names. I added > > >> >>tests/resources/ResourceManager/SWFs/ResourceManagerApp.compile which > > >> >>contains: > > >> >> > > >> >> -locale=fr_FR,ja_JP,en_US,de_DE > > >> >> -library-path+=${sdk.dir}/frameworks/locale/{locale} > > >> >> > > >> >> As the tests do use those for getting resource bundles. Still > > >>getting > > >> >>the same error at > > >> >>ResourceManager_Methods_findResourceBundleWithResource.mxml:136. > > >> >> > > >> >> I don't think this would have any affect but I also did add a > > >> >>ResourceManager_Methods_findResourceBundleWithResource.compile file > > >>next > > >> >>to ResourceManager_Methods_findResourceBundleWithResource.mxml that > > >> >>contains the same value as above. That too didn't have an effect. > > >> >> > > >> >> I have a sneaky suspicion that I'm doing it wrong :) > > >> >> > > >> >> Chris > > >> >> > > >> >> > From: aha...@adobe.com > > >> >> > To: dev@flex.apache.org > > >> >> > Subject: Re: Could not find compiled locale with mustella > > >> >>ResourceManager tests > > >> >> > Date: Thu, 11 Dec 2014 22:03:06 +0000 > > >> >> > > > >> >> > > > >> >> > On 12/11/14, 1:45 PM, "Chris Martin" <chrsm...@outlook.com> wrote: > > >> >> > > > >> >> > >Sweet! Unfortunately even running with the -failures flag, the > > >>test > > >> >> > >still fails, but for a different reason. > > >> >> > > > > >> >> > >Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. > > >>URL: > > >> >> > >file:///c:/tmp/IncludeList.txt > > >> >> > > at > > >> >> > > > >> > > >>>>>IncludeFileLocation$/init()[C:\Users\cmartin\Documents\GitHub\flex-sdk > > >>>>>\m > > >> >>>us > > >> >> > >tella\as3\src\mustella\IncludeFileLocation.as:70] > > >> >> > > > >> >> > On Windows, the -failures switch should cause some code to write to > > >> >> > c:/tmp/IncludeList.txt, then the SWF should try to read from there. > > >> >>If > > >> >> > you have security setups blocking that, there could be issues. > > >> >> > > > >> >> > > > >> >> > >One thing that I have noticed is that the number of passed tests > > >>can > > >> >> > >sometimes be 14 and other times 8. So I think that the test for > > >> >> > >ResourceManager halts when it encounters an actionscript > > >>exception. > > >> >>I > > >> >> > >assume this is only the case because of the nature of the failure. > > >> >> > > > >> >> > The test environment may not be able to fully recover from an > > >> >>exception so > > >> >> > it doesn’t make sense to keep running tests. There could be popups > > >> >>left > > >> >> > on the screen, etc. > > >> >> > > > >> >> > >>try to make these changes? I can try to find time to do it > > >> >>otherwise. > > >> >> > > > > >> >> > >Yeah I can take a crack at it. Do I need to adjust the test names > > >>so > > >> >>they > > >> >> > >are unique as well as add in the .compile files as needed? > > >> >> > > > >> >> > First, make sure I’m right and that there are duplicate test names > > >>and > > >> >> > make them unique. Then see what you need to do to fix the failing > > >> >>test, > > >> >> > which I would guess requires a .compile file to include the fr_FR > > >> >>locale. > > >> >> > > > >> >> > Good luck, have fun, and thanks for working on it. > > >> >> > > > >> >> > -Alex > > >> >> > > > >> >> > > >> > > > >> > > > > > >
