geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Invoking the deploy tool under a security manager and startup scripts
Date Fri, 08 Jul 2005 10:11:07 GMT
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
>>>
>>>
>>>      
>>>
>>    
>>
>
>  
>


Mime
View raw message