commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37727] - [resources] Fix serializability contracts
Date Thu, 01 Dec 2005 09:15:26 GMT
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 niallp@apache.org  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message