...
Created a static test page at: file:///C:/Documents%20and%20Settings/Mark/My%20Documents/_work/uCompass/steam-engine.htm
Talked to Tom Petz on the phone.
My domain needs to be registered. He is registering "localhost" for me.
He will also add some Octate tools to demonstrate.
...
24 sub-pages, most of which are no help.
Other interesting pages:
- Content Hosting /wiki/spaces/ARCHIVE/pages/19428638826 - written by me, no less.
- Content Hosing Service - largely about migration to JCR, which was implemented but never quite went all the way. Got derailed by Sakai-3 (OAE).
...
After analyzing all of the files in the content tool, I have found the following references to getContent():
- FilePickerAction.java - extends PagedResourceHelperAction, one instance of getContent() ****
- ListItem.java - one instance of getContent() ****
- ResourcesAction.java - extends PagedResourceHelperAction, one instance of getContent() ****
- ResourcesEditItem.java - extends ResourcesBrowseItem, one instance of getContent() ****
- ResourcesItem.java - three instances of getContent() ****
So the next step is to put hook messages in every one of these places and see if they get triggered when content is displayed.
Hooks are now in place.
...
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:
...
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.
Oct. 24, 2011
A bit over a week a ago, I started experimenting with a simple, JSP-based application that would allow me to explore support for the Resources tool in the Sakai kernel. I started running into kernel dependencies that made further development (in isolation) difficult. Since then, it occurred to me that if I just embed it in a Sakai environment, I'm very likely to get that simple app working. So let's bundle it up and move it over to my laptop and work on it there.
Naturally, things will build and startup more slowly here, but I might be able to take advantage of the hot-swapping support in Tomcat, since I'm not tinkering with the underlying libraries.
Started up tomcat and tested the app as it currently exists using:
http://localhost:8085/oct/test.jsp
Message indicates that the ContentHostingService was obtained.
...
Notes from June 21 of this year indicate that if I could register a ResourceToolAction helper, I might be able to intercept display events.
I created an OctaneToolAction that implements (so far) ResourceToolAction.
I had to make some guesses on on values to be returned by methods that implement this API, but I have a simple class now.
There are a couple of interfaces that can be implemented to expand what is handled by this class:
- CustomToolAction - must be implemented if the ActionType is CUSTOM_TOOL_ACTION. Doesn't apply.
- InteractionAction - implemented if action involves user interaction to complete the action. May not be needed.
- ServiceLevelAction - (no documentation - idiots) Cancel, finalize, initialize, and isMultipleAction. Not clear if needed.
So we got a basic tool action helper. The question now is, how is this registered?
There is a ResourceTypeRegistry, which includes a register(ResourceType) method.
ResourceType has a set of actions associated with it, which are ResourceToolActions.
So let's do this:
- ResourceTypeRegistry.getType("ResourceType.HTML");
- Examine it's actions.
It may be possible to retrieve the standard definition of the HTML action and substitute a modified version at run time. It seems likely to me that these types are all in-memory anyways.
I added code to grab the ResourceTypeRegistry using the ComponentManager. It seems like a good place to get it from.
Re-compiled - hot deploy to Tomcat worked, so I don't have to cycle Sakai.
Successfully got the registry.
Unable to get a ResourceType of HTML. I have a suspicion about this. The Resource tool may be doing all of the registrations when it is started up. Brought up Sakai and re-tried it. No luck.
There is a registry method to getTypes() that should return all registered types.
This method returned the following types (given by their labels):
- Citation List
- File Upload
- Folder
- Web Link (URL)
- HTML Page
- Simple Text Document
- Form Item
Also interesting is the fact that the id's are given as class names. The id of the HTML page is "org.sakaiproject.content.Types.HtmlDocumentType. I examined these class back in June of this year. It has several tool actions defined for it, including an ACCESS_CONTEST action that has been either deprecated or no longer used. Perhaps I can replace it with a new one.
Oct. 25, 2011
Yesterday I managed to list out all of the registered resource types. Today, I'm going to focus on the HTML type.
Verified that I can get the HTML Resource type and view it's associated actions.
I see that the HtmlDocumentType is in the Sakai Content code. Structures for resource types and resource tool actions are all part of the Sakai kernel, which is what you'd expect of good separation of data vs. structure. This opens the possibility of modifying operation of the Resource tool without having to modify the kernel (which would be difficult).
The finalize() method of a ResourceToolAction presents some possibilities. It is passed a reference to the resource, so I could modify it on demand, but it would be a permanant modification, I believe - not what I really want. What I want to do is to set up a way to intercept a call to getBytes() so that I can inject the Octane power cell.
It seems like ResourceToolActionPipe is the thing I want to take control of. It has a getContent() method that presumably can be used to modify code on the fly.
ResourceToolActionPipe provides a conduit through which ResourcesAction and an unknown helper may communicate about the execution of ResourceToolActions in which the registered action specifies that some part of the action is handled by a helper.
Looking through ResourcesAction, I note that the ResourceToolActionPipe is stored in a tool session attribute. I think it is created when an action is started, persisted as a runtime attribute, then deleted when done. ResourceToolActionPipe objects are not created in ResourcesAction. So where are they created?
A ResourceToolActionPipe can be passed into the creation of a ResourcesItem in the Resource tool, but I have console flags in place that should signal when this happens. It didn't in previous tests.
Just to see if I might gain access via an action, I uncommented support for ACCESS_CONTENT in HtmlDocumentType and added an Octane hook alert in HtmlDocumentAccessAction.finalizeAction(). Didn't get any alerts or messages. Darn.