[
https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.s...
]
Cristina González castellano commented on ARQ-2016:
---------------------------------------------------
Hello!,
We have adapt the Arquillian OSGi Extension so it can use custom extensions, now we are
using it sucessfully in the Arquillian Liferay Extension.
The idea that we have implemented is:
1. The Arquillian OSGi Bundle is automatically generated (with all the extensions that are
declared in the classpath). (This is done only once)
2. For every test:
2.1. The Arquillian OSGi Bundle is installed.
2.2. The test deployment is installed without any enhacement.
2.3. A fragment for the Arquillian OSGI Bundle that contains only the test class is
generated and installed.
2.4 The tests are executed
2.5 All the previously installed bundle are uninstalled.
We have created a pull (
https://github.com/arquillian/arquillian-container-osgi/pull/51)
were you can check the changes. We think that this maybe can be usefull for someone. Maybe
it would be interesting try to merge it with the current Arquillian OSGi Container.
What do you think? If you need more information, please, let us know.
Thanks!
Improve the ability to add custom extensions for the containers
---------------------------------------------------------------
Key: ARQ-2016
URL:
https://issues.jboss.org/browse/ARQ-2016
Project: Arquillian
Issue Type: Feature Request
Components: OSGi Containers
Affects Versions: osgi_2.1.0.Final
Environment: Under Linux, and inside Karaf 4.x
Reporter: Steve Storck
When the arquillian-container-osgi extension is deployed, it also deploys the
arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not
expose) some of the implementation and SPI packages. This effectively results in only
being able to use the provided JUnitBundleTestRunner extension. I want to use the
arquillian-testrunner-spock extension, but it always fails because I have to deploy the
test SPI bundle with my test jar, and it conflicts with those packages that the
arquillian-osgi-bundle uses internally. This causes an exception to be thrown that
complains that the EventTestRunnerAdaptor implementation is not an instance of the
TestRunnerAdaptor interface. The chain of events that results in the exception is as
follows:
{code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid}
package org.jboss.arquillian.spock;
public class ArquillianSputnik extends Sputnik {
import org.jboss.arquillian.test.spi.TestRunnerAdaptor;
import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder;
// Methods and fields omitted for brevity, but you can see that the
// proper packages are imported
public void run(RunNotifier notifier) {
// Code omitted for brevity
final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build();
// More code omitted for brevity
}
}
{code}
{code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core
test/spi)|borderStyle=solid}
package org.jboss.arquillian.test.spi;
public class TestRunnerAdaptorBuilder {
private static final String DEFAULT_EXTENSION_CLASS =
"org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader";
private static final String TEST_RUNNER_IMPL_CLASS =
"org.jboss.arquillian.test.impl.EventTestRunnerAdaptor";
public static TestRunnerAdaptor build() {
// omitted lines for brevity
ManagerBuilder builder = ManagerBuilder.from()
.extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS));
return SecurityActions.newInstance(
TEST_RUNNER_IMPL_CLASS,
new Class<?>[] {ManagerBuilder.class},
new Object[] {builder},
TestRunnerAdaptor.class);
}
}
{code}
{code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid}
package org.jboss.arquillian.test.spi;
final class SecurityActions {
static <T> T newInstance(final String className,
final Class<?>[] argumentTypes,
final Object[] arguments,
final Class<T> expectedType) {
@SuppressWarnings("unchecked")
Class<T> implClass = (Class<T>) loadClass(className);
if (!expectedType.isAssignableFrom(implClass)) {
throw new RuntimeException("Loaded class " +
className +
" is not of expected type " +
expectedType);
}
return newInstance(implClass, argumentTypes, arguments);
}
}
{code}
I think that the best solution would be to completely decouple the JUnitTestRunner from
the container modules, or at the very least, it would be good to change the
<_exportcontents> to export most (or all) of the embedded dependency packages so
that users can make use of other extensions, or build their own.
Edit: After some more thought, it would be really nice to make test extensions loadable
(with a default if it is unspecified, of course). I don't know enough about the code
base (yet) to say if it would be best to do this via an annotation, or if pluggability
would be better leveraged somewhere else in the framework.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)