flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Martin <chrsm...@outlook.com>
Subject RE: Could not find compiled locale with mustella ResourceManager tests
Date Fri, 12 Dec 2014 22:02:43 GMT
> Regarding the change that throws the exception:  Looks like it was done
> for FLEX-17210.
 
Nice :)  Two heads are better than one, for some reason my eyes glossed right over that ticket
number in the commit message.  But yeah, that ticket was resolved as "Not A Problem" and I
bet the exception was added to "slap the developers wrist". I think adding the trace would
be a nice compromise, and for some reason if we get too many people asking about the trace
statement we can re-visit it.
 
In making this adjustment is the practice to reopen FLEX-17210 and update the ticket, or leave
it resolved and update the ticket?
 
Also do we create JIRA tickets when we run into hickups in the mustella tests?
 
Chris
 
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Subject: Re: Could not find compiled locale with mustella ResourceManager tests
> Date: Fri, 12 Dec 2014 21:23:56 +0000
> 
> 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" <chrsmrtn@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: chrsmrtn@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: aharui@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" <chrsmrtn@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: aharui@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" <chrsmrtn@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: chrsmrtn@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: aharui@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" <chrsmrtn@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		 	   		
> >> > >> >> > 
> >> > >> >>  		 	   		
> >> > >> > 		 	   		
> >> > >> 
> >> > > 		 	   		  
> >> > 
> >>  		 	   		  
> > 		 	   		  
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message