Re: o.a.s.jcr.base.internal.loader.Loader vs. o.a.s.jcr.resource.internal.loader.Loader

[Oliver Lietz <ap...@oliverlietz.de>]

Am Donnerstag, 17. April 2008 schrieb Felix Meschberger:
> Hi Oliver,

Hello Felix,

thanks for your detailed explanation and sorry for my late reply. I had to 
move development from a dying Mac OS X 10.4 (ppc/32bit) system to a new 10.5 
(intel/64bit) system and cannot reproduce the problem anymore. The CND files 
(with namespace included) I used for my development are from a working 
Magnolia-based project. It works fine now, though I have some more 
questions...

> Am Donnerstag, den 17.04.2008, 13:17 +0200 schrieb Oliver Lietz:
> > hello all,
> >
> > why are there two Loaders? I'm asking because initial content (with
> > custom node types and namespace) loading from bundle by Loader from
> > resource fails due to missing namespace handling. The necessary methods
> > are present in Loader from base, wonder why they are not used.
>
> This is historic. Initially there was just one loader (in the
> jcr/resource module) which contained node type registration and initial
> content loading. This loader has been split some time ago, such that
> node type registration, which is a repository-wide operation, is part of
> repository "initialization" in the jcr/base module, and the initial
> content loading, which is specific to the Sling workspace, remained in
> the jcr/resource module.
>
> Namespace handling is split: One is the namespaces used for the node
> type registration. These namespaces should be listed in the node type
> definition file (aka CND-file). The other part is the namespaces
> available in the JCR sessions. These namespaces should be declared in a
> bundle - mostly the bundle making the initial node type registration -
> in the Sling-Namespaces header. See for example the jcr/resource module
> [1] itself which defines the sling namespace.
>
> Now, the namespaces are defined in a JCR session emitted from the
> session pool manager by calling the Loader.defineNamespacePrefixes
> method on the session to be returned for login. This should actually
> work pretty fine.
>
> Nevertheless, if you encounter issues, you are very welcome to raise a
> JIRA so that we can fix this.
[...]

The ContentLoader from o.a.s.jcr.contentloader doesn't support same name 
siblings which is a requirement. It's easy to extend the loader but I'm 
unsure about the impact on the rest of Sling. Looks like most parts of Sling 
have to be touched to support SNS. Is it worth the effort? Should I stick to 
Sling or start a new project?

thanks,
O.

Re: o.a.s.jcr.base.internal.loader.Loader vs. o.a.s.jcr.resource.internal.loader.Loader

[Felix Meschberger <fm...@gmail.com>]

Hi Oliver,

Oliver Lietz schrieb:
> Am Donnerstag, 17. April 2008 schrieb Felix Meschberger:
>> Hi Oliver,
> 
> Hello Felix,
> 
> thanks for your detailed explanation and sorry for my late reply. I had to 
> move development from a dying Mac OS X 10.4 (ppc/32bit) system to a new 10.5 
> (intel/64bit) system and cannot reproduce the problem anymore. The CND files 
> (with namespace included) I used for my development are from a working 
> Magnolia-based project. It works fine now, though I have some more 
> questions...

Ok. Glad to hear, it works ...

>> Nevertheless, if you encounter issues, you are very welcome to raise a
>> JIRA so that we can fix this.
> [...]
> 
> The ContentLoader from o.a.s.jcr.contentloader doesn't support same name 
> siblings which is a requirement. It's easy to extend the loader but I'm 
> unsure about the impact on the rest of Sling. Looks like most parts of Sling 
> have to be touched to support SNS. Is it worth the effort? Should I stick to 
> Sling or start a new project?

Well, first of all I don't like SNS as it complicates matters more than 
it helps them. See also Rule #4 in David's Model [1] for more info on 
this topic.

And yes, you are right. Sling is built around the idea of _not_ having 
SNS in that we just ignored the existence of SNS. This does AFAICT not 
mean, the Sling won't work with SNS. I can assume that Sling would be 
perfectly able to resolve an URL of the form 
http://host/content/sns[3]/page.html.

Of course I would be happy, if you would stick with Sling and therefore 
am certainly ready to look into any issues you encounter using SNS.

As a first step, providing a patch for the content loader to support SNS 
content is certainly a good thing.

Regards
Felix

[1] 
http://wiki.apache.org/jackrabbit/DavidsModel#head-1df0224190c265f5156f037eb3f20e314fa6c4a7