[
http://issues.apache.org/jira/browse/JCR-680?page=comments#action_12460456 ]
Jukka Zitting commented on JCR-680:
-----------------------------------
> > * Support for namespace remappings in NAME and PATH values
>
> is this a requirement? IMO the spec doesn't mandate it.
The spec says (6.2.5.2):
"A NAME is a pairing of a namespace and a local name. It must be handled
internally in such
a way that when read through the API the namespace is mapped to the current
prefix."
It can of course be argued that "read through the API" means
Property.getValue() instead of Value.getString(), but then having
Value.getType() return PropertyType.NAME wouldn't really make sense.
> (btw huge!)
Agreed, it's rather large. The amount of code is however about the same as in
the current value implementation.
The rationale for proposing a revolutionary rewrite rather than incrementally
improving the existing Value implementation is that the basic design of the
existing implementation doesn't allow easy extension or customization.
> - SerializableInputStream:
> the stream data is materialized in memory during de-/serialization;
> this renders it imo unusable for large streams. in the entire core
> streams are never unconditionally materialized.
Value serialization should never be used by Jackrabbit core, it's included for
other applications like JCR-RMI. Such applications should consider case-by-case
whether custom serialization of binary values is needed. The goal of the
default implementation is full semantic accuracy without extra external
dependencies (like to the file system). It is easy for an application to
override the default behaviour by subclassing CommittedValueFactory.
> - ValueParser:
> the getDate() method does not preserve the time zone in the
> returned Calendar object. the current implementation internally
> uses to ISO8601 utilty class which preserves the time zone
> information. what was the rationale of not using the ISO8601 class?
I think it's generally more useful for a client to receive all date values in
the default timezone of the system. That's just my opinion though, preserving
the time zone information would be no problem.
I used the ISO8601 class as the basis of the Date parsing in ValueParser and
formatting in CommittedDateValue, the methods there are streamlined versions of
the parse and format methods in ISO8601. Since the ISO8601 date formats are not
used elsewhere and people can just as well use ValueFactory for all format
conversions, I don't think having the formatting in a separate utility class is
needed.
> Improve the Value implementation
> --------------------------------
>
> Key: JCR-680
> URL: http://issues.apache.org/jira/browse/JCR-680
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Attachments: class.jpg, JCR-680.patch
>
>
> The current Value implementation found in jackrabbit-jcr-commons has some
> deficiencies like Value.equals() being incorrect in some cases (see for
> example JCR-320), and Name and Path values not following namespace remappings.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
