...
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.