Skip to main content

Embedded testing woes

23 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04
Points: 0

So many articles about EJBContainer, so many that don't work!

There's a great article here (http://www.adam-bien.com/roller/abien/entry/embedding_ejb_3_1_container) showing how to get an EJB 3.1 container running. It claims that no further configuration is necessary. This implies I don't have to set up a filesystem, or tell the testing machinery where to create the embedded EJB container, or anything. That's great; so I don't. I just say EJBContainer.createEJBContainer() and off I go.

(It starts up, I should add, barfs out several SEVERE messages that look alarming concerning the fact that it doesn't know where its directory is, even though I'm told I don't have to supply one.)

When I fire up a similar JUnit test under Maven, lo and behold Glassfish comes up, tells me no modules were found (!!), and then, understandably, fails when I attempt to do any lookup--any at all, including of "java:", "java:global", etc.--since nothing got installed in it. So much for no further configuration necessary!

Another article here (http://blogs.sun.com/alexismp/entry/testing_ejb_3_1_s) implies that EJBs that are found at container startup time will be deployed. What does that mean? Do I have to package up an ejb-jar? Can't I leave my classes in their maven directories (target/classes, target/test-classes)? What's going on here? Isn't this configuration? Shouldn't my code get found, as described in the article? If not, where are the steps I need to perform so that Glassfish finds my stuff?

So, having read these two articles and the product documentation, I still can't figure out how to test my EJB. What piece of documentation should I read next?

Thanks,
Laird

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mvatkina
Offline
Joined: 2005-04-04
Points: 0

Let me try to explain and answer the questions. (Let me know if I missed some in this long thread):

EJBContainer.createEJBContainer() does search the classpath for any jar or directory that contains EJBs (either looking at annotations or at deployment descriptors). If more than one EJB module (i.e. dir or jar) is found, a temp ear file is created so that EJBs in those modules can access each other through Local interfaces.

Embeddable EJB container API in GlassFish (in its first version) is implemented to work easily against an existing GlassFish installation using glassfish-embedded-static-shell.jar from glassfish/lib/embedded directory (see http://docs.sun.com/app/docs/doc/821-1208/gjlde?a=view and http://docs.sun.com/app/docs/doc/821-1208/giide?a=view). If such jar is used, the code calculates where the install location is, and the domain.xml is.

If you are using a different (non-default) setup, you need to specify either the org.glassfish.ejb.embedded.glassfish.installation.root property or org.glassfish.ejb.embedded.glassfish.instance.root, or both to point to the actual locations.

We didn't have enough time to sort out all other approaches, so if it works in maven without GlassFish install by adding a domain.xml to the classpath, please blog about it for now and file an RFE for us to look at this setup in the next version.

To see what the EJB container is doing undecover, set the javax.enterprise.system.container.ejb.level to FINE in the JDK logging.properties (and java.util.logging.ConsoleHandler.level to FINEST so that you see them).

The logging level from the persistence.xml should work (check that what you are changing is in the classpath and that java.util.logging.ConsoleHandler.level doesn't suppress the output).

The EJBContainer.createEJBContainer() deploys EJB modules, and .close() undeploys them (there is no option to survive embedded container redeployment), so if the ddl-generation is set to drop-and-create-tables, that what we will do. If you don't need the drop part or all of it, comment it out.

HTH,
-marina

ljnelson
Offline
Joined: 2003-08-04
Points: 0

> Let me try to explain and answer the questions. (Let
> me know if I missed some in this long thread):

Hello, and thanks.

> EJBContainer.createEJBContainer() does search the
> classpath for any jar or directory that contains EJBs
> (either looking at annotations or at deployment
> descriptors).

But it does exactly what I thought, which is to ignore Class-Path: entries in a jar's manifest:

Apr 7, 2010 6:51:26 PM AppServerStartup run
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl addEJBModules
FINE: [EJBContainerProviderImpl] Looking for EJB modules in classpath: C:\DOCUME~1\LAIRDN~1\LOCALS~1\Temp\surefirebooter4360404343466698009.jar
Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl isRequestedEJBModule
FINE: ... Testing ... surefirebooter4360404343466698009.jar
Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl isRequestedEJBModule
FINE: ... is EJB module: false
Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl createEJBContainer
SEVERE: ejb.embedded.no_modules_found

As you can see, obviously the surefire booter is NEVER going to be an EJB, and this is the only classpath Glassfish appears to consult. I'm guessing here, but it looks like it doesn't then read the Class-Path: manifest entry and test its entries--if it did, it would find my stuff, because there are 20-odd entries in Class-Path.

(I suspect the reason that Adam Bien's example (and others' examples) worked was because he wasn't running Maven/Surefire in fork-per-test mode, which causes it to build a classpath as a manifest entry.)

> If more than one EJB module (i.e. dir
> or jar) is found, a temp ear file is created so that
> EJBs in those modules can access each other through
> Local interfaces.

And indeed I've seen this...when I specify EJBContainer.MODULES appropriately (i.e. when I point EJBContainer to the right place "by hand".

> Embeddable EJB container API in GlassFish (in its
> first version) is implemented to work easily against
> an existing GlassFish installation using
> glassfish-embedded-static-shell.jar from
> glassfish/lib/embedded directory (see
> http://docs.sun.com/app/docs/doc/821-1208/gjlde?a=view
> and
> http://docs.sun.com/app/docs/doc/821-1208/giide?a=view
> ). If such jar is used, the code calculates where the
> install location is, and the domain.xml is.

Yes, and that's fine; that doesn't happen to be the way that I have it set up (I have no pre-existing Glassfish installation, and was simply relying on the dependencies provided by Maven, spelled out in your second URL reference). My question here is: are you saying that for the time being this is the ONLY way to use EJBContainer#createContainer()? Because that makes this a non-starter for me.

After all, the sentence from your first URL reference reads:

"You must use this API with a pre-installed, nonembedded Enterprise Server instance."

It's unclear to me whether "this API" means javax.ejb.embeddable.EJBContainer or the proprietary Glassfish embedded APIs.
> If you are using a different (non-default) setup, you
> need to specify either the
> org.glassfish.ejb.embedded.glassfish.installation.root
> property or
> org.glassfish.ejb.embedded.glassfish.instance.root,
> or both to point to the actual locations.

OK, but no tutorial I've seen (not that I've seen all of them) indicates that you have to have a pre-existing Glassfish installation. So, yes, I'm using a non-default setup, but I don't know what values to supply for these parameters in the absence of a pre-existing Glassfish installation. Are you saying that even in a non-default setup I am required to have already downloaded and installed Glassfish somewhere else on my machine? Because all the tutorials and documentation (Alexis' included) seem to indicate that all I need to do is have Maven download some stuff on the fly and everything will work.

Thanks for the time you're taking to get involved in this thread.

Best,
Laird

Marina Vatkina

glassfish@javadesktop.org wrote:

>
>>EJBContainer.createEJBContainer() does search the
>>classpath for any jar or directory that contains EJBs
>>(either looking at annotations or at deployment
>>descriptors).
>
>
> But it does exactly what I thought, which is to ignore Class-Path: entries in a jar's manifest:

The spec mandates only that "By default, the embeddable container searches the
JVM classpath(the value of the Java System property java.class.path) to find the
set of EJB modules for initialization."

Please file an RFE (under ejb-container) for also adding Class-Path: entries in
a jar's manifest.

>
> Apr 7, 2010 6:51:26 PM AppServerStartup run
> INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
> Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl addEJBModules
> FINE: [EJBContainerProviderImpl] Looking for EJB modules in classpath: C:\DOCUME~1\LAIRDN~1\LOCALS~1\Temp\surefirebooter4360404343466698009.jar
> Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl isRequestedEJBModule
> FINE: ... Testing ... surefirebooter4360404343466698009.jar
> Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl isRequestedEJBModule
> FINE: ... is EJB module: false
> Apr 7, 2010 6:51:26 PM org.glassfish.ejb.embedded.EJBContainerProviderImpl createEJBContainer
> SEVERE: ejb.embedded.no_modules_found
>
> As you can see, obviously the surefire booter is NEVER going to be an EJB, and this is the only classpath Glassfish appears to consult. I'm guessing here, but it looks like it doesn't then read the Class-Path: manifest entry and test its entries--if it did, it would find my stuff, because there are 20-odd entries in Class-Path.
>
> (I suspect the reason that Adam Bien's example (and others' examples) worked was because he wasn't running Maven/Surefire in fork-per-test mode, which causes it to build a classpath as a manifest entry.)
>
>
>>If more than one EJB module (i.e. dir
>>or jar) is found, a temp ear file is created so that
>>EJBs in those modules can access each other through
>>Local interfaces.
>
>
> And indeed I've seen this...when I specify EJBContainer.MODULES appropriately (i.e. when I point EJBContainer to the right place "by hand".

Right. Otherwise the EJB container doesn't know that it needs to use only one.

>
>
>>Embeddable EJB container API in GlassFish (in its
>>first version) is implemented to work easily against
>>an existing GlassFish installation using
>>glassfish-embedded-static-shell.jar from
>>glassfish/lib/embedded directory (see
>>http://docs.sun.com/app/docs/doc/821-1208/gjlde?a=view
>>and
>>http://docs.sun.com/app/docs/doc/821-1208/giide?a=view
>>). If such jar is used, the code calculates where the
>>install location is, and the domain.xml is.
>
>
> Yes, and that's fine; that doesn't happen to be the way that I have it set up (I have no pre-existing Glassfish installation, and was simply relying on the dependencies provided by Maven, spelled out in your second URL reference). My question here is: are you saying that for the time being this is the ONLY way to use EJBContainer#createContainer()? Because that makes this a non-starter for me.

It might work. The pre-installed option is the supported one in GlassFish 3.0.

>
> After all, the sentence from your first URL reference reads:
>
> "You must use this API with a pre-installed, nonembedded Enterprise Server instance."

see above.

>
> It's unclear to me whether "this API" means javax.ejb.embeddable.EJBContainer or the proprietary Glassfish embedded APIs.

javax.ejb.embeddable.EJBContainer.
>
>>If you are using a different (non-default) setup, you
>>need to specify either the
>>org.glassfish.ejb.embedded.glassfish.installation.root
>>property or
>>org.glassfish.ejb.embedded.glassfish.instance.root,
>>or both to point to the actual locations.
>
>
> OK, but no tutorial I've seen (not that I've seen all of them) indicates that you have to have a pre-existing Glassfish installation. So, yes, I'm using a non-default setup, but I don't know what values to supply for these parameters in the absence of a pre-existing Glassfish installation. Are you saying that even in a non-default setup I am required to have already downloaded and installed Glassfish somewhere else on my machine? Because all the tutorials and documentation (Alexis' included) seem to indicate that all I need to do is have Maven download some stuff on the fly and everything will work.

People tried different things and described how they made them work....
>
> Thanks for the time you're taking to get involved in this thread.

I hope it helps.

Regards,
-marina

>
> Best,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395798
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Gregory Gerard

Once I put domain.xml in org.glassfish.embed on the test classpath (src/test/resources/org/glassfish/embed), my setUpClass() became this and all my beans loaded as expected.

@BeforeClass
public static void setUpClass()
throws Exception {
sEJBContainer = EJBContainer.createEJBContainer();
}

On Apr 7, 2010, at 13:45, glassfish@javadesktop.org wrote:

> Turns out both articles are wrong; you MUST make sure to configure EJBContainer using its EJBContainer.MODULES key, or it will have absolutely no idea where to look to find your EJBs.
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395763
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04
Points: 0

> Once I put domain.xml in org.glassfish.embed on the
> test classpath
> (src/test/resources/org/glassfish/embed), my
> setUpClass() became this and all my beans loaded as
> expected.

Wow; that's [i]horrible[/i]. I mean, that is just absolutely completely horrible.

Was the file empty? How on earth did you figure this out? Thanks for this tip!

Best,
Laird

Gregory Gerard

I agree it's horrific but it got rid of a bunch of crappy code that I'd have to maintain.

It wasn't a straightforward search (I meandered through a bunch of pages for a couple days before I found it):

http://blog.blackbit.be/?p=5

I configured my domain.xml in the admin console, copied it into the magic folder, and away I went. I haven't tried moving the glassfish install directory away (to simulate building on a CI server) yet, but it seems to be self contained so far.

greg

On Apr 7, 2010, at 14:37, glassfish@javadesktop.org wrote:

>> Once I put domain.xml in org.glassfish.embed on the
>> test classpath
>> (src/test/resources/org/glassfish/embed), my
>> setUpClass() became this and all my beans loaded as
>> expected.
>
> Wow; that's [i]horrible[/i]. I mean, that is just absolutely completely horrible.
>
> Was the file empty? How on earth did you figure this out? Thanks for this tip!
>
> Best,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395775
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04
Points: 0

> I agree it's horrific but it got rid of a bunch of
> crappy code that I'd have to maintain.

I hear you there. :-)

> It wasn't a straightforward search (I meandered
> through a bunch of pages for a couple days before I
> found it):
>
> http://blog.blackbit.be/?p=5

But even here he's indicating that the domain.xml file solves a JPA integration problem, not a classpath scanning problem. That is, before he put the domain.xml down, he could (presumably) get the EJBContainer to find his EJBs. I can't do that, with exactly his code. The only thing that has changed is that I am depending on v3.0.1b02, not b74 as he has in his example.

I think I'm going to make a dirt simple maven project that manifests this problem and file it as a critical showstopping bug, because at least that way someone else can reproduce it and explain to me how all these tutorials have it wrong. Man, what a frustrating day.

Thanks again.

Gregory Gerard

Yeah, wasted the weekend on this myself.

I never had problems with @Stateless beans being found and deployed. I only had problems once those beans started hitting JPA. I went through many iterations of installroot/instanceroot and they all sucked.

My project is pretty simple (it was just to preflight GFv3 for deployment and testing before moving from Hibernate/Spring/Tomcat) and is exclusively maven.

I haven't had a chance to post cleaned up version of it to see if others are having similar problems.

Please post your success/failure when you get the chance.

greg

On Apr 7, 2010, at 15:02, glassfish@javadesktop.org wrote:

>> I agree it's horrific but it got rid of a bunch of
>> crappy code that I'd have to maintain.
>
> I hear you there. :-)
>
>> It wasn't a straightforward search (I meandered
>> through a bunch of pages for a couple days before I
>> found it):
>>
>> http://blog.blackbit.be/?p=5
>
> But even here he's indicating that the domain.xml file solves a JPA integration problem, not a classpath scanning problem. That is, before he put the domain.xml down, he could (presumably) get the EJBContainer to find his EJBs. I can't do that, with exactly his code. The only thing that has changed is that I am depending on v3.0.1b02, not b74 as he has in his example.
>
> I think I'm going to make a dirt simple maven project that manifests this problem and file it as a critical showstopping bug, because at least that way someone else can reproduce it and explain to me how all these tutorials have it wrong. Man, what a frustrating day.
>
> Thanks again.
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395778
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Arun Gupta

