Me again
Rickard Öberg wrote:
> The approach is right, but hey, why not use UndeclaredThrowableException
> *as* the container? :-) No need to introduce another class that does the
> same thing.
Actually, I think I found an even simpler way. This is only a problem if
it's a local yet non-optimizable call. Cases:
a) "optimize" is on, but the call is not optimizable anyway
b) "optimize" is off
I have added code to these cases (a. is in JRMPContainerInvoker, and b.
is in *Proxy classes) so that exceptions are marshalled and unmarshalled
through a MarshalledObject before sent to the client. This should
enforce the right classloader to be used. This did not need any new
exception to be introduced.
Unfortunately I have no way of testing this properly. I *have* checked
so that it doesn't break any tests though. So, what I'll do is simply
commit this to CVS, and hope that you can try it out as soon as
possible, and see that it works.
To sum up: the problem was with two EAR's deployed in the same server,
which both contain a certain app exception that is thrown. Due to
classloader issues and non-marshaling of exceptions in local yet
unoptimized cases, this introduced problems. These problems are solved
by adding explicit marshaling of exceptions in these cases.
Let me know if it works or not. Fix is in CVS.
regards,
Rickard
--
Rickard Öberg
Email: [EMAIL PROTECTED]
