Yes, that is also discussed in the link I included:
http://www.java.net/forum/topic/glassfish/glassfish/embedded-glassfish-and-weaving
But it's not the solution
- I would prefer to test with weaving enabled (to guarantee same
results as when code actually runs)
- regardless, disabling weaving does not help, same classloading problems exist
- if my tests have some (or all) ejb classes in classpath while
running, EJBContainer classloading gets broken and I get problems
during deployment
- I am not 100% what the problems are. Sometimes I get class not found
messages in log, sometimes several pages of some glassfish internal
error message, and sometimes just "Exception while loading the app".
End result usually is that
EJBContainer provider available
The following providers:
org.glassfish.ejb.embedded.EJBContainerProviderImpl
Returned null from createEJBContainer call.
- Even if I do not refer to any of the EJB classes from my test
classes, EJBContainer creation gets broken. As soon as I remove all
the ejb classes from my test classpath, deployment goes fine and I can
fetch my ejbs and successfully call their methods using reflection
- It does not matter whether I have one single entity class in the
classpath (in my-ejb-client.jar) or the full my-ejb.jar, the same
problem
I just don't get it. To test your ejbs you need to have the ejb
classes in your test classpath. But having them in your classpath
breaks EJBContainer deployment. How can that work?
On Tue, Apr 12, 2011 at 9:32 PM, Mitesh Meswani
<mitesh.meswani_at_oracle.com> wrote:
> Weaving requires that byte code transformers are installed on the
> classloader before entity classses are loaded. Your test might be triggering
> an entity class load before you create ejb container and hence you run into
> the issue. You can work around that by specifying property
> "org.glassfish.persistence.embedded.weaving.enabled" with value false.
>
> On 4/12/2011 7:05 AM, janne postilista wrote:
>>
>> I'm trying to use EJB 3.1 Embeddable EJBContainer for integration
>> testing my EJB's.
>>
>> My beans use JPA (EclipseLink) and because of EclipseLink weaving, EJB
>> classes must NOT be in classpath when junit executes my tests:
>>
>> http://www.java.net/forum/topic/glassfish/glassfish/embedded-glassfish-and-weaving
>>
>> Of course my junit tests need to have the EJB classes (at least the
>> interfaces and classes used as arguments and return values). Typical
>> test would be:
>>
>> @Test
>> public void testInEJBContainer() throws Exception {
>>
>> File ejbJarFile = new File("target/dum/dum-ejb.jar");
>>
>> Map props = new HashMap();
>> props.put("org.glassfish.ejb.embedded.glassfish.instance.root",
>> "target/classes/instance-root");
>> props.put(EJBContainer.MODULES, new File[]{ejbJarFile});
>> EJBContainer container = EJBContainer.createEJBContainer(props);
>>
>> CompanyService = (CompanyService)
>> container.getContext().lookup("java:global/dum/CompanyServiceImpl");
>> log.info("result of findAll() " + service.findAll(false));
>> }
>>
>> I don't see how I could run the tests without having CompanyService in
>> the junit classpath. If I try do so, and call java.lang.Object through
>> reflection instead of CompanyService, the test works. But any time I
>> try to use the actual CompanyService class (it does not matter whether
>> it is from actual dum-ejb.jar, or created ejb client jar) the
>> Eclipselink weaving gets broken.
>>
>> It is also mandatory to be able to use int the test the Entity classes
>> that EclipseLink weaves, since those are usually parameters or return
>> values.
>>
>> I guess I could alter the build to do eclipseLink weaving statically,
>> but I'd rather not alter the normal built dum-ejb.jar or dum-ear.ear.
>>
>> Shouldn't this be exactly the typical scenario for which Glassfish
>> EJBContainer exists and is used for? Unit/integration testing EJBs
>> that use JPA? How can it be so damn difficult?
>
>