After much messing around, I have now put up a web page on the sourceforge website, about the SLeD player, it’s at: http://ldplayer.sourceforge.net/. SLeD is the name for the player that we’ve finally settled on!
For info the messing around was because I couldn’t get to log in with the SSH client to upload the files to sourceforge. Turns out that after I changed my password all works fine, even though I was using the correct password to begin with – because it was the same one I used to log in to the Sourceforge website and that was working!
Have also put up the latest version of the authoring wizard tool on sourceforge too, it fixes one (fairly major) bug (!), and includes another demo template.
hmmm – well getting the complex type returned and correctly deserialized was working! but it only worked for an hour or so, then it seemed to stop working and I can’t figure out what’s going wrong! I keep on getting an ‘instantiation exception’ every time I try to call one of the methods. For some reason it tries to be instantiating the ‘CopperCoreAdmin’ class, which is an interface, so it shouldn’t be able to be instantiated anyway – so why is it even trying???! I’ve not changed anything 😉
Anyway, I’ll try for a bit longer to get this working, but if not, when I put the final release up on Sourceforge, I’ll leave it using the extra admin web service installed on the CopperCore server, but I’ll include the code that I tried to use to call the ‘proper’ coppercore admin service, so that someone else can pick this up and have a look – if they like 😉
I think I’ve now solved the problem of having to add the extra web service to the CopperCore install, to be able to get the Player to work. I’ve now resolved how to deal with the complex types returned by the CopperCore web service.
Harrie at OUNL showed me the Web Services Designer Wizard in JBuilderX and using this it generates all the required code for the complex classes based on the WSDL for the service. The next problem I found was that it was refering to the WSDL on the localhost and when I tried to change this to point to the name of my machine (alexlittle), every time I compiled it reverted back to local host. I;ve now found that after the Web Services Designer Wizard has done it’s thing, it can be removed from the project – just leaving the generated classes, and now I am able to alter the address of the WSDL without it reverting back to localhost.
The problem with having it revert to localhost is that I don’t want to force people to compile the player code in order to get it running, and want them to be able just to change the location of the CC admin service withi an xml config file.
Next step is to get this embedded into the code of the player (at the moment it’s just in a test class).
I’ve the past couple of days trying to get the player to recognise and deserialize the java classes provided by the CopperCore admin module. However I’ve had no luck with getting this working (I’ll keep trying though!). What I have done is a workaround, so that a small file needs to be added to the CopperCore server which provides the required CopperCore Admin web service method for the player, but returns an xml string instead of a java object.
This isn’t the best solution, but it will have to do for now (!), until I can get the neater solution working correctly.
I’ve tested installing the player on another machine and connecting to the web services version of CopperCore on another machine, and this all seems to be working well!! This is now up on Sourceforge and you can get the link and install instructions from: http://iet.open.ac.uk/pp/a.little/index.cfm?page=ldpInstall
For the problem with the returned data types from the CC admin web service, I built the new skeleton classes in the LD player and tried to test it all out. But, what I’d forgotten about was the fact that the player then cannot deserialize the returned data, to turn it into an instance of the new classes.
I’ve spent most of the day trying to find out how exactly to do this deserialization, and there’s lots of websites which mention it, but they are all too in depth and detailed or specific to a particular application for me to be able to read and understand in the short time I’ve got to get this sorted out. I could find no basic step-by-step examples for how to do deserialization of complex java data types, or arrays of them.
My next thought was then to try to update the coppercore admin web service – but then this would mean trying to find out how all the insides of the CC implementation works (also don;t really have time to get into this), and ensure that this was distributed with the next version of CC.
So, my plan of action is to basically recreate the parts of the CC admin web service that the player needs, but have it return xml strings rather than weird data types! This would mean however that to use the LD player, you would then need access to the CC web service server to be able to add in this new admin web service – but I think that’s the best I can do for now 😉
Now sorted out the problem of passing strings of arrays to the webservice – the problem was actually that I was calling the wrong service – doh! – so it wasn’t expecting an array of strings – hence the error message
Have got most of the rest of the player running with webservices, however there was one little problem that I came across in that the CC admin web service returned arrays of classes that were only defined in the CopperCore engine. This means that I would have to have CC and the player installed on the same machine, so that the player can get to the class definition for these CC classes, and I would like to be able to demonstrate that I can have the player running on one machine and CC on another. There are a couple of solutions to this:
- Update the CC admin webservice so that it returns XML strings rather than arrays of CC clasess
- Write another class within the player which just does the necessary functions to the objects that the player requires
I’ve gone for the second option, mainly because there is actually one one class that I will need to create, and there’s not much time left on the project for me to start updating a load of CC functionality. It may not be the best solution, but it will do what I need it to for now and updtaing CC to return XML instead of java objects can be added to the list of future developments 😉
Been a bit quiet on this recently – but I have been doing stuff!
There are a few things that I’ve now managed to get done….
- put a release up on Sourceforge. This seemed to take a lot longer than it should have done! – I’ve never used sourceforge before and it took a little while to find out how I could actually just upload a zip file for people to be able to download. The release I’ve got up there is still just the first version that’s also available from this site. I’ll get a much more up to date version uploaded in afew days (or so!)
- I’ve updated the player so that it will now run level B learning design, so that the user is able to view and set properties. This took a while to get figured out in my head what the LD package should look like – but the OUNL team helped a lot with this one! In terms of this current JISC project, I don’t think we are going to have time now to get the player up to running level C – or rather there may be time, but then the documentation etc of everything else would suffer. Also i think it’s probably more important to get the player tested and running well with level A & B, before trying to implement too much at once (and in a rush) – this can be something someone else may like to take up…. 😉
- I;ve also now received the webservices version of CopperCore, so I’m in the process of changing the player to run with this api rather than the current java api. This seems to be going well so far. The only problem I’ve come across is trying to pass an array of Strings to the web service – but I’m sure I can find a solution to this somewhere…