WikiLens

Not in use now that we're running JSPWiki

Note that the lens only sees changes that we made, or discovered via the lens

• Pound signs cause a problem as they're not in the DTD, I need to stop JTidy producing them.
• I think you lose tabs if you edit a page -- OliBye
• CSS Stylesheets. URLs need transcription for remote sites.
• Error500 - RussFreeman

• It's getting page names wrong, this is serious, hmm -- OliBye
• I think the sessions are timing out quickly -- OliBye
• • I think the problem is if you log in from another machine
• when editing pages it adds line breaks -- OliBye
• • I think that's JTidy being over nice It was
• Replace OzoneOODBMS? with files

The problem came to light when I started using the IBMDistributedDebugger which is excellent. It was asking for xalan classes that didn't exist in my source tree. That combined with the version number of 1.2 on my VisualAge copy of xalan made me realise what was wrong.

What follows in the story for archiving sometime.

I'm fairly sure it's to do with several jars all containing packages beyond the org.w3c.xml namespace it's really annoying as everything is fine in visualage. Hmm, maybe I'll get visualage to make a mega jar. with everything it needs. Maybe I won't it's a horrid hack

A nicer hack is to sort the classpath so xalan loads first java -cp wikilens.jar:junit.jar:mockobjects.jar:xpdeveloper-testing.jar:xalan.jar:xalanj1compat.jar:Tidy.jar:/opt/tomcat/lib/servlet.jar:ozone.jar com.xpdeveloper.wikilens.test.unit.AllTests

(Apparently using jaxrpc.jar at runtime solves this too).

In the servlet xerces was not parsing the JTidy output properly, which wasn't the error I was getting in the unit tests, but fingers crossed it has the same root cause. So I just have to move the offending jars to the TOMCAT_HOME/lib dir and order them in tomcat.properties. These jars are used elsewhere anyway so they're best off in the common lib dir.

Well cleaning up the classpath fixed something. OliBye noted from the cocoon documentation that putting xerces.jar first on the path was essential.

I think I'm going to have to use the remote debugger to solve the rest.

-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000 -Xdebug -Xnoagent