from:"Christopher Schultz"

Greg,

On 3/31/22 12:17, Christopher Schultz wrote:

Greg,

On 3/29/22 13:41, gelo1234 wrote:

Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters: 
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc 

Hmm. Are the HTMLT / XHTMLT serializers built-in? I have disabled all 
blocks during the build, so I'm just using Cocoon core.

I tried using a view, and it's not perfect but what I ended up with is 
Cocoon dumping-out the originally-generated (from the generator) XML and 
the US flag is already broken.

So it's definitely not being broken by the convoluted pipeline.

I'll try to put together an SSCCE[1]

-chris

[1] http://sscce.org/

wt., 29 mar 2022 o 19:37 gelo1234 <mailto:gelo1...@gmail.com>> napisał(a):

    Hello Chris,

    I think you will not get any icon-type character on output without
    using proper font rendering - like Emoji support? Emoji might not be
    supported by default in Cocoon.
    So this might be the reason why you get HTML entities instead of
    Emoji-icons.
    Also notice:
    https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html
    <https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html>

    Greetings,
    Greg

    wt., 29 mar 2022 o 18:36 Christopher Schultz
    mailto:ch...@christopherschultz.net>>
    napisał(a):

    Cédric,

    On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
    sequence ?

    It's somewhat straightforward:

    https://source/ <https://source/>" />

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

Greg,

On 3/31/22 12:13, Christopher Schultz wrote:

On 3/29/22 13:37, gelo1234 wrote:

Hello Chris,

I think you will not get any icon-type character on output without 
using proper font rendering - like Emoji support? Emoji might not be 
supported by default in Cocoon.

This isn't a font-rendering issue; it's just ... wrong. Either the raw 
character should be output, or the proper set of HTML entities should be 
output. Neither is happening. It's just mojibake somewhere in the pipeline.

So this might be the reason why you get HTML entities instead of 
Emoji-icons.
Also notice: 
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html 

I read that, and was hopeful that 2.1.13 would resolve this issue, but 
it hasn't.

Hmm... strangely, the X-Cocoon-Version header still says 2.1.11. Perhaps 
I didn't upgrade properly...

Yeah, I had Cocoon 2.1.11 as a compile-time dependency which was 
dropping cocoon-2.1.11.jar into the web application along with all the 
other artifacts from the 2.1.13 build. Whoops.

I got that all fixed-up, but the behavior is still the same. I was 
pretty hopeful that was the only thing missing.

-chris

wt., 29 mar 2022 o 18:36 Christopher Schultz 
mailto:ch...@christopherschultz.net>> 
napisał(a):

    Cédric,

    On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
    sequence ?

    It's somewhat straightforward:

    https://source/ <https://source/>" />

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

Greg,

On 3/29/22 13:41, gelo1234 wrote:

Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters: 
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc 

Hmm. Are the HTMLT / XHTMLT serializers built-in? I have disabled all 
blocks during the build, so I'm just using Cocoon core.

Thanks,
-chris

wt., 29 mar 2022 o 19:37 gelo1234 <mailto:gelo1...@gmail.com>> napisał(a):

Hello Chris,

I think you will not get any icon-type character on output without
using proper font rendering - like Emoji support? Emoji might not be
supported by default in Cocoon.
So this might be the reason why you get HTML entities instead of
Emoji-icons.
Also notice:
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html
<https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html>

Greetings,
Greg

wt., 29 mar 2022 o 18:36 Christopher Schultz
mailto:ch...@christopherschultz.net>>
napisał(a):

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
sequence ?

It's somewhat straightforward:

    https://source/ <https://source/>" />

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

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

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

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

Greg,

On 3/29/22 13:37, gelo1234 wrote:

Hello Chris,

I think you will not get any icon-type character on output without using 
proper font rendering - like Emoji support? Emoji might not be supported 
by default in Cocoon.

This isn't a font-rendering issue; it's just ... wrong. Either the raw 
character should be output, or the proper set of HTML entities should be 
output. Neither is happening. It's just mojibake somewhere in the pipeline.

So this might be the reason why you get HTML entities instead of 
Emoji-icons.
Also notice: 
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html 

I read that, and was hopeful that 2.1.13 would resolve this issue, but 
it hasn't.

Hmm... strangely, the X-Cocoon-Version header still says 2.1.11. Perhaps 
I didn't upgrade properly...

Thanks,
-chris

wt., 29 mar 2022 o 18:36 Christopher Schultz 
mailto:ch...@christopherschultz.net>> 
napisał(a):

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
sequence ?

It's somewhat straightforward:

    https://source/ <https://source/>" />

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

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

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

Re: Getting UTF-16 encoding on dynamic content regardless of output content type


Cédric,

On 3/29/22 12:52, Cédric Damioli wrote:

Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version 

> of Xalan.

I'm using whatever Cocoon uses natively. For example, I don't throw-in 
Jackson or StaX or whatever other options there are.


For "markers", you may use labels on your sitemap steps associated with 
a cocoon view.


Yeah, that sound familiar.

Thanks,
-chris


Le 29/03/2022 à 18:36, Christopher Schultz a écrit :

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Christopher Schultz


Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Christopher Schultz


All,

I'm still struggling with this. I have upgraded to 2.1.13 which includes 
the fix for https://issues.apache.org/jira/browse/COCOON-2352 but I'm 
still getting that American flag converted into those 4 HTML entities:




I would expect there to be a single (multibyte) character in the output 
with no HTML entities.


I've double-checked, and the source XML contains the flag as a single 
multi-byte character, served as UTF-8.


Any ideas for how to get this working? I'm sure I could put together a 
trivial test-case.


Thanks,
-chris

On 10/30/18 12:18, Christopher Schultz wrote:

All,

Some additional information at the end.

On 10/30/18 11:58, Christopher Schultz wrote:

All,



I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultimately serializing to XHTML.



