Archive for December 2005

Thursday 22 December 05

I’ve had a couple of queries regarding the latest version of the Sled player…

The first was about a problem running the Sled player with the latest version of CopperCore (v3). I’ve not had chance to investigate this as yet, so I’m not sure what the problem is, but from the JBoss log message I was sent, it looks like a Java Struts problem with the Sled application. The latest version of CopperCore was only released a few days after I put out the latest version of Sled, so if there is a problem, it shouldn’t be too significant. I hope to get chance to look at this early in the new year.

The second one was regarding compiling Sled with Java sdk version 1.5.x and then trying to run JBoss with Java 1.5.x too – from the log there are some ClassNotFound error messages and I suspect that this is due to using the more recent version of Java. All the components of the CopperCore/Sled system (possibly including the extra java libraries such as Axis etc) have been compiled using Java 1.4.x so my advice (!) is to keep using v1.4, for running JBoss and for any compiling of the components. Having said that in theory, you should be able to have all the libraries/code etc compiled with v1.4 but still run JBoss with v1.5 – though maybe there are some incompatibilities.

Thursday 15 December 05

Spent most of the last month working to get the Sled projects finished off – and had a few technical problems (all detailed in my LD diary if you’re interested!). But I’ve finally got it done now and I released the latest version of the Sled player (v2.1) on Tuesday.

Thursday 15 December 05

On Tuesday, I finally finished off the Sled/CCSI integration, and was able to put up on Sourceforge the most recent update Sled v2.1 (see: http://sourceforge.net/project/showfiles.php?group_id=112068) This includes the compiled CCSI with all the extra adapters etc, but I may not need to include this in future versions, as I think that CopperCore will be including CCSI as part of their download package.

If you so try the latest version of Sled and find any bugs or issues, then please report them to the help forum on the Sourceforge website (at: http://sourceforge.net/forum/forum.php?forum_id=383690)

 

Tuesday 6 December 05

I’ve now got the Sled player running so that it uses a java api if CopperCore & Sled are on the same machine, and a web services api if they are on different machines. There is a configuration option that needs to be updated in order to get it to work correctly, so if you have it configured the ‘wrong’ way (eg, using web services connection when they are on the same machine) they it will generate errors, but there’s not much I can do about this at the moment. The other thing I;ve found is that when they are running on the same machine, some of the classes in Sled need to be deleted, there are the compiled classes for org.coppercore.common.* and org.coppercore.dto.* otherwise there is a conflict with the existing classes from the coppercore.ear file. I’ve tested this running using a variety of the services too, using search, forum and QTI.

I’ve still got some finishing off to do, and to sort out how all this gets packaged up so that it’s easy for people to install and I also need to add in the demo ePortfolio service then I ought to be ready to release the new version up on Sourceforge.

Friday 2 December 05

Last night I eventually figured out the problem I was having with the no class definition found when calling the CCSI webservice. The build script had an ant xslt task to transform the deploy.wsdd from the original (with the incorrect class names, eg org.coppercore.ccsi.DispatcherSoapBindingImpl) to an updated version (with the correct class names eg org.coppercore.ccsi.Dispatcher). The original ant xslt task was as follows:

<xslt basedir="WebContent/WEB-INF/@{service}Service/@{package.path}" destdir="WebContent/WEB-INF/@{service}Service/@{package.path}" extension=".wsdd" style="deploy.xsl">
<param name="newClassName" expression="@{implclass}" />
<include name="deploy.bak" />
</xslt>

 and I changed this to:

<xslt in="./WebContent/WEB-INF/@{service}Service/@{package.path}/deploy.bak" out="./WebContent/WEB-INF/@{service}Service/@{package.path}/deploy.wsdd" style="deploy.xsl">
<param name="newClassName" expression="@{implclass}" />
</xslt>

So I’ve got it running and generating the deploy.wsdd files with the correct implementation class names, but that still doesn’t explain why it just stopped working, as I had had it running fine before!

Thursday 1 December 05

Went to the final Unfold meeting in Berlin earlier this week, the most useful day for me was the Tuesday when we were discussing the original LD architecture diagram that had been developed at the Valkenburg meeting a couple of years ago, and we were reviewing to see how relevant it still was (if at all). We did come up with a new architecture, which is pretty much based on the adapter model we have used for the CCSI in the recent toolkit project. So that’s pretty good from my point of view – as it’s the architecure I had started to build for Sled and the external services.

Unfortunately spent the last couple of days tearing my hear out over this web services stuff still, and keep going round in circles. At the end of last week I had decided not to continue trying to get Sled connecting to CCSI using web services when they are on the same machine. Instead if they are on the same machine, the java API shoul dbe used, and web services used when they are on remote machines. I guess this is the way you would usually have it set up, but it would have been nice if I could get it working.

I’ve now managed to get another problem occuring though when compiling the CCSI module, when I move the ccsi.war file over to the server and try calling it from a little test java app on my desktop machine, I get the error that there is no class definition for the class: org.coppercore.ccsi.DispatcherSoapBindingImpl. This is a bit odd because it was previously workig and I’ve not changed anything in the build.xml that should affect this. In the online forums etc it just says to ensure the classes are on the classpath – but I need to work out why this has just started to happen. The build file is creating the .java files for the classes, but they are not being compiled and copied into the final ccsi.war.

Will plug on with this – but it’s really starting to do my head in – just as I think I’m getting close to finishing off, something else comes up that seems to take a few days to resolve 🙁