Re: [2.1] Overzealous escaping of high Unicode code points

[Flynn, Peter]

I had a related problem with 3–4 CJK characters being converted to their &#hex; 
format. Very weird, but it turned out to be the old and buggy copy of jtidy, 
and I can't figure out how to replace it.

I haven't had the problem you describe, though, and I have a user who has 
implemented emoji in Cocoon, see http://research.ucc.ie/emojis/

P

--
Peter Flynn | Academic and Collaborative Technologies | IT Services | 
University College Cork | Ireland | pfl...@ucc.ie | 
http://research.ucc.ie/profiles/H505/pflynn | Sent from 
Hiri


On 2017-06-06 17:08:51+01:00 Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I've been testing my application for use with high Unicode code points
such as emoji like 😍 which is this one:
http://www.fileformat.info/info/unicode/char/1F60D/index.htm

My application and database can handle this code point, but Cocoon
butchers it in a way that I have seen before -- the way that
commons-lang's StringEscapeUtils.escapeXml/escapeHtml seems to do.

Instead of letting the character through as-is, it tries to convert it
into these two numbered entities:

��

Oddly enough, those are the two double-byte UTF-16 characters you'd
get, but they shouldn't be split-up like that, I don't think.

I haven't found a version of commons-lang 2.x that doesn't break these
kinds of characters. commons-lang3 does the right thing, but they are
incompatible libraries.

Does anyone know the code well enough to know how difficult it would
be to change the way Cocoon 2.1 escapes its output? For example, by
using commons-lang3?

I haven't tried Cocoon 2.2, yet, and I can't tell what dependencies it
has. I also can't exactly tell what to do now that I've downloaded the
binary package. Can this just be used as a drop-in replacement for
Cocoon 2.1.x? Cocoon 2.1.x could build a WAR file that I then
customized for my own application, adding various libraries and
configuration files to it. I think I'll follow-up with a separate post
about this.

- -chris

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZNtOBAAoJEBzwKT+lPKRYEuIP/3gSJZDNEbzsHkI5zYjMZbFf
vKvRRnBSl+6IdrcUasftf+AkXIIYwj6xnUQ7winsLW/n8TdDG6jPqsg4Khsozc6z
aa23qDly62gmCsqpLohXxt/ZNKdPY4sOTghaaEUFTtTgpeD3M/INF90myT8SwO4K
WUtqVparSqp/Zf9JMm3OCIguMKbsRNYWVIQuiJxDQJkWYwrw0iVk2v8mc6iz/mDF
w6np4EvFr9fqdDufKpPw8anEkrp5JEuTx47vMOtz4sixVr2C6ehgP4zs3kVzdVid
QPeUsrosV1tsRC9bMVLGmjo7UhNseeXCp/AceIT6AQE8Q1clgy9GcoNMf60dgGku
et0xoGptYgbCfmJL+PuA9y7fJYjgTTQheqzuC721n2/sx+kyBSBWSMIhqia2sd4y
spcT4kw+uChsWjwoeGOHOm4IimrVgXkfJeHVSXV4m66sHS9t+bDiiErwS1SikvSV
qF64/L0u8hYFLD1ehURoHBi4foE1Td3eRGOGHgodcYL9C8U+Yv+fWaiYQ5O4CCnW
pToFvVoQOdZY+VVC8hz1ggbRMSxjT2GQLLJ2mjbGzGUJjlwyQaoZnADSSu0efj88
O2AlWB2Bf/Ag6E4C9jEjj+cauBfR+1NIK7F1Jo6C02yY1SUOSoOAFDZ7EkO4qYAO
YhvgSQXNmKps6rusNjNZ
=q8Eh
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: Help needed moving from 2.1.11

[Flynn, Peter]

On 06/01/16 17:49, Mark H. Wood wrote:
> When I first looked at Cocoon 3, I thought it was more like a return
> to Cocoon's roots, clearing away a lot of stuff that had accumulated
> and concentrating on the pipeline.

I should have another look

> It's quite true that, without intense study of what documentation
> there is, it is very difficult to find any mention of how to configure
> it with XML, but the XML configurator is still in there.

Configuring it with XML would be useful (eg sitemap.xmap) but what I
meant was that Cocoon primary task was (is?) to serve XML documents via
XSLT as {text|xml|html|...}


///Peter

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: Help needed moving from 2.1.11

[Flynn, Peter]

On 06/01/16 14:18, Christopher Schultz wrote:

> Moving from Tomcat 5 on (presumably) an older Java to a newer version
> should not be difficult at all. Is there a reason to move to Tomcat 6
> and not all the way up to Tomcat 8? Tomcat 6 will be EOL very soon.[1]

Tomcat 6 is all that CentOS6 provides in their repos.
Sadly we no longer have the luxury of time to build stuff from scratch.

> If you are going to migrate, you may as well go all the way.

Maybe one day.

> My experience with a Cocoon-only deployment on Tomcat 5 moving all the
> way up to Tomcat 8 (I went version by version and wasted a whole lot of
> time doing so) was basically just drop the WAR file I already had into
> Tomcat's deployment directory and everything worked exactly as expected.
> (This included incremental upgrades from Java 1.5 to Java 1.8 as well).

Yes, dropping my existing cocoon.war file into the new machine works
fine, just it's slow and I'm sure the .war file is full of cruft we
never use.

> I have a relatively simple Cocoon deployment with only a few dozen
> matchers in my pipeline, and two or three separate sitemaps. I also have
> a custom RequestParameterModule, but of course that wouldn't be
> sensitive to a Tomcat upgrade.

