jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Date Tue, 13 Dec 2005 11:07:24 GMT
hi brian

Brian Moseley wrote:
> Angela Schreiber wrote:

> not having a guaranteed node type for the root node, i can't specify one 
> in the <collection/> section of the resource config. the one defined by 
> jackrabbit isn't good enough, since i want cosmo to remain as portable 
> as possible to other jcr implementations.

you want a config that is good enough for any jsr170 implementation?

actually, i thought this exactly what we have the config for:
make it easy to redefine the set of nodetypes that either
define collections or non-collections. otherwise we could have
left it hardcoded in the resource implemenation.

your config example - even with the hardcoded check for the root
node in the configuration - would not provide a useful
result when used with CRX. and CRX is pretty close to
what i want to say is: i'm pretty sure, that you will have to
adjust your configuration a little bit, when running your cosmo
project on jsr170 implementation selected by change (see above
for the initial reason to built the ResourceConfig).

please note, that any nodetype defined by jsr170 is optional
except for nt:base (section 6.7.22 in the specification).
you cannot rely on a jsr170 implementation providing the
nt:folder nodetype... thus your config is not safe for
any arbitrary jsr170 impl.

for this reason i think its feasible to adjust the config,
when running on different implementation. for your example
(perhaps running on jackrabbit) i would suggest to add
'nt:unstructured' (which is extended by the jackrabbit
internal nodetype rep:root) to the set of nodes that
should be displayed as collection.

> also, i do not want to take the opposite route and specify every 
> nodetype that is not a collection, because that could theoretically be a 
> huge and arbitrarily growing list of node types.

yes, that's why we have both options: either define the
collections or the non-collections.
your argument is - from my point of view contradictory.
with an arbitrary implemenation of jsr170 the list of 
collection-nodetypes could equally grow to a theoretically
huge amount of nodetypes.

kind regards

View raw message