Fwd: Adding WebDAV to Jackrabbit

[Oliver Zeigermann <ol...@gmail.com>]

Ooops, that should have gone to the jackrabbit list..

Oliver


---------- Forwarded message ----------
From: Oliver Zeigermann <ol...@gmail.com>
Date: Mon, 1 Nov 2004 00:03:43 +0100
Subject: Re: Adding WebDAV to Jackrabbit
To: david.nuescheler@day.com


Hi David, thanks for the quick answer!

Comments folllow inline.



On Sun, 31 Oct 2004 23:48:50 +0100, David Nuescheler
<da...@gmail.com> wrote:
> in jackrabbit i think we could start with a very straight
> forward acl based authorization model and in my mind
> user / group information should also be reflected in
> the repository. during the specification we thought
> of a mixin nodetype called "accessControllable" which
> would lead us to a very simple yet powerful
> implementation to get started.

Could you provide details please? Are negative and/or inheritable
rights planned? If so how would the algorithm to determine access
rights look like?

> > Can I make use of the transaction manager? Why haven
> > the JTA interfaces not been used?
> yes, you can (should) use a transaction manager.
> hmmm... are you looking beyond the XASession.getXAResource() ?

How would a request using the TM look like? The classes in
org.apache.jackrabbit.core.state.tx confuse me a bit...

What is XASession.getXAResource() intended for? When talking about
transactions I was wondering why there is a new interface for
transaction while JTA defines one. Additionally, I do not quite
understand if this transction is what the user should use (why prepare
then?) or if it is something used by the TM (still why prepare then?).
 Are these distributed transactions? If so which are the parts of the
distributed transactions? What is TransactionalStore for? What is
PlaybackListener for?

Thanks for helping :)

Oliver

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[Oliver Zeigermann <ol...@gmail.com>]

On Mon, 1 Nov 2004 15:01:50 +0100, David Nuescheler
<da...@gmail.com> wrote:
> > As explained above this is the way it works. Each store implements
> > XAResources and is enlisted in the global transaction.
> > > to me the slide transactions look like they are not really
> > > jta, but just somehow use some jta interfaces in a
> > > questionable way. but again my apologies, i might be
> > > completely wrong here.
> > No need for apologies, but it seems to me you are wrong here...
> to me, the way how the repository chooses to interact
> with its stores, does not have to be exposed to the
> repository user (developer). i understand that for

It is not.

> people that develop stores this is very interesting.
> however i think for the vast majority of content
> repository application developer should not develop
> stores, much like the j2ee devs should not develop
> for example jms provider components.

They do not need to.

> again, thank you very much for the
> interesting discussions, i think this certainly
> helps me to learn a lot about slide.

Thanks as well!

Oliver

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[David Nuescheler <da...@gmail.com>]

> That's Slide's special feature. You can map all kinds of stores to
> resource paths. You can even do this with different aspects of a
> resource. E.g. you can store all content of resources in a folder to
> the file system and all the meta data into an RDBMS. All other paths
> could well be mapped to be help in memory only (just as an example).
> Now it should be obvious that all stores need to participate in the
> global tx as a resource might affect all stores. They  do so by
> implemention XAResource.
hmmm... while i appreciate a feature of virtualizing multiple
datasources in a single tree,
http://www.day.com/content/en/product/productline/contentbus.html
i would still question an architecture where a repository has
to ship its own tm. if the slide tm is a good general purpose
tm, then i would suggest that you talk to the geronimo
guys since they probably should be interested, or am i 
way off here?

> WebDAV and the client library and WebDAV JCA implementation for Slide
> is like JDBC and SQL for RDBMS.
> Using the client Side JCA implementation you can have both a local and
> a distributed transaction.
a comparison that involves proprietary and standardized apis, a 
protocol and a querylanguage makes my head spin ;)

> As a side note if anyone asks I always recommend not to 
> use Slide's native API, but to go the "SQL and JDBC" way. 
> This even makes your implementaion independent of Slide 
> and you could *theoretically*  - just like with SQL and 
> JDBC ;) - exchange Slide with another WebDAV server - 
> like SVN for example - which people seem to experiment 
> with already.
i think to use webdav as a protocol to remote
a "content repository api" is a very good idea, that we already 
discussed with remy (& others) about 2 years ago.
[ also see a couple of post earlier on this list ]
i think we additionally benefit from the fact that we do not 
remote a proprietary api but one that is specified through a jsr,
which means that the application developer is not just 
independant from the server implementation but
also from the transport protocol between the client and 
the server (just like with jdbc, to put that in the correct perspective).

