Upgrade use of Slide to Jackrabbit

[GoogleCodeExporter]

The Slide project has been retired:
http://jakarta.apache.org/slide/

We should upgrade to Jackrabbit WebDAV Library 1.4:
http://jackrabbit.apache.org/jackrabbit-webdav-library.html
http://repo1.maven.org/maven2/org/apache/jackrabbit/jackrabbit-webdav/1.4/

Original issue reported on code.google.com by markhob...@gmail.com on 3 Sep 2008 at 4:07

[GoogleCodeExporter]

we're too young now

Original comment by robipo...@gmail.com on 9 Sep 2008 at 1:21

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

to gsoc

Original comment by robipo...@gmail.com on 14 Mar 2010 at 11:40

• Added labels: Milestone-GSoC

[GoogleCodeExporter]

Started on 
http://code.google.com/p/caldav4j/source/browse#svn%2Fbranches%2Fcaldav4j-jackra
bbit

Original comment by robipo...@gmail.com on 17 Feb 2011 at 11:16

• Changed state: Started

[GoogleCodeExporter]

Being a Jackrabbit committer, let me point out that the jackrabbit webdav 
library is more or less tailored for the placing webdav on top of JCR (which is 
what Jackrabbit is all about, webdav is just one remote access protocol for 
it). Hence it might not be optimal for general purpose webdav implementations - 
except you really leverage the JCR below.

Other than that I heard that milton is a good webdav java library, easy to 
implement: http://milton.ettrema.com/index.html

HTH,
Alex

Original comment by alexande...@googlemail.com on 18 Feb 2011 at 11:27

[GoogleCodeExporter]

Hi Alex,

glad to ear from you: can you please go indepth with your comment?

 - will webdav support be stripped off by jcrbt?
 - is jcrbt+webdav team too small to sustain the develop?
 - are there webdav features which won't be implemented due to conflicts between webdav and jcrbt?

AFAISee Milton seems to be a server implementation, while caldav4j is mostly a 
client one

Thanks again for your time + Peace,
R.

Original comment by robipo...@gmail.com on 28 Feb 2011 at 12:26

[GoogleCodeExporter]

Job half done at
http://code.google.com/p/caldav4j/source/browse#svn%2Fbranches%2Fcaldav4j-jackra
bbit

anybody interested can review the code!

Peace,
R.

Original comment by robipo...@gmail.com on 4 Mar 2011 at 10:23

[GoogleCodeExporter]

Hi everybody,

what is the current state of caldav4j-jackrabbit? Comparing to ./trunk, there 
is still a lot missing. It there any rough schedule when this might be 
implemented? For one of my projects I'm interested to use this lib for syncing 
Android with ownCloud. 
Thanks 

Jonas

Original comment by j.cim...@googlemail.com on 6 Oct 2012 at 10:46

[GoogleCodeExporter]

Actually I have no time to finish the implementation.

The get/put methods.should be fine.

The parsing of the report need some work.

The acl stuff is missing even in jackrabbit - but this may be changed.

If you want to contribute let me know and I can grant you svn access.

Peace, Rob
Il giorno 06/ott/2012 12:46, <caldav4j@googlecode.com> ha scritto:

Original comment by robipo...@gmail.com on 6 Oct 2012 at 11:22

[TheAntimist]

Anybody, know the current status of this issue, along with that what about merging the caldav4j-jackrabbit branch?

[ioggstream]

Hi @TheAntimist,

I'd really like to drop slide, but as of my last findings https://wiki.apache.org/jackrabbit/WebDAV slide was the only webdav client library supporting ACLs.

Moving to jackrabbit means either dropping or implement al caldav4j ACL support.

If you want to try the merge I'm willing to help.

[TheAntimist]

I just checked, and according to https://jackrabbit.apache.org/jcr/components/jackrabbit-webdav-library.html RFC 3744 (Access Control Protocol) has been implemented. Not sure, till what extent, though. Here's the Javadoc on the package though: http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/webdav/security/package-summary.html

I might try to to merge, if jackrabbit implements ACL's completely, will ask your help when necessary. Thanks for letting me know.

EDIT: Taking a glance at the org.apache.jackrabbit.webdav.security code, I mostly see all the priveleges and the rest being implemented.

[ioggstream]

@TheAntimist that's great to know.

