Selenium Test passes, but shouldn't! Why?

[pogopaule]

Hi!

I created a simple Apache Wicket project that uses Arquillin/Drone to run a UI test: http://github.com/pogopaule/WiArquillian

I was surprised to see the test pass. There is only a web.xml in my WebArchive. But for some reason Arquillian resolves all dependencies anyway! How is that possible?

How can I get Arquillian to only look at the files in the deployed archive?

Thanks for your help,

Fabian

[aslak]

This is probably due to GlassFish Embedded leaking classes / resources from Application ClassLoader.

You define a web.xml that points to classes available on classpath, not the WebDeployment ClassLoader, but coming in from the Application ClassLoader.

If you want full isolation you currently need to use the glassfish-managed container instead. That forks GlassFish in a new jvm.

http://arquillian.org/modules/glassfish-managed-3.1-container-adapter/

[pogopaule]

Thank you Aslak for your quick reply!

I need to run an emedded version of glassfish. The remote and the managed adapter are not really what I want.

Is this leaking of classes you describe a problem of Glassfish or Wicket or both? What about other containers and other frameworks like JSF?

Is there a way to prevent this leaking in glassfish-embedded?

Cheers,

Fabian

[vineet.reynolds]

The embedded GlassFish container (and most/all other embedded containers) will have this problem. If you're using Surefire and running the tests in a forked VM, the system classloader is responsible for loading both the embedded container and the application classes. The web-app classloader for the deployed app defers to the system classloader and will therefore see classes that may be omitted in the ShrinkWrap archive, but happen to be a part of the Surefire classpath. The same is true even of the testrunner used by the IDE - the classloader will load classes off target/classes or bin/classes (or whatever) and omitting some of the classes from a ShrinkWrap archive would not matter eventually.

The only way to prevent this is to use a managed or remote container since it's system classloader would not be polluted. That way, the deployed archive would be the codesource for the classes that are looked up by the web-app classloader. Loading of other classes would be deferred to the parent classloader(s).