or to unspin my head, we can maybe agree to to something like that:
jdbc is for rdbms, what jcr is for content repositories.

> As explained above this is the way it works. Each store implements
> XAResources and is enlisted in the global transaction.
> > to me the slide transactions look like they are not really
> > jta, but just somehow use some jta interfaces in a
> > questionable way. but again my apologies, i might be
> > completely wrong here.
> No need for apologies, but it seems to me you are wrong here...
to me, the way how the repository chooses to interact
with its stores, does not have to be exposed to the 
repository user (developer). i understand that for 
people that develop stores this is very interesting.
however i think for the vast majority of content 
repository application developer should not develop 
stores, much like the j2ee devs should not develop
for example jms provider components.

again, thank you very much for the 
interesting discussions, i think this certainly
helps me to learn a lot about slide.

regards,
david

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[Oliver Zeigermann <ol...@gmail.com>]

On Mon, 1 Nov 2004 12:10:14 +0100, David Nuescheler
<da...@gmail.com> wrote:
> > I do not know
> > what historical even was causing this, but it at least has the
> > benefit that you do not need a full J2EE server. The drawback
> > was/is that it is pretty hard to let Slide participate in a distributed
> > transaction of a J2EE server. 
> hmmm.... i see... but wouldn't it be pointless to implement
> xa, if you cannot participate in a distributed transaction?
> to me that is the idea of xa, global transactions?

That's Slide's special feature. You can map all kinds of stores to
resource paths. You can even do this with different aspects of a
resource. E.g. you can store all content of resources in a folder to
the file system and all the meta data into an RDBMS. All other paths
could well be mapped to be help in memory only (just as an example).
Now it should be obvious that all stores need to participate in the
global tx as a resource might affect all stores. They  do so by
implemention XAResource.
 
> > As the server side Slide API is suboptimal (hihi)
> > to program to and it is hard to change the transaction
> > manager the solution was to create a client side JCA
> > connector talking WebDAV to Slide that can participate
> > in a JTA transaction of your J2EE server.
> > This way you have a simply API (client side) to program
> > to as well.
> hmm... i would argue that it certainly makes a lot of sense
> to have a repository implement jca, which certainly are
> the plans ( model 2 on http://incubator.apache.org/jackrabbit/arch/deploy.html )
> this would then also expose a LocalTransaction, which in
> my mind is effectively what you get from implementing
> your proprietary (local) tm.
> i do not entirely see why webdav needs to be in the picture
> for that.

WebDAV and the client library and WebDAV JCA implementation for Slide
is like JDBC and SQL for RDBMS.

Using the client Side JCA implementation you can have both a local and
a distributed transaction.

As a side note if anyone asks I always recommend not to use Slide's
native API, but to go the "SQL and JDBC" way. This even makes your
implementaion independent of Slide and you could *theoretically*  -
just like with SQL and JDBC ;) - exchange Slide with another WebDAV
server - like SVN for example - which people seem to experiment with
already.

> > Having said that, maybe it gets a bit easier to understand
> > where I am coming from. Maybe it even is easier to explain
> > what are the differences in Jackrabbit.
> i think that clears up things for me... my question would
> only be,
> "why would you ever do that?"
> ... and if you for whatever reason decide to
> implement a tm ...
> "why wouldn't you do it really according to the jta spec,
> where XAResources are enlisted with the xa tx?"

As explained above this is the way it works. Each store implements
XAResources and is enlisted in the global transaction.

> to me the slide transactions look like they are not really
> jta, but just somehow use some jta interfaces in a
> questionable way. but again my apologies, i might be
> completely wrong here.

No need for apologies, but it seems to me you are wrong here...

Oliver

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[David Nuescheler <da...@gmail.com>]

> Actually Slide has its own JTA implementation! 
ouch ;)

> I do not know 
> what historical even was causing this, but it at least has the 
> benefit that you do not need a full J2EE server. The drawback 
> was/is that it is pretty hard to let Slide participate in a distributed 
> transaction of a J2EE server. 
hmmm.... i see... but wouldn't it be pointless to implement 
xa, if you cannot participate in a distributed transaction?
to me that is the idea of xa, global transactions?

