You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/04/23 10:22:14 UTC
New JCR block
Hi all,
I just committed a new JCR block. This block provides two features: a
Repository component, and a "jcr:" protocol.
The Repository component is nothing more than the standard
javax.jcr.Repository interface, but provides a way to centrally define
how to access the repository (Jackrabbit conf file, JNDI, etc) and how
to obtain credentials to log into the repository. There's currently only
one concrete implementation that uses Jackrabbit.
The JCR source factory is more interesting, as it provides a traversable
and modifiable source that hides away the details of the repository
structure and node types. To achieve this, we need to configure it by
defining a mapping from node types to "files" and "folders" that will be
visible through the "jcr:" protocol.
The result is that we can now use a JCR repository in Cocoon just like
we use the regular filesystem.
As an example, here's how this source factory is configured for the
standard filesystem-like node types defined by JCR:
<component-instance
class="org.apache.cocoon.jcr.source.JCRSourceFactory" name="jcr">
<folder-node type="rep:root" new-file="nt:file"
new-folder="nt:folder"/>
<folder-node type="nt:folder" new-file="nt:file"/>
<file-node type="nt:file" content-path="jcr:content"
content-type="nt:resource"/>
<file-node type="nt:linkedFile" content-ref="jcr:content"/>
<content-node type="nt:resource"
content-prop="jcr:data"
mimetype-prop="jcr:mimeType"
lastmodified-prop="jcr:lastModified"
validity-prop="jcr:lastModified"/>
</component-instance>
More detailed information about this configuration is given in
o.a.c.jcr.source.JCRSourceFactory's javadoc.
This source factory is still a bit primitive regarding all features
provided by JCR. Future enhancements include querying the repository,
handling workspaces, node properties, versions, etc.
Your feedback and opinions about this initial implementation and its
future evolutions are more than welcome!
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: New JCR block
Posted by Torsten Curdt <tc...@apache.org>.
Sylvain Wallez wrote:
> Hi all,
>
> I just committed a new JCR block. This block provides two features: a
> Repository component, and a "jcr:" protocol.
Awesome news, mate!
Looking forward playing with it...
cheers
--
Torsten
Re: New JCR block
Posted by Michael Wechner <mi...@wyona.com>.
Sylvain Wallez wrote:
> Michael Wechner wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Your feedback and opinions about this initial implementation and its
>>> future evolutions are more than welcome!
>>
>>
>>
>>
>> very cool. I will check how it will fit together with the Lenya
>> specific stuff
>>
>> http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/
>>
>> Re the JCR library lib/optional/jcr-0.16.4.jar, is it really allowed
>> to re-distribute
>> this?
>>
>> Re the Jackrabbit library
>> lib/optional/jackrabbit-20050422T153417.jar, I think
>> it would make sense to use the LCR (Last Changed Revision) number
>> instead the date
>> within the filename.
>
>
>
> I'm no subversion expert, hence my hesitation to use it. How does this
> LCR behave when the last commit was done somewhere deep in the
> hierarchy and not on the checkout root?
LCR is "global" in the sense that it is valid for all subdirectories.
Give it a try by running "svn info" within your jackrabbit/trunk
directory ;-)
As Torsten is poiting out, it would make sense for all Subversion based
libraries
which don't have a release version (whereas a release could actually be
mapped onto
a LCR)
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: New JCR block
Posted by Sylvain Wallez <sy...@apache.org>.
Michael Wechner wrote:
> Sylvain Wallez wrote:
>
>> Your feedback and opinions about this initial implementation and its
>> future evolutions are more than welcome!
>
>
>
> very cool. I will check how it will fit together with the Lenya
> specific stuff
>
> http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/
>
> Re the JCR library lib/optional/jcr-0.16.4.jar, is it really allowed
> to re-distribute
> this?
>
> Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar,
> I think
> it would make sense to use the LCR (Last Changed Revision) number
> instead the date
> within the filename.
I'm no subversion expert, hence my hesitation to use it. How does this
LCR behave when the last commit was done somewhere deep in the hierarchy
and not on the checkout root? What is the number returned by "svn
update" at the checkout root?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: New JCR block
Posted by Torsten Curdt <tc...@apache.org>.
> Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar, I
> think
> it would make sense to use the LCR (Last Changed Revision) number
> instead the date
> within the filename.
yepp +1 ...I think we should make this a standard for libs
that are not released yet and come from subversion.
cheers
--
Torsten
Re: New JCR block
Posted by Michael Wechner <mi...@wyona.com>.
Sylvain Wallez wrote:
>
>
> Your feedback and opinions about this initial implementation and its
> future evolutions are more than welcome!
very cool. I will check how it will fit together with the Lenya specific
stuff
http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/
Re the JCR library lib/optional/jcr-0.16.4.jar, is it really allowed to
re-distribute
this?
Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar, I
think
it would make sense to use the LCR (Last Changed Revision) number
instead the date
within the filename.
Thanks
Michi
>
> Enjoy,
> Sylvain
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: New JCR block
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Hi all,
>>>
>>> I just committed a new JCR block. This block provides two features: a
>>> Repository component, and a "jcr:" protocol.
>>
>>
>>
>> Awesome news!
>>
>>> The Repository component is nothing more than the standard
>>> javax.jcr.Repository interface, but provides a way to centrally
>>> define how to access the repository (Jackrabbit conf file, JNDI, etc)
>>> and how to obtain credentials to log into the repository. There's
>>> currently only one concrete implementation that uses Jackrabbit.
>>
>>
>>
>> That's very cool... I needed something like this for Linotype.
>>
>>> The JCR source factory is more interesting, as it provides a
>>> traversable and modifiable source that hides away the details of the
>>> repository structure and node types. To achieve this, we need to
>>> configure it by defining a mapping from node types to "files" and
>>> "folders" that will be visible through the "jcr:" protocol.
>>>
>>> The result is that we can now use a JCR repository in Cocoon just
>>> like we use the regular filesystem.
>>>
>>> As an example, here's how this source factory is configured for the
>>> standard filesystem-like node types defined by JCR:
>>> <component-instance
>>> class="org.apache.cocoon.jcr.source.JCRSourceFactory" name="jcr">
>>> <folder-node type="rep:root" new-file="nt:file"
>>> new-folder="nt:folder"/>
>>> <folder-node type="nt:folder" new-file="nt:file"/>
>>> <file-node type="nt:file" content-path="jcr:content"
>>> content-type="nt:resource"/>
>>> <file-node type="nt:linkedFile" content-ref="jcr:content"/>
>>> <content-node type="nt:resource"
>>> content-prop="jcr:data"
>>> mimetype-prop="jcr:mimeType"
>>> lastmodified-prop="jcr:lastModified"
>>> validity-prop="jcr:lastModified"/>
>>> </component-instance>
>>
>>
>>
>> how do you expand the prefixes in the attribute values?
>
>
>
> I don't ;-)
>
> All methods in the JCR API use prefixed names, and prefix mappings are
> stored within the repository itself.
well, this is not entirely correct. you can overload the prefixes in
your workspace ;-)
> So I expect the mapping writer to
> be consistent with prefixes defined in the repository.
this is a huge mistake. if I take my content and your content and merge
them into a single repository, then we could have the exact same
prefixes, mapped to a different namespace and the JCR API is totally
consistent as long as you specify that prefix in the workspace you are
using.
I agree that by default the default prefix is good enough, but in the
long term we might want to keep the door open for overloading prefixes
in the workspace.
> Now if we want to use full namespace URIs, we can also accept the
> notation that's used in some places in JCR, i.e. "{full-uri}name".
that's ugly :-) I'd much rather use the XSLT-like prefix expansion based
on the current namespace prefix description of the element contenxt in
the XML infoset.
>>> More detailed information about this configuration is given in
>>> o.a.c.jcr.source.JCRSourceFactory's javadoc.
>>>
>>> This source factory is still a bit primitive regarding all features
>>> provided by JCR. Future enhancements include querying the repository,
>>> handling workspaces, node properties, versions, etc.
>>>
>>> Your feedback and opinions about this initial implementation and its
>>> future evolutions are more than welcome!
>>
>>
>>
>> In linotype, what I needed was a way to store new items in the
>> repository and then query the repository for the last n in reversed
>> chronological order (LIFO).
>>
>> There are many ways we can glue query capabilities to JCR in cocoon, I
>> would like to discuss with you people what is best way to do that and
>> what are the requirements.
>
>
>
> My initial thoughts about this is to use URI parameters for querying,
> e.g. "jcr://?xpath=/news/items[position() < 10]" and have this return a
> collection source, i.e. one that has children that would be the query
> results.
>
> The parameter name is the query language to be used (e.g. xpath, sql, etc).
sure, that's a start, let's see how far along we can go with that.
--
Stefano.
Re: New JCR block
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> I just committed a new JCR block. This block provides two features: a
>> Repository component, and a "jcr:" protocol.
>
>
> Awesome news!
>
>> The Repository component is nothing more than the standard
>> javax.jcr.Repository interface, but provides a way to centrally
>> define how to access the repository (Jackrabbit conf file, JNDI, etc)
>> and how to obtain credentials to log into the repository. There's
>> currently only one concrete implementation that uses Jackrabbit.
>
>
> That's very cool... I needed something like this for Linotype.
>
>> The JCR source factory is more interesting, as it provides a
>> traversable and modifiable source that hides away the details of the
>> repository structure and node types. To achieve this, we need to
>> configure it by defining a mapping from node types to "files" and
>> "folders" that will be visible through the "jcr:" protocol.
>>
>> The result is that we can now use a JCR repository in Cocoon just
>> like we use the regular filesystem.
>>
>> As an example, here's how this source factory is configured for the
>> standard filesystem-like node types defined by JCR:
>> <component-instance
>> class="org.apache.cocoon.jcr.source.JCRSourceFactory" name="jcr">
>> <folder-node type="rep:root" new-file="nt:file"
>> new-folder="nt:folder"/>
>> <folder-node type="nt:folder" new-file="nt:file"/>
>> <file-node type="nt:file" content-path="jcr:content"
>> content-type="nt:resource"/>
>> <file-node type="nt:linkedFile" content-ref="jcr:content"/>
>> <content-node type="nt:resource"
>> content-prop="jcr:data"
>> mimetype-prop="jcr:mimeType"
>> lastmodified-prop="jcr:lastModified"
>> validity-prop="jcr:lastModified"/>
>> </component-instance>
>
>
> how do you expand the prefixes in the attribute values?
I don't ;-)
All methods in the JCR API use prefixed names, and prefix mappings are
stored within the repository itself. So I expect the mapping writer to
be consistent with prefixes defined in the repository.
Now if we want to use full namespace URIs, we can also accept the
notation that's used in some places in JCR, i.e. "{full-uri}name".
>> More detailed information about this configuration is given in
>> o.a.c.jcr.source.JCRSourceFactory's javadoc.
>>
>> This source factory is still a bit primitive regarding all features
>> provided by JCR. Future enhancements include querying the repository,
>> handling workspaces, node properties, versions, etc.
>>
>> Your feedback and opinions about this initial implementation and its
>> future evolutions are more than welcome!
>
>
> In linotype, what I needed was a way to store new items in the
> repository and then query the repository for the last n in reversed
> chronological order (LIFO).
>
> There are many ways we can glue query capabilities to JCR in cocoon, I
> would like to discuss with you people what is best way to do that and
> what are the requirements.
My initial thoughts about this is to use URI parameters for querying,
e.g. "jcr://?xpath=/news/items[position() < 10]" and have this return a
collection source, i.e. one that has children that would be the query
results.
The parameter name is the query language to be used (e.g. xpath, sql, etc).
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: New JCR block
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Hi all,
>
> I just committed a new JCR block. This block provides two features: a
> Repository component, and a "jcr:" protocol.
Awesome news!
> The Repository component is nothing more than the standard
> javax.jcr.Repository interface, but provides a way to centrally define
> how to access the repository (Jackrabbit conf file, JNDI, etc) and how
> to obtain credentials to log into the repository. There's currently only
> one concrete implementation that uses Jackrabbit.
That's very cool... I needed something like this for Linotype.
> The JCR source factory is more interesting, as it provides a traversable
> and modifiable source that hides away the details of the repository
> structure and node types. To achieve this, we need to configure it by
> defining a mapping from node types to "files" and "folders" that will be
> visible through the "jcr:" protocol.
>
> The result is that we can now use a JCR repository in Cocoon just like
> we use the regular filesystem.
>
> As an example, here's how this source factory is configured for the
> standard filesystem-like node types defined by JCR:
> <component-instance
> class="org.apache.cocoon.jcr.source.JCRSourceFactory" name="jcr">
> <folder-node type="rep:root" new-file="nt:file"
> new-folder="nt:folder"/>
> <folder-node type="nt:folder" new-file="nt:file"/>
> <file-node type="nt:file" content-path="jcr:content"
> content-type="nt:resource"/>
> <file-node type="nt:linkedFile" content-ref="jcr:content"/>
> <content-node type="nt:resource"
> content-prop="jcr:data"
> mimetype-prop="jcr:mimeType"
> lastmodified-prop="jcr:lastModified"
> validity-prop="jcr:lastModified"/>
> </component-instance>
how do you expand the prefixes in the attribute values?
> More detailed information about this configuration is given in
> o.a.c.jcr.source.JCRSourceFactory's javadoc.
>
> This source factory is still a bit primitive regarding all features
> provided by JCR. Future enhancements include querying the repository,
> handling workspaces, node properties, versions, etc.
>
> Your feedback and opinions about this initial implementation and its
> future evolutions are more than welcome!
In linotype, what I needed was a way to store new items in the
repository and then query the repository for the last n in reversed
chronological order (LIFO).
There are many ways we can glue query capabilities to JCR in cocoon, I
would like to discuss with you people what is best way to do that and
what are the requirements.
--
Stefano.