What's the current state of glassfish-embedded?

[jnorris10]

Currently demo-testng does not pass, ie:

mvn -P glassfish-embedded test

This isn't related to https://jira.jboss.org/jira/browse/ARQ-60 as the glassfish-embedded profile is explicitly enabled.

The current errors are as follows:

java.lang.IllegalStateException: Error launching test com.acme.ejb.InjectionTestCase public void com.acme.ejb.InjectionTestCase.shouldBeAbleToInjectEJB() throws java.lang.Exception
    at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:63)
    at org.jboss.arquillian.testng.Arquillian.run(Arquillian.java:85)
...
Caused by: java.net.ConnectException: Connection refused

I'm not sure what connection is being refused, being embedded.

It's fine if the answer is that this stuff isn't ready yet, or if it's in a holding pattern until potential major changes come out of the design meeting on Mon.  I'm just curious

[jnorris10]

It appears src/test/resources/jndi.properties was the connection problem.  A much greater percentage of tests pass when this is not in play.  What role does jndi.properties play in this process, especially in an embedded container?

[aslak]

Yea, sorry about that. jndi.properties only mess up the Embedded profiles. It should be swapped out with our own configuration https://jira.jboss.org/jira/browse/ARQ-33 so we have a bit more control.

It is used today as configuration to connect to the remote containers(Jboss 5.1 and 6) to resolve the ProfileService.

[aslak]

Not all tests will run btw.

The jms test does not run due to missing queue/jms server.

And CDI does not work atm, due to some poor packaging on the Arquillian side and https://glassfish.dev.java.net/issues/show_bug.cgi?id=11497

EJBs should work..

[jnorris10]

[jndi.properties] is used today as configuration to connect to the remote containers(Jboss 5.1 and 6) to resolve the ProfileService.

Thanks, that makes sense.  I didn't think it had a role in embedded scenarios.  (I supposed you could go through JNDI even in an embedded container, but probably no point as you can just access everything directly in-process).

[jnorris10]

Which embedded container do you guys think will reach a somewhat functional level first, JBoss AS?  Glassfish embedded?  Something else?

As far as prioritization goes, IMHO I think the embedded scenarios should be top-priority as this is going to be a huge sweet spot for JEE testing (and rapid development).  These embedded cases showcase Arquillian extremely well.  This is not to say the other types of remote container testing are not important or useful (they are both).  However, being able to spin up an embedded container test (with eg: a JEE6 web profile) and being able to isolate your deployment artifacts as Dan has very carefully detailed here, is really going to put this tool far above anything currently available.  Then on top of that to be able to configure your tests against any container (local or remote) is fantastic.  It's a really ambitious project but also appears very doable based on the discussion going on in here.  You seem to have the right people involved - and Andrew, if you can pull in Reza's feedback, sweet - he's an EE stud . I think Dan described this project well when he said he wants to provide an infrastructure that complements the EE6 platform so that you can write tests as easily as you can write EE6 applications.

[alrubinger]

aslak wrote:

Not all tests will run btw.

What can we do to exclude the tests known not to work?

IMO we should strive to get everything running as expected, with exclusions and comments to JIRAs where they can't.

S,

ALR

[alrubinger]

I agree; Embedded containers are the lowest hanging fruit and most accessible feature for users.  If we easily enable EmbeddedAS, OpenEJB, and GlassFish Embedded I think we're well on our way.

S,

ALR

[aslak]

I've been thinking of adding test groups pr 'specification'(ejb, cdi, jms), so we can separate more easily what can be tested pr container. But this only works for TestNG, maybe use package name based exclusion instead..?

[jnorris10]

aslak wrote:

I've been thinking of adding test groups pr 'specification'(ejb, cdi, jms), so we can separate more easily what can be tested pr container. But this only works for TestNG, maybe use package name based exclusion instead..?

For this to work, I'm thinking that the container configurations (whatever they end up looking like) would need to declare their capabilities in some way (eg: ejb, cdi, jms, etc.).  Then the framework could run the test against all available container configurations with that capability.  Perhaps this concept already exists in the Arquillian SPI?

On the other hand, perhaps it's simpler and more flexible to just leave it up to the test writers to ensure that their tests are compatible with whatever containers are configured for it.  It's hard to know the best answer here before the container configuration system is ironed out, but I'm worried about accidental complexity (exception cases could get really complex and annoying, eg: this test is good with a "jms" container, except glassfish embedded for whatever reason - it get's nasty really fast).  Perhaps a hybrid solution - allow the user to tag their configurations with their own arbitrary strings that correlate to their testing needs.  Then tests could be tagged with these arbitrary capabilities and automatically run against the appropriate containers.

[aslak]

We've dropped by the topic earlier and I think we ended with a Arquillian groups based approach(like TestNG groups, but that works with both TestNG and JUnit) is the most flexible. The Container can only tell you so much of what it supports, since you can pretty much deploy what ever you want in it, it can't really say it does not support X.

This means the user has to know what container supports what, but it also means the user can control what tests are suppose to run where. The user might have GlassFish/JBoss only/specific issues he need to test etc..

[jnorris10]

aslak wrote:

The Container can only tell you so much of what it supports, since you can pretty much deploy what ever you want in it, it can't really say it does not support X.

Right, I wasn't thinking the container itself should declare what it supports, rather the Arquillian container configuration defined by the tester (wherever that ends up) should declare it.

This means the user has to know what container supports what, but it also means the user can control what tests are suppose to run where. The user might have GlassFish/JBoss only/specific issues he need to test etc..

Agreed, that sounds like the way to go.  Nice.

[peter.vanleeuwen]

Hi Jeremy. It sounds like I am having a similar problem. I am really new to EJBs and Arquillian and I'm having troubles figuring out how to setup my test environment. Could you tell me the steps that you took?