If I have a Unicode character in the XML which is outside of the
BMP, such as this one:   (that's an American flag, in case your
mail reader doesn't render it correctly), then I end up getting a
series of bytes coming from Cocoon after the transform that look
like UTF-16.



Here's what's in the XML:



Test



Just like that. The bytes in the message for the flag character
are:



f0  9f  87  ba  f0  9f  87  b8



When rendering that into XHTML, I'm getting this in the output:



Test



The American flag in Unicode reference can be found here:
https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%

B8


  You can see it broken down a bit better here for "Regional U":
http://www.fileformat.info/info/unicode/char/1f1fa/index.htm



and "Regional S":
http://www.fileformat.info/info/unicode/char/1f1f8/index.htm



What's happening is that some component in Cocoon has decided to
generate HTML entities instead of just emitting the character.
That's okay IMO. But what it does doesn't make sense for a UTF-8
output encodin g.



The first two entities "" are the decimal numbers
that represent the UTF-16 character for that "Regional Indicator
Symbol Letter U" and they are correct... for UTF-16. If I change
the output encoding from UTF-8 to UTF0-16, then the browser will
render these correctly. Using UTF-8, they show as four of those
ugly [?] characters on the screen.



I had originally just decided to throw up my hands and use UTF-16
encoding even though it's dumb. But it seems that MSIE cannot be
convinced to use UTF-16 no matter what, and I must continue to
support MSIE. :(



So it's back to UTF-8 for me.



How can I get Cocoon to output that character (or "those
characters") correctly?



It needs to be one of the following:



 (HTML decimal entities)
 (HTML hex entities) f0  9f  87  ba
f0  9f  87  b8 (raw UTF-8 bytes)



Does anyone know how/where this conversion is being performed ion
Cocoon? Probably in a XHTML serializer (I'm using
org.apache.cocoon.serialization.XMLSerializer). I'm using
mime-type "text/html" and UTF-8 in my sitemap
for that serializer (the one named "xhtml"). I believe I've mads
very few changes from the default, if any.



I haven't yet figured out how to get from what Java sees (\uE50C
for the "S" for example) to , but knowing where the code
is that is making that decision would be very helpful.



Any ideas?



-chris


I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.

Here's the loop and the output:

 try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
 char[] chars = new char[10];

 int count = in.read(chars);

 for(int i=0; i

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

Re: using cocoon 2.1 in the long-term, security concerns

2021-07-19 Thread Christopher Schultz


Vincent,

On 7/19/21 08:03, Vincent Neyt wrote:

Hi Cocoon users,

I'd like to ask your opinion on the long-term security risks of running 
Cocoon on a server. The colleague responsible for the servers at my 
university is inquiring if the software I'm using for my website is up 
to date and is concerned that I'm using outdated software that could in 
the future pose a security risk.


I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 
without many problems. But I'm concerned about the long-term, and 
wondering if it would perhaps be better to reprogram the website I've 
been working on for 10 years into eXist DB (which would be a huge time 
investment). I like cocoon very much and would love to continue using it 
if it's possible.


I'm curious to hear your thoughts about using Cocoon 2.1 for the long 
term: will it still work well inside future versions of servlet 
containers like Tomcat? What about the java dependencies? And will 
cocoon 2.1 continue to put out updates when security risks are identified?


I, like you, have been running Cocoon 2.1.x for years and would like to 
continue to rely on it for some important functions at $work.


I don't see any reason it wouldn't run on current and future Tomcat 
versions. There are a few "current" versions of Tomcat, and the only one 
I would expect to have some issues would be the Tomcat 10.x series, 
which implement the "Jakarta EE" specifications instead of the "Java EE" 
specifications. For the most part, these specifications are simply 
package-renamed versions of the original Java EE specs. So, for example, 
javax.servlet.whatever becomes jakarta.servlet.whatever and so on.


Tomcat has a migration tool which can migrate a binary web application 
(e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if 
that tool works on a webapp which is Cocoon itself and/or 
Cocoon-bundled-with-your-application.


I'm a Tomcat committer and if there are any problems, we could work 
together to make sure Cocoon has plenty of life left in it.


With the semi-recent release of Cocoon 2.2, are there members of the 
community who would be interested in converting the project into a 
Jakarta EE-based project? There is no particular rush, and most of the 
conversion can be done essentially with a single sed script. But working 
that into the build process so you can say "build me a Java EE-based 
Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really 
beneficial moving into the future.


[As a Cocoon user, I'd love to know what is necessary to upgrade from 
Cocoon 2.1 to 2.2. We have an ant-based build process for our 
application which starts with a pre-built cocoon.war and customizes it 
with everything we need. So if e.g. Maven can build Cocoon into a WAR 
file, I might be all set.]


-chris

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

Re: Cocoon 2.1.11 problem with JDK release versions above 255

2021-06-30 Thread Christopher Schultz


Vincent,

On 6/30/21 11:24, Vincent Neyt wrote:

Hi all,

thank you very much for all your reactions. I just found time to try 
Nico Verwer's suggestion, and that worked perfectly! It seems it was the 
very old version of icu4j.jar that caused the problem. As Nico suggested 
I exchanged it for icu4j-69.1.jar in the lib directory, and was able to 
start up cocoon without errors.


Glad you got things working.

I just wanted to reply to say that I'm running Tomcat Cocoon 2.1.11 on 
8.5.x on Java 8 and I have no issues.


openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

Hope that helps somewhat,
-chris

On Wed, Jun 30, 2021 at 5:20 PM Cédric Damioli 
mailto:cedric.dami...@ametys.org>> wrote:


Hi Vincent,

Do you have any stack trace to help finding the actual issue ?

I know there's a similar issue with the ICU library. Do you use it,
and if so in which version ?

Regards,
Cédric


Le 30/06/2021 à 17:11, Francesco Chicchiriccò a écrit :

On 28/06/21 09:48, Vincent Neyt wrote:

Hi list,

I did a stupid thing, I posted to the user list without first
subscribing, so I'm sending my query again now that I am
subscribed to the list. Sorry for the inconvenience!

Since 2011 I've been using a build of Cocoon 2.1.11 (inside
Tomcat 8) as the publishing framework for my website. I've
recently found out that Cocoon fails to start up when the
installed java version has an update number higher than 255.
Things start up properly with Java SE Development Kit 8u255 and
lower, but fail to start up with Java SE Development Kit 8u256
and higher (for instance the current Java SE Development Kit 8u291).

The error I get is

Initialization Problem: Scheduler with name 'Cocoon' already exists.

but it has cost me blood sweat and tears to find out that the
underlying cause is the Java update version number.

Is there a line in a file in my Cocoon 2.1.11 build that I could
change to get rid of this error?


Hi Vincent,
I am afraid I cannot be of much help here, not using Cocoon 2.1
since quite some time.

Anyway, did you find anything more than just the line reported
above? Any stacktrace?

Regards.



-- 


 



Cédric Damioli

Directeur associé

+33 (0)5 62 19 19 07 / +33 (0)6 87 03 61 63 | +33 (0)5 61 75 84 12
cedric.dami...@ametys.org 
40 Rue du Village d'entreprises 31670 Labège
Inscrivez-vous à notre newsletter






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

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2018-10-30 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Some additional information at the end.

On 10/30/18 11:58, Christopher Schultz wrote:
> All,
> 
> I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
> a servlet generating XML in UTF-8 encoding and I have a pipeline
> with a few transforms in it, ultimately serializing to XHTML.
> 
> If I have a Unicode character in the XML which is outside of the
> BMP, such as this one:   (that's an American flag, in case your
> mail reader doesn't render it correctly), then I end up getting a
> series of bytes coming from Cocoon after the transform that look
> like UTF-16.
> 
> Here's what's in the XML:
> 
> Test
> 
> Just like that. The bytes in the message for the flag character
> are:
> 
> f0  9f  87  ba  f0  9f  87  b8
> 
> When rendering that into XHTML, I'm getting this in the output:
> 
> Test
> 
> The American flag in Unicode reference can be found here: 
> https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%
B8
>
>  You can see it broken down a bit better here for "Regional U": 
> http://www.fileformat.info/info/unicode/char/1f1fa/index.htm
> 
> and "Regional S": 
> http://www.fileformat.info/info/unicode/char/1f1f8/index.htm
> 
> What's happening is that some component in Cocoon has decided to 
> generate HTML entities instead of just emitting the character.
> That's okay IMO. But what it does doesn't make sense for a UTF-8
> output encodin g.
> 
> The first two entities "" are the decimal numbers
> that represent the UTF-16 character for that "Regional Indicator
> Symbol Letter U" and they are correct... for UTF-16. If I change
> the output encoding from UTF-8 to UTF0-16, then the browser will
> render these correctly. Using UTF-8, they show as four of those
> ugly [?] characters on the screen.
> 
> I had originally just decided to throw up my hands and use UTF-16 
> encoding even though it's dumb. But it seems that MSIE cannot be 
> convinced to use UTF-16 no matter what, and I must continue to
> support MSIE. :(
> 
> So it's back to UTF-8 for me.
> 
> How can I get Cocoon to output that character (or "those
> characters") correctly?
> 
> It needs to be one of the following:
> 
>  (HTML decimal entities) 
>  (HTML hex entities) f0  9f  87  ba
> f0  9f  87  b8 (raw UTF-8 bytes)
> 
> Does anyone know how/where this conversion is being performed ion 
> Cocoon? Probably in a XHTML serializer (I'm using 
> org.apache.cocoon.serialization.XMLSerializer). I'm using
> mime-type "text/html" and UTF-8 in my sitemap
> for that serializer (the one named "xhtml"). I believe I've mads
> very few changes from the default, if any.
> 
> I haven't yet figured out how to get from what Java sees (\uE50C
> for the "S" for example) to , but knowing where the code
> is that is making that decision would be very helpful.
> 
> Any ideas?
> 
> -chris

I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.

Here's the loop and the output:

try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
char[] chars = new char[10];

int count = in.read(chars);

for(int i=0; ihttps://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvYhDgACgkQHPApP6U8
pFjPZRAAs9jgubhuIVMs52AmAEPXqVSuG8Y18t7RP7W2F5XouZ69SXqihUKmYODM
tQnOlyGghfUnXAkQ3uVNLjbx+dSKGwpuQbkb8987Po6AgzweL9stmqzowdn4Zcam
ow7aZSp8gmxa31YHbb7pphGPnjzVqr84Mz9MCCCcSMg/1ZkvayarJTWhYkBgeWip
wdxbR2nP7wYNLkEy+v4hLvIcWYI8IeuA2nWb5qNvb6zFVYkPLZZGhdOm19J06cHR
Rvxb83g+8X80ngP6Uztbg0p4/qa7vfJXlM46iCEqOM/7+eE0gMwOGk7Akbt+2Utd
sSNUChUPzgeRZkzSAbOZcnDhGLXCWodEM75GL1nDJED1N+gWtJwRDb4kfLdY337R
ghiVB9yupjFZFhho2BArWl58hx8WrQ9Lawsrn/OFOTjea9A+3/k9QYYCpMObpwJ9
rhTA1bQV9rQbbPC2CG1iajAlb5Moe7tWF1AmhJsqFXKPjMGiIwBlOKRAgcaIZxbr
rJRI4SKDkbIlCTWKOqe4cT/HgDQ/O9mBynZ353EcmSrr4Oye8k91e8SRjUh3UdLh
XfRnMcEKEwJfIzv+JZgJQK8kwERM4mxLrf3tdhvo9IUwN44Z5QKjZjQHbkYQaIT/
m58tqqNmApzH3gyWeyd6F7HqeTO8wlaRMCipBVX6/SW1Qop2Qno=
=YXAW
-END PGP SIGNATURE-

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

Getting UTF-16 encoding on dynamic content regardless of output content type

2018-10-30 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have a
servlet generating XML in UTF-8 encoding and I have a pipeline with a
few transforms in it, ultimately serializing to XHTML.

If I have a Unicode character in the XML which is outside of the BMP,
such as this one:   (that's an American flag, in case your mail
reader doesn't render it correctly), then I end up getting a series of
bytes coming from Cocoon after the transform that look like UTF-16.

Here's what's in the XML:

Test

Just like that. The bytes in the message for the flag character are:

f0  9f  87  ba  f0  9f  87  b8

When rendering that into XHTML, I'm getting this in the output:

Test

The American flag in Unicode reference can be found here:
https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%B8

You can see it broken down a bit better here for "Regional U":
http://www.fileformat.info/info/unicode/char/1f1fa/index.htm

and "Regional S":
http://www.fileformat.info/info/unicode/char/1f1f8/index.htm

What's happening is that some component in Cocoon has decided to
generate HTML entities instead of just emitting the character. That's
okay IMO. But what it does doesn't make sense for a UTF-8 output encodin
g.

The first two entities "" are the decimal numbers that
represent the UTF-16 character for that "Regional Indicator Symbol
Letter U" and they are correct... for UTF-16. If I change the output
encoding from UTF-8 to UTF0-16, then the browser will render these
correctly. Using UTF-8, they show as four of those ugly [?] characters
on the screen.

I had originally just decided to throw up my hands and use UTF-16
encoding even though it's dumb. But it seems that MSIE cannot be
convinced to use UTF-16 no matter what, and I must continue to support
MSIE. :(

So it's back to UTF-8 for me.

How can I get Cocoon to output that character (or "those characters")
correctly?

It needs to be one of the following:

 (HTML decimal entities)
 (HTML hex entities)
f0  9f  87  ba  f0  9f  87  b8 (raw UTF-8 bytes)

Does anyone know how/where this conversion is being performed ion
Cocoon? Probably in a XHTML serializer (I'm using
org.apache.cocoon.serialization.XMLSerializer). I'm using mime-type
"text/html" and UTF-8 in my sitemap for that
serializer (the one named "xhtml"). I believe I've mads very few
changes from the default, if any.

I haven't yet figured out how to get from what Java sees (\uE50C for
the "S" for example) to , but knowing where the code is that
is making that decision would be very helpful.

Any ideas?

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvYf7cACgkQHPApP6U8
pFhSdg/+NFO0iHGiACYgLyOJoZBay3XTDLptbynh/nTk+RHua7kLoYx4OFE9kLSu
Kf5psWFNrhsr3aRiJ7zmhqronlwG8M2WP8cqSAC8HlYmxTy9eJmrVfGQMLmH4OWB
KaNmRoDW3TCTTQYTkVHFSVv1GxfZVwO1bZrILPgIRgflVNzuERqYCmrdkxRK1z3i
Qau8WKQ/sKBmIAOhlrXALCkU5yfhn6zQpD5A8mmqUZHJACxvyOFhlT+jrqrlWx47
pVmtyyXZxAMc2KqrG9jlY5fG+Jzv3FAyTuCZzZWmgPEGbrdeZdlJi5IlYI6Sm4zZ
nk5d1153wB4+y/JfU/wR4rn22XfbKpS4I1j03vfuGO/WNa1a+WEZ70M3yd6LYveK
JDX6MDFIRt+PvGcC3pxq08iBpzmTaGfaYJU9JY3Ywii51CmzCSxHNjB48NEIYS9C
KTehmgio2MVIVh2mu3p6NV4RoVF81LSiJk+q3OpsKnTAjC85WtuSO/ntLiZwFK2R
USrtpE/nZdF4fZqgSnTJMml7ogc91upcHG8HB3oz1rS256SjhH48ug1XcDAEinEK
cvwonUEKsM33l0apKdk0RdcdQXmWZJVxcOtxphzDYHW9VvaDhNp3yVDAJt+hnlgO
8Pps5av4iyW7KffHFFQf3xPEaYhZYYDniVZTSIFSDAg4OHrBJ/4=
=bW4T
-END PGP SIGNATURE-

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

Replacable parameters in HTML in I18nTransformer

2018-05-16 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm using the i18n transformer to localize my XSLTs.

I have a somewhat odd use-case where I'd like to have some (final)
text that looks like this:

Please click here to do something interesting.

The url in the link needs to have some parameters added to it by the
template (it's not static), so I've done this:


  
  
  


In my catalogue, I have:

  Please click here to do something
interesting.

The URL in the resulting output has literal {0} and {1} text in it. Is
there a way to get the i18n transformer to replace parameters within
markup in the message values? This works fine when the {0}, etc. are
outside of markup. Do I have any better options than splitting-up the
message into pieces and gluing them together? That's terribly awkward...

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr82BoACgkQHPApP6U8
pFgXOA//QYR5daF16Y4aYqGMkmqlCexvkXIu9YkLThpnYXzepekLjUg7VGk8o0r1
UF6c8keBTBd35KXXNdOfwr5PDkPTSfgfAEk1oe4ZaxMQo+w325eDa2zebfycHUKt
G0n8DUx0K4Vwdmd9U3ZKB+9tym/pEEkv/ZfPdYcsqPIygfBj/KViKxItOGWLJ5RL
OuKge9Oo5Lyt6sLjGQ/0px6UK28LBKHxLyew6BH21156IvLput+owQ/4xHKmLLCO
IvxgL8zVTAFk9VCth+76mUPyeGOKngvsgQAXQLcckTnySoMoGIKuD8uWtDdJVSfX
tyJqUksNbIT3gUr3DscMb//YDmAihHaMsyHnU4ZCfe90C/4PrX2gLCs4iaVDLpVc
6O70/SjnIezfoRo3jz9hr5TdniFphWViRI9Ea/LrlgFCPUv2Bc/BYD0/gbY+Aay0
E+CTWDjGi1SdSp/gCPj8wLsG1rQTw31D87SppffFDDDTnfcFgZKGLpPtKu8quzQJ
7VmtcG4SGtDICNd2cqUe6APnXSoM1JyrDJjLNTBgyAVB6d7kRzgzPW09/YbDqOA9
zJxmUm7wv1xe6iirrNZ/qpOMp2JIm0YlJFFmCrsVYbOUBCKwD7EpyhdhMyxH40xh
6a/tbCqo07cGIOC8ykOcPeqyJx2mjbqmo1Y/Iu/oYDWnDXrbdh0=
=+f/W
-END PGP SIGNATURE-

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

Re: Trouble switching locales with i18ntransformer

2018-01-11 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cédric,

On 1/9/18 2:39 PM, Cédric Damioli wrote:
> Just in case, did you try to hardcode the "es" value :
> 
>   /> 

I just tried this, and it appears to work as expected: I get the
strings being loaded from bundle_es.xml.

That got me to reviewing a few things and I think this was a simple,
boneheaded syntax error on my part:

This:

  


should have been this:


  


Two changes:

1. Variable references do not have a $ prefix
2. Global variable references need the "global"

After fixing those two issues, I'm getting the expected text in the
expected language.

Apologies for the noise, and thanks for the help!

Thanks,
- -chris

> Le 09/01/2018 à 17:34, Christopher Schultz a écrit : All,
> 
> I have an I18NTranformer configured and  elements in my 
> stylesheets and everything is working for the default locale. But 
> changing locales doesn't seem to be working for me. I think I must
> be missing something.
> 
> I'm using Cocoon 2.1.11.
> 
> Here's what I have:
> 
> sitemap.xmap:
> 
>...>   location="/path/to/dir" />  location="/path/to/dir" />   ... 
> 
> 
>
> en ...  
> 
> 
>   ...  
>  
>  ...   
> 
> 
> I have 3 files in /path/to/files:
> 
> common.xml [xml:lang="en"] summary.xml[xml:lang="en"] 
> summary_es.xml [xml:lang="es"]
> 
> This works as expected with en is set
> in the global-variables section.
> 
> I was expecting that changing  to:
> 
> es
> 
> And then restarting Cocoon would end up using the text from my 
> summary_es.xml file, but it's still showing the English text from 
> summary.xml.
> 
> Replacing summary.xml with summary_es.xml works of course (i.e.
> the text from summary_es.xml is now showing in my rendered pages).
> 
> The client (browser) is advertising a preference for lang=en, but
> that shouldn't matter because I'm invoking the i18n transform
> specifically with locale="en", right? I even changed by browser's
> preferred language from English to Spanish and nothing changed.
> 
> I'd prefer to be able to change the locale by setting the 
>  global variable and not doing anything else. What am
> I missing, here?
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
>> For additional commands, e-mail: users-h...@cocoon.apache.org
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpXlGIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiB0BAAkrdBkLQc4zy+D0Db
dRDpB6Tt2umhRR5T6fidWhWsY661IEV9GNWl1WdbYGW2OuozVwik8nOJBsFvmbTa
y+eejwWjzxRPqjwM+Lon9/6LVWgOWkHRTXrqwyxRD/6XfiXq73G5lc1e2xeFZICA
c3hmgHS98Ett1iX+pmMR+EDlW73dRR7SPFDk477v69E5JG4tnUamArlzLBURl5yA
OWkmY73wdLD2DQksb2ldHvTVM93b4K9PAz+7Y0Ch2zRBrIGzXsBzJ6YWHysEsdr0
IQNfUGwrj7BV8QmNwJx+rfSnJ5OSfaVM/+K3MAhyu8OPA1LouEos3L8D7KZnUpY5
mqN1/2XH8SotRsYrtnLF5dlongSGDtP+h/4PXyPevaBaPSQBlMLnET8COps3rR0E
lo4w6++Wtguv03rgt8KTegGtPq+RKOwvS12DKjx8ZMeEJipOYe1P/BwP90Xeq6J9
4ZqAqRIdGJd5SfVZfmnO+5Xa0X2q3spayHpVMnR2qHXsUEltDqvXdzuXUU2xTtln
FP6pC1c47lmWXSrwwZE8CXYfPpr2wvSdXFAlQ/a053kEi0QgPiO/pHU331cThBqE
pmxKtaj1xX1jIbKWfBu/0Y5Mgg1AJPbD5SxAWYweWNQ59qsXl986xnzuF83cUQJA
heZprqscW2yAz45/G8uRJkSwY6o=
=NJLR
-END PGP SIGNATURE-

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

Re: Trouble switching locales with i18ntransformer

2018-01-09 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 1/9/18 11:34 AM, Christopher Schultz wrote:
> All,
> 
> I have an I18NTranformer configured and  elements in my 
> stylesheets and everything is working for the default locale. But 
> changing locales doesn't seem to be working for me. I think I must
> be missing something.
> 
> I'm using Cocoon 2.1.11.
> 
> Here's what I have:
> 
> sitemap.xmap:
> 
>...>   location="/path/to/dir" />  location="/path/to/dir" />   ... 
> 
> 
>
> en ...  
> 
> 
>   ...  
>  
>  ...   
> 
> 
> I have 3 files in /path/to/files:
> 
> common.xml [xml:lang="en"] summary.xml[xml:lang="en"] 
> summary_es.xml [xml:lang="es"]
> 
> This works as expected with en is set
> in the global-variables section.
> 
> I was expecting that changing  to:
> 
> es
> 
> And then restarting Cocoon would end up using the text from my 
> summary_es.xml file, but it's still showing the English text from 
> summary.xml.
> 
> Replacing summary.xml with summary_es.xml works of course (i.e.
> the text from summary_es.xml is now showing in my rendered pages).
> 
> The client (browser) is advertising a preference for lang=en, but
> that shouldn't matter because I'm invoking the i18n transform
> specifically with locale="en", right? I even changed by browser's
> preferred language from English to Spanish and nothing changed.
> 
> I'd prefer to be able to change the locale by setting the 
>  global variable and not doing anything else. What am
> I missing, here?

Another data point:

I decided to remove the "default" locale, like this:

$ cd /path/to/dir
$ mv summary.xml summary_en.xml
$ mv common.xml common_en.xml
$ ls
common_en.xml   summary_en.xmlsummary_es.xml

[i18n-locale in sitemap is still set to "es" (Spanish)]
[bounce Cocoon, reload page]

Now, the page shows "untranslated" (which is my 
value) for everything.

So it seems that Cocoon is not picking-up my non-default localized
files at all; it's only using [catalogue.xml] and not the
locale-specific ones.

Any suggestions?

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpU89UdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgyOA//cEGu5N7AudHdNSV9
L6pvhBRjoHcWtukUmnNqv7F57fztelEj7eI3WRNeBFbV8f5xS2sJZd/dJI28eGzR
6VHXJwHXQWv5RT4KKAEhw/esI2CduncwMrpf+ZZvD5YiA4qYT/Jqnte/ove4O/6s
hbZJ6a+qvaedVVOMNVCUrrNcgslJHcMAXzzZYtDU9r4EMKgn7ZOWM1uFmBYliSlT
k80KZS+0czjZ/0VzWGATAXX7z7lqAL5DLwX+A8aReCDl4rWAtR21Gl4nUKX2Gfc0
mwQX0SFp4Uh0vBtmjIUezK0S4adCFG/d5vzVCA5goHaJxkctNkqt6VEWuge2MbTK
0INeVpfql6g8bKA3kKxTIqioUwbbcPKxtv1RrjCUqTPSJqY/I6HHhDnNJHvodmmJ
p+7pp0kLqoTwWC0uahuzqwN95HwHfnknjcCcTrmisJ3mK9hNV66owRVfyb9EI342
PGHCCimpTXfENGsw+biI+bpo08XQHEohiylSKfsnMRUYU75EhZjtedy0PXKpv6mF
wWzmfCL2y1DKrZPUB7ukL7JZ7M5CqETa2x2adolwu/oT+xeDY5QfBzNFy144OsEP
0tLH9JpVuQWQH2Fk6+Dw/71Z4fQqiU6vP/L5bLc2qVmkgKl1udNPsJ/Ffb6nAZEU
BsUkDSw/nRgRbDpBtc6T2Lo+VM0=
=7YqD
-END PGP SIGNATURE-

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

Trouble switching locales with i18ntransformer

2018-01-09 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I have an I18NTranformer configured and  elements in my
stylesheets and everything is working for the default locale. But
changing locales doesn't seem to be working for me. I think I must be
missing something.

I'm using Cocoon 2.1.11.

Here's what I have:

sitemap.xmap:


  

  


  

 ...
  

  

  
en
...
  


  

  ...
  

  
  ...

  


I have 3 files in /path/to/files:

common.xml [xml:lang="en"]
summary.xml[xml:lang="en"]
summary_es.xml [xml:lang="es"]

This works as expected with en is set in
the global-variables section.

I was expecting that changing  to:

  es

And then restarting Cocoon would end up using the text from my
summary_es.xml file, but it's still showing the English text from
summary.xml.

Replacing summary.xml with summary_es.xml works of course (i.e. the
text from summary_es.xml is now showing in my rendered pages).

The client (browser) is advertising a preference for lang=en, but that
shouldn't matter because I'm invoking the i18n transform specifically
with locale="en", right? I even changed by browser's preferred
language from English to Spanish and nothing changed.

I'd prefer to be able to change the locale by setting the
 global variable and not doing anything else. What am I
missing, here?

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpU7yMdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiDLQ/6A0SqCs/ava78tK53
CSvMZqpY4xfKXu3GQqS+7DK0wxi4pOcnsNtRxhaQHmPVPvtPKv6H0+fzGIMkRpGn
lJRcXzSFAa4zkWcQ2zDPh+FatROftroTRK+TljVIrmYJG4BNFbuH1PlNgpj3dPOC
bpuKhTNAC8lz7Pdu9JbTiy3mCSXihv18S/wcJ52g69Uh8oa5Vo1o6nHDO1hEe1zt
ejBDVQd5pytmFomWrYm2BR0/OG3mjUY+9uyI3Ys1K8uuFDFxtT6u0Ew0RtpYP9T3
UdWCvcR1ixmVNQ9Xwxtk8Cf0n0eoYdffdj+LK3h7WdCF/eJCkRkxTzrB2KmFnaiq
BwHJmXs1u0V5If9POEBsP+GjhdwCtdV2up16yb6f2Mw6X0/fsQvmmVA9eQUk7/EH
s94qvOkjeozTZVGd8Hovw9GXYze9MMHOp4lVz5H93e0Psjy8BBIOfSyxQEtPx9A9
xh/POW1BOKDUw1O2/x8f21yHwlOcwfIrkQKRvp9cAFQMWtAsJ7QJVqUX5jdtIsrO
H/tBO0+qO7HNfxllyHeSVbx+nPkHEXceijUZfhG+Nakmi/GfgMgtangrKbfSflEU
vl+qRHbHYdBphrIrWRy6huyOQojV4RAxp8WcV8+M9NrtItFIUeDuCnJumH51Fm1Y
oubhYj1xaPRowGIlWmrAD3tlEIo=
=NoLl
-END PGP SIGNATURE-

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

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

2017-06-20 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg,

On 6/20/17 4:11 PM, Christopher Schultz wrote:
> Greg,
> 
> On 6/8/17 2:17 PM, gelo1234 wrote:
>> Chris,
> 
>> Even with C3 (cocoon 3.0 beta) unless you specify optional
>> encoding in your Serializer config, you fallback to default
>> UTF-8:
> 
>> org.apache.cocoon.optional.servlet.components.sax.serializers.util
>
>>  public class ConfigurationUtils {
> 
>> private ConfigurationUtils() { }
> 
>> public static String getEncoding(Map<String, ? extends Object> 
>> configuration) { String encoding = (String) 
>> configuration.get("encoding");
> 
>> if (encoding == null || "".equals(encoding)) { encoding =
>> "UTF-8"; }
> 
>> return encoding; } ...
> 
> I would have expected the Unicode codepoint to be converted into a 
> single 4-byte UTF-8 byte without any &-encoding at all. It looks
> like what I got was a pair of 2-byte characters with &-encoding.
> 
> I'll try UTF-16 but my expectation is that it's going to get
> worse, not better.

Interestingly enough, my emojis are now showing (which I don't totally
understand why!) but it looks like my CSS aren't being loaded. That's
a separate problem I'll have to figure out for myself.

In my own application, switching from commons-lang to commans-lang3
HTML/XML escaping allowed me to use these 4-byte emojis and UTF-8
together. I'm surprised that Cocoon can't do the same thing. (I think
it comes down to exactly how the character-escaper makes its decisions).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJgiwACgkQHPApP6U8
pFgJkRAAqiXn7DWNDN41m1V98aI5xWjTuoka0tKcadN1IUGemTZwipaXHtYQcois
6yuI3st31ZuanghIpRPcBu9pZzuHtOSBVSHZSIhDGqPwYgczScQ2LgnfMi6zwAdd
j2LFlSWtKGjgCczV5Ok56PyMq1BEAOVw96vmF5xfXmpLAyNA/PvLKsncoW4pN+ES
1MQMm1aPwbmEpWz7ykReUzfauwBtL4rEX1wO3pl88m9Wq3x174AKHWs/a+4Z1Hdq
0CnxfrdTK50p7Ng+ECfnPwx8y1Em64lA7KKMuz2jTd0PnxlpZTAgO6lq8S7BdSeY
H1lwBJojVT/+m2w8b9OC/XoyiAyiC/zIswQ3TSMA3ZC2SnCxxAXMTsmT49Ql+lyq
01JRCIVMitKeoKI4I4066oaBW91FpSSpZXX14XCHrMBtKnIJI+NxBnI++eQq8wdi
ZdX3GzLF2zaPHvZMSz4DRskR1xKGLsAxZAukINW3AGrEAZ/GwbPd76ml3YJam5Yy
R31u0kcRJl4z79pd1n46yxB66V10Rn5IkSMQ8R7uK/ht9wLi5T8bkeAoLjZFFoyq
awmfQTbJzquXAtwjX99WKWEzviN2ph+P0h2rBInHnos5ud8IlLjcS7FmdxQ4DNOw
Nirmj7cikxcr2Fn22pGQh6o3/Eph0lMf1d1HjUZ1C7SchEgsqrk=
=0nTd
-END PGP SIGNATURE-

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

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

2017-06-20 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg,

On 6/8/17 2:17 PM, gelo1234 wrote:
> Chris,
> 
> Even with C3 (cocoon 3.0 beta) unless you specify optional encoding
> in your Serializer config, you fallback to default UTF-8:
> 
> org.apache.cocoon.optional.servlet.components.sax.serializers.util
> 
> public class ConfigurationUtils {
> 
> private ConfigurationUtils() { }
> 
> public static String getEncoding(Map 
> configuration) { String encoding = (String)
> configuration.get("encoding");
> 
> if (encoding == null || "".equals(encoding)) { encoding = "UTF-8"; 
> }
> 
> return encoding; } ...

I would have expected the Unicode codepoint to be converted into a
single 4-byte UTF-8 byte without any &-encoding at all. It looks like
what I got was a pair of 2-byte characters with &-encoding.

I'll try UTF-16 but my expectation is that it's going to get worse,
not better.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJgYoACgkQHPApP6U8
pFjKCg//UXuln4vSZ4bw32OVWRlsLnfm9RcOjiuDb+DqKjfTTqdIY1kdLyZQK+o4
Y8n12ct3sHQRdsViULtm9dhOClF+6qBXFgbjKO9ya6v4WvWeC4NOh0HK+nFlmvqA
1fNjTuc4orDgDl5npt+6Co8LprToPKBJlF7Vq+dvgLbiYJHh4lTrgAQuyY7YCXoC
BUJAieW/ntPficv6q/Tm0g32N/pBnLYArJd3ncwxIZyEYt4jX6tMsPZNwqaY2HrE
+D1nc5jTfMnx7B9WH3W5MMw0t4VxiwE2KbK88oHSUf6IV/Nok/5EfMNefQSZr71Z
gtxvFRld8Lim/YYMgFieAHXFP5axE81Bk7Z76lj9jOK7YcOMFUPYST63JVv0uVUZ
urIEwf5FBEiW/264YTESUfOuPWsbuQQ9x23FRFKh2HiZJmN0afp7uJrkLK55XCT/
OAn6h9wcAtch4idney8BWkLfMOtdHTTaY5PzZRc1EpWDZk4jYYyD+2sdjnHD21Ka
CmwKkwnA9WDTJ5owD6n5lIZpYaPBGqFRaCcwWYQtERUA7ZrmBvI7GbuSvfLA3CDp
H0nO97fOd2s+IXlxno73V9B7Kvj56CKxP2O5OoXgQHl6b2J+z9ZZ16l83beEblNS
5HWxQSvFw2FjLqhSSQOOsLvkIjWLL/tpBSWq4XEH1iVxViFGJvk=
=KIbJ
-END PGP SIGNATURE-

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

[2.1] Overzealous escaping of high Unicode code points

2017-06-06 Thread Christopher Schultz

-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: Handling errors retrieving a for

2016-08-21 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Javier

On 6/1/16 3:19 PM, Javier Puerto wrote:
> Hi Christopher,
> 
> I more used to version 2.2 but it should be the same. By you
> description I think about creating a new pipeline with a matcher to
> handle the external request with a specific error handler[1] that
> contains a reader with an empty file.
> 
> It should be something like:
> 
> 
> 
>   src="http://remote-server/{1}"/> 
> 
>   
> 
> 
> 
> 
> Then you could substitute all your calls to external resources
> that needs to produce an empty XML in case of error to call to the
> new matcher. This way you can tune up the external pipeline for
> caching if it's needed.

I tried:


  

  
  



  
  

  


When I get a "no route to host" error from the unavailable-resource, I
get the standard Cocoon error page with a stack trace. I would have
expected the  from the unavailable resource to simply
provide no content to aggregate with the other sources.

Do I need a more complicated handle-errors section? All of the
examples in the docs have a  in them to check the
exception type.

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

iQIcBAEBCAAGBQJXudkCAAoJEBzwKT+lPKRY5NIP/2j5npsvm4VZEXDkCPYDrZCv
Zk8mfShffDkf0Xh1lOUnbXiwezv3YkQIq7gRa1rhWnR69lriAJQku1vsSsnagADH
Re4BzJXxWhJ8a+x7Hv8Ibhvjzl53qxxVl9U/cop8R4u9tQAH4aVWPaLUrkxtnFGh
0G+MEnOr8x62NG1RHSVuhNfXgFTxVaXDkxcS3w47Vq/Ts+ulU7Hm0XXfPUJB5XG/
/sREax46fY0/9Qweb82QbG5CHaI22Uv/xnxq4t+HHA1I3DJtZDpiHHcueF02Hn5R
LtRq4gDvYqAriGSy31W+roNCT+ItT2yThQ9EdcRg4Dc2meN/0s7jTdbIhF1YU2ut
GjfW1504z5GoPYO1kaS5pSFH5zIaOaKUp3SYCHrkCAhEY5u5u10NIqleHUnj8g6z
latO8gp26UgdlBMZwaVXc2TOIX3BbKhZTveEjwc9wCd1EyrrryoLr6xT5hKUctaf
u1oGOaQcgHVNAskztwDNAYzyeep+lRAIPPGQ1irhXrPA66nOuyHW6+I4EBiboQ8J
RUi0djAUZg/srOxpWvC5ww+FyGleH+a0bJe3qz6BhSPVqy+VddjUl4SnqeT+1m6t
yU/K+q8i3TPGHGDJwDQeGqkesB5e3okT9UJuj2SqOMOQ7yHe0aR0JOepP4Y9oNuI
sTgQuM/AzAsTpO60ML1v
=ewdz
-END PGP SIGNATURE-

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

Re: Handling errors retrieving a for

2016-06-02 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Javier,

On 6/1/16 3:19 PM, Javier Puerto wrote:
> I more used to version 2.2 but it should be the same. By you
> description I think about creating a new pipeline with a matcher to
> handle the external request with a specific error handler[1] that
> contains a reader with an empty file.
> 
> It should be something like:
> 
> 
> 
>   src="http://remote-server/{1}"/> 
> 
>   
> 
> 
> 
> 
> Then you could substitute all your calls to external resources
> that needs to produce an empty XML in case of error to call to the
> new matcher. This way you can tune up the external pipeline for
> caching if it's needed.
> 
> I hope it helps.

Thanks.

How can I reference a matcher from a different pipeline? Do I need to
address it any differently than I would if the matcher were in the
same pipeline?

Speaking of caching, I'd prefer for the "remote-handler" matcher to
re-try pretty regularly. Do matchers cache at all under normal
circumstances? I've never bothered attempting to configure any caching
in Cocoon before.

Thanks,
- -chris

> 2016-06-01 19:56 GMT+02:00 Christopher Schultz 
> <ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>:
> 
> All,
> 
> Using Cocoon 2.1, I've got an aggregate generator like this:
> 
>   
>   src="http://remote-server/baz.xml; />  ... 
> 
> 
> There are times when "remote-server" is not available and I'd like
> to basically include nothing at that location within the aggregate
> document .
> 
> Can I do that within the  or  elements, or
> is it better to wrap the  another  with an
> error handled?
> 
> Followup question: how can I configure an error handler to do
> whatever I want? I only want this particular behavior to happen for
> this particular  ... presumably, I'll want other behavior
> in other situations.
> 
> Thanks, -chris
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> <mailto:users-unsubscr...@cocoon.apache.org> For additional
> commands, e-mail: users-h...@cocoon.apache.org 
> <mailto:users-h...@cocoon.apache.org>
> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXUDY/AAoJEBzwKT+lPKRY7TcP/jxbYNldkn7MFFwKKR9SYtEd
Ow6XBZ/dTyXhrcSWz9lyOulZ2/WqHpar7S1jwPmYSx+Ga9FOlWghU+5CYI3Ohovi
R+v44GTLaydwp2QnqG7sEXl3l2UxY83pzGl/1ae5M5BTULPdkM8LTRNl1U1bssAC
W2BY2ScSv5g8psLLc7dKOCfY7QQqwz84M6YVzorLsUJ96NETvuKn2yvWoYYs+iuX
LZrFTRWDwbWxedm5fArFoNYd1uYgslvc4Ua7sZbv3qLimy8ms1h61vABbI/bUcwM
M2JxXIgOAsMc7MGVuw5jjZQOSvg7S/8H/QUPQ+BflXlEBkaZNnz0RFN7wTGgEjVl
fzdyY9FF9QxVQysfyaFquJqZCbvIRy1c7vpzpG5B3NXVm92ZFrfVgOr1vFb4tcY2
nR7FQoCZ2ZuHtNcPgyNhk2MpHtjkj14mFq0jIyxzRu/A6Ltd//pyw7cGosP7xzFn
+12KdigPK45nSRo7TOlSxv7RZ7FfYFwOj2UeXP/5xPoaWom5PoYemzSn7HULr4NM
MSX7v02Ndb0ZBKEn7O1YOLdQmaQTYGnTPP7zhJ2jaccHAxz5RmbjWR2r0EE3MtdO
6Gu2KC/PqiIJF3qM6l/xcLHRRSilh+Xl/qu/0cUIGbzWtgAfkkZAWP42DT/pzA/o
I0gdBU+WWcqZaPCEFYcf
=89az
-END PGP SIGNATURE-

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

Handling errors retrieving a for

2016-06-01 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

Using Cocoon 2.1, I've got an aggregate generator like this:

  

  
  http://remote-server/baz.xml; />

...
  

There are times when "remote-server" is not available and I'd like to
basically include nothing at that location within the aggregate document
.

Can I do that within the  or  elements, or is
it better to wrap the  another  with an error
handled?

Followup question: how can I configure an error handler to do whatever
I want? I only want this particular behavior to happen for this
particular  ... presumably, I'll want other behavior in
other situations.

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

iEYEARECAAYFAldPIeUACgkQ9CaO5/Lv0PBW7wCfZtyG7w8bcgOuVn80V4NZtxoy
n10AnAtqYx0F2uHml7wbEPh4Bg9G3s3Y
=aPSk
-END PGP SIGNATURE-

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

Re: [2.1] Non-trivial uses of i18n transformer

Francesco,

On 5/23/16 9:58 AM, Francesco Chicchiriccò wrote:
> On 23/05/2016 15:55, Christopher Schultz wrote:
>> Marc,
>>
>> On 5/23/16 9:39 AM, Marc Salvetti wrote:
>> > Try something like this > > I18n-attr="title"/>
>>
>> > That's by memory but should find the exact syntax in  the doc
>>
>> Yep, this totally works.
>>
>> Since I'm on a roll, how about this:
>>
>> <xsl:comment>
>>   function whatever() {
>> document.getElementById('link').title = 'translated-text';
>>   }
>> </xsl:comment>
>>
>> Probably the simplest way is to just remove the  from
>> around the script, since I don't think that's actually been necessary
>> since the days of MSIE4. Is there another convenient way to do it?
> 
> Why not
> 
> 
> <![CDATA[
>   function whatever() {
> document.getElementById('link').title = 'translated-text';
>   }
> ]]>
> 

Since the 'translated-text' is really , it would be ignored
if it were in a CDATA section.


<![CDATA[
  function whatever() {
document.getElementById('link').title = '<i18n:text key="foo" />';
  }
]]>


That's not going to work any better than the javascript embedded within
an  element, right?

Thanks,
-chris

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

Re: [2.1] Non-trivial uses of i18n transformer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marc,

On 5/23/16 9:39 AM, Marc Salvetti wrote:
> Try something like this  I18n-attr="title"/>
> 
> That's by memory but should find the exact syntax in  the doc

Yep, this totally works.

Since I'm on a roll, how about this:


  function whatever() {
document.getElementById('link').title = 'translated-text';
  }


Probably the simplest way is to just remove the  from
around the script, since I don't think that's actually been necessary
since the days of MSIE4. Is there another convenient way to do it?

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

iEYEARECAAYFAldDC+EACgkQ9CaO5/Lv0PDbdQCfet+DodTVUTYu/zw0Y6FKu07a
QLkAn2RZgvnbABrZBM0P+eCFG7aCHNr+
=4NcC
-END PGP SIGNATURE-

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

Re: [2.1] Non-trivial uses of i18n transformer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Francesco,

On 5/23/16 9:41 AM, Francesco Chicchiriccò wrote:
> On 23/05/2016 15:39, Marc Salvetti wrote:
>>> Hi Chris, > > Try something like this  title="some.catalogue:some.text" I18n-attr="title"/> > > That's by 
> memory but should find the exact syntax in  the doc Here it is:
> 
> https://cocoon.apache.org/2.1/userdocs/i18nTransformer.html
> 
>  
> This text will be translated. 

Aw, geez. How did I miss that in the docs? That's WAY better than the
stupid stuff I was coming up with.

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

iEYEARECAAYFAldDCTIACgkQ9CaO5/Lv0PBt/ACgolWWUsFvXAHdCGehUxNoxN0F
TcwAmgKf5WgUHXvrvVTAzpi1IIvc5GOA
=xWAl
-END PGP SIGNATURE-

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

[2.1] Non-trivial uses of i18n transformer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'm finally getting around to internationalizing the XSLT-based parts
of my application, and I'm running into a problem with non-trivial
uses of  in a template.

Here's an excellent example of the kind of thing I'm having trouble
with. I have a single XML document going through a pipeline with a few
transformations in it. There is one major transform where pretty much
everything interesting happens. I'd like to use  in there to
produce an HTML  element with a localized "title" attribute.
Something like this:


  click me


Localizing the "click me" text is trivial. Doing the same with the
"title" attribute is not.

   "  [...] >

That obviously won't work because the attribute won't be parsed and
evaluated by the XSLT parser. Use of {} around it doesn't work because
it's an element, not an expression.

  

  

[...]
  

That doesn't work because  evidently can't contain
. At first, this irritated me but then I realized that this
would never work, because the second case would basically degenerate
into the first case after the  completed its work for
this template before I (later) ran the I18nTransformer.

The only idea I've had is to flip the current i18n process on its head
and instead do this:

  





  

  



  



  

So instead of transforming the input document with an
internationalized stylesheet, then transforming the result with the
i18n transformer, I first transform the transformer itself to get a
localized transformer, and transform the input document with *that*.

Is that "recommended technique"? Alternatively, is that entirely stupid?

If this is a good idea, how specifically can I accomplish what I have
above? I haven't yet tried it, but I'm concerned I'll have the same
problem with elements not being allowed in other elements.

Any suggestions?

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

iEYEARECAAYFAldDBi0ACgkQ9CaO5/Lv0PC3HQCfQLoPna+oFFoWxXggz0rKwxis
vyAAn1IrMa5SNcy+8fhr6Wt5JxdJ8abT
=i48t
-END PGP SIGNATURE-

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

Re: [2.1] cinclude using a pipeline as a generator source

2016-05-10 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nico,

On 5/10/16 4:35 AM, Nico Verwer wrote:
> On 7-5-2016 15:10, Christopher Schultz wrote:
>> On 5/7/16 7:38 AM, warrell harries wrote:
>>>> cocoon:// is understood as standard
>>> Awesome. I was hoping it would be something simple like that.
> You can use something like
> 
>  src="cocoon://{normalize-path:{request:sitemapURIPrefix}../somewhere/e
lse}/whatever.xml"/>
>
>  The RequestModule is standard, and the NormalizePathInputModule
> comes from this project
> <https://github.com/nverwer/cocooncomponents>. Doing this will make
> you project "relocatable" relative to the sitemap root. This works
> in Cocoon 2.1, which for me is still preferable over 2.2 or 3.
> 
> It is good to see that people are still using Cocoon (2.1)!

Thanks. And yes, I too prefer 2.1 over the later versions. We spent so
much time trying to figure out how 2.1 worked with little usable
documentation that upgrading seemed like it wouldn't be worth it. It's
been a looong time since I checked-out the documentation for the later
versions. Maybe things have gotten better.

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

iEYEARECAAYFAlcx8KcACgkQ9CaO5/Lv0PBVcACfam2SJPROJUgkKth36JXCmo0h
Up0AnAuwS5AKl0wFYzAMpw+/JeIOVqtl
=5MYS
-END PGP SIGNATURE-

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

Re: [2.1] cinclude using a pipeline as a generator source

2016-05-07 Thread Christopher Schultz

Warrell,

On 5/7/16 8:58 AM, Christopher Schultz wrote:
> Warrell,
> 
> Thanks for the quick reply!
> 
> On 5/7/16 7:38 AM, warrell harries wrote:
>> cocoon:// is understood as standard
> 
> Awesome. I was hoping it would be something simple like that.
> 
>> Use :/ to go relative to the root
> 
> I'm having trouble configuring it properly, though.
> 
> So, my original URL looks like this:
> 
>src="https://host/context/foo/bar/baz.html{$jsessionid}; />
> 
> My sitemap is actually foo/sitemap.xmap, so it matches all the stuff in /foo
> 
> When I change the URL to this:
> 
>  
> 
> I get this error:
> 
> java.lang.RuntimeException: The current URI
> (/foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E) doesn't
> start with given prefix (foo)
> 
> If I remove the "extra" leading / :
> 
>  
> 
> I get this error:
> 
> org.apache.cocoon.ResourceNotFoundException: No pipeline matched
> request: foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E
> 
> If I use ./ like this:
> 
>  
> 
> I get this error:
> 
> org.apache.cocoon.ResourceNotFoundException: No pipeline matched
> request: ./foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E
> 
> I'm vry close. Just have to fix the speling, evidently ;)

The last permutation ended up doing it:

  

So since the sitemap currently operating is "foo", the "foo" isn't
necessary in the URL? This completely solves my problem but I have an
academic question: what would happen if I wanted to use a pipeline from
a different sitemap in my URL? Something (conceptually) like this?

 

Since I need to remove the "other-foo" to get this to work, how can I
address it?

Thanks,
-chris

>> On 7 May 2016 12:12, "Christopher Schultz" <ch...@christopherschultz.net
>> <mailto:ch...@christopherschultz.net>> wrote:
>>
>> All,
>>
>> I've got a Cocoon setup with a pipeline whose transformer contains
>> something like this:
>>
>>   https://my-app/get-some-data; />
>>
>> Now, the URL included there is actually coming from Cocoon, and actually
>> I have a certificate that Java doesn't trust, so I get errors about PKI
>> certification paths. I can "easily" solve that (and have been for some
>> time, now) by specifying a truststore for the JVM process that contains
>> my server's TLS certificate in it.
>>
>> I'd like to stop doing that for at least two reasons:
>>
>> 1. When my server certificate needs an update, I have to update my trust
>> store and bounce Cocoon
>> 2. It could be more efficient (no loopback HTTP request, no TLS
>> handshake, etc.)
>>
>> Does cinclude understand Cocoon-relative paths?
>>
>> I'm looking for something like this:
>>
>>   
>>
>> Does something like that exist?
>>
>> Thanks,
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
>> <mailto:users-unsubscr...@cocoon.apache.org>
>> For additional commands, e-mail: users-h...@cocoon.apache.org
>> <mailto:users-h...@cocoon.apache.org>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
> 

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

Re: [2.1] cinclude using a pipeline as a generator source

2016-05-07 Thread Christopher Schultz

Warrell,

Thanks for the quick reply!

On 5/7/16 7:38 AM, warrell harries wrote:
> cocoon:// is understood as standard

Awesome. I was hoping it would be something simple like that.

> Use :/ to go relative to the root

I'm having trouble configuring it properly, though.

So, my original URL looks like this:

  https://host/context/foo/bar/baz.html{$jsessionid}; />

My sitemap is actually foo/sitemap.xmap, so it matches all the stuff in /foo

When I change the URL to this:

 

I get this error:

java.lang.RuntimeException: The current URI
(/foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E) doesn't
start with given prefix (foo)

If I remove the "extra" leading / :

 

I get this error:

org.apache.cocoon.ResourceNotFoundException: No pipeline matched
request: foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E

If I use ./ like this:

 

I get this error:

org.apache.cocoon.ResourceNotFoundException: No pipeline matched
request: ./foo/bar/baz.html;jsessionid=97079C2DC1E19B20F2BEB8303AECF74E

I'm vry close. Just have to fix the speling, evidently ;)

Thanks,
-chris

> On 7 May 2016 12:12, "Christopher Schultz" <ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>> wrote:
> 
> All,
> 
> I've got a Cocoon setup with a pipeline whose transformer contains
> something like this:
> 
>   https://my-app/get-some-data; />
> 
> Now, the URL included there is actually coming from Cocoon, and actually
> I have a certificate that Java doesn't trust, so I get errors about PKI
> certification paths. I can "easily" solve that (and have been for some
> time, now) by specifying a truststore for the JVM process that contains
> my server's TLS certificate in it.
> 
> I'd like to stop doing that for at least two reasons:
> 
> 1. When my server certificate needs an update, I have to update my trust
> store and bounce Cocoon
> 2. It could be more efficient (no loopback HTTP request, no TLS
> handshake, etc.)
> 
> Does cinclude understand Cocoon-relative paths?
> 
> I'm looking for something like this:
> 
>   
> 
> Does something like that exist?
> 
> Thanks,
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> <mailto:users-unsubscr...@cocoon.apache.org>
> For additional commands, e-mail: users-h...@cocoon.apache.org
> <mailto:users-h...@cocoon.apache.org>
> 

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

[2.1] cinclude using a pipeline as a generator source

2016-05-07 Thread Christopher Schultz

All,

I've got a Cocoon setup with a pipeline whose transformer contains
something like this:

  https://my-app/get-some-data; />

Now, the URL included there is actually coming from Cocoon, and actually
I have a certificate that Java doesn't trust, so I get errors about PKI
certification paths. I can "easily" solve that (and have been for some
time, now) by specifying a truststore for the JVM process that contains
my server's TLS certificate in it.

I'd like to stop doing that for at least two reasons:

1. When my server certificate needs an update, I have to update my trust
store and bounce Cocoon
2. It could be more efficient (no loopback HTTP request, no TLS
handshake, etc.)

Does cinclude understand Cocoon-relative paths?

I'm looking for something like this:

  

Does something like that exist?

Thanks,
-chris

-
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

2016-01-07 Thread Christopher Schultz

Peter,

On 1/6/16 11:59 AM, Flynn, Peter wrote:
> 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.

Yeah, it's a shame they are about to be *3* versions behind. Sad.

> Sadly we no longer have the luxury of time to build stuff from scratch.

No need to build anything from scratch. Download the tarball and unpack.
Installation is done. You can even run multiple versions side-by-side
and switch back and forth changing nothing but an environment variable.

>> 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.

Slow... how? Slow to start? Slow all over? Tomcat didn't get many more
times more complicated between Tomcat 5 and Tomcat 6. It's not like
upgrading from Windows 3.1 to Windows 95 (I chose that analogy to
reinforce the idea that Tomcat 6 is oold).

>> 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.

Shouldn't be a problem, assuming it's on the same hardware. Tomcat 7 is
a lot more efficient and is missing some of the weirdness of Tomcat 6.
Tomcat 8 is even better. Please reconsider.

>> 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.

Well, your original question was "I want to upgrade; any suggestions"?
so I responded with suggestions. If you're already done the work... what
are you actually asking?

>> 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.

I understand. You should petition CentOS to provide newer Tomcat
versions. Amazon Linux's package repos (yum-based, RHEL-compatible) all
support up to Tomcat 8. Supporting only up to Tomcat 6 is ... deeply
disappointing.

> 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.

-chris

-
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

2016-01-06 Thread Christopher Schultz

Peter,

On 1/6/16 6:33 AM, Flynn, Peter wrote:
> ...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?

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]

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

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).

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.

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.

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.

-chris

[1] http://tomcat.apache.org/tomcat-60-eol.html

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

Adding EXSLT functions

2014-02-27 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I've been successfully using EXSLT functions -- specifically, the
date-and-time functions (http://exslt.org/date/index.html) -- for some
years now and I was interested in using the seconds function. It
turns out that the seconds function is not in the core functions and
so for whatever reason, it's not been included in Xalan (I'm using
Cocoon 2.1.11 which uses Xalan 2.7.1 by default).

I've tried to download and use the date.seconds.xsl template and
included Javascript and MSXML XSL templates with a mixture of
xsl:import and xmlns:date declarations, but nothing seems to get the
two working together.

Has anyone ever manually-plugged an EXSLT function into Xalan? How did
you do it?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTD7JXAAoJEBzwKT+lPKRYseIP/0hQ6PgCu6HpJgs7VmoWNyo/
8EheSdqHO+Na6jRZFJ+cTBAmQqpHGL2oejXV1AJJHfgfyOkWB3HiX2e3qAXnUjOW
ervQx8yDrFKLqICT3GrOW10TtZOGy3YN2E+fGK6y+BeD2LmJGDRS1h0NvicQLt0O
AUED+igO1NWshYZkpePamx7DacQbhZvrgRsSAzzDT2s0rkNb+DMxJlsdqY2PV3hS
rcN+/f2vUFJkrFXkdfI0HisRpGYDkpC1cYlo40WyDYADIrihA8O0l+UyRYsBsLiH
+VLloM/wsW65CaNKKUdlQ6Drs5k9AnLVZEdeo1qPZ51nDYfv6U9FGrEemwn5xTb8
tmStuLhJ+T0A2OtppVut1jCbjASUO92nN0jkFmOD5+Ta5gP389eaXcCA25yQ8/xY
rRmecZLUvn3PRfU1iHJY9VgzNy1pho+peZ3dctNLAPwgcl6vbmXQe8zja7Yqb4+M
qift8rPfdCCFLkHeNZKDrGBOWg9U6m/AGqvx8oa6f76xTit+fIJ23Q9XlLcorFiX
xQjPuqeUfmeAkP6u3kvEhFV7BSh7XKqpzn5dnUCf3x2J8VGo0R2VQervUFd3bpiQ
kAoLtQf4Ln0MQaDbqzwekWHSkaoU0OV6OWl0DZUbNHIf+QpiCVmdXr29m5MmB/qG
RItiFqEquBtVTJ1/I4vr
=mgkb
-END PGP SIGNATURE-

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

Re: Getting the value of the browser selector

2013-12-19 Thread Christopher Schultz

Peter,

 On Dec 19, 2013, at 4:24, Peter Flynn pfl...@ucc.ie wrote:
 
 Let me try again in a shorter post :-)
 
 1. Has anyone ever used the browser selector?
 
 2. Can it be used to pass the *value* to a transformation as a parameter 
 without resorting to map:when, instead of just doing selection?

Isn't the value of the browser selector the same as the user-agent header 
value? You can just pass-in the header to the transformation... No need for the 
browser selector.

-chris

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

Re: Trouble with disable-output-escaping

2012-11-14 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robby,

On 11/13/12 1:41 PM, Robby Pelssers wrote:
 Allright...
 
 You should reminder this tip.  It will only work if you do this in
 the very last transformer right before calling the serializer.

Okay, since I have a number of transform operations, I'll have to do
some fancy footwork. Would this work?

 map:match pattern=foo.html map:generate src=source.xml /
 
 map:transform src=generate-cincludes-1.xsl /
 
 map:transform src=generate-cincludes-2.xsl /
 
 map:transform type=cinclude /
 
 !-- this is the XSL I'm working with: -- map:transform
 src=the-transformer-in-question.xsl /

In the above XSL, add an attribute (or element) to the text I want to
un-escape.

 map:transform type=cinclude label=content /
 
 map:transform type=i18n / map:transform
 src=strip-namespace.xsl /

Here, I could modify the strip-namespace.xsl to also find anything
wrapped in the special un-escapify element (or with a similar
attribute) and use disable-output-escaping=yes here?

 map:serialize type=xhtml / /map:match

 You owe me a beer ;-)

Not quite yet: I haven't got this sorted, yet. I'll buy you one if you
are going to attend ApacheCon NA 2013.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCjwM8ACgkQ9CaO5/Lv0PBIkwCcC6NGOvLl1Qc15mrZDMk5iuGg
noQAn0MFKEzBAcXNu63J1MXHGp7Kwths
=kyBO
-END PGP SIGNATURE-

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

Trouble with disable-output-escaping

2012-11-13 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'm running Cocoon 2.1.11 on Oracle Java 1.6.0_26. I'm using the
default Xalan 2.7.1 XSLT processor.

All examples are roughly mocked-up from a much more complicated
configuration so I apologize if there are typos, etc. -- I hand-typed
this message with no copy/paste.

I have some text data wrapped-up in XML like this:

node
  subnode
There is lt;bgt;HTML textlt;/bgt; in here.
  /submode
/node

I'd like to spit-out that text as if it were HTML -- that is, without
escaping it on output. I would like to get this text output:

There is bHTML/b in here.

But instead I get this:

There is lt;bgt;HTML textlt;/bgt; in here.

Which, of course, is no surprise given no other instructions.

So I tried using disable-output-escaping, which seems uniquely-suited
for this purpose:

xsl:template match=subnode
  xsl:value-of select=. disable-output-escaping=yes /
/xsl:template

I observe no change in the output. The XSL file has definitely been
re-read from the disk (I made other changes so I could verify at least
that much), so that's not an issue.

Here's my (rough) configuration:

sitemap:
map:match pattern=foo.html
  map:generate src=source.xml /

  map:transform src=generate-cincludes-1.xsl /

  map:transform src=generate-cincludes-2.xsl /

  map:transform type=cinclude /

  !-- this is the XSL I'm working with: --
  map:transform src=the-transformer-in-question.xsl /

  map:transform type=cinclude label=content /

  map:transform type=i18n /
  map:transform src=strip-namespace.xsl /
  map:serialize type=xhtml /
/map:match

My template header:

xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:i18n=http://apache.org/cocoon/i18n/2.1;
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
xmlns:java=http://xml.apache.org/xalan/java;
 
xsl:output method=html indent=yes /
...

My understanding is that Xalan itself does support
disable-output-escaping, and I can't see why Cocoon would interfere
with that.

Am I trying to use disable-output-escaping incorrectly? Do I need to
run Cocoon (or Xalan) in any special mode or with any particular
settings in order to enable disable-output-escaping?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCik6cACgkQ9CaO5/Lv0PAqZgCeIX65HKLVa6rEe6TnL65wEdoi
48gAmgJfBNT+082ehqg7DhduZtEg/4RV
=l8ul
-END PGP SIGNATURE-

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

Re: Cocoon 2.1 web application base path

2012-05-17 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andy,

On 5/16/12 12:36 PM, Andy Stevens wrote:
 Hi Bob,
 
 Assuming you have the request input module in your cocoon.xconf,
 then you can pass the context path into an xsl:param (or otherwise
 use in the sitemap) with e.g. map:transform
 src=mytransform.xslt map:parameter=xslParamName
 ={request:contextPath}/ /map:transform

+1

IMO this is the right way to do things.

If you want a completely, fully-absolute URL, you might want to:

 map:parameter name=requestScheme value={request:scheme} /
 map:parameter name=requestServerName value={request:serverName} /
 map:parameter name=requestServerPort value={request:serverPort} /

 map:parameter name=context-path value={request:contextPath} /
 map:parameter name=request-uri value={request:requestURI} /
 map:parameter name=query-string value={request:queryString} /

We have a bunch of XSL templates that produce XHTML and need to
provide references back to themselves in certain circumstances. So, we
pass everything and the template can build as much of the URL as it
chooses in a case-by-case basis.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+1IRUACgkQ9CaO5/Lv0PCCZQCgqewzX0xNnTU4rPzeccS2tadN
AwYAn3xRtJ2ZpXOHU8tg2IJLD1BAq87m
=9G3l
-END PGP SIGNATURE-

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

Re: Using I18NTransformer with Dynamic Locales

2012-02-15 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cédric,

On 12/2/11 4:04 PM, Cédric Damioli wrote:
 Le 01/12/2011 17:49, Christopher Schultz a écrit :
 All,
 
 I'd like to start using the I18NTransformer so I can localize
 the output of my XSLTs. We have what I believe to be a somewhat
 unique situation with regard to the actual source of the locale
 information.
 
 Here goes:
 
 We have Cocoon set up as a webapp all by itself, separate from
 our real webapp. Our pipelines take incoming HTTP requests and 
 essentially forward them, with modifications of course, to our
 real webapp that produces XML for consumption by Cocoon. The
 Cocoon webapp does not maintain session state of any kind: it
 merely forwards requested session ids from the incoming request
 through the outgoing request to the real webapp.
 
 The real webapp knows what the user's preferred Locale is, and
 can provide that information back to Cocoon if necessary. We have
 lots of options: HTTP response headers, something in the XML
 document returned, etc.
 
 Unfortunately, I'm not sure how to get any of those data when
 calling the I18N transformer itself.
 
 Can anyone offer any suggestions?
 
 If I can't come up with anything else, I'll have to encode the
 locale in each request's URL which, while doable, will likely be
 fragile and a total PITA to actually accomplish.
 
 Thanks, -chris
 
 The locale of the I18nTransformer may be set a sitemap parameter : 
 map:transform type=i18n map:parameter name=locale
 value=/ /map:transform
 
 In this cas, the actual locale value may be computed in a
 surrounding action :
 
 map:act type=proxy map:generate/ map:transform type=i18n 
 map:parameter name=locale value={locale}/ /map:transform 
 map:serialize/ /map:act
 
 where the proxy action actually proxy the request to your real
  webapp, get the responses header you mentionned and put it in the 
 result map.

I've considered this approach and I definitely think it will work.
However, I'm wondering if I can avoid another round-trip to the
original server that is producing the XML document currently being
processed.

I can alter this XML document to contain the locale itself if that's
any help. Is there a way to extract a piece of information from the
event stream and use *that* as a variable for the pipeline?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk87+xQACgkQ9CaO5/Lv0PB9RACeJbi86fHX4xA2HyYipOcnBxtk
ohoAn0+btE5WUBwcW7E8LXVUi4DdST3T
=Pnci
-END PGP SIGNATURE-

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

Re: AW: revelet not repsonding

2012-02-15 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jürgen,

On 1/6/12 5:14 AM, Ehms, Jürgen wrote:
 With the first mapping /* all is going to Cocoon. Put it in last
 place.

That's not how url-pattern matching works: longest-match always wins.
/* is the default mapping, which takes lowest precedence.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk87/O8ACgkQ9CaO5/Lv0PDzJgCcDYpWNBfwvzjYSOhUPjr0QSIl
RnkAn0ToLZz1z0oolRjFFusgqrgG+sny
=eTpz
-END PGP SIGNATURE-

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

Using I18NTransformer with Dynamic Locales

2011-12-01 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'd like to start using the I18NTransformer so I can localize the
output of my XSLTs. We have what I believe to be a somewhat unique
situation with regard to the actual source of the locale information.

Here goes:

We have Cocoon set up as a webapp all by itself, separate from our
real webapp. Our pipelines take incoming HTTP requests and
essentially forward them, with modifications of course, to our real
webapp that produces XML for consumption by Cocoon. The Cocoon webapp
does not maintain session state of any kind: it merely forwards
requested session ids from the incoming request through the outgoing
request to the real webapp.

The real webapp knows what the user's preferred Locale is, and can
provide that information back to Cocoon if necessary. We have lots of
options: HTTP response headers, something in the XML document
returned, etc.

Unfortunately, I'm not sure how to get any of those data when calling
the I18N transformer itself.

Can anyone offer any suggestions?

If I can't come up with anything else, I'll have to encode the locale
in each request's URL which, while doable, will likely be fragile and
a total PITA to actually accomplish.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7XsBIACgkQ9CaO5/Lv0PBAxwCdER3GqI5TLETkSIeRzstvFcYn
nAkAoJ+5dPRr0zymd6dMez9pm4we4JJS
=GlJl
-END PGP SIGNATURE-

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

Re: Setting URLConnection User-Agent String

2011-10-04 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Warren,

Resurrecting an old thread: I hadn't noticed your reply back in March.

On 3/1/2011 5:46 AM, warrell harries wrote:
It doesn't make any difference - it's plain old HTTP despite the
jargon :)

Of course.

If you have already seen this
http://www.mail-archive.com/users@cocoon.apache.org/msg34182.html

then investigate the original Generator code at
/cocoon-2.1.11/src/blocks/proxy/java/org/apache/cocoon/generation/WebServiceProxyGenerator.java

It could be that this will be sufficient for your requirements.

So, I'm using a simple XML-over-HTTP request as my generator, like this:

map:part src=http://host/service.xml; /

I'm using the default set of Cocoon generators with default=file, or
org.apache.cocoon.generation.FileGenerator. The request is definitely
using an HTTP connection, as this URL is not otherwise reachable (and
it's showing up in our request logs, too).

But, it's not a web service. Maybe that's not relevant, but I thought
I'd point it out as you directed me towards WebServiceProxyGenerator.java.

I took a look at how WSPG works, and it's a relatively straightforward
use of commons-httpclient, which has an addUserAgentRequestHeader
method available.

The question is how to get the setting from the sitemap into the
object that actually makes the connection.

Is the setup(..., Parameters par) method the right place to do such
things? If so, a simple patch like this:

if(par.isParameter(user-agent))
this.httpClient.getParams(HttpParam.USER_AGENT,
par.getParameter(user-agent));

Would this be the right place to put such code, and how does one
configure parameters to map:generator? Using attributes like
map:generator ... user-agent=MyUserAgent / or using sub-elements?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LKO4ACgkQ9CaO5/Lv0PBT2gCfVAgtjQSTjPi24/7q3YX1KTbf
q7wAn3ZmyoSa+qWrMICb8PSY398UGOwh
=KKRy
-END PGP SIGNATURE-

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

Re: tomcat memory issue

2011-06-01 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 5/25/2011 11:14 AM, DAVIGNON Andre (Responsable du PANDOC) -
SG/SPSSI/CPII/DONP/PANDOC wrote:
 As far as I know, it is the same Tomcat engine that you run either on a
 32 or 64 bits JVM. Only the JVM matters. If your JVM runs in 64 bits,
 Tomcat can use as much as memory allowed by the JVM.

+1

There is no 32-bit Tomcat, nor is there a 32-bit Cocoon: it all
depends upon the JVM.

AFAIK, both work just fine under a 64-bit JVM.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3mkZ4ACgkQ9CaO5/Lv0PDCOwCfYr4FPTSx8CfU/oQ1s8gxL43a
Cz0AoMCKLvU96SinD4Ed4dUKfEkopczm
=vt7l
-END PGP SIGNATURE-

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

Re: Setting URLConnection User-Agent String

2011-02-28 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Warrell,

On 2/28/2011 6:41 AM, warrell harries wrote:
 Please see recent discussion regarding proxying to another server. In
 brief, I usually deploy a custom transformer based on the web service
 proxy transformer but setting the user agent header before invoking the
 web service.

I was talking about a vanilla HTTP request that returns an XML document,
not a formal web service. Not sure if that changes your suggestion(s).

 Seems like this is a common requirement and it would be good if the
 desired header could be passed in as a sitemap parameter to an existing
 component. I am not aware of any existing component that provides this
 facility.

That would be cool. I've had a hard time penetrating the Cocoon code
base in the past. Any pointers on where to look to possibly implement this?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1rybAACgkQ9CaO5/Lv0PAA8wCfWcDOcdJ/U4SiB3X9UTuRBqK0
FG4AoKsjKpjN4Cdy/msD8N6WmCJ0yMHT
=U07J
-END PGP SIGNATURE-

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

Setting URLConnection User-Agent String

2011-02-25 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'm using Cocoon 2.1.11 with some pipelines that fetch data from another
webapp via Apache httpd which logs the requests with the User-Agent
being Java/whatever. I'm wondering if Cocoon offers the ability to
tweak the User-Agent string that is used when fetching data from http://
resources?

I believe I can set the http.agent system property, but I was wondering
if anyone has another (better?) technique to do this?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1n3uIACgkQ9CaO5/Lv0PAjqwCdEeS0fpVuAHhXEeyEXKehyTO6
54IAoLWV0wHj6TjiAXihOTUZAwOMHRRB
=e1Ma
-END PGP SIGNATURE-

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

Re: i18n cookies storing path

2011-01-07 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Johan,

On 1/7/2011 5:45 AM, Johan Cwiklinski wrote:
 Le 07/01/2011 11:24, Laurent Medioni a écrit :
 Strictly match, at the beginning of the pipeline,  (or /, I never 
 remember...) and call the LocaleAction only there. Then end the matcher just 
 after without response.
 This will work if your users always start browsing your application through 
 .../myapp/, typically just after login as a homepage.

 Now if you cannot be sure of this then, yes, something similar to the 
 proposed patch in COCOON-1592 will enable you to set a root cookie from 
 any subpath...
 
 I cannot be sure where users will start browsing unfortunately. I'll
 take a look at the proposed patch ; thank you for the clarifications :)

If you're willing to write a bit of Java code, you can do this easily
using a servlet filter.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0nRxYACgkQ9CaO5/Lv0PAt3QCbBb3cyvUN51n2kPb3QD01GgK7
9yMAoIYcJONG4tZg36bhuun2Tcz3HpbT
=o9yo
-END PGP SIGNATURE-

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

Re: Encoding

2010-12-20 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Laurent,

On 12/17/2010 11:25 AM, Laurent Medioni wrote:
 Have a look at http://wiki.apache.org/tomcat/FAQ/CharacterEncoding I
 think the comment you refer to tries to say that if no
 charset/encoding is set when producing a response then assume the
 ISO-8859-1 default value (do not ask why ;) ).

That wiki page explains why. I know because I wrote it :) It's all in
the servlet and HTTP specifications.

There's actually an open issue in Tomcat that proposes to switch the
default request body encoding /and/ URI encoding to UTF-8. Comments welcome:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48550

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0P1FEACgkQ9CaO5/Lv0PCHMgCeIJ8Zt4DczFzMQA9ZFMd/ALiI
zvEAn2g14sxMECi+X7HaJ1y+X5FqXlV8
=pH7L
-END PGP SIGNATURE-

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

Re: Deploying a Cocoon 2.2 webapp in Tomcat 6.0.20

2010-10-04 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florian,

On 10/4/2010 7:01 AM, Florian Schmitt wrote:
 i'm quite new regarding cocoon 2.2 and i'm stuck trying to deploy a
 Cocoon 2.2 webapp in Tomcat 6.0.20.

Ok.

 I followed those steps to create a minimal webapp :

Good. If you have a WAR file, then you should be done with the
Cocoon-related steps.

 - Tomcat log contains the stacktrace attached.
 
 I found some hints online regarding class loaders, but i'm not
 experienced enough to fix this on my own.

These issues can sometimes be complex: note that the server can't find
javax/servlet/ServletContextListener, which is a pretty intrinsic class
for a servlet container.

 I tried to add
 
 dependency
 groupIdjavax.servlet/groupId
 artifactIdservlet-api/artifactId
 version2.5/version
 /dependency
 
 to webapp/pom.xml because it seems that Tomcat can't find the
 javax.servlet.ServletContextListener class, but that didn't help.

This is unlikely to help: Tomcat doesn't use pom.xml for anything: only
Maven and the compilation/build steps use it. If your code has complied
properly, then your pom.xml should be good to go.

Can you tell us how you installed Tomcat? Please list the libraries in
TOMCAT_HOME/lib and also (all) the libraries in your WAR file's
WEB-INF/lib directory.

It might also be a good idea to cross-post to us...@tomcat.apache.org.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyp8ecACgkQ9CaO5/Lv0PCn/wCgtXHghVzdRxZtY56R6h3Ju7jJ
xuAAn3nCXbKzWJDiKvPWnvkY0qxVjOCU
=K0FI
-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.

2010-09-29 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/29/2010 1:10 AM, . . wrote:
#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*

Yeah, that makes a ton of difference. I'm glad it wasn't 0xa9, 'cause
that would have been a real mess. :)

[file.encoding] 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.

ANSI_X3.4-1968, as you probably found out, is essentially basic ASCII,
and ISO-8859-1 is ASCII plus a few other things, so they are compatible.
It's not surprising that these two character sets are both working: if
one works, the other has a good chance of working.

The application runs fine on both of them. On the new server that too
is giving out ISO-8859-1.

Interesting.

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.

Cocoon packages it's own Xalan library, so that shouldn't be the
problem, although I can't remember when Sun started packaging Xalan with
Java. At some point, I think they even removed it. What version of Xalan
are you running? It should be in your webapp's WEB-INF/lib directory. I
don't think there's been a Xalan update in quite a few years.

Let us know how things turn out.

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 :(

Technically speaking, servlet containers are supposed to be backward
compatible. I wouldn't be surprised if, given a review of your Context
element for Tomcat (it should go into META-INF/context.xml, now in your
webapp, instead of in conf/server.xml for the server), everything else
works exactly as it did before.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjQiMACgkQ9CaO5/Lv0PBtOACeKG7EgdIqh+vDNND8wFKAtGHM
N08AnjBBlR2cvmgIu1BfIDy79bMSAs7Q
=h7CA
-END PGP SIGNATURE-

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

Re: form encoding issues

2010-09-29 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ron,

On 9/29/2010 5:43 AM, Ron Van den Branden wrote:
 There is stated that
 apparently (and counter-intuitively, IMO), 'request parameters are
 always decoded using ISO-8859-1 ',  and that consequently
 'container_encoding should always be ISO-8859-1 (unless you have a
 broken servlet container), and form_encoding should be the same one as
 on your serializer.'.

Note that it's not /all/ parameters that are decoded using ISO-8859-1:
it's only GET parameters. If you use POST, you will likely have better
results.

Note that this means you can't send anything with non-ISO-8859-1
characters in GET parameters safely. There are three solutions:

1. Always use POST (not really a bad idea, but not always practical)
2. Force your container to use UTF-8 to decode GET parameters
   (in Tomcat, this can be accomplished using the URIEncoding
attribute of the Connector element: see your own container's
documentation for similar capabilities)
3. Never send strings as GET parameters (similar to #1, but somewhat
   different: perhaps use HttpSession or other strategies to avoid
   passing strings through the URL

Good luck,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjRP0ACgkQ9CaO5/Lv0PCwEgCZAXF/2nyM3qyQN4twApw1uvM7
IRsAoJiI91NyLyMIJ30kT3pMf/KHRB7B
=9sJ3
-END PGP SIGNATURE-

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

Re: form encoding issues

2010-09-29 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas,

On 9/29/2010 7:05 AM, Thomas Markus wrote:
  hi,
 
 that arabic character should fail with latin1.
 
 we see a difference between jetty and tomcat (6.0). tomcat follows specs
 (see Andre's mail) and uses iso per default. you can switch completely
 to UTF-8 with:
 - send html content in utf-8
 - set container-encoding to utf-8
 - set form-encoding to utf-8
 - set URIEncoding to utf-8
 - and include a class like SetCharacterEncodingFilter to set request
 character encoding

Note that this item sets the character encoding for reading request
/bodies/ and not GET parameters from the URL. It also only sets the
request character encoding if the client has not set it.

All these issues are covered in this Tomcat document, though the content
is generally applicable to all containers:

http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjUBgACgkQ9CaO5/Lv0PCSUwCfan2R1diQzmoMj6s6Aohgyvw8
Lx0AnA7jrQeEoQjbum7rEzEhHI/iuvEm
=23lE
-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.

2010-09-28 Thread Christopher Schultz

-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: Cocoon 2.2 PUT HTTP request

2010-09-22 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre,

On 9/22/2010 3:36 AM, Andre Juffer wrote:
 Try confirming (say, with LiveHttpHeaders) that the PUT is being
 redirected by the server.
 
 This is what I see with LiveHttpHeaders:
 
  http://localhost:/equipment/
 
 POST /equipment/ HTTP/1.1

No, I meant try to PUT to http://localhost:/equipment (no trailing
slash) and see if the server redirects you. Also, it would be nice to to
know what kind of redirect is being issued. If a 303 response is being
generated, then the client is supposed to use a GET method for the
followup request. Other response codes have other meanings.

 [W]ith cocoon one can create very easily various
 resource representation using XSLT, without the need the hardcode this
 into Java. Cocoon 3 (there is an alpha version) is better prepared for
 REST.

Excellent. Good luck.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyaJEAACgkQ9CaO5/Lv0PBapgCeJuwk/PWW1x+mBKa8gA7x8k6J
paUAnita0RxYiQkAVPogO19b/E+tmCzX
=TbU7
-END PGP SIGNATURE-

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

Re: Cocoon 2.2 PUT HTTP request

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre,

(Is everyone on the list named Andre? :)

On 9/21/2010 9:10 AM, Andre Juffer wrote:
 There is still one other issue to be solved. In the case of a PUT
 request (or any other HTTP request for that matter), my understanding is
 that I should be able to identify the request HTTP method in flowscript
 by cocoon.request.getMethod() or in a pipeline using map:parameter
 name=method value={request:method} /. I find in either case that
 this parameter's value is always GET, whatever the original request
 method received by the servlet engine was. It seems that the original
 request method value is simply lost somewhere, -before- the request is
 being handled in the sitemap.

I'll check to see what I can get from {request:method} in my sitemap.
Other {request:*} methods seem to be working okay, though. I am also
using Cocoon 2.1, but at (the other) Andre points out, the differences
shouldn't be great in these areas.

I'm still interested in how Cocoon passes parameters to functions. In
the code you posted before, it didn't seem like you were actually trying
to access that parameter. If you use {request:method} in your pipeline,
I suspect it will give you the right method as long as you read the
/parameter/ instead of trying to use cocoon.request.getMethod() as it
appeared you were doing.

I find the Cocoon documentation very difficult to navigate. Can you
point me to the documentation for calling javascript functions? All I
could find was this:
http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyY36MACgkQ9CaO5/Lv0PALAgCgtih3jh2Z4nqm+RuRafLbGOEe
qCAAoLofwTo+Tah8/kyZlF2sA2B504Wh
=B+Zg
-END PGP SIGNATURE-

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

Re: RESTful applications

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre,

On 9/21/2010 6:22 AM, Andre Juffer wrote:
 I found this (for Tomcat 5)
 
 http://webcache.googleusercontent.com/search?q=cache:lJ-4J6f0GPQJ:old.nabble.com/How-to-configure-Toncat-to-accept-HTTP-PUT-requests--td18652489.html+%22HTTP+PUT%22+Tomcathl=enstrip=1

 Seems to indicate that one can apply this to the individual wepapps
 as well.

Correct: you can configure the DefaultServlet specifically for an
individual webapp if you choose. Otherwise, you inherit the global
configuration that gets applied to all webapps.

 I thought that the readOnly configuration parameter could be employed
 only for the default webapp (DefaultServlet).

I think you're confusing webapps (represented by a ServletContext
object) with servlets, of which the DefaultServlet is one. Each webapp
gets a copy of a DefaultServlet deployed into it to handle requests not
otherwise mapped.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyY4FAACgkQ9CaO5/Lv0PCv/gCfaO/R2awXV7MXwq7vRkzsrrpU
4FcAniEuYEh92U/XXGFbB7JStJfY++JO
=Mori
-END PGP SIGNATURE-

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

Re: Cocoon 2.2 PUT HTTP request

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre,

On 9/21/2010 2:04 PM, Andre Juffer wrote:
 On 09/21/2010 07:38 PM, Christopher Schultz wrote:
 I find the Cocoon documentation very difficult to navigate. Can you
 point me to the documentation for calling javascript functions? All I
 could find was this:
 http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
 
 Yeah, it is not that well organized. Have a look at:
 
 http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html

In the examples, I see them use code like this:

cocoon.request.get(foo)

to get a request parameter. get() is not a standard method on
HttpServletRequest, so this must be some kind of wrapper around
HttpServletRequest.

There seems to be nothing about working with map:parameter elements
from the sitemap in the flowscript. :(

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz
0LAAoKlpGlBDntPj09UTTlyVID7OZkS+
=JCr8
-END PGP SIGNATURE-

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

Re: Cocoon 2.2 PUT HTTP request

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre,

On 9/21/2010 3:15 PM, Andre Juffer wrote:
 This provides an overview of the cocoon.request methods:
 
 http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html

Okay, this looks like a HttpServletRequest object with a few more
methods (like get()). It's too bad the methods are poorly documented:
for instance, get() says that it gets an object from either the
attributes or parameters, but doesn't tell you what the rules are about
when it chooses parameter or attribute.

In either case, that parameter would almost certainly be a /request
parameter/, not a parameter to the function itself.

 However, on the cocoon 2.1 site, there is the following:
 
 http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html

That seems to indicate that the proper way to pass parameters from the
sitemap to the flowscript function is like this:

map:match pattern=*
  map:call function=equipmentHandler
map:parameter name=method value={request:method} /
  /map:call
/map:match

and read them like this:

function equipmentHandler()
{
var request = cocoon.request;
var method = cocoon.parameters.method;
...


See if that works for you.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyZDQcACgkQ9CaO5/Lv0PB50wCggBRhrbi7JSoDEvsTj4YnHRXf
CggAoJXr6TiRSQBznh131qQeqGJ91m4C
=svV1
-END PGP SIGNATURE-

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

Re: Cocoon 2.2 PUT HTTP request