I was not aware of this design decision, thanks for clarifying. Anyway, the remote API is currently implemented on top of the ContentRepository API. This means that I have to take care of providing values for autocreated properties. Is there anything that can be done do prevent this?
I was thinking that maybe, when the "JCR plugins" are installed, a wrapper of Tree may be installed as well. This wrapper could take care of the generation of autocreated properties in the transient space. This is kind of a big change, because the ContentRepository API is not meant to be extended this way. 2015-03-26 14:26 GMT+01:00 Angela Schreiber <[email protected]>: > hi francesco > > well... so far we claimed that it's the responsibility of the > Oak API caller to make sure that items defined to be autocreated > from a JCR point of view must be created. as the Oak API itself > doesn't know about autocreated items. > > afaik delegating this to the TypeEditor will not work, because > JCR mandates for various autocreated items that they are already > present in the transient state (before being saved). > > as you can see it's not only the NodeDelegate that autocreates > items but e.g. also the user management implementation, the versioning > etc. > > kind regards > angela > > On 26/03/15 14:10, "Francesco Mari" <[email protected]> wrote: > >>Hi all, >> >>when using the ContentRepository API with the JCR plugins (as >>installed by the Jcr builder), autocreated properties are not >>generated. >> >>IIUC, this happens because >>org.apache.jackrabbit.oak.util.TreeUtil#autoCreateItems is only called >>when using a org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate, >>instead of being part of the logic executed by >>org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor. >> >>I think that TypeEditor, instead of NodeDelegate, should take care of >>autocreated items. What do you think? >
