> I think in the end with your example is that SybaseSQLException is not
> in the classloader of your client side application. Two observations: > > 1) You could just unpack it from sybase.jar and zip it into > the client side jar (not a great crime). > 2) Alternatively hide not wrap the causing exception in your own > ServerException ( thout sounds very generic, I hope you don;t > have it on every method, unless it is Runtime derived. I ended up going with #1 because it would be easiest. Our server side exceptions should be responsibe for wrapping any excetpions anyhow. Also, having the internal exceptions on the client side makes it alot easier to debug on our end. :) > Questions, > - your client side app Swing or a webapp? Initially it is a webapp in tomcat, but eventually we will be supporting a lots of different apps with lots of different protocols. Kind of like a do-all EDI server. Right now we have lots of old apps doing file based queueing and this project should be able to replace all of them. (Even mantaining backwards-compatibility if needed) > - AltRMI supports (or appears that it does) object publishing as > opposed to interface publishing. We are thinking of droppping that > frivilous claim. It will mean that a fair few arg names get renamed > from "classesOrInterfacesToExpose" to "interfacesToExpose". How say > you....(given you are the only user of AltRMI that I know about on > projects I am not a committer to)? Actually I hadn't even noticed that this was implied. (Though I did wonder why it was called "classesOrInterfacesToExpose" :) I think for normal RMI it makes the most sense to do interfaces. Besides, it makes it easier to do the client-side impelmentation when you can cast a class from a factory method. -mike -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
