Ian McCallion wrote: > I run into similar issues but I happily resolve them by having extra copies of > classes. This is my rationale...
I have no problems with using copies of classes, as such, but there *will* be classloading issues with that strategy (mainly ClassCasts' of the usual kind), since objects are being passed without serialization between layers. I.e. I can't do the "put it everywhere" approach. > This approach suits large team development. Each subteam is responsible for > development and testing of a unit of deployment, and once a shared set of > interfaces, exceptions, and data types has been agreed and developed they can > only be changed with the agreement of all affected subteams. Most of the time > subteams can develop independently, which is one of the most critical things to > enable in a large team environment. In principle I agree with you. It just doesn't apply in my case. The main problem I had was how to make my classes visible everywhere without causing classcast exceptions due to multiple versions. /Rickard -- Rickard �berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
