james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincenzo Gianferrari Pini" <vincenzo.gianferrarip...@praxis.it>
Subject Mail attributes: backward and forward compatibility
Date Wed, 16 Jul 2003 15:45:19 GMT
Addressing compatibility issues that may be introduced by the new mail attributes feature,
I'd like to write the following considerations:

1.	Using file-based repositories

	1.1	The mechanism used to have messages persistent is by java serialization/de-serialization.
MailImpl.writeObject(java.io.ObjectOutputStream out) and MailImpl.readObject(java.io.ObjectInputStream
in) do the work. The various fields of a MailImpl object are explicitely managed by appropriate
in.readObject() and out.writeObject(...) commands, in a synchronized sequence. The last field
being serialized and hence de-serialized is the "lastUpdated" field.

	1.2	Soeren Hilmer implemented serialization/de-serialization of the mail attributes HashMap
by serializing the "attributes" field as the last but one field,i.e. the sequence is:
	        ...
	        out.writeObject(attributes);
	        out.writeObject(lastUpdated);
	        ...
	1.3	De-serialization for those two last fields is done as follows:
	        ...
	        Object o = in.readObject();
	        //this check is done to be backwards compatible with mail repositories
	        if (o instanceof Date) {
	            setLastUpdated((Date)o);
	            attributes = new HashMap();
	        } else {
	            attributes = (HashMap)o;
	            setLastUpdated((Date) in.readObject());
	        }
	        ...

	1.4	This way, any message serialized by a "pre-mailAttributesFeature" James.sar, that hence
is WITHOUT the "attributes" field, will be automatically de-serialized by a "post-mailAttributesFeature"
James.sar, and the attributes field will simply contain an empty HashMap. Backwards compatibility
is achieved. I did test it.

	1.5	It is not true the reverse (forward compatibility): if a message is stored by a "post-mailAttributesFeature"
James.sar, hence WITH the "attributes" field, and for some reason the James installation is
reverted back to a "pre-mailAttributesFeature" James.sar, a de-serialization of such message
will throw an exception, probably a ClassCastException.

	1.6	Because of that I suggest the following change:

		1.6.1	Serialize the attributes by last:
	        ...
	        out.writeObject(lastUpdated);
	        out.writeObject(attributes);
	        ...

		1.6.2	De-serialize with the following code:
	        ...
	        setLastUpdated((Date) in.readObject());
	        // the following is under try/catch to be backwards compatible
	        // with messages created with James version <= 2.2.0a8
	        try {
	            attributes = (HashMap) in.readObject();
	        } catch (OptionalDataException ode) {
	            if (ode.eof) {
	                attributes = new HashMap();
	            } else {
	                throw ode;
	            }
	        }
	        ...

		1.6.3	This way compatibility would be automatically and safely achieved in both directions.
I just tested all this and it works both ways.

2.	Using db-based repositories

	2.1	In this case things are simpler, though not automatic. It's based on the following two
steps:

		2.1.1	Installing the "post-mailAttributesFeature" James.sar. This will *not* by itself activate
the mail attributes feature.

		2.1.2	Some time later on changing sqlResources.xml (commenting/uncommenting all together
the relevant sql commands) and having the "message_attributes" field defined in the "inbox"
and "spool" tables. Restarting the server at this point will activate the mail attributes
feature.

	2.2	If there is (like in 1.4) any message serialized by a "pre-mailAttributesFeature" James.sar,
that hence is WITHOUT the "attributes" field, it will be automatically de-serialized by a
"post-mailAttributesFeature" James.sar, and the attributes field will simply contain an empty
HashMap. Backwards compatibility is again achieved. I did test it. The only thing to care
is that, when altering the two tables to define the "message_attributes" field, it will have
to allow for nulls, even if new messages will be stored with "message_attributes" set to a
valid HashMap.

	2.3	Going back to a "pre-mailAttributesFeature" James.sar (forward compatibility) implies
also reverting to a "pre-mailAttributesFeature" sqlResources.xml. The "message_attributes"
field must either be dropped OR set to allow nulls. Because of this, I suggest to have the
"inbox" and "spool" tables create statements in sqlResources.xml have the definition of the
"message_attributes" allowing nulls IN ANY CASE.

Any suggestion, particularly regarding points 1.6 and 2.3?

Vincenzo


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message