> As the server side Slide API is suboptimal (hihi) 
> to program to and it is hard to change the transaction 
> manager the solution was to create a client side JCA 
> connector talking WebDAV to Slide that can participate 
> in a JTA transaction of your J2EE server.
> This way you have a simply API (client side) to program 
> to as well.
hmm... i would argue that it certainly makes a lot of sense
to have a repository implement jca, which certainly are
the plans ( model 2 on http://incubator.apache.org/jackrabbit/arch/deploy.html )
this would then also expose a LocalTransaction, which in
my mind is effectively what you get from implementing 
your proprietary (local) tm.
i do not entirely see why webdav needs to be in the picture
for that.

> Having said that, maybe it gets a bit easier to understand 
> where I am coming from. Maybe it even is easier to explain 
> what are the differences in Jackrabbit.
i think that clears up things for me... my question would
only be, 
"why would you ever do that?"
... and if you for whatever reason decide to 
implement a tm ...
"why wouldn't you do it really according to the jta spec, 
where XAResources are enlisted with the xa tx?"
to me the slide transactions look like they are not really
jta, but just somehow use some jta interfaces in a 
questionable way. but again my apologies, i might be
completely wrong here.

regards,
david

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[Oliver Zeigermann <ol...@gmail.com>]

Yes, anyone lives in his/her own world. Me as well :)  

Actually Slide has its own JTA implementation! I do not know what
historical even was causing this, but it at least has the benefit that
you do not need a full J2EE server. The drawback was/is that it is
pretty hard to let Slide participate in a distributed transaction of a
J2EE server. As the server side Slide API is suboptimal (hihi) to
program to and it is hard to change the transaction manager the
solution was to create a client side JCA connector talking WebDAV to
Slide that can participate in a JTA transaction of your J2EE server.
This way you have a simply API (client side) to program to as well.

Having said that, maybe it gets a bit easier to understand where I am
coming from. Maybe it even is easier to explain what are the
differences in Jackrabbit.

Oliver

On Mon, 1 Nov 2004 11:26:16 +0100, David Nuescheler
<da...@gmail.com> wrote:
> hi oli,
> 
> just one more thing, now that i was looking at the slide transactions:
> why did you guys implement your own org.apache.slide.transaction.SlideXid, and
> all the other stuff that in my mind belongs into the transaction manager?
> http://jakarta.apache.org/slide/javadoc/org/apache/slide/transaction/SlideXid.html
> 
> did you guys implement your own transaction monitor?
> 
> [experiencing my confusion when looking at the slide tx, i can
> understand your confusion looking at the jackrabbit tx. LOL]
> 
> regards,
> david
>

Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]

[David Nuescheler <da...@gmail.com>]

hi oli,

just one more thing, now that i was looking at the slide transactions:
why did you guys implement your own org.apache.slide.transaction.SlideXid, and 
all the other stuff that in my mind belongs into the transaction manager?
http://jakarta.apache.org/slide/javadoc/org/apache/slide/transaction/SlideXid.html

did you guys implement your own transaction monitor?

[experiencing my confusion when looking at the slide tx, i can 
understand your confusion looking at the jackrabbit tx. LOL]


regards,
david

Re: Adding WebDAV to Jackrabbit

[Oliver Zeigermann <ol...@gmail.com>]

On Mon, 01 Nov 2004 11:48:31 +0100, Dominique Pfister
<do...@day.com> wrote:
> Hi Oliver,
> 
> Oliver Zeigermann wrote:
> > Thanks, I now think understand the XASession.getXAResource() thing, it
> > is for usage with the app server transaction manager, right?
> > 
> Exactly, it is the one that should be returned in the
> javax.resource.spi.ManagedConnection.getXAResource method.

Got that now :)
 
> > Concerning non-JTA interfaces there is this inferface looking weired
> > http://incubator.apache.org/jackrabbit/apidocs/org/apache/jackrabbit/core/state/tx/Transaction.html
> > 
> Yes, I should have chosen another name, since this is already taken by
> the JTA spec and therefore easily causes confusion. It should rather be
> called TransactionContext, because it rather acts as part of a global
> transaction. Right now, it also serves as controller for a local
> transaction, which was probably not a good design decision.

So, this is nothing I should care about, right? It is just something
that gets called by the Jackrabbit's guts?

Thanks,

Oliver

Re: Adding WebDAV to Jackrabbit

[Dominique Pfister <do...@day.com>]

Hi Oliver,