On 4/7/10 1:12 PM, glassfish@javadesktop.org wrote:
> So many articles about EJBContainer, so many that don't work!
>
> There's a great article here (http://www.adam-bien.com/roller/abien/entry/embedding_ejb_3_1_container) showing how to get an EJB 3.1 container running. It claims that no further configuration is necessary. This implies I don't have to set up a filesystem, or tell the testing machinery where to create the embedded EJB container, or anything. That's great; so I don't. I just say EJBContainer.createEJBContainer() and off I go.
I followed this blog ...

... created a template Maven project
... changed generated App.java to:

@Stateless
public class App {

public static void main(String[] args) {
System.out.println("Hello World!");
}

public static String sayHello(String name) {
return "Hello " + name;
}
}

... added a new method in generated AppTest.java as:

public void testEJB() throws NamingException {
EJBContainer ejbC = EJBContainer.createEJBContainer();

Context ctx = ejbC.getContext();

App app = (App) ctx.lookup("java:global/classes/App");

assertNotNull(app);

String NAME = "Duke";

String greeting = app.sayHello(NAME);

assertNotNull(greeting);

assertTrue(greeting.endsWith(NAME));

ejbC.close();
}

... and invoked mvn test to see:

Apr 7, 2010 3:06:10 PM com.sun.enterprise.security.SecurityLifecycle
onInitialization
INFO: Security service(s) started successfully....
Apr 7, 2010 3:06:11 PM com.sun.ejb.containers.BaseContainer initializeHome
INFO: Portable JNDI names for EJB App :
[java:global/classes/App!org.glassfish.embedded.samples.App,
java:global/classes/App]
Apr 7, 2010 3:06:11 PM org.glassfish.admin.mbeanserver.JMXStartupService
shutdown
INFO: JMXStartupService and JMXConnectors have been shut down.
Apr 7, 2010 3:06:11 PM com.sun.enterprise.v3.server.AppServerStartup stop
INFO: Shutdown procedure finished
Apr 7, 2010 3:06:11 PM AppServerStartup run
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] exiting
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.429 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

