I was thinking to something either programmatic or declarative (I
prefer the last one that's why it is the sample I'll propose in the
next part of the mail but not sure we can avoid first one, if so +1 to
do it):

public class MySuperTest { // don't be humble
    @Rule
    public final ServiceRule serviceRule = new ServiceRule(); // we
can also add some builder stuff if preferred

    @Test
    // of couse we'd support @Services({@Service(...), @Service(...), ...})
    @Service(type = PropertySource.class, inheritFromClassPath = true,
additionals = { MySuperPropertySource.class })
    public void testPropertySourceInAClevermanner() {
    }
}

Then all this classloader switch logic and resource finding would be
in ServiceRule statement implementation.

Even if we use SW enhancing SWClassLoader to support
"inheritFromClassPath" we could add such a rule to make our tests less
technical.




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-29 10:19 GMT+01:00 Reinhard Sandtner <reinhard.sandt...@gmail.com>:
> hi,
>
> +1 romain
>
> i think we need both too - i had the idea to have an AbstractTest-class which 
> „ignores“ classes and resources starting wich org.apache.tamaya* and use only 
> the specified classes and resources (kind of what we have in OWB).
>
> a java SE container would be really nice as we can later easily switch 
> containers for EE. i found a project on github but its about 4 years old and 
> i didn’t try if it works - but we can easily write an arquillian SE container 
> for our needs.
>
> what about a tck-like test-suite to test our java7/java8 core?
>
> lg
> reini
>
>
>> Am 29.01.2015 um 09:52 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
>>
>> Well AFAIK it doesnt bring isolation, just the ability to fake SPIs.
>> If we don't need more that's ok - if you dont forget to restore
>> Thread.currentThread() ;)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-29 9:40 GMT+01:00 Oliver B. Fischer <o.b.fisc...@swe-blog.net>:
>>> Here is the test case I wrote yesterday:
>>>
>>> public classJavaConfigurationProviderIT {
>>>
>>>    @Test
>>>    public voidbla() {
>>>        JavaArchive roundtrip = ShrinkWrap.create(JavaArchive.class)
>>>            .addAsServiceProvider(PropertySource.class, MPS.class);
>>>
>>>        ClassLoader parent = Thread.currentThread().getContextClassLoader();
>>>        ShrinkWrapClassLoader swcl =newShrinkWrapClassLoader(roundtrip);
>>>
>>>        Thread.currentThread().setContextClassLoader(swcl);
>>>
>>>
>>>        for(PropertySource propertySource :
>>> ServiceLoader.load(PropertySource.class)) {
>>>            System.out.println("*****");
>>>            System.out.println(propertySource.getName());
>>>        }
>>>
>>>        System.out.println(roundtrip.toString(true));
>>>    }
>>>
>>>    public static  classMPSimplementsPropertySource {}
>>> }
>>>
>>>
>>>
>>> Am 29.01.15 um 09:27 schrieb Oliver B. Fischer:
>>>>
>>>> But even with Arquillian we would need ShrinkWrap to build deployable
>>>> artifacts. Or what do you mean? For SE we need only to tweak our class path
>>>> or class loader.
>>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>> Am 29.01.15 um 08:31 schrieb Mark Struberg:
>>>>>
>>>>> That's why I wanted some 'isolating' Arquillian SE adaptor :)
>>>>> I prefer using Arquillian over any homegrown solution as we might use
>>>>> that to later test EE containers as well.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fisc...@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fisc...@jabber.org
>>> X http://xing.to/obf
>>>
>

Reply via email to