X-Application Version: 4.1.1
Tamino Version : 4.1.4.1
Platform : WinXP, Solaris
WebContainer : Tomcat 4.1.27
JDK Version : 1.4.2

X-Application Version: 4.1.1
Tamino Version : 4.1.4.1
Platform : WinXP, Solaris
WebContainer : Tomcat 4.1.27
JDK Version : 1.4.2


Problem: When I generate application, the following shows up in the browser…

Processing command: Generate

--------------------------------------------------------------------------------

generating
Preparing directory c:\tomcat4\webapps\PurchaseOrderSchema
generating c:\tomcat4\webapps\PurchaseOrderSchema\WEB-INF
generating
generating C:\Tomcat4\webapps\PurchaseOrderSchema\structure.xml
Success.
generating search.jsp



search.jsp does not contain anything and the other jsp files do not get generated.



In the tomcat window I see:

org.apache.xml.utils.WrappedRuntimeException: The output format must have a ‘{Xalan-Java version 1}content-handler’ property!

followed by a long list or errors.


Using the generate.cmd command, the application is created nicely. I’ve already changed to the Xerces version supplied by xapplication in the ‘endorsed’ folder and the demo application runs fine.


Can anyone help?

Sean.

I’ve seen exactly the same problem on my RedHat 9.0 machine when I used X-Application with jdk 1.4.2.

The problem vanished when I switched back to jdk 1.4.1. That’s the only work-around I know … it seems that 1.4.2 introduced some changes in the XSTL processor, and this breaks the generator.

Do you have this problem on your Windows Box or only on the Solaris machine?

If you happen to find a better work-around, please let us know!

Michael

Software AG Germany, Darmstadt

Thanks. I will try with 1.4.1. I’m only using WinXP.
Sean.

Yes. It works with jdk1.4.1
Thank you for the feedback.
Sean.

Is there a way to get it to work with jdk1.4.2?

I thought you could use tomcat_4.1.18/common/endorsed for this purpose, but it does not work!

Any ideas/suggestions?

Regards,
Rudolf de Grijs

I still haven’t seen a work-around for 1.4.2 but placing a recent xalan version into common/endorsed is exactly what I’d suggest. It’s also possible to place xalan into jdk/jre/lib/ext to force it into your classpath.

Did you already try something like that?

Michael

Software AG Germany, Darmstadt