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 35804] - [configuration] Make Configuration Serializable
Date Fri, 22 Jul 2005 09:47:33 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=35804>.
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=35804





------- Additional Comments From oliver.heger@t-online.de  2005-07-22 11:47 -------
I fully agree that serializable configurations are a useful feature.

However an implementation may be complicated and tricky, especially because a
configuration may hold references to some other objects: a reloading strategy
has already been mentioned, an XML document (XMLConfiguration), later maybe
event listeners, helper objects for interpolation, or strategies for locating
the source files. Forcing all of these objects to be serializable is a too
strong restriction IMO. And declaring all these fields as transient may cause
other problems.

As an alternative approach: What if not the configuration objects as a whole are
serialized, but only the important portions (containing the properties)? There
could be an interface like that:

public interface SerializableConfiguration
{
  /** Returns serializable data of this configuration.*/
  Serializable getSerializable();

  /** Initializes this configuration from serialized data.*/
  void initFromSerializable(Serializable data) throws ConfigurationException;
}

This is a bit less convenient to use, but will probably save us a lot of trouble.

-- 
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