please use 3.2.x branch instead of trunk On Thu, Apr 28, 2016 at 11:22 PM, Ankush Mishra <[email protected]> wrote:
> Alright, a couple of things I'm having problems with in my OM install. My > Screensharing for some reason does not work, after launching the jnlp file > with javaws, I get a error saying unable to launch application with the > > ERROR that > /tmp/mozilla_e/$codebase/openmeetings-sceenshare-4.0.0-SNAPSHOT.jar (No > such file or directory) > > > and JNLP file has: > > <application-desc > main-class='org.apache.openmeetings.screen.webstart.CoreScreenShare'> > <argument>$url</argument> > <argument>$publicSid</argument> > <argument>$labels</argument> > <argument>$defaultQuality</argument> > <argument>$defaultFps</argument> > <argument>$showFps</argument> > <argument>$allowRemote</argument> > <argument>$allowRecording</argument> > <argument>$allowPublishing</argument> > <argument>$keystore</argument> > <argument>$password</argument> > </application-desc> > > > > also, the server log file, keeps logging the following error > > ERROR 04-28 22:50:39.907 o.a.o.w.r.StartSharingEventBehavior:131 > [http-nio-0.0.0.0-5080-exec-8] - Unexpected error while creating jnlp file > java.lang.NullPointerException: null > at java.net.URI$Parser.parse(URI.java:3042) ~[na:1.8.0_74] > at java.net.URI.<init>(URI.java:588) ~[na:1.8.0_74] > at > org.apache.openmeetings.web.room.StartSharingEventBehavior.respond(StartSharingEventBehavior.java:97) > ~[openmeetings-web-4.0.0-SNAPSHOT.jar:na] > at > org.apache.openmeetings.web.room.RoomPanel$4.onClick(RoomPanel.java:190) > [openmeetings-web-4.0.0-SNAPSHOT.jar:na] > > I know something's wrong, just not entirely sure what. Any help is > appreciated. > > Ankush > > On Thursday 28 April 2016 02:41 PM, Maxim Solodovnik wrote: > > I prefer to solve problems as soon as they appears :) > But it's totally up to you :) > > On Thu, Apr 28, 2016 at 1:35 PM, Ankush Mishra <[email protected]> > wrote: > >> Alright, makes sense. >> >> Should I leave their Apache Slide issue temporarily and if possible later >> check up on their jackrabbit-webdav dependencies, and make changes in a >> fork for it? >> Or just leave it as it is and add necessary changes as and when needed? >> >> I'll have to look into their codebase this week, to get a hang of it, in >> any case. >> >> Thanks >> Ankush >> On 28 Apr 2016 09:34, "Maxim Solodovnik" <[email protected]> wrote: >> >>> If I were you I would use <https://github.com/caldav4j/caldav4j> >>> https://github.com/caldav4j/caldav4j :) >>> You always can fork it fix something and propose PR to the original repo >>> :) I would update libraries they are depend on :) >>> In case their community is not active at all I can publish necessary >>> artifacts into our own repo: <https://bintray.com/openmeetings/maven/> >>> https://bintray.com/openmeetings/maven/ >>> >>> On Thu, Apr 28, 2016 at 6:56 AM, Ankush Mishra < >>> <[email protected]>[email protected]> wrote: >>> >>>> Looks like I forgot to CC, again. Would love to hear what you all think >>>> on this. >>>> >>>> Ankush >>>> ---------- Forwarded message ---------- >>>> From: "Ankush Mishra" < <[email protected]> >>>> [email protected]> >>>> Date: 27 Apr 2016 19:34 >>>> Subject: GSoC: Discussion on Libraries to use for CalDAV >>>> To: "dev" <[email protected]> >>>> Cc: >>>> >>>> Here's the current list of CalDAV library implementations in JAVA: >>>> >>>> - iCal4j (which is used in the project already for handling ics): >>>> This is already used to send out event invites through email. Just >>>> that this might still be used for handling CalDAV as the calendar data is >>>> still made up of iCal. >>>> There exists an iCal4j-connector which from their page, also, >>>> implements the CalDAV using jackrabbit-webdav library. But it's development >>>> seems to have stopped since 2013. >>>> >>>> - CalDAV4j ( https://github.com/caldav4j/caldav4j ): >>>> >>>> From their Project Page: >>>> CalDAV4j is a protocol library that extends the Slide project's >>>> WebDAV client library (which itself is an extension of the Apache's >>>> HttpClient library) to allow high level manipulation of CalDAV calendar >>>> collections as well as lower level CalDAV protocol interactions. This >>>> project uses iCal4j for iCalendar processing. >>>> >>>> This project is promising and their library is stable to use. But >>>> from their googlecode commits it was last commited on Nov 2013, though >>>> since moving to GitHub, it still hasn't had much happen. >>>> >>>> One thing I have noticed it's still missing the CalDAV ACL's, things >>>> like "PRINCIPAL" query haven't been implemented. I'm also not sure of it's >>>> status of development or it's integration to the JackRabbit sources, but >>>> from digging up it's history I notice that the Open Source Applications >>>> Foundation (OSAF) is now defunct, and thus, it might seem like the project >>>> is at a halt. There also seem to be issues with jackrabbit-webdav >>>> integeration, it still seems to be using Apache Slide as the WebDAV >>>> library, atleast in the master branches, though there is a branch on the >>>> Google Code for caldav4j-webdav using the jackrabbit-webdav library( >>>> <https://caldav4j.googlecode.com/svn/branches/caldav4j-jackrabbit/> >>>> https://caldav4j.googlecode.com/svn/branches/caldav4j-jackrabbit/). >>>> >>>> >>>> - JackRabbit-WebDAV ( >>>> <https://jackrabbit.apache.org/jcr/components/jackrabbit-webdav-library.html> >>>> https://jackrabbit.apache.org/jcr/components/jackrabbit-webdav-library.html) >>>> : >>>> Taken from their project page: >>>> This is the WebDAV Library component of the Apache Jackrabbit >>>> project. This component provides interfaces and common utility classes used >>>> for building a WebDAV server or client. >>>> >>>> It supports DAV 1, 2, DeltaV, Ordering, Access Control, Search, Bind. >>>> >>>> >>>> In the end both CalDAV4j and Jackrabbit-webdav, can be used. It'd be >>>> preferrable to use CalDAV4j, which directly implements CalDAV protocol but >>>> extends Apache Slide WebDAV protocol library. The main problem with >>>> caldav4j is that Apache abandoned Slide in 2007 and therefore it is based >>>> on a deprecated library (now Apache advises to consider Jackrabbit project >>>> instead). And Jackrabbit-webdav implements only WebDAV specific code. Some >>>> operations will be very familiar if you already have experience with HTTP >>>> services (GET, PUT and DELETE), but many are added too (MKCOL, MKCALENDAR). >>>> >>>> >>>> Thus comes the dilemma of which library to use, perhaps at some part >>>> even the CalDAV4j, could fail, and it would be easier to use >>>> jackrabbit-webdav at places to implement parts which don't already exist. >>>> >>>> In the end, I'm still not certain of which library to use. >>>> >>>> Ankush >>>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> > > > -- > WBR > Maxim aka solomax > > > -- WBR Maxim aka solomax