Oliver Zeigermann wrote:
> Thanks, I now think understand the XASession.getXAResource() thing, it
> is for usage with the app server transaction manager, right?
> 
Exactly, it is the one that should be returned in the 
javax.resource.spi.ManagedConnection.getXAResource method.

> Concerning non-JTA interfaces there is this inferface looking weired 
> http://incubator.apache.org/jackrabbit/apidocs/org/apache/jackrabbit/core/state/tx/Transaction.html
> 
Yes, I should have chosen another name, since this is already taken by 
the JTA spec and therefore easily causes confusion. It should rather be 
called TransactionContext, because it rather acts as part of a global 
transaction. Right now, it also serves as controller for a local 
transaction, which was probably not a good design decision.

> If a UserTransaction should be used does Jackrabbit require a full
> J2EE implementation then?

Yes, it does. Right now, an application server will always take the 
extra steps of starting a global transaction even when none is required. 
But as stated in the previous post, the "Transaction" should be 
separated into a TransactionContext (when used in a global transaction) 
and a LocalTransaction (when the application server determines that a 
global transaction is unnecessary or when a client wants to start its 
own, local transaction).

Cheers
Dominique

Re: Adding WebDAV to Jackrabbit

[Oliver Zeigermann <ol...@gmail.com>]

> > What is XASession.getXAResource() intended for? When
> > talking about transactions I was wondering why there is
> > a new interface for transaction while JTA defines one. 
> is there?? it clearly was out intention to just use JTA. if we
> didn't it must have been clearly by accident. ;)
> well, the getXAResource() returns a javax.transaction.xa.XAResource
> is to enlist the resource in a xa transaction with the transaction
> monitor, which is something that has been successfully tested
> through implementing a resource adapter with the transaction
> managers of all the major j2ee appservers even for container
> managed transactions. i think i do not your question.

Thanks, I now think understand the XASession.getXAResource() thing, it
is for usage with the app server transaction manager, right?

Concerning non-JTA interfaces there is this inferface looking weired 
http://incubator.apache.org/jackrabbit/apidocs/org/apache/jackrabbit/core/state/tx/Transaction.html

> > Additionally, I do not quite understand if this transction is
> > what the user should use (why prepare then?) or if it is
> > something used by the TM (still why prepare then?).
> > Are these distributed transactions? If so which are the
> > parts of the distributed transactions? What is
> > TransactionalStore for? What is PlaybackListener for?
> well, of course the user should interact with the transactional
> aspects of the repository through UserTransaction if anything,
> since the interactions with transactions can also be left up
> to the container... but since i am way out of my league
> here, maybe dominique, who i think did an excellent job
> at implementing the tx for jackrabbit, can answer your
> questions in a much conciser fashion than i ever could ;)

If a UserTransaction should be used does Jackrabbit require a full
J2EE implementation then?

Would be great if Dominique could explain bit more! Is he a commiter as well?

All this information would be important for me to interface the WebDAV
API to Jackrabbit and maybe even have a more generic implementation
against the JCR. I guess this will be good for the Jackrabbit, right?
Or do you people plan a WebDAV implementation of your own?

Oliver

Re: Adding WebDAV to Jackrabbit

[David Nuescheler <da...@gmail.com>]

hi oli,

how paul put it earlier on this mailing list:
"I could well be teaching grandma to suck eggs here, 
so for apologies for that ..."

> What is XASession.getXAResource() intended for? When 
> talking about transactions I was wondering why there is 
> a new interface for transaction while JTA defines one. 
is there?? it clearly was out intention to just use JTA. if we
didn't it must have been clearly by accident. ;)
well, the getXAResource() returns a javax.transaction.xa.XAResource 
is to enlist the resource in a xa transaction with the transaction 
monitor, which is something that has been successfully tested 
through implementing a resource adapter with the transaction 
managers of all the major j2ee appservers even for container 
managed transactions. i think i do not your question. 
 
> Additionally, I do not quite understand if this transction is 
> what the user should use (why prepare then?) or if it is 
> something used by the TM (still why prepare then?).
> Are these distributed transactions? If so which are the 
> parts of the distributed transactions? What is 
> TransactionalStore for? What is PlaybackListener for?
well, of course the user should interact with the transactional
aspects of the repository through UserTransaction if anything,
since the interactions with transactions can also be left up 
to the container... but since i am way out of my league
here, maybe dominique, who i think did an excellent job 
at implementing the tx for jackrabbit, can answer your 
questions in a much conciser fashion than i ever could ;)

regards,
david