I believe a solution to the remote class loading problem is to wrap any deployment exceptions in such a way that you don't need the remote classes. For example, print the stack trace of a QL exception to a String, pop that in a field of a DeploymentException, and send the DeploymentException without a linked QL exception. Or better yet, forget the stack trace (or only print it on the server) and just print the actual error message on the client side (Can't deploy: your EJB QL is invalid: '...'"). That seems to make a lot more sense to me than allowing remote class loading just to print arbitrary exceptions.
Aaron On Thu, 7 Jul 2005, Gianny Damour wrote: > One of the benefit is to allow for remote class loading of classes, > which cannot be loaded from the deployer classpath. For instance, > exceptions nested within DeploymentExceptions may not be defined by the > deployer classpath, e.g. org.tranql.ql.QueryException, which result in > ClassNotFoundException to be thrown on the deployer side. > > I don't think that we should enable remote class loading by default, > especially with the provided policy file. Perhaps that we could control > the installation of a security manager via a switch. > > Thanks, > Gianny > > > > >> John > > > > > > Jacek > > > > > >
