Hi, Ian.
Is the missing class in a library JAR file? Is that JAR at the top-level of the EAR?
If so, that explains things. Java EE 6 prescribes stricter rules about what JARs should and should not be visible to clients, and GlassFish v3 enforces those stricter rules. In v2 top-level JARs (and EJB modules, for that matter) were automatically available to app clients. In v3 the developer must either
1. declare an explicit dependency using the app client JAR's manifest Class-Path setting, or
2. place the library JAR into the EAR's library directory (/lib by default or, if your application.xml specifies <library-directory>, whatever that is)
3. deploy the app using the --property compatibility=v2 option which, for that deployment of the application, uses the v2 JAR visibility rules. While this might be the quickest option for now, I'd recommend (if this is indeed the problem) that you adopt #1 or #2 fairly soon.
Many people feel that the cleanest design (although it might lead to an extra JAR file) is to place the EJB interfaces into a library JAR that's available to the client and the EJB module, with the EJB implementation classes in the EJB JAR. Then the interface library JAR can be placed into the EAR's library directory and would therefore be available to both the client and the EJB module. But the EJB implementations would not be exposed to the client. Obviously you have a v2 app already in a form that used to work, but as you make changes to it you might think about moving to this approach.
- Tim
[Message sent by forum member 'tjquinn' (timothy.quinn_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=382440