Me neither... So I'll stick to injecting the ClusteringProvider for now and
will add others as I go along.
The main hesitation I had was around the DummyClusteringProvider. But looks
like nobody objects to that one :)
On 20 May 2010, at 17:33, Chris Dennis wrote:
> I don't see the harm in having separate annotations for the different
> things that could be injected rather than having what will amount to a
> single injected struct...
>
> On May 20, 2010, at 11:31 AM, Alex Snaps wrote:
>
>> I indeed want the test fw to inject the proper provider depending on
>> the current environment the test is being run in.
>> As for injecting the URL, this will indeed also be required (say to
>> configure your ehcache).
>> I also expect the current Environment you're being executed in to
>> become relevant (like loading different configs).
>> Maybe I should rather inject some other TcTestContext that would
>> also provide access to the ClusteringProvider?
>>
>> On 20 May 2010, at 17:20, Chris Dennis wrote:
>>
>>> So this would be the route in for direct toolkit users? In express
>>> we
>>> would instantiate a StandaloneClusteringProvider connected to the
>>> server that the test framework started, in standalone we would
>>> instantiate a dummy, and in custom we would just do
>>> Clustering.provider() and get the globally (or classloader) scoped
>>> instance?
>>>
>>> What if I've written a toolkit/express product and my product has its
>>> own bootstrapping class much like Express Ehcache. Will I be able to
>>> have the URL of the server injected instead so that I can feed that
>>> to
>>> my application in whatever way it normally handles it?
>>>
>>> Chris
>>>
>>> On May 20, 2010, at 11:02 AM, Geert Bevin wrote:
>>>
>>>> Sounds all good to me!
>>>>
>>>> On 20 May 2010, at 16:28, Alex Snaps wrote:
>>>>
>>>>> Since we have more targeted platforms than DSO now, we've decided
>>>>> to put a new test framework in place that would enable developers
>>>>> to run tests as easily as possible in all 3 environments: Custom,
>>>>> Express and "standalone" (i.e. no clustering).
>>>>> The way I've started this is that tests are simple junit tests that
>>>>> need to be annotated with @TerracottaTest like this:
>>>>>
>>>>> @RunWith(TerracottaRunner.class) // Still trying to get rid of this
>>>>> guy here!
>>>>> @TerracottaTest
>>>>> public class usefulTest {
>>>>>
>>>>> @Test
>>>>> public void testSomethingUseful() {
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> By default, this would result in the test being run in all 3
>>>>> environments. One could influence this by specifying the targeted
>>>>> environments as:
>>>>> @TerracottaTest({TargetEnvironment.EXPRESS,
>>>>> TargetEnvironment.CUSTOM})
>>>>>
>>>>> The annotation currently also takes an additional parameter,
>>>>> participants:int, which defaults to 2
>>>>> Now in order to orchestrate these participants, one would generally
>>>>> rely on a j.u.c.CyclicBarrier... which would be obtained by a
>>>>> ClusteringProvider.getBarrier("myBarrier", 2);
>>>>> In order to get to the appropriate ClusteringProvider, I was
>>>>> thinking about injecting it in the test through the mean of some
>>>>> annotated field. Should the test be in "standalone" (i.e. 2 threads
>>>>> running the "classpath isolated" test), I'd inject some
>>>>> DummyPersistenceProvider.
>>>>>
>>>>> This makes the most sense to me right now, wdyt?
>>>>> Thanks,
>>>>> Alex
>>>>>
>>>>> _______________________________________________
>>>>> tc-dev mailing list
>>>>> tc-dev@lists.terracotta.org
>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>>
>>>> --
>>>> Geert Bevin
>>>> Terracotta - http://www.terracotta.org
>>>>
>>>> _______________________________________________
>>>> tc-dev mailing list
>>>> tc-dev@lists.terracotta.org
>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>
>>> _______________________________________________
>>> tc-dev mailing list
>>> tc-dev@lists.terracotta.org
>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>
>> _______________________________________________
>> tc-dev mailing list
>> tc-dev@lists.terracotta.org
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>
> _______________________________________________
> tc-dev mailing list
> tc-dev@lists.terracotta.org
> http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
