Re: Remoting and future of JCR-RMI

2009-10-20 Thread Lennard Fuller
I agree with Felix. JCR-RMI definitely has it drawbacks (perf is HORRIBLE). However, it is easy to use and until the dav based communications is at least as easy, JCR-RMI should not be dropped. - Original Message - From: "Felix Meschberger" To: dev@jackrabbit.apache.org Sent: Tuesday

Re: Remoting and future of JCR-RMI

2009-10-20 Thread Felix Meschberger
Hi, At first sight, I would say nay ;-) Because, the RMI stuff is easy and simple to use and just works. Period. Now, on the other hand the RMI stuff has some serious drawbacks: * Performance (we never really built caching into it, which would be hard anyways) * Secondary communications

Re: Generic JCR repository factory

2009-10-20 Thread Felix Meschberger
Hi, Jukka Zitting schrieb: > Hi, > > The current jackrabbit-jcr-client component contains a > RepositoryFactory implementation that can choose between different > Repository implementations based on given parameters. Currently it > depends on the SPI implementations encoded in the > Jcr2spiReposi

Re: Merging jcr2spi and spi2jcr to spi-commons

2009-10-20 Thread Jukka Zitting
Hi, On Tue, Oct 20, 2009 at 5:40 PM, Angela Schreiber wrote: > i wouldn't be in favor of such a move. How about an alternative of merging just jcr2spi to spi-commons and leaving spi2jcr as a separate component like spi2dav? This would support the long term goal of getting rid of the separate tr

Re: Merging jcr2spi and spi2jcr to spi-commons

2009-10-20 Thread Angela Schreiber
hi jukka i think this would be wrong from a conceptual point of view. - jcr2spi is a JCR implementation - spi2jcr is an example implementation of the SPI that we mainly used for developing jcr2spi as it was straight forward to implement having a jackrabbit-core as jcr-part in spi2jcr. - spi-

Re: Remoting and future of JCR-RMI

2009-10-20 Thread Jukka Zitting
Hi, On Tue, Oct 20, 2009 at 4:42 PM, KÖLL Claus wrote: > If we drop the RMI layer how would you connect to the Repository ? Using the spi2dav component together with jcr2spi. This gives you JCR API access to a remote repository just like the JCR-RMI layer does. At Day we've been increasingly us

Generic JCR repository factory

2009-10-20 Thread Jukka Zitting
Hi, The current jackrabbit-jcr-client component contains a RepositoryFactory implementation that can choose between different Repository implementations based on given parameters. Currently it depends on the SPI implementations encoded in the Jcr2spiRepositoryFactory class in jackrabbit-jcr2spi an

AW: Remoting and future of JCR-RMI

2009-10-20 Thread KÖLL Claus
Hi Jukka, We are using very often the WebDAV Layer in our Applications and bind it with the RMI Layer to a central Jackrabbit Repository. If we drop the RMI layer how would you connect to the Repository ? greets claus

Merging jcr2spi and spi2jcr to spi-commons

2009-10-20 Thread Jukka Zitting
Hi, I was looking at ways to simplify the dependency set for SPI implementations, and started thinking of why we really do need to have jcr2spi and spi2jcr in separate components. They're obviously architecturally different, but they share essentially the same dependencies and will both need to be

Remoting and future of JCR-RMI

2009-10-20 Thread Jukka Zitting
Hi, So far I've just assumed that, since JCR 2.0 is backwards compatible with JCR 1.0, we'll have no trouble using the JCR-RMI layer on top of a JCR 2.0 repository even if the layer itself is still built against JCR 1.0. Unfortunately, now that I looked at this in more detail, my assumption turns

[jira] Commented: (JCR-2357) Duplicate entries in the index

2009-10-20 Thread Benjamin Papez (JIRA)
[ https://issues.apache.org/jira/browse/JCR-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767750#action_12767750 ] Benjamin Papez commented on JCR-2357: - So a solution for this problem would either be tha