I thought long and hard about whether this belongs on the dev or user list; I may have still picked the wrong one.
There's a nasty little issue rolling along in the Glassfish forums; https://glassfish.dev.java.net/issues/show_bug.cgi?id=11764 has the issue and a link to the discussion. Briefly, if one calls (the standard EJB API method) javax.ejb.embeddable.EJBContainer#createEJBContainer() it is supposed to scan the classpath for EJBs. But in surefire with <forkMode>always</forkMode>, the classpath is actually a surefirebooter.jar located in $TEMP with a big ol' Manifest Class-Path: entry. Perfectly legal, you'd think. I do too. That is, I would have expected that just as this effectively defines a classpath as though all the classpath elements were specified by hand individually, so, I'd assume, the logical classpath defined by it would also be scanned for EJBs. Now Ken Saks, spec author for EJB 3.1 is saying sure, whoops, Glassfish has a problem, it doesn't consult the *effective* classpath because it doesn't take into consideration Manifest.MF Class-Path entries. Fine. But *then *he says something WAY more troubling: that any classpath roots reachable by way of Surefire's booter jar's Manifest Class-Path entry aren't actually roots for new EJB modules. That is, the classpath defined by Manifest.MF Class-Path is somehow...special as regards scanning. I say: huh?! I bring this up here, because if he's right and that ends up being part of the spec, then the neat way that surefire deals with big classpaths could effectively break standardized EJB 3.1 unit/integration testing. That might lead to you wanting to change or otherwise mess with the way Surefire does classpath construction. Again, I apologize if this is the wrong list, but I wanted to make sure some eyes from the Maven camp got on this issue. Thanks for your time. Best, Laird
