Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing

[David Blevins <da...@visi.com>]

ljnelson wrote:
> 
> 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.
> 

Per spec you are also able to list the file paths of the jars you want
scanned.  So in the end you should be able to take that approach even if
GlassFish can't find the jars on its own.  The classes are there and
loadable in the thread context classloader so if you explicitly point at the
jars, all should be fine.

In terms of Glassfish effectively "changing" the spec.  If they want to
limit their support to specific techniques for scanning and finding modules,
that's their call.  But it only affects their implementation and not the
spec itself.

The new Embedded EJB Container functionality in the spec is intentionally
minimalistic so that vendors have adequate room figure out how to make it
work with their architecture.  This is just part of the expected challenges
that vendors will face.
-- 
View this message in context: http://old.nabble.com/Surefire-plugin-and-surefirebooter-jars-and-Glassfish-and-EJB-unit--testing-tp28184255p28185208.html
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org