I can easily implement that. At the same time, I propose to ditch
geronimo-classloader-server, which becomes dead code if we do no more
require remote class loading. I will ditch the module in 48h from now if
no one objects during this period.
Thanks,
Gianny
On 7/07/2005 11:02 PM, Aaron Mulder wrote:
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
