Michael Wechner wrote:
Andreas Hartmann wrote:

Michael Wechner wrote:

Hi

It seems to me that the current implementation/configuration is mixing
the "pure" JCR usage and the Lenya JCR usage, e.g. within cocoon.xconf

<component class="org.apache.lenya.cms.jcr.LenyaRepository" logger="jcr" role="javax.jcr.Repository">
....



This is no "mixture". The LenyaRepository is a specialization of the
JackrabbitRepository of the JCR block. It attaches the JCR session to the
Cocoon session (this will be necessary to use JCR transactions)

why not implement this into the Cocoon block directly?

Because it's Lenya-specific. The JCR block doesn't make any
presumptions how the JCR session is handled (see discussion on
cocoon-dev).


and
registers Lenya namespaces and node types.



are these for the meta-data?

Yes.


That's just how OOSD works :)

ok. But wouldn't it make sense to differentiate the logger, e.g. jcr.lenya
instead just jcr, in case people use both, I mean the Cocoon JCR repo and the Lenya JCR repo?

Yes, that would certainly make sense.


<component-instance class="org.apache.lenya.cms.jcr.LenyaJCRSourceFactory" name="jcr">
...



The LenyaJCRSourceFactory adds the Lenya mixin nodetype to new
repository nodes.

what's the reason for that?

Meta data are stored as properties. To support these properties, the
node type has to be declared and attached to the content nodes.


won't there be problems if people for instance want to reuse existing pipelines which were making use of the Cocoon JCR Factory?

No, the Lenya JCR components only add functionality.


I think the one of the Cocoon block should be able to coexist beside the
Lenya one and not be replaced the Lenya one.

That would be possible for instance by using a selector for different
repositories.

can you give an example

cocoon.xconf:

<repositories>
  <default> ... </default>
  <myrepo> ... </myrepo>
</repositories>

selector = (...) this.manager.lookup(Repository.ROLE + "Selector");
repository = (...) selector.select("myrepo");



Multiple source factories can be registered anyway
(using different protocols).

I think it makes sense to register teh Lenya Source Factory with another protocol, e.g. jcr-lenya or whatever.

OK, we could do that if we use a selector to manage the repository
implementations or define our own repository service (which
I wouldn't recommend).


To be honest I am still very confused. Where are these classes actually, because I cannot find them within src/java and what file does patch the cocoon.xconf file. I thought this is being done by src/webapp/WEB-INF/cocoon-xconf.xsl, but it doesn't
really contain anything with re to that.

All JCR related stuff is in the JCR publet. This way, we can keep
it clearly separated from the core. (reminder for me: I forgot to
move the jcr.import usecase to the publet)


I'll update the docs "real soon now".

Sorry if the implementation causes confusion, I tried to keep it as
straightforward as possible and use only Cocoon/Avalon development
principles.

BTW - I hope you'll get well soon!

-- Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to