You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/06/24 16:37:12 UTC
Playing with the JCR RI
Dear Cocooners,
I've just started to take a look at the JCR (a.k.a. JSR-170) Reference
Implementation from Slide, after having read the latest JSR draft, and
I feel like exploring the possibilities of its usage inside Cocoon.
First thing I tried to do is an implementation of the
o.a.c.components.repository.Repository, but then I started to think
that it didn't make much sense. Our Repository interface is meant to
provide a virtual repository API on top of different implementations
(only a WebDAV impl. is available at the moment). But isn't this just
what JCR is about? Wouldn't it be better if we dropped our own
Repository and adopted the JCR APIs? We already have a WebDAV and a
local filesystem implementation available in the RI (plus an
implementation on top of a "virtual filesystem" which I haven't grokked
yet). Of course, nothing prevents us from wrapping a JCR repo inside an
Avalon component, if we want.
Then I thought about doing a Generator that could stream the XML
representation of a JCR repo provided by the API. Should be a piece of
cake as there's a method that streams it to a ContentHandler.
In order to show off what can be done with Cocoon+JCR, we could try to
clone the Web frontend distributed by Day at http://jsr170tools.day.com
or some part of it.
Thoughts? Questions? Volunteers?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Playing with the JCR RI
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 24/giu/04, alle 19:45, Pier Fumagalli ha scritto:
> I am personally talking to David to try to include JAAS and
> transactions into the JSR-170 spec, as VNU's going to use the spec for
> our own repository and we need few features.
I thought transactions were already there, at least in level 2.
> So, for me, if that means tight integration between Cocoon and JCR, a
> big +1, but for the moment, wait for the final version of the spec :-P
Well no, I don't plan to implement a "tight" integration, just to
experiment a little. Nothing more than traversing a repository, reading
content via a generator or source and maybe writing some content.
Pretty simple stuff.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Playing with the JCR RI
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24 Jun 2004, at 15:37, Ugo Cei wrote:
> Dear Cocooners,
>
> I've just started to take a look at the JCR (a.k.a. JSR-170) Reference
> Implementation from Slide, after having read the latest JSR draft, and
> I feel like exploring the possibilities of its usage inside Cocoon.
>
> First thing I tried to do is an implementation of the
> o.a.c.components.repository.Repository, but then I started to think
> that it didn't make much sense. Our Repository interface is meant to
> provide a virtual repository API on top of different implementations
> (only a WebDAV impl. is available at the moment). But isn't this just
> what JCR is about? Wouldn't it be better if we dropped our own
> Repository and adopted the JCR APIs? We already have a WebDAV and a
> local filesystem implementation available in the RI (plus an
> implementation on top of a "virtual filesystem" which I haven't
> grokked yet). Of course, nothing prevents us from wrapping a JCR repo
> inside an Avalon component, if we want.
>
> Then I thought about doing a Generator that could stream the XML
> representation of a JCR repo provided by the API. Should be a piece of
> cake as there's a method that streams it to a ContentHandler.
>
> In order to show off what can be done with Cocoon+JCR, we could try to
> clone the Web frontend distributed by Day at
> http://jsr170tools.day.com or some part of it.
>
> Thoughts? Questions? Volunteers?
I am personally talking to David to try to include JAAS and
transactions into the JSR-170 spec, as VNU's going to use the spec for
our own repository and we need few features.
So, for me, if that means tight integration between Cocoon and JCR, a
big +1, but for the moment, wait for the final version of the spec :-P
Pier
Re: Playing with the JCR RI
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 24/giu/04, alle 16:37, Ugo Cei ha scritto:
> Then I thought about doing a Generator that could stream the XML
> representation of a JCR repo provided by the API. Should be a piece of
> cake as there's a method that streams it to a ContentHandler.
It *would* be a piece of cake if those methods would be not simply be
implemented as:
throw new RepositoryException("not yet implemented");
:-(
--
Ugo Cei - http://beblogging.com/
Re: Playing with the JCR RI
Posted by Guido Casper <gc...@s-und-n.de>.
Ugo Cei wrote:
> Dear Cocooners,
>
> I've just started to take a look at the JCR (a.k.a. JSR-170) Reference
> Implementation from Slide, after having read the latest JSR draft, and I
> feel like exploring the possibilities of its usage inside Cocoon.
>
> First thing I tried to do is an implementation of the
> o.a.c.components.repository.Repository, but then I started to think that
> it didn't make much sense. Our Repository interface is meant to provide
> a virtual repository API on top of different implementations (only a
> WebDAV impl. is available at the moment). But isn't this just what JCR
> is about? Wouldn't it be better if we dropped our own Repository and
> adopted the JCR APIs?
I thought about that as well (don't reinvent the wheel). However I came
to the conclusion that I currently don't care about JCR as much as I
care about WebDAV :-) The JCR RI for sure is not (yet) as tested and
proven as Slide's WebDAV library and currently I have doubts that JCR is
the best "API for WebDAV" (sigh, time will tell).
In addition I still think there is space for a more "user-oriented" API
that works on a higher abstraction and is geared towards usage within
Cocoon. I'm still planning to work on that (reworking
o.a.c.components.repository.Repository (especially the exception
handling ;-) and having another more "user-level" component operating on
top of it) but I'm currently completely swamped :-(
However I would be looking forward to have some JCR support/sample
within Cocoon.
Guido
> We already have a WebDAV and a local filesystem
> implementation available in the RI (plus an implementation on top of a
> "virtual filesystem" which I haven't grokked yet). Of course, nothing
> prevents us from wrapping a JCR repo inside an Avalon component, if we
> want.
>
> Then I thought about doing a Generator that could stream the XML
> representation of a JCR repo provided by the API. Should be a piece of
> cake as there's a method that streams it to a ContentHandler.
>
> In order to show off what can be done with Cocoon+JCR, we could try to
> clone the Web frontend distributed by Day at http://jsr170tools.day.com
> or some part of it.
>
> Thoughts? Questions? Volunteers?
>
> Ugo
>
Re: Playing with the JCR RI
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
>> Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto:
>>
>>> But I do think it makes sense to have general pipeline components
>>> that are able to read and write into a JCR repository anyway, but
>>> probably a Source would be better in this regard.
>>
>>
>> Hmmm, I thought you were somewhat contrary to writable sources, or
>> did I misunderstood?
>
>
> I'm talking about reading stuff out of a JCR repository.
>
> yes, I'm not keen to writeable sources.
I don't see why there's a problem with writeable sources per se. The
problem IMO comes more from the SourceWritingTransformer, which modifies
the system state (by writing somewhere) as a side effect of the pipeline
processing.
But writeable soures used in the business logic and/or flowscript just
rock, and make it braindead easy to write data to anyone of file, cvs
repo, SQL blob, etc.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Playing with the JCR RI
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto:
>
>> But I do think it makes sense to have general pipeline components that
>> are able to read and write into a JCR repository anyway, but probably
>> a Source would be better in this regard.
>
>
> Hmmm, I thought you were somewhat contrary to writable sources, or did I
> misunderstood?
I'm talking about reading stuff out of a JCR repository.
yes, I'm not keen to writeable sources.
--
Stefano.
Re: Playing with the JCR RI
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto:
> But I do think it makes sense to have general pipeline components that
> are able to read and write into a JCR repository anyway, but probably
> a Source would be better in this regard.
Hmmm, I thought you were somewhat contrary to writable sources, or did
I misunderstood?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Playing with the JCR RI
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Dear Cocooners,
>
> I've just started to take a look at the JCR (a.k.a. JSR-170) Reference
> Implementation from Slide, after having read the latest JSR draft, and I
> feel like exploring the possibilities of its usage inside Cocoon.
>
> First thing I tried to do is an implementation of the
> o.a.c.components.repository.Repository, but then I started to think that
> it didn't make much sense. Our Repository interface is meant to provide
> a virtual repository API on top of different implementations (only a
> WebDAV impl. is available at the moment). But isn't this just what JCR
> is about? Wouldn't it be better if we dropped our own Repository and
> adopted the JCR APIs? We already have a WebDAV and a local filesystem
> implementation available in the RI (plus an implementation on top of a
> "virtual filesystem" which I haven't grokked yet). Of course, nothing
> prevents us from wrapping a JCR repo inside an Avalon component, if we
> want.
>
> Then I thought about doing a Generator that could stream the XML
> representation of a JCR repo provided by the API. Should be a piece of
> cake as there's a method that streams it to a ContentHandler.
>
> In order to show off what can be done with Cocoon+JCR, we could try to
> clone the Web frontend distributed by Day at http://jsr170tools.day.com
> or some part of it.
>
> Thoughts? Questions? Volunteers?
I think that the JCR API is so low-level that a higher level poor-man
dead-easy Repository interface for the repository cocoon block still
makes sense, at least it will avoid you to cut/paste a bunch of similar
functions over and over in your business logic handling things.
For many reasons, JCR tends to generate pretty verbose usage.
But I do think it makes sense to have general pipeline components that
are able to read and write into a JCR repository anyway, but probably a
Source would be better in this regard.
As for duplicating the JSR170tools, I think it would just rock, but
don't expect anymore effort than writing a few lines of email, sorry.
--
Stefano.