Hi, Wouter
>> If not, can you send your application.xml
>>
>
> Well, Maven generates an application.xml file:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" version="5">
> <display-name>my-ear</display-name>
> <module>
> <web>
> <web-uri>my-web.war</web-uri>
> <context-root>/my</context-root>
> </web>
> </module>
> <module>
> <ejb>my-ejb.jar</ejb>
> </module>
> <module>
> <ejb>my-ws.jar</ejb>
> </module>
> </application>
>
> Besides these module artifacts there are several jar files in the EAR
> that are needed for the application. It looks like these jars aren't
> loaded properly.
>
>
Maybe these jars are the problem. Are the missing classes from one of
these jars? Where are the jars located, are they just at the ear root
and not referenced by any Manifest Class-Path entry? We used to load any
jars at the ear root, but no longer doing that in v3 (to enforce the jar
visibility rules defined in EE spec). The ear library jars need to be
packaged in the ear lib directory.
You can also try the "compatibility" property to use the same v2 jar
visibility to see if it makes a difference:
asadmin deploy --property compatibility=v2 foo.ear
If repackaging or the property does not work, please provide more
details on your packaging (what is the class that's not loaded and where
is the jar that has it etc etc), and of course a test case will be the
best, but as you said it may take you some time to come up with the test
case.
Thanks,
- Hong