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?