...
So if I could figure out how to register a ResourceToolAction helper, I might be able to intercept display events.
Oct. 13, 2011
Looking back at my notes on the Sakai Confluence site, I note that I haven't done any work on Octane since July. That's longer than I thought.
It occurred to me last night that perhaps I should try to understand the underlying mechanisms of the Resource tool before trying to hack it's user interface. Much of the functionality of the RT has been moved into the kernel. It might be possible to create a small JSP servlet that calls out to the Sakai kernel. If so, it would allow me to play with the functionality there.
The idea is to create a small application that displays a list of files from a well-known directory. If files are of type text/html, allow them to be opened and inject the Octane powercell. Display them in an i-frame.
I've created a folder in c:/dev called octane and added folder in it called octtool, which will be the experimental octane tool.
The kernel is up to version 1.2.6. I have 1.2.2 on my laptop.
I checked out 1.2.6 from the subversion repos.
I am attempting to build it using maven.
Kernel built without error.
Edited files to create an app (now called) oct. It just has a test page. Compliled and deployed. Works using the following URL:
Next step is to find the kernel JAR and bundle it into app.
Built JavaDoc using "javadoc:javadoc", which is deprecated but seems to still work. The comment mentioned "javadoc:aggregate".
JavaDoc got built to file:///C:/dev-sakai/kernel-1.2.6/target/site/apidocs/index.html
Copied the following JARS into the lib section of oct:
- sakai-kernel-api-1.2.6
- sakai-kernel-impl-1.2.6
Hopefully, this will provide full access to the kernel. We shall see.
The first step is to grab a hold of the ContentHostingService. From there, all things are possible.
Let's see if we can bring this into Eclipse.
Seems like the static cover for ContentHostingService is now deprecated. They recommend that I use the ComponentManager, but that might lead to trouble. We shall see.
Problems right off the bat. The object, "org.sakaiproject.component.cover.ComponentManager" can't be resolved.
Sigh. It's documented in the JavaDoc. It's where I remember it to be, but Eclipse can't find it.
Hmm. When I look in "C:\dev-sakai\kernel-1.2.6\api\src\main\java\org\sakaiproject\component\cover", there are no objects.
This is where it lives: "C:\dev-sakai\kernel-1.2.6\component-manager\src\main\java\org\sakaiproject\component\cover".
So it exists, why can't I resolve the reference?
It just doesn't seem to be included in the compiled JARs.
From the looks of the m2 local maven repository, the component manager is built into a separate JAR. I found a sakai-component-manager-1.2.6.JAR in C:\Documents and Settings\Mark\.m2\repository\org\sakaiproject\kernel\sakai-component-manager\1.2.6. I'll bundle this into the oct tool and see if that helps.
Yes, that looks like it worked. Kinda makes me wonder what else didn't get included.
So, while Eclipse is seeing the ComponentManager, and ant compiles it, I get a runtime error saying it's not there.
It looks like the JARs were not deployed.
I deployed them by hand.
Ah, now we are going to run into the kernel dependencies:
java.lang.ClassNotFoundException: org.springframework.context.ConfigurableApplicationContext
There are a BUNCH of these, as you might expect.
A total of eight spring JARS alone.
Well, that helped. App is coming up now. I'm getting the following in the console:
| Code Block |
|---|
Could not resolve placeholder 'sakai.security' in [file:${sakai.security}security.properties] as system property: neither system property nor environment variable found
java.lang.Exception: traceback
at org.sakaiproject.util.NoisierDefaultListableBeanFactory.destroySingle
|
I think this is the result of the various Sakai property files not being found.
Oh, and I'm going to need a database, I suspect.
I think I can create a Java system property called "sakai.security". I assume it points to the directory where the security.properties file lives, but I don't have an example of what that file looks like.
I created a (mostly) empty file at c:/security.properties and created a system property to refer to it.
It no longer complains about the security properties, but still fails. I think that Spring is failing to initialize, likely due to some missing piece or other.
| Code Block |
|---|
java.lang.Exception: traceback
at org.sakaiproject.util.NoisierDefaultListableBeanFactory.destroySingletons(NoisierDefaultListableBeanFactory.java:96)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:388)
at org.sakaiproject.component.impl.SpringCompMgr.init(SpringCompMgr.java:154)
at org.sakaiproject.component.cover.ComponentManager.getInstance(ComponentManager.java:98)
at org.sakaiproject.component.cover.ComponentManager.get(ComponentManager.java:111)
at com.nolaria.oct.LocalContent.test(Unknown Source)
|
Short of debugging the whole initialization logic, I'm not sure it makes much sense to continue this line of inquiry. Better, I think, to build the whole Sakai environment and make a tool that runs within it to analyze the ContentHostingService.