[arquillian-issues] [JBoss JIRA] (ARQ-2153) Enable @Deployment @ShouldThrowException(DefinitionException.class) in WebSphere Liberty Managed Container

[Gordon Hutchison (JIRA)]

    [ https://issues.jboss.org/browse/ARQ-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492788#comment-13492788 ] 

Gordon Hutchison commented on ARQ-2153:
---------------------------------------

I only have experience relating to this for this particular TCK. 
There is some related discussion at the moment regarding the TCK assertions here: 
https://gitter.im/eclipse/microprofile-fault-tolerance?source=orgpage  

I was going to do some more work to explore if, in this case, the asserted exception
is indeed wrapped inside the outer deployment exception and if so,
if there is a better arquillian assertion syntax to assert if the exception is present
but wrapped.

Interesting you say "Normally I would not assume that exceptions thrown in the application server are directly also thrown in the managed container implementation".  I guess Microprofile TCK's are trying to be able to get something like:
@ShouldThrowException(value=DefinitionException.class, testable=true) that can be
used to verify implmentations as 'compliant' using Arquillian.  Having
a vendor 'custom' container scraping logs etc. (as in this PR) could lead to thoughts of  'cheating'
unless there is some settled community consensus of how to test deployment errors in code? Ideally
that we can make cross vendor/spec/platform - at least at an abstract level.  
I will do some more investigations :-)

> 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/src/main/java/org/eclipse/microprofile/fault/tolerance/tck/invalidParameters/InvalidCircuitBreakerDelayTest.java
> 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)