Indeed the RequestDumperValve has the very annoying side effect of setting the encoding, which parasites everything. They really should document that in Tomcat.
Regards, Serge Huber.
Daniel Zimmermann wrote:
We found the error in the server.xml. It was the RequestDumper which
we activated for
testing purpose. Strange!
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
If it's commented, everything works like a charm...
On Tue, 7 Dec 2004 14:11:48 +0100, Daniel Zimmermann
<[EMAIL PROTECTED]> wrote:
To take the possible urgency out of this topic, I would like to inform you that UTF-8 support in Jahia 4.0.5 is just fine. We currently don't know why, but it seems like our cutomized Jahia server.xml file for Tomcat is the reason why tidy or UTF-8 support seems like to misbehave. If we start our automatic build process the templates, config file and other stuff is packaged and overwrites a fresh or existing jahia version. When I restore our server.xml with a fresh (from scratch jahia installation) server.xml, UTF-8 and tidy are fine. Maybe you can have a look on the file?
Cheers Daniel Zimmermann
On Mon, 06 Dec 2004 12:22:49 +0100, St�phane Croisier
<[EMAIL PROTECTED]> wrote:
Strange because umlauts work fine for us on a fresh UTF8 4.0.5 install...
So is this coming only for migrated data or also for new 4.0.5 data? Is this happening only for big texts (stored on the file system) or also for small texts (stored directly in the database)? Do you see the umlauts in the WYSIWYG Editors when loading the data or is it already wrong here (or only wrong when saving the data)? Are you sure your old big texts are still in UTF-8 format (if you, for example, reinstall the old data on a new server by zipping/tar.gzing the old data perhaps you this process converted your text files back in ISO format)? Are you sure that your linux config (etc/sysconfig/i18n) is correct?
Finally if everything seems correct, could send us an exemple of big text with an umlaut and where the error occurs such as: E:\jahia405\tomcat\webapps\jahia\WEB-INF\var\content\bigtext\1-2-20-de.jahia
1-2-20-de.jahia = sitekey-pid-field-lang.jahia Version with -s means this is a staging version. Version with the timestamp that this is an archive.
Cheers St�phane
At 11:30 06/12/2004, you wrote:
...with german umlauts and other special characters again. I have posted this before and the error is still in Jahia 4.0.5... and even worse. We use a UTF-8 MySQL database, with a UTF-8 RedHat Linux on Intel platform.
tidy.properties is (after the jahia "wizard" installation) for standard configured to latin-1 or UTF-8 (at least it was UTF-8 on 4.0.5PR) via the content-encoding property. UTF-8 should be fine for our configuration.
On 4.0.4 we could set the property to "raw" to get for example german umlauts right.UTF-8 did never ever work correctly. That was strange, but it was some kind of a solution. But with Jahia 4.0.5PR neither value works. When a Jahia page is displayed in the browser, both IE6 SP1 and Firebird tell that it's UTF-8. If you already have Bigtext or DB Fields with UTF-8 content (e.g. from migration) everything is displayed correct. But if you try to edit a container, the text is corrupted :(
The failure arises regardless of which editor you use. ActiveX, simple, HTMLArea... They all corrupt the text after you apply changes or save via "ok". So it really seems to be something about the html tidy option in Jahia or HTMLTidy itself.
P.S.: Tidy is activated though. We can set "internal" links like 123
and they are resolved to the correct relative path URL for page 123.
