WikiLens

- Last edited November 20, 2002

WikiLensStories | xpdeveloper.com/wikilens/home.jsp (broken link, Tomcat 404)

The WikiLens is more stable. More thought needs to go into the UI.

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

Bugs

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

Done

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

OliBye had a lot of troubling installing the lens on chicken. It mostly came down to using xalan2 on chicken, when all the code had been written against xalan1.

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.

Here's what I get trying to run the tests on chicken

 java.lang.LinkageError: loader constraints violated when linking

org/w3c/dom/Document class

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

- Last edited November 20, 2002

https://casino-brain.com/