So the instructions for a minimal EJB did work fine for me. I had to
change the dependency to "compile" instead of "test" in order to compile
the bean. There are other ways to solve this problem but the promise of
"no further configuration" seems fine with this setup.

I'll try adding JPA to the mix and see this changes.

-Arun

>
> (It starts up, I should add, barfs out several SEVERE messages that look alarming concerning the fact that it doesn't know where its directory is, even though I'm told I don't have to supply one.)
>
> When I fire up a similar JUnit test under Maven, lo and behold Glassfish comes up, tells me no modules were found (!!), and then, understandably, fails when I attempt to do any lookup--any at all, including of "java:", "java:global", etc.--since nothing got installed in it. So much for no further configuration necessary!
>
> Another article here (http://blogs.sun.com/alexismp/entry/testing_ejb_3_1_s) implies that EJBs that are found at container startup time will be deployed. What does that mean? Do I have to package up an ejb-jar? Can't I leave my classes in their maven directories (target/classes, target/test-classes)? What's going on here? Isn't this configuration? Shouldn't my code get found, as described in the article? If not, where are the steps I need to perform so that Glassfish finds my stuff?
>
> So, having read these two articles and the product documentation, I still can't figure out how to test my EJB. What piece of documentation should I read next?
>
> Thanks,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395759
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04
Points: 0

Hi, Arun; try it so that Surefire uses an empty surefirebooter jar file to run its tests. I got mine to do this by setting the surefire configuration option perTest. I believe you'll see the same behavior.

Thanks all for chiming in here. Good to know as I suspected that the somewhat breathless zero-config, fire it up, nothing else needed types of posts I've seen are...not entirely accurate, to put it gently. :-) I do appreciate your time and effort on these forums.

Best,
Laird

Marina Vatkina

glassfish@javadesktop.org wrote:
> Hi, Arun; try it so that Surefire uses an empty surefirebooter jar file to run its tests. I got mine to do this by setting the surefire configuration option perTest. I believe you'll see the same behavior.
>
> Thanks all for chiming in here. Good to know as I suspected that the somewhat breathless zero-config, fire it up, nothing else needed types of posts I've seen are...not entirely accurate, to put it gently. :-)

Or it might not be as simple in a more complicated environment ;)

Regards,
-marina
> I do appreciate your time and effort on these forums.
>
> Best,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395813
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04
Points: 0
ljnelson
Offline
Joined: 2003-08-04
Points: 0

Incidentally, when I set my maven configuration parameter for maven-surefire-plugin to "once", everything works as in Adam's original article, and Maven builds a "normal" java.class.path. Unfortunately, a of "once" will cause problems downstream for other tests which require "always". Maven folks will know what I'm talking about.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04
Points: 0

You can detect whether Surefire is in play and running with a forkMode of once by using this (horrible) little bit of logic:

[code]
@BeforeClass
public static void handleSurefire() {
final String surefireRealClassPath = System.getProperty("surefire.real.class.path");
final String surefireTestClassPath = System.getProperty("surefire.test.class.path");
final String javaClassPath = System.getProperty("java.class.path");

if (surefireRealClassPath == null) {
if (surefireTestClassPath != null) {
// surefire, and forkMode == never; puke
fail("It looks like you're running under the Maven Surefire plugin, but your forkMode is set to never. forkMode must be set to once.");
} else {
final int psepIndex = javaClassPath.indexOf(File.pathSeparator);
if (psepIndex < 0) {
// No path separator, so only one classpath entry
final int surefireBooterIndex = javaClassPath.indexOf("surefirebooter");
if (surefireBooterIndex >= 0) {
// surefire, and forkMode == always; puke
fail("It looks like you're running under the Maven Surefire plugin, but your forkMode is set to always. forkMode must be set to once.");
}
}
}
}
}
[/code]

mvatkina
Offline
Joined: 2005-04-04
Points: 0

This will only be a hint, not a solution... Can you attach the boot jar with the class-path manifest entry?

thanks,
-marina

ljnelson
Offline
Joined: 2003-08-04
Points: 0

Sure; it's attached. In case it's not obvious, its contents change wildly depending on what's in your Maven dependency list.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04
Points: 0

A last note here, kindly provided to me by the Maven developers list.

For those needing to leave their always, you can work around the classloading problem by having a look at http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loa.... Setting to false did the trick, with the drawback being if you have a big classpath it might not "fit" on the command line.

Best,
Laird

Gregory Gerard

Hi, Laird,

I ran into the same issue. I was able to get automagical container configuration by putting a domain.xml into the package org.glassfish.embed:
src/test/resources/org/glassfish/embed/domain.xml

With that I was able to get my JDBC DataSources to resolve okay.

There seem to be a lot of problems with embedded in general -- the recent thread on the db not being setup reliably for unit testing for instance.

I still have two outstanding issues:
1. logging doesn't work when set in persistence.xml under embedded -- same file in real GF works fine and I get all the messages.
2.
in my persistence.xml drops and creates the tables at the beginning and when I close the container, drops them all. Again, real GF works as expected and the tables remain.

greg

On Apr 7, 2010, at 13:12, glassfish@javadesktop.org wrote:

> So many articles about EJBContainer, so many that don't work!
>
> There's a great article here (http://www.adam-bien.com/roller/abien/entry/embedding_ejb_3_1_container) showing how to get an EJB 3.1 container running. It claims that no further configuration is necessary. This implies I don't have to set up a filesystem, or tell the testing machinery where to create the embedded EJB container, or anything. That's great; so I don't. I just say EJBContainer.createEJBContainer() and off I go.
>
> (It starts up, I should add, barfs out several SEVERE messages that look alarming concerning the fact that it doesn't know where its directory is, even though I'm told I don't have to supply one.)
>
> When I fire up a similar JUnit test under Maven, lo and behold Glassfish comes up, tells me no modules were found (!!), and then, understandably, fails when I attempt to do any lookup--any at all, including of "java:", "java:global", etc.--since nothing got installed in it. So much for no further configuration necessary!
>
> Another article here (http://blogs.sun.com/alexismp/entry/testing_ejb_3_1_s) implies that EJBs that are found at container startup time will be deployed. What does that mean? Do I have to package up an ejb-jar? Can't I leave my classes in their maven directories (target/classes, target/test-classes)? What's going on here? Isn't this configuration? Shouldn't my code get found, as described in the article? If not, where are the steps I need to perform so that Glassfish finds my stuff?
>
> So, having read these two articles and the product documentation, I still can't figure out how to test my EJB. What piece of documentation should I read next?
>
> Thanks,
> Laird
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395759
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04
Points: 0

(Switched this question to unanswered.)

ljnelson
Offline
Joined: 2003-08-04
Points: 0

Turns out both articles are wrong; you MUST make sure to configure EJBContainer using its EJBContainer.MODULES key, or it will have absolutely no idea where to look to find your EJBs.

ljnelson
Offline
Joined: 2003-08-04
Points: 0

Both articles are wrong, and the Javadoc is wrong. The javadoc says that if you call the no-argument createEJBContainer() method, that the classpath will be scanned for, among other things, exploded EJB modules.

I'm in Maven, and so I read this to mean that it will pick up my EJBs if they are visible under either the target/classes or target/test-classes area, both of which are in my classpath. However they are not picked up.

Pushing the com.sun.enterprise and the org.glassfish log levels to FINEST does not indicate what the problem is.

Specification violations aside, at least I have a workaround!

ljnelson
Offline
Joined: 2003-08-04
Points: 0

I should mention that my tests are being run by Maven's surefire plugin, which is hardly revolutionary. Nevertheless, it does deal with classpaths in a slightly odd way, if I remember correctly. It builds an empty jar in a temp area whose Class-Path: manifest entry contains the "real" Maven-computed classpath.

Could it be possible that EJBContainer#createEJBContainer() is doing something insanely stupid like asking its classloader for a list of URLs that it should scan? Because of course if it does that it won't get the Class-Path: manifest entries, will it?

ljnelson
Offline
Joined: 2003-08-04
Points: 0

> Could it be possible that
> EJBContainer#createEJBContainer() is doing something
> insanely stupid like asking its classloader for a
> list of URLs that it should scan? Because of course
> if it does that it won't get the Class-Path: manifest
> entries, will it?

Just hacked the living snot out of the parent URLClassLoader to shove in the actual URLs from the surefire manifest, so that by the time EJBContainer is run it's running with a "real" classpath, just in case that was the issue.

It's not. Of course.

So lessons learned so far:
1. Always specify MODULES. Yes, that means re-creating your classpath.
2. There must not be a TCK entry for this particular specification component. Ahem.
3. "No configuration" NEVER EVER EVER means no configuration.

Plowing ahead to see what else is broken here. :-(