Rickard, I've run into similar issues. I often write client-side proxies for my remote EJBs (Business Delegates, or in WebSphere, Access Beans). My instinct is to package these separately (in a client.jar), but like you said they also need access to the EJ Bean interfaces. I certainly don't want to package my bean interfaces in two places.
To me, there seems to be a natural packaging schemes of server-side-only classes (EJB implementation classes), client-side only (Business Delegate), and a shared package of interfaces, exceptions, and data types that form the shared lingo that the client and server use to talk to each other. What I've taken to doing (and this is the way WebSphere's tools handle it) is to package all shared and client-side classes in the ejb-jar. Then, for anyone who needs those classes, put the whole jar on their classpath. For web components, as in your example below, I'd add the ejb-jar.jar to the Manifest Class-Path of the war file. I don't particularly like this, since now the war has access to the server-side classes (the last thing I need is a maintenance programmer directly instantiating an AccountBean), but it seems to be least-bother solution. Ken DeLong -----Original Message----- Date: Thu, 10 Jan 2002 15:16:59 +0100 From: Rickard <[EMAIL PROTECTED]> Subject: Packaging problem I have a packaging problem that I'm curious how people get around. My code consist of 1) EJB beans and interfaces 2) servlet layer JavaBeans 3) external libraries Everything needs to be packaged into an EAR. 2) references classes in 1), including the bean classes. And that's the problem: I want to package the servlet layer stuff in /WEB-INF/classes in my WAR file, and my EJB's in an EJB-JAR file, but that just doesn't work, since then 2) then cannot see 1). If I package classes in 1) in a jar and reference it from the EAR's manifest, then deployment of EJB's fail (using Orion at least) since the classes cannot be found in the EJB-JAR (which now only contains the DD). One option would be to use the "alt-dd" in the module description in the EAR DD, and keep all classes in one jar, but this whole scheme seems broken. And it seems it is the classloading logic used that messes things up, i.e. Java2 classloading. If I did things the way I *really* want it to work, i.e. keep servlet stuff in /WEB-INF/classes (or /WEB-INF/lib) and EJB code in an EJB-JAR, then the classloading logic would have to be changed to a mode that allow loading of classes that are on a "parallel" level and not necessarily "above" in the classloader hierarchy (i.e. a la JBoss 3.0). Have others run into this problem? How did you solve it? Is it solvable..? /Rickard -- Rickard �berg ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
