Awesome!  Thanks for figuring that out.  It is strange that the wrong test
is marked as failing.  In the debugger, it looks like the test SWF
properly sent out the test case start and end messages.  That’ll be
trickier to figure out.  It might involve the Java code.  Do you want to
take a shot at it?

Regarding the change that throws the exception:  Looks like it was done
for FLEX-17210.  Maybe a better move is to trace a warning instead of
throwing an error, but you could also argue that the bug itself is “Not A
Problem” if the code before the change properly set the error property on
the formatter.  The developer should be checking for errors when
formatting.

I agree with no longer throwing an exception, but don’t have a opinion on
whether to replace with a trace or not.  Up to you.  A more complex
scenario where someone sets the localeChain before loading resourceModules
popped into my head.  Maybe that shouldn’t warn, but maybe that’s too rare
a case and we’ll help more developers out by warning them.

Congrats on the find!
-Alex

On 12/12/14, 12:39 PM, "Chris Martin" <chrsm...@outlook.com> wrote:

>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_UICompon
>ent_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/ae28ab34c558957927471d54ce2a0c
>>>a6
>> > >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-s
>>>>>>>dk
>> > >>>>>\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                                      
>> > >> >> > 
>> > >> >>                                      
>> > >> >                                       
>> > >> 
>> > >                                    
>> > 
>>                                        
>                                         

Reply via email to