Job Opportunity
NXP Semiconductors Sales Marketing organisation and particularly the Global Brand Experience department is looking for an experienced developer in the area of Content Management, xml dB's transformations. As NXP is working hard on the next steps of a Dita xml environment they are looking for a developer with experience in integrating authoring environments using xml dB's in relation to CMS systems (preferably Alfresco) and xml editors using also the Dita xml standard and open toolkit. Transformation knowledge using Cocoon, Spring and Java is also required. Spring webservices is used for the SOA monitoring environment. In addition to that NXP uses the Maven development methodology within the IT department. Personal skills like excellent knowledge of english is a must and as you will be part of a team NXP is off course looking for someone that can easily work together with colleagues. In first instance NXP is looking for a full time 3 month assignment with a good opportuniy for extension. Technical skills: Required: - eXist-dB (hands on experience - xquery)! - xslt transformation - Cocoon - Java - Spring / Spring-WS - Maven Nice to have: - XMax/ xml editor - xml/ Dita - Good in english as well in speaking as writing - Good communicator - Team worker In case you are interested you can send your resume and availability details to Tim Nelissen, tim.nelis...@nxp.com. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: System upgrade and now Cocoon is escaping tabs/entities.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J, On 9/28/2010 10:09 AM, . . wrote: Our original application components were: NetBSD 3.0.3 with Suse 9.x Linux compatibility layer. Sun JDK 1.4.26 Tomcat 5.0.23 Cocoon 2.1.6 As part of the upgrade we switched to: Centos 5.3 Sun JDK 1.6.21 Tomcat 5.0.30 Cocoon 2.1.6 [snip] Firstly, if any of our source XML/XSL files use tabs to indent the nodes, the outputted source escapes them as #A9; which it didn't do before. This isn't a problem for output to be displayed in a browser but we have a number of legacy Flash components which, annoyingly, don't recognise this as whitespace and refuses to load causing the Flash component to fail. #a9 should be a copyright symbol if you're using ASCII. I suspect that #a9 is being used instead of a newline (0xa) followed by a tab (0x9). My guess is that your JVM's file.encoding system property used to be something like ISO-8859-1 or UTF-8 and now it's been changed to something that is more exotic, perhaps even mandating 16-bit characters (though your pages would be horribly jumbled if everything were interpreted at 16-bit characters). Check the file.encoding of your JVM in the old, working system relative to the new, broken one. Also, check to make sure that your XML files have the encoding set in the ?xml? processing instruction, and that the encoding actually matches what you used when you wrote the file to the disk. Finally, check to see if you have BOM characters at the start of your XML files. This is likely to solve both of your problems. NB: Tomcat 5.0 has been retired and really should be replaced. Upgrading to Tomcat 6.0 shouldn't be too much trouble. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyiNykACgkQ9CaO5/Lv0PD5xgCbBS0jEpDVsd5z9OA3vwlkOqKr WNoAoLLZfRUNW+Dbx/UiGyyOXLtdV2y9 =RGqP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: System upgrade and now Cocoon is escaping tabs/entities.
#a9 should be a copyright symbol if you're using ASCII. I suspect that #a9 is being used instead of a newline (0xa) followed by a tab (0x9). Actually it was a typo on my part. It's using #9; :( *oops* My guess is that your JVM's file.encoding system property used to be something like ISO-8859-1 or UTF-8 and now it's been changed to something that is more exotic, perhaps even mandating 16-bit characters (though your pages would be horribly jumbled if everything were interpreted at 16-bit characters). Check the file.encoding of your JVM in the old, working system relative to the new, broken one. Also, check to make sure that your XML files have the encoding set in the ?xml? processing instruction, and that the encoding actually matches what you used when you wrote the file to the disk. Finally, check to see if you have BOM characters at the start of your XML files. This is likely to solve both of your problems. I wrote a little JSP page to spit out the System.getProperty(file.encoding) value and got some surprising results. I tried two of the existing machines and got ISO-8859-1 for one and ANSI_X3.4-1968 for the other. The application runs fine on both of them. On the new server that too is giving out ISO-8859-1. That said, we did an experiment last night and copied the entire previous Tomcat folder over to the new CentOS server and ran it with Sun JDK 1.4.29 - the problem disappeared. When we ran it with JDK 1.5 or 1.6 the problem manifested itself. So the problem appears to related to the JDK in some way. Googling I came up with this: http://stackoverflow.com/questions/1059854/how-do-you-prevent-a-javax-transformer-from-escaping-whitespace Which makes me wonder if the old Xalan from our previous Tomcat is having issues with JDK 1.5 and up. I guess an Xalan upgrade is in order. NB: Tomcat 5.0 has been retired and really should be replaced. Upgrading to Tomcat 6.0 shouldn't be too much trouble. Only issue there is we have to support this legacy application for another 12 months and it's a hand me down so we have little or no source code or documentation. Porting it now would take up more time/effort than is financially viable right now :( - J
