jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <Felix.Meschber...@day.com>
Subject Re: JCR-RMI diffs
Date Mon, 09 May 2005 09:27:33 GMT
Hi Jukka,

I just finished the implementation of the Value stuff in the jcr-rmi 

My patch is centered around your proposal of Value and ValueFactory 
implementation with some modifications:

(1) SerialValue is the only class implementing the Value interface. The 
state classes implement the (similar) interface StatefullValue - if you 
come up with a better name, please go ahead :-)

(2) All instance creation is done in SerialValueFactory, where protected 
creator methods have been defined for all constructors. This allows for 
extension of given StatefullValue classes by also extending the 
SerialValueFactory class but prevents breaking the State pattern contract.

(3) The concrete StatefullValue implementation classes are public for 
them to be extensible. The constructors are protected for extensibility 
and to prevent inadvertent instantation.

(4) Added BaseNonStreamValue abstract class providing default 
implementations for the getter methods throwing the correct exceptions. 
Concrete non-stream state classes extend this class and overwrite 
getters allowed according to the spec.

There are still some issues to be resolved:

(a) The InputStream on which a BinaryValue is based is not necessairily 
closed. Should we provide a finalize method to close the stream or wrap 
the InputStream in an anonymous class providing such a finalizer method ?

(b) The parser/formatter of the DateValue class does not work correctly 
according to the spec. See below.

(c) The NameValue, PathValue, and ReferenceValue classes do not 
currently check the syntax of the string value. See below.

Currently the implementation is in the org.apache.jackrabbit.value 
package in the jcr-rmi contribution.

I suggest this to be moved to some common project within jackrabbit such 
that all jackrabbit users - and possibly external users - may reuse the 
same code to prevent code duplication. This would probably also mean to 
move some helper classes from jackrabbit core to that sommon project 
such as the ISO8601 helper class providing Calendar formatting and 
parsing according to the spec.

I will now go on to test this thing and would be happy to receive any 
feedback regarding this issue.

The patch can be retrieved from here: 


View raw message