[
https://issues.jboss.org/browse/ARQ-1020?page=com.atlassian.jira.plugin.s...
]
Mark Struberg commented on ARQ-1020:
------------------------------------
If we come to the result that this needs to be done in the container-integration modules,
then we at least need to add a TCK test for this use case.
Arquillian doesnt set ThreadLocalClassLoader to the @Deployment
---------------------------------------------------------------
Key: ARQ-1020
URL:
https://issues.jboss.org/browse/ARQ-1020
Project: Arquillian
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Base Implementation
Affects Versions: 1.0.0.Final, 1.0.1.Final
Reporter: Mark Struberg
Arquillian doesn't set the ThreadLocalClassLoader to the @Deployment archive. This
leads to getResources() calls not finding any deployed resources.
The following code fragment from Apache DeltaSpike should make clear what I mean:
{code}
@RunWith(Arquillian.class)
public class PropertyConfigSourceTest
{
@Deployment
public static WebArchive deploy()
{
return ShrinkWrap.create(WebArchive.class, "beanProvider.war")
.addAsLibraries(ArchiveUtils.getDeltaSpikeCoreArchive())
.addAsResource(new StringAsset("prop=value"),
"myconfig.properties")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Test
public void testCustomPropertyConfigSources() throws Exception
{
Enumeration<URL> resources =
Thread.currentThread().getContextClassLoader().getResources("myconfig.properties");
// kawumms...
Assert.assertTrue(resources.hasMoreElements());
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira