Tuesday, November 18, 2008

NetBeans and Eclipse

Getting NetBeans and Eclipse to work together isn't all that hard. I'm now cycling through the Sakai SOPI App re-work ( spec drift ) using both IDEs against the same checkout. One just has to keep the specific project dependencies wired up correctly.

I think I've figured out the NetBeans performance issues. Watching the OS X Activity Monitor I see that Eclipse uses all the CPUs in this quad g5. NetBeans will spike one CPU and grind away.

It's still dangerous to get ahead of NetBeans rendering!

Friday, November 14, 2008

progress

Plowing on; now the business constraints are more of an issue than uploads, roles, sections and all that.

Saturday, November 8, 2008

Uploads continued

So after building the proper multipart request and posting to the content tool I of course was granted NPEs. The content tool behaves differently than the 2.4 era access servlet, and preforms a lot of wiggling as it gathers magic pipes for accepting the upload. The short of it is that having a session isn't sufficient - the request has to be part of an overarching tool state.

I'll admit I wasn't looking forward to using the content tool this way - scrounging around to ge the tool ID seemed pretty tedious.

The good Dr. S. threw me a bone in comments here yesterday - thanks. I had examined this builds version of the Access servlet and didn't see that the Post did anything but login. I'll have to do some future archeology and see what post 2.4 version of access had the Rutgers extensions to allow uploads. The SAF app I'm building is already using the access servlet a great deal to pull media.

later doh. I should of looked at the zenly named "WebServlet" in the Access project. I had ignored it thinking that the name implied it was somebodies scratchpad. This WebServlet servlet looks more promising. it looks like it's using some deprecated methods but heck if it works off we go. I may have to dork around more; the upload has to go to an area which the the Student cannot Read, and which the Instructor sometimes cannot read, and sometimes to another site altogether. These rules are why I'll probably end up in a WS solution with sessions for both the user and an agent. anyway this WebServlet servlet is where I start my morning coding.


SteveS mentioned webservices - I see that the 2.4 ContentHosting.jws did get some upload endpoints. That will be where I go after the access servlet. Steve, is there an alternate webservice package you would recommend?

In my original plan I fall back to working with a Java WebDAV client if I can't get the access upload verion integrated or the WS to work out quickly. I expect that would be a real mess

Friday, November 7, 2008

Uploading to Sakai 2.4 foo

reverse engineering Sakai's Resource tool uploading. I'll be doing this from outside Sakai so I want to see what the URLs are like.

first it looks like there is a POST to set the folder / location

POST /portal/tool/0ed2a194-16d0-425f-8022-1250ca000fe1?panel=Main HTTP/1.1

Host: localhost:9595

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://localhost:9595/portal/tool/0ed2a194-16d0-425f-8022-1250ca000fe1?panel=Main

Cookie: JSESSIONID=388ce121-9b5d-4bbe-8098-e904e98e0477.santoku

Content-Type: application/x-www-form-urlencoded

Content-Length: 217

source=0&collectionId=%2Fgroup%2FF08-SOPI-101%2F&navRoot=&criteria=title&sakai_action=doDispatchAction&rt_action=org.sakaiproject.content.types.fileUpload%3Acreate&selectedItemId=%2Fgroup%2FF08-SOPI-101%2FResponses%2F

then a POST multipart to get the stuff up:

http://localhost:9595/portal/tool/0ed2a194-16d0-425f-8022-1250ca000fe1/sakai.resource.type.helper.helper?sakai_action=doUpload&flow=save



POST /portal/tool/0ed2a194-16d0-425f-8022-1250ca000fe1/sakai.resource.type.helper.helper?sakai_action=doUpload&flow=save HTTP/1.1

Host: localhost:9595

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://localhost:9595/portal/tool/0ed2a194-16d0-425f-8022-1250ca000fe1/sakai.resource.type.helper.helper

Cookie: JSESSIONID=388ce121-9b5d-4bbe-8098-e904e98e0477.santoku

Content-Type: multipart/form-data; boundary=---------------------------126032761616950317512028061602

Content-Length: 3839

-----------------------------126032761616950317512028061602

Content-Disposition: form-data; name="fileCount"



1

-----------------------------126032761616950317512028061602

Content-Disposition: form-data; name="lastIndex"



0

-----------------------------126032761616950317512028061602

Content-Disposition: form-data; name="exists_0"

( I cut off the rest of this... )

Wednesday, November 5, 2008

Java for quicktime; no HTTPS?

So now my application is logging into Sakai, pulling university affiliations, workgroups and sundry, and finding all the Sites bearing the mark of SOPI.

The Sakai access URLs are working fine; I'm pulling content I am supposed to be able to pull. The Quicktime Movie URLs are resolving into movies to present to the user. The user answers them - and I was about to crack the nut of uploading the recorded response movies to Sakai when I decided to use a faster remote host at the Client's facility.

So it's all going swimmingly, er, except if I use a HTTPS URL. That's not a big deal for the webservices. Nor for reading text files such as the XML manifest for the assessment media.

Apparently Apple never implemented a HTTPS transport URL resolver for quicktime.

What a headache to dig down into. I was sure that I had something screwed up with self-signed certs, certs not matching host names, and dorked with all sorts of work arounds. ( such as a custom no-op host name verifier )

I finally trawled the Apple Quicktime mailing lists and found a lone posting from a couple of years ago. Feh. An apple engineer suggested reporting a bug.

So I snork up some old IO code and securely spool the files locally only to re-read them into quicktime with a file:/// URL.

This was quite derailing.

However the national election results were a boost!