Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
On Thu, Apr 8, 2010 at 4:46 PM, Benjamin Bentmann wrote: > Laird Nelson wrote: > > But in surefire withalways, the classpath is actually >> a surefirebooter.jar located in $TEMP with a big ol' Manifest Class-Path: >> entry. >> > > [0] describes some options to control how the test class path is created. I > would expect that one of these solves your problem. > Sure; thanks; I'm actually not objecting to surefire's behavior at all. A manifest-only jar is just fine with me, but Glassfish (IMHO) doesn't deal with it properly. Wasn't sure if anyone from Maven wanted to weigh in on the bug, that's all. Thanks again for the link. Best, Laird
Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
Laird Nelson wrote: But in surefire withalways, the classpath is actually a surefirebooter.jar located in $TEMP with a big ol' Manifest Class-Path: entry. [0] describes some options to control how the test class path is created. I would expect that one of these solves your problem. Benjamin [0] http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
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 always, 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
