DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37727>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37727 ------- Additional Comments From [EMAIL PROTECTED] 2005-12-01 10:15 ------- (In reply to comment #2) > So the reasoning is (I hope you're right, it'll be good to be wrong here) - > * BasicMessage has this field - Object[] values > * Therefore, one may not guarantee serializability of BasicMessage > The rest is just a cascading effect since BasicMessage's go everywhere. Am I > being too convoluted about some corner cases? ;-) The more I think about the > above, there is little that can be done either way. OK, I understand where you're coming from now. My view is as long as we (the libarary developers) haven't put anything that would prevent serializabilty then thats good enough. If a user adds a non-serializable object as a replacement parameter then thats their issue. > And I agree with you when you say that there is little that we can do with the > other classes we *surely* know are not serializable. Maybe its best to leave > a "known issue" in the release notes about these and move on? Personally I would rather the webapp implementations were removed from Commons Resources - it would be one less "off putting" dependency (even if it is realistically optional) and theres so little to the implementations. I also think we could probably refactor XMLResources and PropertyResources so that its straightforward to customize how the InputStreanm is acquired - which means Webapp implementations of these would be simpler to do. I also think we should remove the ResourcesBundle implementation - the main point of Commons Resources is to provide an alternative to that class - so I don't see much merit in "wrapping it". -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
