Archive for 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 🙁

Thursday 24 November 05

Still having ‘fun’ trying to get this web services stuff to work correctly. Currently I have CCSI running and I have Sled running, unfortunately I can’t run them on the same machine (or instance of JBoss) as I then run into error because of class loading etc. I found that if I replace the JBoss axis.jar with v1.2.1, then start up fails because of errors with CCSI.war, however, in order to get sled.war to start up correctly I must have the up to date version of axis in the JBoss lib directory – so that’s my conumdrum – how to get this working!

I’ve been googling and emailing a few people to try and find a solution to the problem – essentially I’m trying to fnd out how I can run the 2 apps on the same instance of JBoss (which I ought to be able to do) – and here’s how far I’ve got…

I found the page on the Jboss wiki (http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration) which is meant to explain how you can override classes. Unfortunately theres no actual example, they give the code snippet:

<jboss-app>
  <loader-repository>
  dot.com:loader=unique-archive-name
     <loader-repository-config>
     java2ParentDelegation=false
     </loader-repository-config>
  </loader-repository>
</jboss-app>

But I don’t know *exactly* what I shoud put instead of unique-archive-name, should it be ‘axis.jar’ or ‘lib/axis.jar’ etc, and also I don’t know if I’m meant to change the ‘dot.com’ to be ‘org.apache.axis’ or something else or not!

The other options I have are either upgrading to version 4.x of JBoss or to just leave as is and just Java api when the apps are running on the same box, and webservices if they are on seperate boxes. Upgrading is a bit of a non-starter – as it could quite easily introduce many more problem than I’ve already got – especially as I’d need to ensure that CopperCore, CCSI and Sled all ran fine underthe new environment. Took much work I think! Having them run on seperate boxes, or just using java if they are going to be on the same box is a fallback solution for me – I wouldn’t be that happy leaving it at that, because then I’ve not actually solved the problem – just got around it. I know that in a produciton environment if you had 2 java apps running on the same App server you wouldn’t need them to be communicating using web services, but for the purposes of this project, I’d at least like to be able to demonstrate that you can if you want.

Actually another option for me could be to see if I can get the CCSI.war to start up and run when the latest version of axis is in the JBoss lib directory. So I might try and have a look at that too.

If anyone out there has any bright ideas  – please email me ASAP!

Wednesday 23 November 05

Think I’ve got it now. The Jboss server is using the axis.jar in the C:\coppercore\ccrt\jboss-3.2.6\server\default\lib directory, rather than the one in the Sled2 lib directory, which would explain why it couldn’t find the method because the axis.jar that’s included with that version of JBoss is an old one – not sure of the exact version number, but the one include with JBoss is about 1.2Mb and axis.jar for 1.2.1 is about 1.5Mb.

Wednesday 23 November 05

Getting the webservices running seems to be going in fits and starts at the moment. I have got WTP to create all what I think is the correct code for the webservice client, and I can run this fine as a standalone java app in Eclipse. However, when I then try to move to using it within Jboss in the Sled Player code, I keep getting the following message:

java.lang.NoSuchMethodError: org.apache.axis.description.OperationDesc.setStyle(Lorg/apache/axis/constants/Style;)V
org.sled.coppercore.ccsi.DispatcherSoapBindingStub. _initOperationDesc1(DispatcherSoapBindingStub.java:33)

So I’m guessing that my version of Jboss doesn’t have the corrrect jar file somewhere – most likely that it’s not got Axis 1.2.1, I’ve tried to figure out which one is wrong, but not found it yet so I’ll keep trying 😉

Tuesday 22 November 05

At the beginning of last week Hubert & Harrie put the updated version of the CCSI module up on Sourceforge, so I have spent the last few days converting the Sled player to use the web services connection to the CCSi module, rather than the java API we were previously using. I had a bit of frustrating time getting it to call some of the Admin functions, but the problem ended up being that I had compiled the CCSI with an older version of Axis than the one I should have been using, once I’d compiled with Axis 1.2.1 it seems to be working ok. There is still a fair bit more work for me to do, so far I have only got the CopperCore and CopperCoreAdmin connections converted to using the CCSI webservices connection. Once I have got this tested and working fine, I can then move on to getting the other modules, APIS, Forum, Search etc moved over. For the Forum and Search I will need to create the web services adapters in the CCSI for it all to be running from web services API rather than a mixture of webservices and Java. I’m certainly learning more about using Eclipse, WTP and web services doing all this!