We have 34 directories, many with subdirectories; 47 sitemap.xmaps in
all. And 15GB of XML text.

> My advice would be to put the latest Java and the latest Tomcat on a
> test server and drop your existing application's WAR in there and test
> everything. I think you'll be pleasantly surprised at how painless it is.

All that is done, fortunately. That part of it was never really a problem.

> As for Cocoon upgrade suggestions, others have made those already in
> this thread. Honestly, if it were me, I'd upgrade Java/Tomcat first and
> make sure everything works, and then focus on upgrading Cocoon.

If I upgrade manually to Tomcat 8 it's going to break all the directory
changes and control software setups that RH-based systems expect, which
will create work for my ops and my staff because it will be different
from all the other Tomcat servers around here. Unfortunately.

It's a pity that Cocoon has strayed so far from its original task of
serving XML via XSLT. In fact it's not at all clear to me what problem
Cocoon 3 is intended to solve. At the moment it looks more like a
development playground or sandbox for Java architects (in itself a
valuable thing; I wish there were more of them) than a production
application solving a business or social requirement. It's basically way
too much Java and nowhere near enough XML.

///Peter
-- 
Peter Flynn | Academic & Collaborative Technologies
| University College Cork IT Services | ☎ +353 21 490 2609
| ✉ pfl...@ucc.ie | 🌍 www.ucc.ie

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Help needed moving from 2.1.11

[Flynn, Peter]

...I think.

I have an existing Cocoon service running 2.1.11 under Tomcat5 and
Apache in CentOS5 on a very old server, and I now have a new server
running CentOS6, Apache2, and Tomcat6 that I want to migrate to, but I
am held up by my lack of understanding of what has been happening to
Coocon, and I'm an XML person, not a Java person :-)

The existing service is not an "application" in the normal sense: it's
just a large collection of directories under /var/www/xml, each with its
own sitemap.xmap, serving a lot of XML documents as HTML via XSLT. Many
of the documents are in fact HTML, retrieved in real time from elsewhere
in our site using Tidy in order to force xhtml or HTML5.  The cocoon.war
is the stock 2.1.11 with no mods except the substitution of saxon9.jar
so we can use XSLT2.

I would like to be able to update all this to 2.2, and eventually to
Cocoon 3.0, but the lack of a prebuilt .war file means I am at a loss as
to how to do this. The existing service simply serves XML converted with
XSLT2, nothing more: there are no requirements for authentication (it's
all public), templates, forms, or FOP (we use XSLT2 and XeLaTeX for
PDFs), and no "applications" as such. The stock 2.1.11 cocoon.war file
undoubtedly includes vast amounts of stuff we never even go near using,
but I have no idea what to exclude or include when it comes to building
a new one in 2.2 or 3.0. The block examples in the 2.2 Tutorials
*appear* to be vastly more complex than is needed for what we want to do
(although this may just be my ignorance: in fact Cocoon 1.x always did
everything we needed!).

A further requirement is obviously robust and working versions of Ant or
Maven, as in the past I have never been able to get either of these to
work on the platform available (there have always been unresolvable
dependencies for libraries simply unavailable). Has anyone ever
implemented Cocoon 2.2 or 3 on CentOS6?

I have a small budget for help with this, either for training or
consultancy or both (preferably both so that I can learn). Or do I just
pick up the current 2.1.11 cocoon.war file and drop it into the new
system and leave it alone?

///Peter
-- 
Peter Flynn | Academic & Collaborative Technologies
| University College Cork IT Services | ☎ +353 21 490 2609
| ✉ pfl...@ucc.ie | 🌍 www.ucc.ie

RE: Switching to Saxon

[Flynn, Peter]

On 22/12/10 10:16, Johan Cwiklinski wrote:
[...]
> I always use the doc-available($uri) function so I can print $uri using
> xsl:message if there is an error:

Unfortunately I'm still using XSLT 1.0 in this application because the
scripts also need to run elsewhere in an environment where XSLT2 is not
available. But that will change soon :-)

>> b. Any ambiguity in template selection (normally a recoverable warning
>> if you run Saxon from the command line) returns the "Ambiguous..."
>> message as an error. Is this configurable? (ie get Saxon to not pass an
>> error status to Cocoon, but just log a warning, and continue recoverably
>> as it does in commandline mode?).
>
> I do not know.
> When I've got ambiguity in template selection, I usually solve that in
> the XSL file ;)

Yep. Fixed now...thanks for all the help.

///Peter
<>
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: [HELP]No pipeline matched request: ejournals/pdf/endoscopy/doi/10.1055/s-0030-1255941

[Flynn, Peter]

On 26/12/10 21:17, uwe will wrote:
> Please give me help for this problem – I can not read my online papers!
>
> Thanks U Will
>
> Description:org.apache.cocoon.ResourceNotFoundException: No pipeline
> matched request: ejournals/pdf/endoscopy/doi/10.1055/s-0030-1255941
>
> *Unfortunately the URL is not available.**
> Please check your spelling. If you have clicked on a link inform your
> webmaster.
> No pipeline matched request:
> ejournals/pdf/endoscopy/doi/10.1055/s-0030-1255941*

At a wild random guess, the DOI is the literal string
"10.1055/s-0030-1255941" including the slash. This would be
exceptionally silly, and whoever allowed DOIs to contain slashes should
be forced to use a card index for the rest of their life :-)

The only way round this that I can see is to define the pipeline match
as "ejournals/pdf/*/doi/**" so that "endoscopy" can match your subject
parameter, and everything after "doi/" will be passed into a parameter
that your XSLT can examine.

But perhaps something else is going on: you have not given us any
information.

///Peter