Re: i18n cookies storing path
Hello Christopher, Le 07/01/2011 18:02, Christopher Schultz a écrit : > 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". I was not aware of this possibility ; I'll take a look. Thank you for the tip! > > -chris Best regards, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: i18n cookies storing path
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 :) > > Laurent Best regards, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: i18n cookies storing path
Hello, Le 07/01/2011 09:59, Laurent Medioni a écrit : > Hi, > You should only set the cookie when responding to "/myapp/" level and then it > will be available to all subpathes (for the same domain of course). Yes, but I don't know how to achieve that. Cookie is setted when calling the locale action, as far as I can understand ; it does not seems possible to tell the action not to create a cookie, or set a specific path. I've found a similar issue that has already been reported (it's pretty old tought): https://issues.apache.org/jira/browse/COCOON-1592 Regards, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
i18n cookies storing path
Hello, I'm currently working on i18n for our apps. I've put on the pages a simple form with a select element for useres to change language themselves, sending à 'locale' attribute in the URL. Doing that, I had to enable language storage in a session (store-in-session and create-session true) or in a cookie (store-in-cookie true). Using session storage makes things work well, but I'm unsure creating a session only for a language is really needed, I guess that is more costly than a simple cookie. Using cookies does not work as I've excpected, since cookies stores paths : I've a cokkie for '/myapp/' and another one for '/myapp/functions/'. Both these path require i18n, but since there is two different cookies, only one gets changed :( We use cocoon 2.1.10 ; but it does not seems there are changes in the relevant classes in 2.1.11. So, my questions: - is using a session so costly when it's no really needed? Some parts of our app already require a session ; but others don't (static pages for example). - is there a way to make cookies not to store paths? I've not see how in the doc or in the code :/ Thank you. Regards, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hello and best wishes for 2011 :) Le 23/12/2010 18:38, Johan Cwiklinski a écrit : > Hi, > > Le 23/12/2010 10:49, Johan Cwiklinski a écrit : >> I've just put the 2.1.11 RessourceReader class into my WEB-INF/classes >> directory ; I'm currently testing that way on the server (would be great >> if I can solve this problem until I can spend some time for 2.1.11 >> upgrade ;)). > > Well... It seems that solved the issue :) > > Server is up and running for a few hours now, without having any more > CPU issues. After more than a week in pa production environment, I can confirm that the issue is now solved. Again, thank you! Regards, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hi, Le 23/12/2010 10:49, Johan Cwiklinski a écrit : > I've just put the 2.1.11 RessourceReader class into my WEB-INF/classes > directory ; I'm currently testing that way on the server (would be great > if I can solve this problem until I can spend some time for 2.1.11 > upgrade ;)). Well... It seems that solved the issue :) Server is up and running for a few hours now, without having any more CPU issues. Thank you very much Laurent! Merry Xmas and happy new year everyone, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hello, Le 22/12/2010 17:12, Johan Cwiklinski a écrit : > Le 22/12/2010 15:14, Laurent Medioni a écrit : >> Time to swich to 2.1.11 then ;) >> >> ResourceReader in 2.1.10: >> private static final Map documents = new HashMap(); >> >> ResourceReader in 2.1.11: >> private static final Map documents = Collections.synchronizedMap(new >> HashMap()); >> >> See https://issues.apache.org/jira/browse/COCOON-1977 > > Oh! I was not aware of that... > > Thank you for the tip! :-) JDK 1.6.0_23 did not solve the issue :( I've just put the 2.1.11 RessourceReader class into my WEB-INF/classes directory ; I'm currently testing that way on the server (would be great if I can solve this problem until I can spend some time for 2.1.11 upgrade ;)). > >> >> Laurent >> > > Johan Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Le 22/12/2010 15:14, Laurent Medioni a écrit : > Time to swich to 2.1.11 then ;) > > ResourceReader in 2.1.10: > private static final Map documents = new HashMap(); > > ResourceReader in 2.1.11: > private static final Map documents = Collections.synchronizedMap(new > HashMap()); > > See https://issues.apache.org/jira/browse/COCOON-1977 Oh! I was not aware of that... Thank you for the tip! :-) > > Laurent > Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hello André, Le 22/12/2010 13:23, andre.davig...@free.fr a écrit : > Hi Johan, > > Does the same problem occur with mod_proxy (full http) instead of > mod_proxy_ajp. > > We have encountered some problems with mod_proxy_ajp that were solved by > using simple mod_proxy. Yes, I also have tested with http proxy... Issue is still the same, even if the tomcat seems to load less in normal usage. I have also tried to set up a load balancer (with ajp then with http), without more luck :( > > Cheers, buddy. > > André Thank you :) Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hello, Le 22/12/2010 11:53, Laurent Medioni a écrit : > Hi, > have you tried to upgrade to the latest JDK fix available ? Not yet, I'll try that this afternoon. I have already tested that with at least two jdk versions (_17 and _21). > Laurent > > Thank you, Johan - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Switching to Saxon
Hi,
Le 22/12/2010 11:05, Peter Flynn a écrit :
> On 17/12/10 08:43, Johan Cwiklinski wrote:
>> Hello,
> [...]
>> Here is our configuration:
> [...]
>> Hope that could help you :)
>
> Thanks very much, that did it. It was unclear from the docs where you
Cool :)
> put the name of the .jar file ("saxon9") and where you just put the name
> "saxon".
>
> One thing that switching to Saxon has done is reveal the holes in my
> XSLT :-)
>
> a. If a URI call to Cocoon to retrieve a web page through a Tidy
> pipeline (to make it XML) returns an empty file (really null, not even
> an empty root element), Xalan treats the statement
>
I always use the doc-available($uri) function so I can print $uri using
xsl:message if there is an error:
Unable to load:
> as a non-event, and $foo is unset (that is, a binary test for if="$foo"
> returns false). Saxon, on the other hand, emits a Java error message
> about a null pointer; technically correct, except that it makes it
> untestable because the error occurs before the document() call
> completes, so its status is inaccessible in the XSLT.
>
> b. Any ambiguity in template selection (normally a recoverable warning
> if you run Saxon from the command line) returns the "Ambiguous..."
> message as an error. Is this configurable? (ie get Saxon to not pass an
> error status to Cocoon, but just log a warning, and continue recoverably
> as it does in commandline mode?).
I do not know.
When I've got ambiguity in template selection, I usually solve that in
the XSL file ;)
>
> Obviously writing better XSLT is the answer...I should have paid closer
> attention to Mike and Jeni's sessions on testing at the XML Summerschool...
>
> ///Peter
Regards,
--
Johan Cwiklinski
AJLSM
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Tomcat6/Cocoon 2.1.10 using 100% CPU on windows
Hello, I have a problem with a cocoon 2.1.10 webapp running under tomcat 6.0.26 under windows 2003 server 64 bits with oracle's JDK 1.6.0_21. This application is installed on a 'background' server, an application on another server request it via AJP using apache mod_proxy_ajp. For some reasons, the application will often eats 100% of the CPU, we then need to kill and restart tomcat. Logs says absolutely nothing :( I was not able yet to reproduce the issue on my dev environment. This application mainly use some classes we've developed on the top of cocoon that will: - search for image file in some directories on different hard disks (mainly by testing each directory + image path and looking if the file exists), - retrieve and show the image, - additionally use ImageMagick to resize, rotate, etc. The 'main' class extends cocoon's ResourceReader. Using the jvisualvm tool provided with Oracle's JDK, I can observe that: - ajp threads are sometimes running, and sometimes waiting; ok, that seems normal, - when the 100% cpu issue occurs, some ajp threads keeps running (never get back to waiting state). At the beginning, only one or two threads are affected, many more will be if we wait. I can also observe that some threads (a few ones unfortunately) will still having the normal behavior. All running threads using our class (ImageMagickReader) seems to be kind of blocked on super.setup or super.generate methods: "ajp-9009-9" - Thread t...@65 java.lang.Thread.State: RUNNABLE at java.util.HashMap.get(HashMap.java:303) at org.apache.cocoon.reading.ResourceReader.getLastModified(ResourceReader.java:242) at org.apache.cocoon.reading.ResourceReader.setupHeaders(ResourceReader.java:177) at org.apache.cocoon.reading.ResourceReader.setup(ResourceReader.java:157) at org.pleade.reading.ImageMagickReader.setup(ImageMagickReader.java:272) [...] Line 242 of ResourceReader.java is: final String systemId = (String) documents.get(request.getRequestURI()); "ajp-9009-8" - Thread t...@102 java.lang.Thread.State: RUNNABLE at java.util.HashMap.transfer(HashMap.java:484) at java.util.HashMap.resize(HashMap.java:463) at java.util.HashMap.addEntry(HashMap.java:755) at java.util.HashMap.put(HashMap.java:385) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:346) at org.pleade.reading.ImageMagickReader.generate(ImageMagickReader.java:584) [...] Line 346 of ResourceReader.java is: documents.put(request.getRequestURI(), inputSource.getURI()); Those two examples are based on the first threads that will never release. I do not know if it is possible for a HashMap to be sort of corrupted ; of maybe HTTP headers? I'm not sure even if what we're seeing is is the cause or the consequence of the issue :( The same issue has been observed in the past on another server which is now running under GNU/Linux, and now seems to be ok (about two weeks under Linux, and no longer 100% CPU!). We've trying several tomcat and java versions, that changes anything. The issue can occurs after several uptime hours, or only a few minutes! If there are many connections, the issue will occurs more often; but is still present with just a few connections. I really do not know where the problem should be... Is it our code? Is it cocoon? Is it tomcat? Or more probably something one of them is doing that windows dislikes? It's difficult to know when exactly the problem happens (we've asked system administrators but get no answer) ; so I've not yet tried to log in debug mode (well, I've tried it once, but this is really verbose...). Any ideas? I do not know what to try or where to look at now :/ Many similar issues I can show over the web were related to a bug in tcnative under tomcat 5.5 ; I guess that is resolved now, I did not found any similar bug under tomcat 6. I also found a few ones with tomcat 6, but some were related to the apps, and the others were not resolved (at least there is no information on the forums/mailing lists saying it is resolved and what was the issue). You could take a look at the whole thread dump after about 10-15 minutes of 100% cpu usage: http://ouessant2.ajlsm.com/cocoon_app_cpu_issue The two threads I gave in example (ajp-9009-8 and ajp-9009-9) are ones that were started approximately when the server runs out of CPU ; and are still in the same state 10-15 minutes after. Thank you. Regards, -- Johan Cwiklinski AJLSM - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Switching to Saxon
Hello, Le 16/12/2010 16:58, Peter Flynn a écrit : > I just tried this, but there seems to be a lack of up-to-date details on > doing this in Cocoon 2.1.11 with saxon9. Following the assorted web > pages for earlier versions, I got as far as adding saxon9.jar to > Cocoon's WEB-INF/lib and editing the two files (commenting out the Xalan > entries): > > - cocoon.xconf: > > role="org.apache.excalibur.xml.xslt.XSLTProcessor/saxon" > class="org.apache.cocoon.components.xslt.TraxProcessor"> > > value="net.sf.saxon.TransformerFactoryImpl"/> > > > - sitemap.xmap: > > pool-min="8" logger="sitemap.transformer.xslt" > src="org.apache.cocoon.transformation.TraxTransformer"> > false > false > false > false > saxon > true > > > But then Cocoon spits out: > >> Internal Server Error >> Message: Could not find component (key >> [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) >> Description: org.apache.cocoon.ProcessingException: Lookup of transformer >> 'xslt' failed at - >> file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 >> Sender: org.apache.cocoon.servlet.CocoonServlet >> Source: Cocoon Servlet >> >> cause >> org.apache.avalon.framework.component.ComponentException: Could not find >> component (key [org.apache.excalibur.xml.xslt.XSLTProcessor/saxon]) >> full exception chain stacktrace >> org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt' failed >> at - >> file:///usr/share/tomcat5/webapps/ROOT/sitemap.xmap:1174:71 >> at >> org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:113) > > What is it actually looking for when it says > org.apache.excalibur.xml.xslt.XSLTProcessor/saxon? I have no idea what > or where "org.apache.excalibur.xml.xslt.XSLTProcessor" points to (I'm > sure it's possible to find out, but I'm not a Java programmer :-) > > ///Peter > Here is our configuration: cocoon.xconf: sitemap.xmap: false false false saxon8 true Hope that could help you :) Regards, -- Johan Cwiklinski AJLSM - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Too many open files
Hello, Le 16/12/2010 13:58, Peter Flynn a écrit : >> Caused by: java.net.SocketException: Too many open files >> at java.net.Socket.createImpl(Socket.java:388) >> at java.net.Socket.connect(Socket.java:517) >> at java.net.Socket.connect(Socket.java:469) >> at sun.net.NetworkClient.doConnect(NetworkClient.java:157) >> at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) > > In my ignorance of the internals of Cocoon and Tomcat and Java, is it > running out of file handles when making a HTTP call? > > The server is lightly loaded, but each page does open a significant > number of document()s: is there a setting that will increase the number > of open files allowed? We already have seen this issue on some cocoon applications ; most of the time, that was due to intensive use of xpath "document" function with. We observe that using saxon as xslt processor genrerally solved that issue. Most of these issues has been resolved for us doing that ; some are always present but I did not have time to further investigate yet. > > Is there any way to get it to report *what* it was trying to open (the > URI) when it failed? > > ///Peter > Hope that could help you. Regards, -- Johan Cwiklinski AJLSM - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Problem using XSP pages
The begining of the sitemap.xmap should looks like:
http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0
http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd";
xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
[...]
Regards,
--
Johan Cwiklinski
AJLSM
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Problem using XSP pages
Hi, Le 07/09/2010 14:12, Shweta Singhai a écrit : > When I try > > > > in my sitemap.xmap > > > > Then my browser showing: > > As Output of xsp page. But I think its not a proper output. I don’t know > where I did mistake. Can any one tell me please. Looks like your XSP page is simply read, not executed. If you have properly build the XSP block (that is no longer shipped as default in cocoon 2.2), maybe you have missed to declare the generator? You should have added something like the following in your sitemap.xmap: > > > > Thanks, > > Shweta > > Regards, -- Johan Cwiklinski AJLSM - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Firefox 3 ajax response
Johan Cwiklinski a écrit : Hello, It seems that Firefox3 has an encoding bug with ajax responses (see https://bugzilla.mozilla.org/show_bug.cgi?id=431701). Wa have a CFoms form with repeaters handled with ajax. On IE and Firefox 2, all is ok, but with Firefox 3, data encoding is not correct (ie "Amitit?s" instead of "Amitiés"), problem occurs when we add a new repeater if one with special character is already present, and also when we finally submit the form. A "solution" has been posted here : https://bugzilla.mozilla.org/show_bug.cgi?id=407213#c8 Is these solution applicable to cocoon 2.1.11/Dojo ? I've tried to replace "implementation.createDocument" with the .parseFromString method, but without success :-( Best regards, Johan Cwiklinski Hello, I still cannot use Firefox3 with cocoon ajax actions :-/ Since it's a Firefox bug, I should wait for a new release, but not sure it will be corrected soon. Anyways, as Firefox3 has been released, it's not possible to ignore users wich will use it. Any hints ? Ideas ? I'm stucked :-( Kind regards, Johan Cwiklinski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Firefox 3 ajax response
Hello, It seems that Firefox3 has an encoding bug with ajax responses (see https://bugzilla.mozilla.org/show_bug.cgi?id=431701). Wa have a CFoms form with repeaters handled with ajax. On IE and Firefox 2, all is ok, but with Firefox 3, data encoding is not correct (ie "Amitit?s" instead of "Amitiés"), problem occurs when we add a new repeater if one with special character is already present, and also when we finally submit the form. A "solution" has been posted here : https://bugzilla.mozilla.org/show_bug.cgi?id=407213#c8 Is these solution applicable to cocoon 2.1.11/Dojo ? I've tried to replace "implementation.createDocument" with the .parseFromString method, but without success :-( Best regards, Johan Cwiklinski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
