On 2/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I did indeed see that (thanks for the fix) ... and Sean has already checked
that change in (I see it in the trunk sources for Shale that I just checked
out), so it will be in the 20060221 nightly build. That doesn't necessarily
translate
The call is required in the setUp() method to make things work correctly on
the *first* test, when you have the MyFaces implementation in the classpath
of the tests. Calling it in tearDown() doesn't hurt anything, but protects
test developers who try to subvert the JUnit test lifecycle stuff.
fyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed by ContextClassLoader (including FactoryFinder internal state), we created a trivial wrapper ClassLoader to provide a unique ContextClassLoader in setUp()
Development'
Subject: Re: FactoryFinder.releaseFactories() - was [continuum] BUILD FAILURE:
API
fyi - IIRC we tackled this problem slightly differently in the ADF Faces
codebase.
In an effort to fully isolate anything that might be keyed by
ContextClassLoader (including FactoryFinder internal
Hi Dennis,On 2/20/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Do you guys have anything fancy for ThreadLocal references of FacesContext?Did you set this to null per TestSuite? per TestCase? per test method ?Yes, IIRC there is a TestFacesContextFactory implicitly registered with the FactoryFinder by
On 2/20/06, John Fallows [EMAIL PROTECTED] wrote:
fyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed by ContextClassLoader (including FactoryFinder internal state), we created a trivial wrapper ClassLoader to
That is a *really* good idea ... I'll be adding it to Shale's test framework
tonight. I don't see it as mutually exclusive with any of the other cleanups
we are doing to ensure that different tests do not interfere with each
other.
Craig
You may want to look at this when you do that.
On 2/20/06, Dennis Byrne [EMAIL PROTECTED] wrote:
That is a *really* good idea ... I'll be adding it to Shale's test frameworktonight. I don't see it as mutually exclusive with any of the other cleanupswe are doing to ensure that different tests do not interfere with each
other.CraigYou may want
I updated the Shale snapshots about half an hour ago... coincidence?
Wendy
This would have happened w/ or w/out your update.
The fix for this was to put FactoryFinder.releaseFactories() in setup() and in
tearDown() . This setup() call is to clear configured Factory info from
previous tests (
On 2/19/06, Dennis Byrne [EMAIL PROTECTED] wrote:
I updated the Shale snapshots about half an hour ago... coincidence?WendyThis would have happened w/ or w/out your update.The fix for this was to put FactoryFinder.releaseFactories() in setup() and in tearDown() .This setup() call is to clear
Purely speaking, FactoryFinder.releaseFactories() should
only be necessary in tearDown() - which is where it makes
the most sense, since releasing factories is cleanup, which
is the job of tearDown().
Practically speaking, it's simplest and safest to call it
in both methods - which means that
On 2/19/06, Adam Winer [EMAIL PROTECTED] wrote:
Purely speaking, FactoryFinder.releaseFactories() shouldonly be necessary in tearDown() - which is where it makesthe most sense, since releasing factories is cleanup, whichis the job of tearDown().Practically speaking, it's simplest and safest to
12 matches
Mail list logo