Just fork the project and start running the tests against a caldav-compliant server. Once the tests work let me know and I'll do my best to support you.

Thx++, R.

[TheAntimist]

Alright, it's just that, I haven't gotten used to the CalDAV4j codebase yet, would like to work on that first, and then work on the jackrabbit-webddav integration.

Also, would there be a more direct mode of communication to you in case, I want to contact you? Or does this work for you?

[ioggstream]

@TheAntimist here or on irc.freenode.net#caldav4j. You can subscribe to caldav4j google group too.

[TheAntimist]

@ioggstream Alright, thanks I'll get back to you soon.

[TheAntimist]

@ioggstream Got a bit of trouble compiling using maven 3, the repositories, you've placed in the pom.xml seem to point to addresses which seem to not exist, specifically this one: http://m2.modularity.net.au/releases

Any other repositories, I could add, for the dependencies?

[ioggstream]

@TheAntimist It seems that ehcache 2.5.2 can't be downloaded anymore.

You can try:

• http://repo1.maven.org/maven2/
• ehcache 2.10.2

Ehcache has changed its interface, so I found this compilation issue

[ERROR] /home/rpolli/workspace-luna/caldav4j/src/test/java/org/osaf/caldav4j/CalDAVCalendarCollectionWithCacheTest.java:[64,9] error: CalDAVCalendarCollectionWithCacheTest.TestingCacheEventListener is not abstract and does not override abstract method notifyRemoveAll(Ehcache) in CacheEventListener

It should be something easy to manager though...

[TheAntimist]

@ioggstream Got the ehcache 2.10.2 and made some dummy methods to fit the CacheEventListener interface, which now makes all the code compile with the following

public void notifyElementEvicted(Ehcache cache, Element element) {
}
public void notifyRemoveAll(Ehcache cache) {
}
public Object clone(){
    return (Object) (new TestingCacheEventListener());
}

But I still get the following error in lots of files during the running of the Tests in the surefire-reports, for files such as org.osaf.caldav4j.util.GenerateQueryTest in the constructor, org.osaf.caldav4j.util.ICalendarUtilTest at testUpdateMasterComponent

java.lang.NoClassDefFoundError: Could not initialize class net.fortuna.ical4j.util.CompatibilityHints

Still, not sure what's going wrong. :(

EDIT: I think ical4j uses a deprecated library for HashMap in version 1.0.3 i.e edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap. Perhaps update it something higher

[ioggstream]

Can you please link your caldav4j fork so I can test the code?

Thx++, R.

[TheAntimist]

@ioggstream Here's the link: https://github.com/TheAntimist/caldav4j

Also, just a note that the test errors could be due to the Artifact corruption, which I downloaded. Like every time I try updating, I get Non-Parseable POM for ical4j-1.0.3 and even on 1.0.5

Thanks A

[ioggstream]

@TheAntimist Testing your build with davical I got issues only on ACL and FreeBusy... Not bad it seems.

java -version
openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)

# mvn clean package
Failed tests:   testAddRemoveCalendarResource(org.osaf.caldav4j.google.methods.GooglePutGetTest): Response status expected:<201> but was:<404>
  createNewDocument(org.osaf.caldav4j.model.request.FreeBusyQueryTest): createNewDocument expected:<... encoding="UTF-16"?>[
  testGetCalendarByPath(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest)
  testGetEventResources(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): expected:<0> but was:<1>

Tests in error: 
  getFolderAces(org.osaf.caldav4j.ACLCalDAVCollectionTest): Error gettinh ACLs. PROPFIND status is: -1
  getResourceAces(org.osaf.caldav4j.ACLCalDAVCollectionTest): Error gettinh ACLs. PROPFIND status is: -1
  testGetOptions(org.osaf.caldav4j.CalDAVCollectionAceTest)

Tests run: 65, Failures: 4, Errors: 3, Skipped: 21

[TheAntimist]

@ioggstream Looks like it's a problem on my side, because I still get the ical4j NoClassDefFoundError exception. I guess, it's an artifact issue after all. Sigh. I'll check it tomorrow, too tired for today.

[TheAntimist]

@ioggstream Phew got it to work. I found my problem was with a dependency of ical4j, which had a corrupt artifact due to as stated earlier: http://m2.modularity.net.au/releases

Here's the errors, I get pretty much similar to yours, plus some because I didn't realize that hub.chandlerproject.org doesn't exist now. Plus, your Free Busy tests. Though, since I notice you've used davical instead of chandlerproject, which seems to be defunct. I don't have the other errors. Here's my errors:

Results :

Failed tests:   createNewDocument(org.osaf.caldav4j.model.request.FreeBusyQueryTest): createNewDocument expected:<... encoding="UTF-16"?>[
  testAddRemoveCalendarResource(org.osaf.caldav4j.google.methods.GooglePutGetTest): Response status expected:<201> but was:<404>

Tests in error: 
  testGetOptions(org.osaf.caldav4j.CalDAVCollectionAceTest): hub.chandlerproject.org
  testGetOptions(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testGetCalendar(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testGetCalendarByPath(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testGetEventResources(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testAddNewRemove(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testUpdateEvent(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  testMultigetCalendar(org.osaf.caldav4j.CalDAVCalendarCollectionTest): hub.chandlerproject.org
  getFolderAces(org.osaf.caldav4j.ACLCalDAVCollectionTest): hub.chandlerproject.org
  getResourceAces(org.osaf.caldav4j.ACLCalDAVCollectionTest): hub.chandlerproject.org
  testCacheGetsHit(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testGetCalendar(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testGetCalendarByPath(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testGetEventResources(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testAddNewRemove(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testUpdateEvent(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): hub.chandlerproject.org
  testFun(org.osaf.caldav4j.FunTest): hub.chandlerproject.org

So, what should I do next? Correct these errors? or something else?

[ioggstream]

1- configure the GooglePutGetTest to use a google calendar account

  testAddRemoveCalendarResource(org.osaf.caldav4j.google.methods.GooglePutGetTest):
Response status expected:<201> but was:<404>

2- for the others, you should point to a caldav server (use whatever you have instead of chandler) and let me know the results.

[TheAntimist]

@ioggstream Just an update it seems that Google has changed their Location URL for CalDAV, because they switched to OAuth, for authentication. Read more here on this issue: https://blog.mozilla.org/calendar/2013/09/google-is-changing-the-location-url-of-their-caldav-calendars/ and for using them now, you need to use this guide from google, for using their developer API's: https://developers.google.com/google-apps/calendar/caldav/v2/guide

Thus, that test won't work, if I just put in my credentials, there.

Other than that, still working on the rest.

[ioggstream]

2016-05-01 14:13 GMT+02:00 Ankush Mishra notifications@github.com:

Google has changed their Location URL for CalDAV,

For now we can just ignore Google stuff unless you need it, OK?

PS: Which caldav server are you using?

[TheAntimist]

@ioggstream Finally, got my CalDAV server working. Used DAViCal, since it seemed to be not too complicated but good enough to work against, plus uses SabreDAV. Now, here's my errors:

Failed tests:   createNewDocument(org.osaf.caldav4j.model.request.FreeBusyQueryTest): createNewDocument expected:<... encoding="UTF-16"?>[
  testGetCalendarByPath(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest)
  testGetEventResources(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest): expected:<0> but was:<1>
  testCacheGetsHit(org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest)
  testAddRemoveCalendarResource(org.osaf.caldav4j.google.methods.GooglePutGetTest): Response status expected:<201> but was:<404>

Tests in error: 
   testGetOptions(org.osaf.caldav4j.CalDAVCollectionAceTest)

Tests run: 65, Failures: 5, Errors: 1, Skipped: 21

Of which, one of them is the Google error of course. But, it seems to be the same as yours. Any suggestions on why? Perhaps the update of ehcache is causing the CalDAVCalendarCollectionWithCacheTest trouble, not sure about the rest.

[ioggstream]

Hi, I refactored your code a bit, see https://github.com/caldav4j/caldav4j/commits/fix-pom-ehcache-ical4j

1- squashed all pom.xml modification, used ${user.home} variable, ... 2- added a caldav4jUri in CaldavCredential

Now you should be able to point to a server without editing files:

   mvn clean package -Dcaldav4jUri=https://user:password@host/caldav.php/user/

You can @Ignore google tests for now. To troubleshoot the others you need to enable http.wire and debug log. Then follow the communication trace between the client and the server.

[TheAntimist]

A bit of a late reply, worked on understanding the code for a bit, and a bit busy here and there. Anyway, I just updated the my fork, with the fix to CalDAVCollectionAceTest, also an update for CalDAVCalendarCollectionBase.allows(), which used a regex which didn't work. Found here: 689fffb5ec4c18ee26f6a2bbe7aa569c5d7ab7e5

Just a note: My fork, enables Log4j for logging from Sl4j. Remove that if you like.

I'll see if I can get the rest of the tests working. Also, just one thing, I was wondering, for a client which can emulate most of Thunderbird's Lightning plugin which would be better to use CalDAV4j or ical4j-connector. Hoping for an unbiased answer on this one. Since, I am not entirely sure, which library to go with.

EDIT: Further note, Fixed FreeBusyQueryTest.

EDIT 2: Got a doubt on org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest.testGetEventResources. We get a Assertion Error in two places one is on:

        for (Calendar calendar : l) {
        ComponentList vevents = calendar.getComponents().getComponents(
                Component.VEVENT);
        VEvent ve = (VEvent) vevents.get(0);
        String uid = ICalendarUtils.getUIDValue(ve);
        int correctNumberOfEvents = -1;
        if (ICS_DAILY_NY_5PM_UID.equals(uid)) {
            // one for each day
            correctNumberOfEvents = 1;
        } else if (ICS_ALL_DAY_JAN1_UID.equals(uid)) {
            correctNumberOfEvents = 1;
        } else if (ICS_NORMAL_PACIFIC_1PM_UID.equals(uid)) {
            correctNumberOfEvents = 1;
        } else if (ICS_FLOATING_JAN2_7PM_UID.equals(uid)) {
            correctNumberOfEvents = 0;
        } else {
            fail(uid
                    + " is not the uid of any event that should have been returned");
        }

        assertEquals(correctNumberOfEvents, vevents.size());
    }

Specifically, in line:

        } else if (ICS_FLOATING_JAN2_7PM_UID.equals(uid)) {
            correctNumberOfEvents = 0;

Since the event, ICS_FLOATING_JAN2_7PM, uses a Floating timezone, this, depending on the timezone sets correctNumberOfEvents to 0, and the l.size() to 4. Thus, causing the assertion to fail at:

 231:           assertEquals(correctNumberOfEvents, vevents.size());

comes as (0, 1). And at line:

    // 3 calendars - one for each resource (not including expanded
    // recurrences)
 236:    assertEquals(3, l.size());

as stated earlier, l.size() comes up as 4, thus causing this to fail as well. What do you propose for this specific Test?

Seems a bit of logical issue in any case.

EDIT: Fixed everything else except, org.osaf.caldav4j.CalDAVCalendarCollectionWithCacheTest.testGetEventResources.

[ioggstream]

Hi @TheAntimist

I looked at your commits and they seem ok: I'm going to merge some of them.

• slf4j: I think it's time to move;
• FB query: ok, but probably depends on the server response adding a newline after ;

For different errors (eg. the floating tz one) please open new tickets!

About ical4j-connector and caldav4j: I don't know very much ical4j-connector, but ical4j is a good project. We use caldav4j for the ability to create complex queries using sql-like syntax and the built-in cache support. All this moves code outside from your application.

Let me know if you have further questions and thanks for the good work!

[TheAntimist]

@ioggstream Thanks for the response.

With respect to FB query, we could have a function which preprocesses spaces and so on, which sort of normalizes both. But yes, it is entirely server dependent. For Floating TZ one, I'll probably open a new ticket, soon.

Also, thanks for the review on ical4j-connector.

Addressing the Migration, issue finally, having checked some of the code on the caldav4j-jackrabbit branch, till what extent are the methods migrated? They seem ready on that side. Anything specific, do I have to work on, or just work on an extension of that branch in my fork?

[ioggstream]

@TheAntimist I merged your changes into https://github.com/caldav4j/caldav4j/commit/a7c64c71819434f75267f320c99c73413127a86a

About jackrabbit:

• the basic methods (PUT, GET, DELETE) should work;
• the xml search related methods needs to be checked;
• ACL methods should be rewritten entirely as the class hierarchy is probably very different from the slide one.

[TheAntimist]

@ioggstream Alright, thanks. I'll see what I can do, though I expect the migration may be completed partially depending, on my requirement. But anyway, I'll give it a try.

One, last thing, can I refer to the caldav4j-jackrabbit branch here: https://github.com/caldav4j/caldav4j/tree/caldav4j-jackrabbit during migration?

[ioggstream]

@TheAntimist:

• Every good work of software starts by scratching a developer's personal itch (E.S. Raymond, The Cathedral and the Bazaar);
• the jackrabbit branch should contain working PUT/GET/DELETE stuff: I suggest trying to merge your changes there as a starting point;

[TheAntimist]

@ioggstream Alright, thanks. I'll see what I can come up with. :smile:

[TheAntimist]

@ioggstream I have question with respect to MkCalendarMethod. In the caldav-jackrabbit branch MkCalendarMethod, line 61, in function addRequestHeaders, there's a comment which states:

   //first add headers generate RequestEntity or 
   //addContentLengthRequestHeader() will mess up things > result "400 Bad Request"
   //can not override generateRequestBody(), because called to often

But upon running, all the tests in MkCalendarTest, without the overridden MkCalendarMethod.addRequestHeaders, it works just fine. No sign of a "400 Bad Request" anywhere? Any clue, why this was specifically done?

I have updated fork with, the following, with working methods and their tests.

• Put, implements httpclient method. Tested, already works, no changes to make.
• Post, implements httpclient method. Already tested, should work.
• Options, changed to jcr. Tested works.
• Get, changed to jcr. Tested works.
• Delete, changed to jcr. Tested works.
• MkCalendarMethod, changed to jcr. Tested Works.

EDIT: With respect to MkTicketMethod, what should be the Success StatusCode, CalDAVConstants.SC_OK, i.e. 200? or SC_CREATED, 201?

EDIT 2: Never Mind, it's 200 based on this RFC here: https://tools.ietf.org/html/draft-ito-dav-ticket-00

EDIT 3: One thing, I notice is that with in multiple cases I notice org.apache.webdav.lib.properties.PropertyFactory.register being used in PropFind, though not just in PropFind, but a lot of other places as well.

From what I see, it seems to be a sort of a cache, for properties most frequently used. Feel free to correct me if I am wrong, because I am not entirely sure about this. But anyway, what I notice is that in the caldav4j-jackrabbit branch, org.osaf.caldav4j.model.util.PropertyFactory class exists. Which seems to be emulating the same function or similar in any case, to the jakarta-slide' PropertyFactory, except for like a Set of Properties.

But, from the analyzing the Jackrabbit sources, I find instead of this, there is class called org.apache.jackrabbit.webdav.property.DavPropertyName which implements an almost identical function for register, but which also creates a DavPropertyName, stores in the cache and returns the property back to the user. Here's the javadoc: https://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/webdav/property/DavPropertyName.html

It seems to be a better option, but there are two ways of using this, one would be to extend, the PropertyFactory to use it, or use it directly. Which do you think is more feasible?

Just in case here's the source code: https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/property/DavPropertyName.java

Hope for a response, soon.

EDIT 4: Just a further note, if this is going to change, then a lot of code would have to change. Including a lot of classes, so I suggest, we just stick with the current way. But, if we want to get rid of all the PropertyFactory.register dependency, then we'd have to implement something with respect to jackrabbit. And this is what they use.

[ioggstream]

@TheAntimist maybe it's time to split-up this ticket with sub-tickets ; )

1- comments on error 400 may be tied to the caldav server implementation. 2- tickets: does davical implement them? If they work is fine anyway. 3- please open tickets for the rest.

[TheAntimist]

@ioggstream The tickets, work fine, on davical, mkticket and delticket.

For 2, well, not entirely sure, for what the ticket would be, because it seems to be a bit of specific thing to migrate in caldav4j, to jackrabbit. But yeah, alright.

[TheAntimist]

@ioggstream With respect to PropFindMethod, I want to ask, why has the whole class overridden, just for ticketdiscovery? Including a whole initResponseHashtable, function? I am wondering on how to proceed in this case, I could simply just override and DavMethodBase, and the except for a couple of a things most of the responses and rest would use the jcr classes.

[ioggstream]

@TheAntimist about org.osaf.caldav4j.model.util.PropertyFactory:

• exists in all branches;
• it's an utility to avoid creating manually a lot of xml documents;
• if the DavPropertyName supports the creation of the xml docs required to manage ACL you can get rid of the PropertyFactory.

The more the code is clean, the better.

[ioggstream]

This is moved to different tickets