geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Invoking the deploy tool under a security manager and startup scripts
Date Thu, 07 Jul 2005 13:02:25 GMT
	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.


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
> >
> >

View raw message