ArquillianTest starts jboss but never completes


#1

Running on Windows 7.

I’m pulling and building the latest “camunda-bpm-examples”. When it gets to running “org.camunda.bpm.example.spring.servlet.pa.ArquillianTest” it appears that this starts a standalone JBoss instance, but that’s as far as the test and the build gets. It hangs there forever. The last line of output that appears is this:


15:07:45,807 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015899: JBoss AS 7.2.0.Final “Janus” starting

It all exits when I press ^C. I’ve tested this multiple times.


#2

Hi @David_Karr,

I could reproduce it, but I do not see the problem at the first sight. I created a Jira issue 1.

Cheers,
Roman


#3

I’m not a huge fan of the Arquillian test infrastructure. Though it’s convenient, I prefer starting an actual JBoss/Wildfly server first and then run my tests, typically via HTTP clients, against this server. My reasoning is that I first need to see a clean, error free server startup (first part of test). Then, after I get a clean startup, begin the regression run.

If your server “hangs”, I’m guessing you have a port conflict or some sort of firewall issue? You should see the port conflict in the logs.

NOTE: Another reason I test via HTTP-clients against a server instance is that this approach requires a lot less time to execute the test-suite. I use Eclipse setup with JBoss-tools, configured for “automatically publish” (i.e. “hot-deploy”).


#4

Hi,

the example works for me with JDK7. Please use JDK 6/7 with JBoss 7.2.0, JDK 8 won’t work. It just will make the JBoss hang. This is a JBoss issue.

Cheers,
Christian


#5

I’m using JDK 8 for Wildfly 10.x and haven’t yet bumped into this sort of trouble. I ran a complete test-suite just a few days ago.

Though I don’t know if this is an actual bug… I have run into troubles when mixing JDK/JRE versions. I’d recommend verifying your test driver (and the platform you’re developing from) is fully aligned with your target platform JDK. I was getting a bunch of funky errors/hangs until I fixed this issue within my lab.


#6

Hi @garysamuelson,

That’s why I explicitly wrote JBoss 7.2.0 and nothing about Wildfly.
See this thread in Jboss forum. The RedHat ppl never fixed the JDK 8 issue in JBoss 7.1 and 7.2 line.
It is fixed with EAP 6.3.3 and later as stated here, which features JBoss 7.3+. Those are only available for enterprise customers.
Wildfly isn’t affected by this because the fixes for JDK 8 went into it right away.

Cheers,
Christian


#7

Sorry for the confusion… thanks for the update.
But, gotta’ love open-source projects. Community support leads on the features/fixes.


#8

mind-bending version complexity

So I’m trying to understand the impact of this. Obviously Camunda itself works fine on Java8, it’s just that at least this “camunda-bpm-examples” repo won’t fully build/run on Java8. That is because the Arquillian test is using JBoss 7.2, which won’t run with Java8. However, I’m hearing here that recent versions of Wildfly will work on Java8. Is Arquillian limited to JBoss, or can Arquillian use Wildfly?


#9

Hi David,

it is also possible to use Arquillian together with Wildfly.
There exist some blogpost about this topic, see here 1
and here 2.

Camunda also runs integration tests against Wildfly and other AS. You can take a look into the
integration test suite, which is written and used by Camunda.

Greets,
Chris


#10

I’ll take a look at those resources, but for some reason I can’t get to “1”. It reports some sort of SSL error.


#11

I’m also diving into some of the build/test details - it does get complex…


#12

And… even when attempting to scope the test to WildFly10, I’m now also seeing the same Arquillian error. I’m sure Wildfly works with Arquillian… mostly sure.

here’s my error:

within:
/camunda-bpm-platform/qa

command:
mvn clean test -Duser.timezone=CET -Denforcer.skip=true -Pengine-integration,wildfly,wildfly10,h2

Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [300] s
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:159)