[
https://issues.jboss.org/browse/ARQ-2153?page=com.atlassian.jira.plugin.s...
]
Gerhard Poul commented on ARQ-2153:
-----------------------------------
[~hutchig] do you know which arquillian container adapter the others are using for their
testing? It might be good to take a look. If your test is already running, then it is
running inside the container and they will see all the exceptions just be fine, but if
there is an exception while deploying or starting the application, then the exception is
seen outside in the process where the arquillian container adapter is running. It would be
interesting how this is handled in other container adapters where this behaves
differently, because the architecture is the same for all of them and the container
adapter always runs outside the container.
In your case with the
[
Deployment|https://docs.jboss.org/arquillian/api/1.0.3.Final/org/jboss/ar...]
annotation this is running outside the container and I don't see how you would get a
container exception unless you're running inside something like an embedded container
where the deployment is actually taking place in the same JVM process and not outside in a
separate remote or local process.
Enable @Deployment @ShouldThrowException(DefinitionException.class)
in WebSphere Liberty Managed Container
----------------------------------------------------------------------------------------------------------
Key: ARQ-2153
URL:
https://issues.jboss.org/browse/ARQ-2153
Project: Arquillian
Issue Type: Feature Request
Components: WebSphere Containers
Affects Versions: 1.0.0.Final
Environment: MicroProfile FaultTolerance TCK testing with
arquillian-wlp-managed-8.5 container.
For example testing
https://github.com/eclipse/microprofile-fault-tolerance/blob/master/tck/s...
with open Liberty or any other Arquillian test testing for DefinitionExceptions that
cause
Deployment Exceptions.
Reporter: Gordon Hutchison
Assignee: Gerhard Poul
Priority: Minor
When running the MicroProfile Fault Tolerance TCK there are numerous tests'
deploy methods that have:
{code:java}
@Deployment
@ShouldThrowException(DefinitionException.class)
public static WebArchive deploy() {...
{code}
The current wlp-managed-8.5 container return these as Deployment
Exceptions to the test client which makes the TCK tests fail even if the server
has raised a definition exception.
I have a code patch from an IBM colleague Nathan Mittlestat (whose permission I have to
make this 'issue' and a pull request from on his behalf ) along the lines of:
{code:java}
private void checkForDefinitionExceptions(String applicationName)
{
String messagesFile = containerConfiguration.getWlpHome() +
"/usr/servers/" + containerConfiguration.getServerName() +
"/logs/messages.log";
BufferedReader br = null;
try {
br = new BufferedReader(new InputStreamReader(new
FileInputStream(messagesFile)));
String line;
while ((line = br.readLine()) != null) {
if (line.contains("CWWKZ0002E: An exception occurred while starting the
application " + applicationName + ".")
&&
(line.contains("org.jboss.weld.exceptions.DefinitionException") ||
line.contains("javax.enterprise.inject.spi.DefinitionException"))) {
System.out.println("############DEBUG found CWWKZ0002E for
application: " + applicationName);
System.out.println(line);
throw new DefinitionException(line);
}
}
} catch (IOException e) {
System.err.println("Exception while reading messages.log" +
e.toString());
e.printStackTrace();
// } catch (FileNotFoundException e) {
// System.err.println("Exception while reading messages.log" +
e.toString());
// e.printStackTrace();
} finally {
try {
if (br != null)
br.close();
} catch (Exception e) {
System.err.println("Exception while closing bufferedreader " +
e.toString());
e.printStackTrace();
}
}
}
{code}
This method is called in waitForApplicationTargetState if a wrapping Deployment
exception
is observed:
{code:java}
} catch (Exception e) {
checkForDefinitionExceptions(applicationName);
throw new DeploymentException("Exception while checking application
state.", e);
}
{code}
I will do a PR shortly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)