Re: Migration problem
Xindice is a dependency of the optional block 'xmldb'. As Bertrand I recommend to exclude all blocks you don't need. Joerg On 14.05.2009 10:32, Jean-Claude Moissinac wrote: Checked the command ./cocoon.sh, it works So, it's only the war deployed in tomcat6 which fails to work with the previously mentioned error. I have found nothing about Xindice in Install.txt or block.properties. Perhaps it is something always necessary for Cocoon? Jean-Claude - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Migration problem
On 14.05.2009 14:56, Jean-Claude Moissinac wrote: On Thu, May 14, 2009 at 1:55 PM, Joerg Heinicke joerg.heini...@gmx.de wrote: Xindice is a dependency of the optional block 'xmldb'. As Bertrand I recommend to exclude all blocks you don't need. So, I need to check all my applications to find what are my block dependencies. I suspect it could take a lot of time. I will began by removing all the blocks. When developing a new application you should start with the minimal set and add additional only when needed. Afterwards it's indeed more difficult. It should be possible though to exclude at least those blocks that you don't use for sure (like xmldb, midi, etc.). Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Migration problem
On 14.05.2009 15:08, Jean-Claude Moissinac wrote: With all blocks removed, the problem remains. May 14, 2009 3:02:41 PM org.apache.catalina.core.ApplicationContext log INFO: ERROR (2009-05-14) 15:02.41:363 [access ] (Unknown-URI) Unknown-Thread/Unknown-Class: Exception reloading java.security.AccessControlException: access denied (java.util.PropertyPermission org.apache.cocoon.settings read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:669) at org.apache.cocoon.util.PropertySettings.init(PropertySettings.java:74) at org.apache.cocoon.util.SettingsHelper.createSettings(SettingsHelper.java:43) at org.apache.cocoon.Cocoon.contextualize(Cocoon.java:237) at org.apache.avalon.framework.container.ContainerUtil.contextualize(ContainerUtil.java:116) at org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1421) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:499) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:537) ... I think cocoon is trying to write a file at a place where it has not necessary rights (line org.apache.cocoon.util.SettingsHelper.createSettings(SettingsHelper.java:43)) But??? It seems you made it one step further. This looks like a generic Java security manager issue rather than a Cocoon issue. I don't think it tries to write a file rather than reading a property: java.lang.System.getProperty(System.java:669) Seems it's prevented by security manager settings. Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Migration problem
On 14.05.2009 15:41, Jean-Claude Moissinac wrote: OK I will investigate in that direction. But it will help if I can find what cocoon is trying to write. (I think, I'm not the first to use cocoon.war in tomcat on Ubuntu) Looking at your stack trace it's at java.lang.System.getProperty(System.java:669) at org.apache.cocoon.util.PropertySettings.init(PropertySettings.java:74) // now read all properties from the properties directory readProperties(context://WEB-INF/properties, resolver); // read additional properties file String additionalPropertyFile = properties.containsKey(Settings.PROPERTY_USER_SETTINGS) ? (String)properties.get(Settings.PROPERTY_USER_SETTINGS) : System.getProperty(Settings.PROPERTY_USER_SETTINGS); It's not the file access troubling you but the access to system properties (last line in code snippet). This is not a file system issue but an issue with a configured SecurityManager which doesn't allow you to access system properties. Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: custom serializer
The idea is to have a pipeline that creates the ZIP file. This would be the one that matches the user's request. In the XML for the ZIP archive serializer you list the files you want to be included in the ZIP file. By using cocoon:/ pseudo protocol this can be another (maybe internal) pipeline. The docu [1] has such an example: foo.html is pulled out of another pipeline. Joerg [1] http://cocoon.apache.org/2.1/userdocs/ziparchive-serializer.html On 12.05.2009 21:02, Saeid Bashir wrote: I was not able to undrestand the code i want to know how to put xml in to string and encode it and display the result On 12.05.2009 14:17, Joerg Heinicke wrote: In which way not helpful? Is ZIP the wrong compression for you or did you just not get it to work? Joerg On 12.05.2009 07:53, saeid itune wrote: Basically i have xml file which it will be compressed and the result will be displayed to the user in compressed format. i want to get whole xml file as a string and pass it to function which will compress the string and returns the result as string. the result will be displayed to the user. ZipArchiveSerializer example was not helpfull for me - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: custom serializer
In which way not helpful? Is ZIP the wrong compression for you or did you just not get it to work? Joerg On 12.05.2009 07:53, saeid itune wrote: Basically i have xml file which it will be compressed and the result will be displayed to the user in compressed format. i want to get whole xml file as a string and pass it to function which will compress the string and returns the result as string. the result will be displayed to the user. ZipArchiveSerializer example was not helpfull for me - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: ServerPagesGenerator in 2.2 ?!
I'm not sure why you can't find the XSP block in 2.2 but there is a ServerPagesGenerator: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/generation/ Joerg On 11.05.2009 10:37, Søren Krum wrote: Hi! Now i tried out the ServerPageGenerator coming from cocoon:cocoon-xsp 2.1.11 but if i try to run it in an environment which is based on 2.2, i get the following error: Caused by: java.lang.NoSuchFieldError: manager at org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170) That normally points to a version conflict (i.e. different versions of the class. Here it seems to be ServletGenerator, but that one has a manager, and it is protected, so the ServerPageGenerator should be able to see it Anyone who has a idea what is going wrong? Søren D. Krum - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: ServerPagesGenerator in 2.2 ?!
Ah, that is true. Not all blocks actually got released as part of 2.2 release. But you can still take the block and use it. Regarding your error, the type of manager might have changed from ComponentManager to ServiceManager. Joerg On 11.05.2009 12:37, Søren Krum wrote: Joerg Heinicke wrote: I'm not sure why you can't find the XSP block in 2.2 but there is a ServerPagesGenerator: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/generation/ Joerg Looks like that is Snapshot 6, seems like that package never made it over to cocoon 2.2 release. Strange enough, in 2.2 is there still a manager field. And i have just one version of the ServerGenerator in the classpass, so should not be confusion about which version to use. Really strange. Thx for your suggestions anyway. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: ServerPagesGenerator in 2.2 ?!
Cocoon 2.2 still has an XSP block (cocoon-xsp) with the ServerPagesGenerator. Joerg On 08.05.2009 12:07, Søren Krum wrote: Hi! While upgrading from a cocoon 2.1 to 2.2 i found some pices of code using a ServerPageGenerator, but i was not able to find that one in one of the cocoon modules. Any idea if it was removed or in wihch module it was placed? The documentation of views (found here: http://cocoon.apache.org/2.2/core-modules/core/2.2/1374_1_1.html) knows about this generator, but that may just not up to date... Best Regards - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Howto: Make CSS available from within a stylesheet?
What exactly are you trying to achieve? An XSLT is used for transforming an XML structure into another one. There is no CSS involved. Do you want to style the output? Joerg On 29.04.2009 11:46, Yet another person wrote: I've been trying to use a css stylesheet in my xsl transformation but It doesn't come through. It seems cocoon doesn't understand relative paths nor does it understand resource/internal/stylesheets/file.css or any other link i've tried. I even made a pipeline to match the css from my sitemap but that didn't work either. It's probably something silly but I can't seem to find it - any help would be greatly appreciated Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: how to call continuation, created by button's action?
By redisplaying the form a continuation should be created anyways. It
should not be necessary to do this yourself.
Joerg
On 28.04.2009 07:50, Maria Grigorieva wrote:
By means of button I make the xml-file.
And I want after button click (and after making xml-file) to show in the
same page in browser the link to download this file.
2009/4/28 Joerg Heinicke joerg.heini...@gmx.de
Can you tell us what you are actually trying to achieve (independent from
the code)?
Joerg
On 25.04.2009 09:34, Maria Grigorieva wrote:
Hello!!!
I need to create continuation with the button's click.
var k;
..
form.lookupWidget(report).addActionListener(function(event) {
var str = dao.jdbc.getXML(id);
var doc = dao.jdbc.loadXML(str);
dao.jdbc.saveXML(path+id+.xml, doc);
k = new Continuation();
}
);
...
But outside this function I can't call this continuation... How to make it
visible?
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: how to call continuation, created by button's action?
Can you tell us what you are actually trying to achieve (independent
from the code)?
Joerg
On 25.04.2009 09:34, Maria Grigorieva wrote:
Hello!!!
I need to create continuation with the button's click.
var k;
..
form.lookupWidget(report).addActionListener(function(event) {
var str = dao.jdbc.getXML(id);
var doc = dao.jdbc.loadXML(str);
dao.jdbc.saveXML(path+id+.xml, doc);
k = new Continuation();
}
);
...
But outside this function I can't call this continuation...
How to make it visible?
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: COCOON-1887 (was: Getting started with C2.2 -- where's the exception information?)
On 30.01.2009 18:04, Andy Stevens wrote: I uploaded https://issues.apache.org/jira/browse/COCOON-1887 2 1/2 years ago and it's still waiting, even though it's a relatively trivial change and only about half a dozen lines of code if you ignore the comments and unit test :-( Hey Andy, this particular patch has been applied. Thanks, Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Getting started with C2.2 -- where's the exception information?
On 30.01.2009 18:04, Andy Stevens wrote: Nobody said 2.1 is dead, it is clearly (IMHO) in maintenance mode. Sounds good in theory, but the big assumption is that submitted patches might actually be applied. I uploaded https://issues.apache.org/jira/browse/COCOON-1887 2 1/2 years ago and it's still waiting, even though it's a relatively trivial change and only about half a dozen lines of code if you ignore the comments and unit test :-( Less, if you exclude the bit to preserve backward compatibility. And it's by no means the oldest patch in the summary list that's sent to the list every few weeks... That's not a problem with 2.1 but with Cocoon in general at the moment. There is not going on too much and the patch list is usually just growing. Asking for getting a patch applied usually helps though :-) Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Articles about Cocoon in French
Hi Christophe, you can actually do such changes to the documents yourself. See the link at the end of every page on cocoon.apache.org. I did it this time. They will go live with the next site update. Joerg On 11.02.2009 11:29, Christophe Nowicki wrote: Hi, I've wrote an article about Apache Cocoon in French : Link: http://www.csquad.org/2009/02/10/systeme-dimpression-pdf-restful-pour-le-web/ Article: Système d’impression PDF “RESTful” pour le Web This article explain in French the architecture used my the MAVISE database ( http://mavise.obs.coe.int/ ) for producing PDF documents. There is another article written by Pierre-Yves Landuré abount Apache Cocoon setup on Debian GNU/Linux. Link: http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-cocoon-2-1-x-et-fop-0-9x-sur-debian-4-0-etch Article: Installer Cocoon 2.1.x et FOP 0.9x sur Debian 4.0 Etch Could you add thoses two articles in the Articles section : http://cocoon.apache.org/1288_1_1.html Best Regards, - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
Original Message Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open Date: Fri, 23 Jan 2009 13:28:19 + From: Tony Stevenson pct...@apache.org Reply-To: commun...@apache.org To: travel-assista...@apache.org The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: generate pdf from xml with embedded image?
Marten van der Honing wrote:
Peter: Did you write a preprocessor in cocoon? Where can i find more info on
that?
Meanwhile i tried another approach:
xsl:variable name=image-base64 select=.//IMAGE/
You might try
xsl:variable name=image-base64 select=string(.//IMAGE)/
just to be sure.
fo:external-graphic
src=url('data:image/gif;base64,{$image-base64}')
height=3cm width=3cm /
But now i get an error in html instead of an pdf file:
java.lang.NullPointerException:
Cocoon stacktrace[hide]
java.lang.NullPointerException cocoon://fop_post/xsl - 4:14
Exception in StreamGenerator.generate() cocoon://fop_post/xsl - 4:14
[TransformerException]
context://fop_post/sitemap.xmap - 11:32 map:serialize type=xml
context://fop_post/sitemap.xmap - 7:33 map:generate type=stream
context://fop_post/sitemap.xmap - 44:37 map:serialize type=fo2pdf
context://fop_post/sitemap.xmap - 43:42 map:transform
context://fop_post/sitemap.xmap - 32:38 map:generate
context://sitemap.xmap - 1034:92 map:mount
Can you post parts of the actual Java stack trace?
Joerg
Maybe i should try to show the base64 as text in the pdf first to see if it
still there.
-Oorspronkelijk bericht-
Van: Peter Flynn [mailto:pfl...@ucc.ie]
Verzonden: donderdag 18 december 2008 10:24
Aan: users@cocoon.apache.org
Onderwerp: Re: generate pdf from xml with embedded image?
Ken Starks wrote:
[...]
I did have a few images that were stored also in a database, but I
would pre-process them in a seperate stage, generating a local copy,
and populating a table of the database with the path. This was a batch
process, not an interactive one, and it used python rather than
cocoon. (Actually, it could do a minor amount of image-processing as
well, such as cropping, changing contrast, creating thumbnails,
changing to a different format, Etc and used Image magick as well as
python).
I do something very similar, taking in Word XML documents. The
preprocessor extracts any encoded image data, converts them back to
image format, creates thumbnails and web-res versions, and adds details
of them to an XML file in their directory, rather than using a database.
The XSL[T] processes then reference them externally as images, which is
probably faster than doing database extraction and image conversion in
real time.
I suppose it depends on the amount of storage you have, and how
important it is to you to store your images on a database.
In this case there are typically only a handful of images, so a database
would be overkill: YMMV.
///Peter
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: FW: Problem with large xml using aggregate
Kothapalli, Rajani K wrote:
We have a pipeline that looks like:
map:pipeline
map:match pattern=*/*.testcontent
map:aggregate element=wrapper
map:part src=cocoon:/{1}/x/
map:part src=cocoon:/{1}/y/
map:part src=cocoon:/{1}/z/
map:part src=cocoon:/{1}/xx/
map:part src=cocoon:/{1}/xy/
/map:aggregate
map:transform src=x.xsl type=xslt-saxon8/
map:transform src=y.xsl type=xslt-saxon8/
map:transform src=z.xsl type=xslt-saxon8/
map:serialize type=xml/
/map:match
/map:pipeline
One of the request produces large xml
What size are we talking about?
and if I run it in its own generator, the xml comes up fine.
However, if it is a part of the aggregate it is clobbering the xml and then
xslt Parser is chocking on it.
Even without any xslt parsing, I can see that the xml is clobbered.
How do the sub pipelines look like? Are there components of yours or is
it just a plain file generator?
Error message says; Invalid Qname
Using cocoon-2.1.8
I played with outputbuffersize for pipelines
JVM_OPTS
CATALINA_OPTS
Cocoon servlet file-upload-size in web.xml
Cocoon.xconf
I would not expect any of those to help.
Joerg
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: How to set the language for a date?
Smigge wrote: Isn't there a simple way of just changing the locale - even only within one xslt? As you can see there is no standardized way of handling dates locale-aware in XSLT. I really recommend to do this using i18n functionality of Cocoon. Joerg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: FW: Caching XMLResourceBundle in a disk persistent store not possible
From what I see the only reason for not implementing Serializable is that XMLResourceBundle will miss its dependencies after deserialization, which is only the Logger which has to be injected by the component manager. So every call to getLogger() would return null after the deserialization. In 2.2 this is probably no longer a problem since there the logger is instantiated with the object. Joerg On 21.10.2008 17:57, Laurent Medioni wrote: Hi, as I did not have many answers on the users list, maybe the dev side has a better idea ? Thanks. -Original Message- From: Laurent Medioni [mailto:[EMAIL PROTECTED] Sent: mercredi, 15. octobre 2008 13:33 To: users@cocoon.apache.org Subject: Caching XMLResourceBundle in a disk persistent store not possible Hi, Our process of assembling a XMLResourceBundle being quite costly, I tried to use the core store, configured to be disk persistent. That is when I realised that XMLResourceBundle is not Serialisable (well, one of the log files told me first...). Do you see any reason why XMLResourceBundle could not be Serialisable ? (quite weird as it is supposed to represent a serialized file ;)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.1] Generator src from document content
On 14.11.2008 04:26, Palol Carlos wrote:
I'm trying to query a Daisy 2.2 repository from a Lenya 2 website
(Cocoon 2.1)
So i have XML documents like this:
mydoc
query
SELECT name WHERE InCollection('xyz')
/query
/mydoc
And would like to query that repository through HTTP API, like this:
http://user:[EMAIL PROTECTED]/repositoryquery?q=SELECT+name+WHERE
InCollection%28%27xyz%27%29
which returns an XML result.
What i would like to do (in the pipeline) is:
1. Read de XML query text node.
2. Escape the string, create de full url in an action, XSLT or else.
3. Generate (file generator) using the full url.
4. Transform, etc
I can't find a simple way to take content to de sitemap. Is it necessary
to use an action and access the document from it?
Hi Carlos,
There is no direct access to the content in the sitemap as you describe
it. Also you would need 2 generators in a pipeline what's not possible
(first one querying the repository, second one reading the file).
You need a 2-pipeline setup. In the main pipeline you query the
repository, transform the result adding an xinclude directive (an
element in the xinclude namespace) to it, run the xinclude transformer
and maybe some post transformations. The included document (even it
will replace the original XML from the query completely) will be created
from a sub-request to Cocoon (cocoon:/-protocol), i.e. second pipeline.
Here you have again the free choice about what to do.
Hope this helps,
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: not sure how to modify xsl match
What's the HTML result you get? I would have to check how onload is handled, but I'd expect this to be the problem. Cocoon Forms tries to set onload itself, I just don't know exactly how it handles existing onload values. Joerg On 04.11.2008 23:52, Paul Joseph wrote: Hi Robby, I *think* the template that is not matching is the one below. As you see, it calls forms-advanced-field-styling.xsl. The line on my xml file that seems to make the double-listbox work is this one: body If I change body to body onLoad=javascript:myJavaScriptFunction then the double-listbox does not work--says option.length() is null or not an object. thx! Paul ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; !--+ Include styling stylesheets, one for the widgets, the other one for the | page. As 'forms-advanced-field-styling.xsl' is a specialization of | 'forms-field-styling.xsl' the latter one is imported there. If you don't | want advanced styling of widgets, change it here! | See xsl:include as composition and xsl:import as extension/inheritance. +-- xsl:include href=forms-page-styling.xsl/ xsl:include href=forms-advanced-field-styling.xsl/ xsl:template match=head head xsl:apply-templates/ xsl:apply-templates select=. mode=forms-page/ xsl:apply-templates select=. mode=forms-field/ /head /xsl:template xsl:template match=body body !--+ !!! If template with mode 'forms-page' adds text or elements |template with mode 'forms-field' can no longer add attributes!!! +-- !--img border=0 src=images/Pagetitle.gif width=550 height=63/-- xsl:apply-templates select=. mode=forms-page/ xsl:apply-templates select=. mode=forms-field/ xsl:apply-templates/ p align=centerimg border=0 src=images/footer.jpg width=880 height=57//p /body /xsl:template /xsl:stylesheet Robby Pelssers wrote: Hi Paul, Could you post the snippet that matches the normal body tag? Is it something like xsl:template match=body ... /xsl:template That should also match the body tag with the onload attribute... Cheers, Robby -Original Message- From: Paul Joseph [mailto:[EMAIL PROTECTED] Sent: dinsdag 4 november 2008 19:00 To: users@cocoon.apache.org Subject: not sure how to modify xsl match Hi there, I have an xsl newbie question I am using the double-listbox style of a multivalue widget. This uses the forms-advanced-field-styling.xsl stylesheet. This stylesheet appears to match against body and the double-listbox works nicely on the many pages that have the body element. However on one (just one) page I have a body onLoad=javascript:myJavaScriptFunction() and not a plain old body My question is what is the best way to make the advanced field styling template match against this. thx! Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon become very slow on load (Solved)
On 09.10.2008 22:25, Thorsten Mauch wrote: Hallo Joerg, Thanks a lot for you help. The hint about the importPackage was the key for the solution. A least i removed a import of one of my new service classes and replace it with some line of JavaScript code. I have no idea why a simple module import can cause such heavy blocking, but I'm happy that my application works now very nice under heavy load. About reloading: I was successful disable it, but it had no effect on the blocking problem I'm glad I could help :-) Joerg Joerg Heinicke schrieb: I have no idea if setupContext() is such a heavy operation. From your other mail I saw you tried disabling reloading of the scripts without success. Did you fail disabling it or did it just have no effect? Do you use certain features in the scripts which you don't use in other applications? IIRC importPackage was once causing problems. Is it possible to figure out what in setupContext() or compileScript() (both locking on compiledScript) costs so much time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to implement back button functionality from within a flow script
On 08.10.2008 16:05, Paul Joseph wrote: Thank you kindly for your prompt reply Derek...I surmised this was the case but wanted to check with the experts... I'm not considering myself an expert especially on AJAX, but I second Derek's analysis. Joerg Derek Hohls wrote: Paul The short answer is, AFAIK, probably no. That said, I am sure there are some flowscript gurus who might show a way to do this with continuations? The right answer might be don't i.e. if a user has changed an item in a list, why take him back to a previous version of the list which will not show his changes? An alternative longer answer might be that you need to use some clever browser-side Javascript to manipulate the list values *inside the page it is displayed* (i.e. do not send the user off to a new page with another form) to make it appear like an instant change while, in the background, you use AJAX to send off the changed value. Without knowing more about the specifics of where you get the data from, where it goes to, and how it is validated etc. its not possible to flesh this out further. Sidebar: I have come across a number of articles recently which point out how poor the web is for dynamic applications and yet that seems to be what we are forcing ourselves to tackle. Square pegs in round holes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: How to force a Save As prompt?
On 08.10.2008 09:25, Matthias Müller wrote:
Hey, one more question:
in your example you serialize your stream as xml. i want to be flexible with this, e.g. for xml or pdf files.
That's not a problem at all. Actually wrapping map:serialize in map:act
is pointless in this case. Just have the action somewhere in your pipeline.
Joerg
- Ursprüngliche Mail
Von: Geert Josten [EMAIL PROTECTED]
Hi,
I typically do something like this:
map:match pattern=download/*/**
map:generate src=cocoon:/{2}/
map:act type=set-header
map:parameter name=Content-Type value=application/x-download/
map:parameter name=Content-Disposition value=attachment ;
filename={1}/
map:serialize type=xml/
/map:act
/map:match
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon become very slow on load
On 08.10.2008 17:20, Thorsten Mauch wrote: Hi All I have a really weird problem with cocoon 2.1.11. My Application becomes very slow under a load, even if it now relay heavy. A page request take up to one Minute. The strange point is that in another application I use exactly the same java code and it works well. All my request a past to a flow script and handled there. The time spend in the flow (10 ms) is very small can not cause the problem. With visualvm I figure out that a lot threads are blocked: http-8080-34 daemon prio=10 tid=0x081a0800 nid=0x45aa waiting for monitor entry [0x9dc4c000..0x9dc4cdc0] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:571) - waiting to lock 0xa6089138 (a java.util.HashMap) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:718) - locked 0xa7dea538 (a org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter$ThreadScope) The bad point is that I have absolutely no idea what the root cause of this is. Any help what I could check is really appreciated This does not look like an issue with XSLT processors or other pooled components since it's simply an area of code that's blocked. I have no idea if setupContext() is such a heavy operation. From your other mail I saw you tried disabling reloading of the scripts without success. Did you fail disabling it or did it just have no effect? Do you use certain features in the scripts which you don't use in other applications? IIRC importPackage was once causing problems. Is it possible to figure out what in setupContext() or compileScript() (both locking on compiledScript) costs so much time? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FlashVars
On 03.10.2008 17:56, Charlie Rose wrote: I am trying to embed a Flash movie in an html page. object clsid: ... param name=FlashVars value=lcId=1234567890 ... When I get to the lcId the ampersand is interpreted as entity ref indicator and the generation fails. I try to replace by amp; and it is never converted back. Likewise urlencoding, backslashing, and all other attempts to escape the ampersand in the query string fail. Are there any examples anywhere which demonstrate use of FlashVars inside object and embed tags? amp; is the way to go and it does not need to be converted back. The HTML parser on the client does that for you. lcId=1234567890 is actually wrong also in HTML. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMailTransformer
On 01.10.2008 01:14, Christian Decker wrote: java.lang.NoSuchMethodError: org.apache.cocoon.mail.transformation.SendMailTransformer.getLogger()Lorg/apache/avalon/framework/logger/Logger; at org.apache.cocoon.mail.transformation.SendMailTransformer.setup(SendMailTransformer.java:313) BTW: I'm using cocoon-mail-2.1.9 with cocoon 2.2, is that a problem and if yes how could I work around it? That's indeed the problem. The getLogger() implementations of 2.1 and 2.2 are incompatible. In 2.1 it returns o.a.avalon.framework.logger.Logger while in 2.2 we Apache Commons Logging and so the method returns o.a.commons.logging.Log. Compiling 2.1.9's SendMailTransformer against 2.2 libs should fix this but I wonder why you are not using 2.2's SendMailTransformer. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMailTransformer
On 01.10.2008 01:46, Christian Decker wrote: I wonder why you are not using 2.2's SendMailTransformer. There actually isn't any reason that I'm not using the 2.2's SendMailTransformer, except I was unable to find it. You see, I;m using mvn to manage the project and there appears to be no online repository that provides me the 2.2's version of cocoon-mail (according to http://maven.ozacc.com/search?keyword=cocoon-mailtype=all ) or am I just shooting in the wrong direction? I see it in the sources. Maybe we are just not yet releasing the mail block in 2.2. Reinhard? Is there any work left to do with this block? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database connection by cocoon 2.2
On 25.09.2008 12:53, yosauron wrote: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 23 in XML document from URL [jar:file:/home/caribdis/.m2/repository/org/apache/cocoon/cocoon-databases-bridge/1.1.0-SNAPSHOT/cocoon-databases-bridge-1.1.0-SNAPSHOT.jar!/META-INF/cocoon/spring/SpringToAvalonDataSourceBridge.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'beans'. at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:359) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) at org.apache.cocoon.spring.configurator.impl.AbstractSettingsElementParser.handleImport(AbstractSettingsElementParser.java:197) at org.apache.cocoon.spring.configurator.impl.AbstractSettingsElementParser.handleBeanInclude(AbstractSettingsElementParser.java:187) at org.apache.cocoon.spring.configurator.impl.AbstractSettingsElementParser.parse(AbstractSettingsElementParser.java:145) ... 59 more Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'beans'. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) I'm very confused, I don't understand why do I get the second error? Is it a versions dependencies errors? In that case, Which versions do I have to use to fix it? How do I know the versions of the dependencies that do I have to use? Forgive me but I'm very lost.. :'(. I hope that you can help me... This time it seems there is a problem with Spring jars. I can't help you with the dependencies in particular, I just interpret the error messages. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database connection by cocoon 2.2
On 23.09.2008 09:12, yosauron wrote: Please, Does anybody know where is the error? I have been searching the error for 5-6 days and I don't have any more clues... Can anyone help me? Caused by: java.lang.NoSuchMethodError: org.apache.cocoon.transformation.SQLTransformer.getLogger()Lorg/apache/commons/logging/Log; at org.apache.cocoon.transformation.SQLTransformer.configure(SQLTransformer.java:278) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:202) Hi, such errors usually result from incompatible jars. It means SQLTransformer.configure() is looking for a method getLogger() which it doesn't find. It's SQLTransformer's super class AbstractLogEnabled providing this method. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cforms + javaflow + sitemap problem
On 21.09.2008 15:11, Magsend wrote:
the content is still duplicates... but without style
My guess is that one of the parts comes with a content root element as
well (or something like that). How do index.xml and
form-template/{1}.xml look like?
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1.5.1 and Windows Handle Leak
On 12.09.2008 17:40, Stephen Connolly-2 wrote: I was able to get a patch that seems to work. There were only two transactions in SVN required for a back-port: http://svn.apache.org/viewvc?view=revrevision=56921 http://svn.apache.org/viewvc?view=revrevision=57424 I hope nobody else has to do this... but hopefully this information will be useful if they ever have to repeat this patching fun! Thanks for reporting back! Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1.5.1 and Windows Handle Leak
Stephen Connolly-2 stephen.alan.connolly at gmail.com writes: We have an application that is using Cocoon 2.1.5.1 (I know that's a wee bit old) With the application IDLE, no clients have even attempted to connect. We see on Windows a handle leak at a rate of approx 64 handles (32 Event and 32 Semaphore) every 5-6 seconds. Searching the archives I found COCOON-1305 [1]. Somewhere in the middle (around) discussion points to TPCThreadManager which was used by ContinuationsManager. Unfortunately, there is no fix/patch linked explicitly but on 12/Nov/04 it is confirmed that the issue is fixed: Migration from Excalibur Event to RunnableManager fixes this bug IMO. So I guess you can have look at the changes from around that time. Hope this helps, Joerg [1] http://issues.apache.org/jira/browse/COCOON-1305 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon 2.1.11, fc9, build.sh error
On 09.09.2008 01:21, Al wrote: I'm having trouble getting the sun java installed properly. alternatives never see the install and jpackage seems to also have problem with version 1.6 I uncommented : include.block.imageop=false in local.blocks.properties. Is that the best way to do option 2. It seems to compile now. Did I loose anything besides the ability to server images files from cocoon? I server static files from apache. Yes, that's the best option since you don't need the imageop block. You can even still serve images from Cocoon. The ImageReader is only for applying transformations to images on the fly, a rarely used feature I'd say. so that should have worked. I will have to look at it again. Maybe I dont have local file name correct. local.blocks.properties is correct as it is written in the blocks.properties. You have to have it in Cocoon's root dir where block.properties is as well. You also might need a build clean after removing a block. Imageop block has no dependencies so there should not be any new compile errors resulting from the deactivation. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon 2.1.11, fc9, build.sh error
On 09.09.2008 00:36, Al wrote: I'm having trouble getting the sun java installed properly. alternatives never see the install and jpackage seems to also have problem with version 1.6 I uncommented : include.block.imageop=false in local.blocks.properties. Is that the best way to do option 2. It seems to compile now. Did I loose anything besides the ability to server images files from cocoon? I server static files from apache. Yes, that's the best option since you don't need the imageop block. You can even still serve images from Cocoon. The ImageReader is only for applying transformations to images on the fly, a rarely used feature I'd say. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forms crash with selection-list/@src
On 01.09.2008 21:40, Andre Thenot wrote: I'm getting an error with CForms when trying to use selection-lists. If I embed the fd:items in the form model, under fd:selection-list, everything works fine. But if I try to reference that list from elsewhere, using the @src attribute of fd:selection-list, I get the stacktrace below. I am using Cocoon 2.2 and running it within Jetty. I've compared this with the samples but can't figure out what I'm doing wrong. java.lang.NoSuchMethodError: org.apache.cocoon.components.source.SourceUtil.toSAX(Lorg/apache/excalibur/xmlizer/XMLizer;Lorg/apache/excalibur/source/Source;Ljava/lang/String;Lorg/xml/sax/ContentHandler;)V at org.apache.cocoon.forms.datatype.DynamicSelectionList.generateSaxFragment(DynamicSelectionList.java:105) Hi Andre, you must have a classpath issue. The jar that contains SourceUtil and the one with DynamicSelectionList are not compatible. NoSuchMethodError means that the according sources would not compile against each other. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sticking with 2.1.* ( was '[Announce] Apache Lenya 2.0.2 released' )
On 01.09.2008 12:28, Andreas Kuehne wrote: Yes, for a pure 'uses' relataionship ... But there a re a bunch of transformers, actions and stuff ... this won't migrate withn a coffee break ! I don't get your point. What's the difference to a normal update? Joerg - Original Message From: Carsten Ziegeler [EMAIL PROTECTED] To: users@cocoon.apache.org Sent: Monday, September 1, 2008 11:20:11 AM Subject: Re: [Announce] Apache Lenya 2.0.2 released Andreas Kuehne wrote: Hi Andreas, intersting to hear lenya team's view on 2.2 / maven ! I'm shure there are many projects around not willing / not able to migarte to Cocoon 2.2 / Maven. What about a formal (sub-)project to maintain the 2.1.* thread ? And let's give it a diffent name ( like 'cocoon granite' ) to avoid the the smell of a dead version walking ... Imho, there is no need to use maven if you want to use Cocoon 2.2. Things might be easier (or not - depending on your pov) if you use maven, but it is not a requirement. Just download the required jars and use them as libs. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAOSecurityHandler
On 06.08.2008 02:30, Robin Rigby wrote:
I am looking for the Java equivalent of the JavaScript
var parser =
cocoon.getComponent(Packages.org.apache.excalibur.xml.dom.DOMParser.ROLE);
and the same for SourceResolver.
Sitemap components seem to get them from an Avalon ServiceManager and I
found a thread
suggesting to copy from ContainerTestCase. Is there not a simpler way?
Hi Robin,
you need indeed a ServiceManager to retrieve the components as follows:
DOMParser domParser;
try {
domParser = serviceManager.lookup(DOMParser.Role);
// do something with the DOMParser
} catch (ServiceException e) {
...
} finally {
serviceManager.release(domParser);
}
It depends on your use case if you can release the DOMParser instance
immediately in the finally block or want to keep it and release it for
example in a recycle method.
And: The Java code needs access to a Service Manager what means more or
less that it has to be a Avalon component itself.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Authentication
Magnus Haraldsen Amundsen Magnus.Haraldsen.Amundsen at computas.com writes:
We use the Coocoon authentication block in our web app through the following
dependency in our pom.xml:
In our Spring configuration we have declated a simple security handler and a
standard application:
This is used in the sitemap in the following way:
map:match pattern=do-login
map:act type=cauth-login
map:parameter name=application value=Sublima/
map:parameter name=name value={request-param:username}/
map:parameter name=password value={request-param:password}/
map:redirect-to uri=admin/
/map:act
map:redirect-to uri={request:contextPath}/login/
/map:match
The Java code to handle the login is as follows (snippet):
http://pastebin.com/m77ef2312
When ie. the username does not exist, the code throws an
AuthenticationException and the stacktrace is presented to the user. We want
the user to be directed back to the login page with the exception message as
an text explaining what went wrong. How do we do this?
Take a look at Cocoon's error handling [1]. You can catch this particular
exception in the error handlers block and do pretty much whatever you want with
it. A plain redirect would probably not work for you since you would lose the
information from the exception, but you can store it somewhere (e.g. as request
attribute) and grab it in the login page.
Joerg
[1] http://cocoon.apache.org/2.2/core-modules/core/2.2/1379_1_1.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: flowscript string length
On 25.07.2008 15:56, Jeff Schmitz wrote: Using cocoon 2.1 I'm trying to get the length of a string in my flowscript code, but it always returns undefined instead of a number. I've tried both of the below with the same results: var part = this is a test; var last = part.length(); var last = part.length; Do the string properties work in flowscript? part.length should work since your string is a JavaScript object rather than a Java object. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to stop validating the XML output
On 11.07.2008 00:20, Leonid Geller wrote: Does anyone know if there is an easy way to tell cocoon to stop validating the transformed XML output for correctness? E.g. I intentionally want to not close some element tags. As Andre said you are talking about well-formedness rather than validity. If possible, I would like to do this for only for some (limited number of) pipelines while the others will continue to function with validation as before. Rather don't try that. You might tell us what you actually try to do. If it is just about HTML output you only need to switch to the right serializer which can handle those elements correctly that must not be closed. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with setCharacterEncoding
On 08.07.2008 08:26, Gautam Joshi (jgautam) wrote: We are trying to set character encoding to UTF-8 in the request object (org.apache.catalina.connector.RequestFacade) to ensure that the Danish and some other characters are processed correctly. We observed however that just using request.setCharacterEncoding( encoding ) does not work and the Danish characters are converted to question marks. However when you add the line Enumeration e = request.getParameterNames() before request.getParameterNames() the encoding works and the original characters submitted from the form are retained. The request object is an instance of org.apache.catalina.connector.RequestFacade. Has anyone come accross this problem and does anyone know why accessing the method request.getParameterNames enables the character encoding to work appropriately? That's how it works. You MUST set character encoding BEFORE accessing request parameters. IIRC that's what form-encoding parameter is therefore with which Cocoon ensures that. See Cocoon's web.xml. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: block communication and page fragment
On 19.07.2008 19:26, Mansour Al Akeel wrote: Thank you, I am trying it now, but getting errors. I think it's with block communications. When I put this in my site map: map:aggregate element=root map:part src=cocoon:/block1/ /map:aggregate I get java.lang.StackOverflowError If I do this: map:aggregate element=root map:part src=cocoon:/block1/somefile.blck1/ /map:aggregate javax.servlet.ServletException: org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: block1/somefile.blck1 If you are using Cocoon 2.2 with actual blocks (compared to 2.1) you probably have to use the block protocol rather than cocoon protocol. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: test if map:read was successful?
On 16.07.2008 16:23, Nick McDonald wrote: I'm using map:read to send a file. I use cocoon.sendPage() in my flowscript to initiate the transfer; once the transfer is complete, I need to return to the flowscript and possibly perform some additional actions, depending on whether the file was successfully transferred. As it stands now, the additional action gets executed regardless of whether I cancel the download, it fails, etc. Is there anything I can do? I don't think you can really do something about it. A failing download might end with an exception on the server as well which you can handle. But whether a file was downloaded completely or the download cancelled by the user ... I don't think you get any information about it from the client. Also you don't know what the user does with a downloaded file anyway. Only approach that might work is via taking control of the download on the client via JavaScript, maybe the Ajax libraries provide such support. Then you react from there. But everything that's related to uploads or downloads is often restricted for security reasons. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database connection by cocoon 2.2
On 23.07.2008 08:00, Derek Hohls wrote: Not sure if you are speaking for the dev team here? No, that was my opinion. What exactly does kind of obsolete mean - has it been deprecated, or is it still a valid component in 2.2? Or is there is some other meaning? I'm not a native English speaker but I think obsolete is exactly what I want to express: It's still there, you are free to use it, but you don't need to since there are superior ways to do it like the DAO support provided by Spring. I did not intent any additional meaning than that (like deprecation). Joerg On 2008/07/19 at 01:08, in message [EMAIL PROTECTED], Joerg Heinicke [EMAIL PROTECTED] wrote: I agree with Boris. In Cocoon 2.2 the database block is kind of obsolete. An application should rather be developed with more standard means as provided by Spring. Cocoon was never very good at integrating database stuff. Joerg On 06.06.2008 10:05, Johannes Hoechstaedter wrote: I know, cocoon is based on spring. But isn't there another possibility with cocoon blocks only? There is this database-block. What it is good for, when I have to write my own spring application? I want to write as less code as possible. Johannes Johannes -- you may want to search for tutorials on using databases with Spring. My understanding is that with Cocoon 2.2 it is best to have Spring configure and manage any database connections. Then you can add Cocoon features (eg, the SQL transformer or whatever) once that is set up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hi
On 24.07.2008 00:30, student csu wrote: * Question: how to debug xslt in cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder There is hardly anything available allowing you to debug XSLT. You probably need one of the commercial XML editors. cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder as there is some important xml file that combines with my xslt and display but I am not aware of among so many important which xml it is combining .so I will be thankful to you just let me know how to debug xsl using in jbuilder2008 . If you just want to know which files are combined in a pipeline by aggregation or whatever (I don't quite get what really happens in your case) just raising the log level of Cocoon might help. If you want to see the actual content you might find the LogTransformer useful. It might be also helpful to show us your pipeline and explain what you are after. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: images in svg not serializing as jpeg
On 09.08.2007 14:14, Lincoln Mitchell wrote: How do I create a jpeg from an SVG which has reference to a relative external image? In previous posts I read that you can't write... xlink:href=image.jpg ... because the path CAN'T be relative. Is this true? Yes, that's true. The SVG2JPEG serializer (based on Apache Batik) has no idea on how to resolve relative paths since no context is available. A fix as letting Batik work with Cocoon's source resolver has never been implemented. Any workarounds? Only solution that works out of the box is to use a absolute http:// path pointing back to the Cocoon instance and let Cocoon resolve the path in the sitemap by providing an appropriate pipeline delivering the image. That way you can get the path even kind of relative. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to restrict file uploads to certain URLs?
On 29.01.2008 01:20, Andy Stevens wrote:
I have a new requirement for one of our sites to allow the users to
upload some files. However, I read in the Cocoon docs/wiki that
switching on the enable-uploads init parameter will make it use the
multipart request factory etc. on all requests it receives. This
seems to me like a lot of unnecessary work (and either disk IO or heap
churn) when only a couple of pipelines will be processing the uploaded
files.
If you look at the actual implementation you will see that there isn't a
real overhead:
CocoonServlet.service(..):
if (this.enableUploads) {
request = requestFactory.getServletRequest(req);
} else {
request = req;
}
That's exactly what you described, as soon as uploads are enabled
multipart request factory is used.
RequestFactory.getServletRequest(..):
String contentType = request.getContentType();
if ((contentType != null)
(contentType.toLowerCase().indexOf(multipart/form-data) -1)) {
// wrap request object in MultipartHttpServletRequest
}
return request;
This means the actual multipart parsing is triggered only by form
content type multipart/form-data - and that's what you have to set
explicitly on the form. So the overhead is only to check for that
particular request property.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with CInclude and nested exceptions
I remember a problem with exceptions/errors in flowscript swallowing the
actual exception just like
try {
...
} catch (Exception e) {
throw new Exception();
}
in Java.
Joerg
On 10.09.2007 13:18, Tobia Conforto wrote:
I'm currently experiencing an annoying problem where Cocoon does not log
exceptions generated by sub-pipelines called through CInclude.
Here is my setup: a pipeline (already nested in other calls) generates a
CInclude include element and passes it through the CInclude transformer.
The transformer invokes a sub-pipeline via a cocoon:/... url, which
executes a function or continuation call. Now, if the flowscript raises
an exception, such as a runtime EcmaError, I can't see it anywhere!
Here is what I get instead:
Exception page title (notice that EcmaError isn't mentioned anywhere!)
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
Exception in CIncludeTransformer
Java full stacktrace (abridged)
org.apache.cocoon.ProcessingException:
Sitemap: error calling function 'B'
Caused by:
org.mozilla.javascript.WrappedException:
Wrapped org.apache.cocoon.ProcessingException:
Sitemap: error calling function 'A'
Caused by:
org.apache.cocoon.ProcessingException:
Sitemap: error calling function 'A'
Caused by:
org.mozilla.javascript.WrappedException:
Wrapped org.apache.cocoon.ProcessingException:
Sitemap: error calling function 'C'
Caused by:
org.apache.cocoon.ProcessingException:
Sitemap: error calling function 'C'
Caused by:
org.mozilla.javascript.WrappedException:
Wrapped org.apache.cocoon.ProcessingException:
Failed to process pipeline
Caused by:
org.apache.cocoon.ProcessingException:
Failed to process pipeline
Caused by:
org.apache.commons.lang.exception.NestableRuntimeException:
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
Exception in CIncludeTransformer
Caused by:
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
javax.xml.transform.TransformerException:
Exception in CIncludeTransformer
The included flowscript function that raises the error is neither A, B,
nor C. Those are higher-level functions that call one another before
getting to the pipeline with the CInclude transformer. Why their
presence should cause so much exception noise is beyond me.
Am I losing exceptions because of some nesting limit? If that is so,
can I increase that limit?
Otherwise, how can I get the CInclude transformer to pass along the
exception, so that I can see why the inner pipeline is failing, at least
in the logs?
I don't recall having this problem before, so it could very well be that
I've reached a nesting limit.
Any help will be appreciated!
Tobia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic call pipeline at startup
If you don't want to program it yourself you have to use the infrastructure provided. In your case it's the servlet API as Andreas pointed out. Joerg On 30.01.2008 14:40, Alessandro Vincelli wrote: Thank you for this solution, but I want find a solution less inasive. Andreas Kuehne ha scritto: Can I configure Cocoon Cron to invoke the same pipeline also at application startup? I'm not familiar with cron ... but for sure you can get it by implementing an ServletContextListener. It will be called at sturtup / shutdown of your app or (un-)deployment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database connection by cocoon 2.2
I agree with Boris. In Cocoon 2.2 the database block is kind of obsolete. An application should rather be developed with more standard means as provided by Spring. Cocoon was never very good at integrating database stuff. Joerg On 06.06.2008 10:05, Johannes Hoechstaedter wrote: I know, cocoon is based on spring. But isn't there another possibility with cocoon blocks only? There is this database-block. What it is good for, when I have to write my own spring application? I want to write as less code as possible. Johannes Johannes -- you may want to search for tutorials on using databases with Spring. My understanding is that with Cocoon 2.2 it is best to have Spring configure and manage any database connections. Then you can add Cocoon features (eg, the SQL transformer or whatever) once that is set up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Max file size in FileGenerator and encoding in StreamGenerator
On 26.02.2008 16:05, Stefan Ludwig wrote:
my problem is solved!
now i use the FileGenerator. configured like this:
map:generate type=file src={request-param:file}/
I'm really surprised this works. It seems to be a valid alternative to
upload protocol. But then I wonder why having the latter at all?
last (non-working for bigger files) configuration for FileGenerator was:
map:generate type=file src=upload://file/
This sounds very much like an error in the upload source implementation.
Maybe it creates an additional buffer. But even that (an additional
memory usage of 20 MB) doesn't sound to bad.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cache-dir keeps adding same jar files when creating an object
I might be wrong but I don't think the cache-dir is created by Cocoon. Joerg On 16.08.2007 21:54, footh wrote: The cache-dir in my cocoon app keeps adding about 4 megs of jar files every time I instantiate a certain class. The class in question is the ServiceClient class from Axis2. Simply using this code (in a class called from a javaflow) causes the problem: org.apache.axis2.client.ServiceClient sc = new org.apache.axis2.client.ServiceClient(); The problem is, I use this object quite often. So, as you can imagine, the cache-dir grows quite large. In a couple days, it reaches over 3 gigs. I can probably figure out a way to create this object and stick it in the application context for reuse, but I'd prefer to figure out what is going on with cocoon and fix it there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More continuation scope questions ... [was: map:flow scope?]
On 01.02.2008 20:43, Steven D. Majewski wrote: So it appears that the continuation uri must resolve back to the same sitemap that originated the initial flowscript call. Yes, they have to. IIRC this feature was only introduced later on for security reasons and not there from the beginning. I'm not sure there is an option to switch it off. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IncludeCacheManager vs. SourceUtil.toSAX
On 11.06.2008 15:00, Christoph Gaffga (triplemind.com) wrote: What is the best practice on including another pipeline? Does SourceUtil does use the pipeline cache also. And is IncludeCacheManager really using the pipeline cache? Somebody might correct me here, but I'm pretty sure ... Both methods just ask Cocoon for executing the pipeline. Since it is simply an internal request all the features provided by Cocoon are applied - including caching. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
On 31.05.2007 09:20, Niels van Kampenhout wrote: I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! I know what you mean, here in our office everyone call matchers pipelines too :-) But that's actually not correct, matchers are just not pipelines. I explained it recently on the dev list because somebody asked if he can change this in the documentation [1]. I guess I should add my explanation to the official documentation. Joerg [1] http://marc.info/?t=12134488441r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultipartHttpServletRequest in a generator
On 16.06.2008 23:10, Grzegorz Kossakowski wrote: Situations like this are little bit worrying me but anyway standard question: why do you want to cast to MultipartHttpServletRequest? MultipartHttpServletRequest provides a method get(String) for access to multiparts which can't be accessed in another way. This method is not available from an interface. Is this proxy castable to org.springframework.aop.scope.ScopedObject? Then you would be able to call getTargetObject() and so get access to the actual MultipartHttpServletRequest object. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Firefox 3 and URL
In Javascript you can use prototype to redeclare functions of an object. I wonder if it works though with core libraries or if they aren't locked. Joerg On 02.07.2008 08:48, Luca Morandini wrote: i have : xElt.getElementsByTagName(...); xElt is a XMLElement. i want to use your function instead of getElementsByTagName but i don't know how can i make it. Hmm... as I see it, there is only one way: change every instance of xElt.getElementsByTagName(pipeline) to getElementsByTagNameNoNS(xElt, pipeline, map) either manually or using your editor of choice searchreplace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pass wildcard parameters to transformer
On 10.06.2008 07:39, Johannes Hoechstaedter wrote:
I have the follwing smapping:
map:match pattern=test/*
...
/map:match
Now I want to insert this paranmeter defined by the wildcard in the
generated xml document. I want to do this by a transformer. All I
managed is to insert a variable by a url paramter (test?paramName=Value)
and use-request-parameterstrue/use-request-parameters for the
transformer. Can I pass a wildcard variable, too? Thanks everybody in
advance
You can use map:parameter name=myParameter value={1}/.
Due to caching issues we recommend to not use
use-request-parameterstrue/use-request-parameters.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: character-maps in cocoon
On 09.06.2008 06:29, Heather Rankin wrote:
Are character-maps supported in Cocoon 2.1? I need to replace lt; and
gt; entity references with the literal characters '' and '' and can't
get it to work in Cocoon. I have the following character-map in my XSLT:
xsl:output use-character-maps=cm1 method=xml indent=yes
encoding=UTF-8 media-type=text/xml/
xsl:character-map name=cm1
xsl:output-character character=lt; string=lt;/
xsl:output-character character=gt; string=gt;/
/xsl:character-map
This works fine outside of cocoon (e.g. in Oxygen). But when I run it
through the second transformer in the following pipleline:
map:match pattern=terms
map:generate src={request-param:url} type=html/
map:transform type=xslt2 src=transforms/getTerms.xsl/
map:transform type=xslt2
src=transforms/convertStringToXML.xsl/
map:serialize type=xml/
/map:match
... the lt; and gt; characters do not get replaced (remain escaped).
Is this something to do with the xml serializer? Do I need to change
something there?
disable-output-escaping (and it seems also charater-map) only passes
serializer hints along with the actual XML. With a second transformation
following the one using disable-output-escaping these hints get lost.
That's why you should not use this feature in Cocoon. It only works in
a non-streaming environment, where you serialize after each transformation.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsl:copy-of select
That makes it xsl:copy-of select=sql:rowset/sql:row/sql:email/. You have to navigate the tree. Joerg On 09.06.2008 11:05, Johannes Hoechstaedter wrote: The output is the following: sql:rowset nrofrows=... name=lastmod sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row sql:row sql:login_namename/sql:login_name sql:emailemail/sql:email /sql:row /sql:rowset - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XSP block (was: Type 'serverpages' does not exist for 'map:generate')
Moving this discussion from users list (for reference [1]) to dev list. On 06.06.2008 19:02, Alfred Nathaniel wrote: Warning: I'm stating my own opinion here, nothing official or something like that. There are at least three problems with XSP: 1. No active committer is interested in XSP anymore, and even more, hardly anyone wants to invest her time in technology that seems to be deprecated in every dev's head but still block is not officially marked as deprecated. I may be not as active as you but I am a committer who is still very interested in XSP. In may daytime job we have 1000+ XSPs in production and no intention to drop that technology in the forseeable future. XSP has its shortcomings and pitfalls but after 7 years experience we know how to handle that. 2. The only reason why people keep trying to use XSP is that it has decent documentation on our site and this documentation has no information about XSP status. We should really explain people that Templates + Flowscript is much better approach. I think the reason why XSP appeals to newcomer is that the concept is familiar from JSP, and it is a combination of the three core technologies which Cocoon handles extremely well: XSP = XML + XSLT + Java. Personally, I still do not consider Flowscript an alternative for enterprise websites for three reasons: a.) Serverside JavaScript is an additional level in the technology stack you and your team have to master. b.) I would not bet my head on Rhino being threadsafe, and it is such a big beast to debug it yourself. c.) Continuations are a great idea, but how do you know when it is safe to free the memory? 3. XSP is really old technique and is not maintained by anyone (again officially, at dev/commits list). I'm not the one willing to take costs of XSP maintenance in C2.2 therefore I'll probably vote -1 for any actions leading to release of XSP block for C2.2. This is my first such a strong voice in this case but I firmly believe it's a high time have a concrete opinion. XSP is a really mature technology which hardly needs any maintenance any more. The reason why the XSP block (as many other blocks) is not released yet is actually more of a C2.2 issue than an XSP problem. Still, I'm open for discussion of course. I'd prefer to have this sort of discussion on the dev-list. I completely agree with Alfred. I don't see any reason for not releasing XSP block. Yes, somebody has to do the actual work. But why blocking it when somebody puts in the effort? You can estimate the maintenance costs by looking at the changes in the last years in the 2.1 branch. Joerg [1] http://marc.info/?t=12124988641r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
Joerg Heinicke joerg.heinicke at gmx.de writes: 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? That's a very good question - with a negative answer: A buffer of that particular size is created initially. [..] One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. Hi Bruce (et al.), this functionality is now in SVN. The initial buffer size is 8192 bytes (but not yet configurable), the default flush buffer size is 1 MB and configurable on the pipeline. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type 'serverpages' does not exist for 'map:generate'
On 04.06.2008 02:25, Derek Hohls wrote: XSP is not available in Cocooon 2.2 - see: http://marc.info/?l=xml-cocoon-usersm=120349702914226w=2 where the developers suggest you migrate your code to use java objects + flowscript + template. Alternatively, stick to Cocoon 2.1 unless you have some other critical reasons to use 2.2 XSP is available, it's just that the block infrastructure has not been migrated yet to Cocoon 2.2/Maven. I don't think (but somebody might correct me here) that actual code needs to be changed. So the migration should be rather easy. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss 5.0.0.CR1 / Cocoon.war deployment issue - java.lang.IllegalAccessError: class javax.xml.parsers.SecuritySupport12
On 03.06.2008 20:55, Andrew Madu wrote: I am in the process of migrating my application from 4.0.3SP1 to 5.0.0.CR1, on Win XP SP1, and am receiving the following error message in the server logs when placing my WAR (Cocoon 2.1.8) into the deploy directory. It would seem that there is an issue concerning the xml-apis.jar/xml-apis-1.3.04 files situated within Cocoon.war/WEB-INF/lib(?): [code] 2008-06-04 01:09:54,796 WARN [org.jboss.detailed.classloader.ClassLoaderManager] (main) Unexpected error during load of:javax.xml.parsers.SecuritySupport12 java.lang.IllegalAccessError: class javax.xml.parsers.SecuritySupport12 cannot access its superclass javax.xml.parsers.SecuritySupport The closest I got is [1]. From that I'd guess you should avoid to deploy the mentioned classes and to the webapp's WEB-INF/lib directory. Joerg [1] http://qaix.com/java-programming/30-567-jboss-3-tomcat-4-0-3-illegalaccesserror-read.shtml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installation problem
On 30.05.2008 14:16, [EMAIL PROTECTED] wrote: I have just installed a new Cocoon 2.1.10 WAR file to our Tomcat 5 server. When you call Cocoon for the first time the following error shows up in the log file and Cocoon never appears in the browser. Has anyone seen this before? Here is the error stack. Any help you may be able to offer would be great. To my knowledge, there is only the one Cocoon instance on Hey Vince, One problem could be multiple or incompatible versions in general of Xerces on your classpath. The way to fix it depends on the JVM (endorsed lib directory) and your setup. IMO more likely though in this case is that you are using a Xerces version that's just incompatible with HP's Deli/Jena. It looks like Jena is using Xerces internally directly. This means it's not an issue of fixing the classpath but figuring out what exact version of Xerces you need to use. Another question is if you need the Deli block at all. Maybe you can just deselect it, see INSTALL.TXT on how to do it. Joerg 2008-05-29 15:34:58 StandardContext[/cocoon]StandardWrapper.Throwable java.lang.NoSuchMethodError: org.apache.xerces.xni.grammars.XSGrammar.toXSModel()Lorg/apache/xerces/xs/XSModel; at com.hp.hpl.jena.datatypes.xsd.XSDDatatype.loadUserDefined(XSDDatatype.java:341) at com.hp.hpl.jena.datatypes.xsd.XSDDatatype.loadUserDefined(XSDDatatype.java:305) at com.hp.hpl.deli.VocabularyConfig.parseConfigFile(VocabularyConfig.java:170) at com.hp.hpl.deli.VocabularyConfig.parseConfigFile(VocabularyConfig.java:184) at com.hp.hpl.deli.VocabularyConfig.init(VocabularyConfig.java:65) at com.hp.hpl.deli.Vocabulary.init(Vocabulary.java:43) at com.hp.hpl.deli.Workspace$1CreateWorkspace.init(Workspace.java:189) at com.hp.hpl.deli.Workspace.configure(Workspace.java:338) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in thread Store cocoon-ehcache Spool Thread java.lang.NullPointerException
On 22.05.2008 04:05, Magnus Haraldsen Amundsen wrote: We've got a Cocoon 2.2 webapp using the Cocoon Authentication 1.0 block to authenticate users. A short period of time after logging in we sometimes get a Exception in thread Store cocoon-ehcache Spool Thread java.lang.NullPointerException. Can you provide a stacktrace? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML binding in the default namespace
On 21.05.2008 08:04, Suzan Foster wrote: https://issues.apache.org/jira/browse/COCOON-1794 But the patch does not change anything for non-repeater bindings. Does this imply that binding to default namespace actually works in general, the namespaces are just not propagated down to repeater children? Joerg Grzegorz Kossakowski schreef: Suzan Foster pisze: Grzegorz, I didn't mean it as criticism. I understand that Cocoon is a large codebase and that there are often more pressing issues. The issue comes down to relative JXPathContexts not inheriting the namespace declarations. My patches call JXPathBindingBase.applyNSDeclarations and JXPathBindingBase.applyLeniency on the result of .JXPathContexts.getRelativeContext. Mainly RepeaterJXPathBinding and MultiValueJXPathBinding are affected by this issue. Hope this helps. Is there an issue in JIRA with attached patches? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange (?) cocoon.context.getInitParameter() == null problem
On 15.05.2008 12:16, Shahriar Aghajani wrote: Hi, I'm using Cocoon 2.2 RC2 on top of Tomcat and I had a strange problem with getInitParameter(). I defined some parameters in Tomcat's context block for my application, eg: These init parameters are not in Tomcat's servlet.xml (or whatever it is named), but in the webapp's web.xml. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CForms Aggregator Widget--preserving line breaks in text areas
On 14.05.2008 13:00, Paul Joseph wrote: However, when I use a Text Area type widget in an aggregator, I find that the Aggregator does not seem to be able to retrieve and display any information in any of the widgets that make up the aggregator, IF I enter even a single line break in the Text Area widget that is part of the Aggregator widget. It is able to save it with line breaks to the database--it is only on retrieval that it the Aggregator seems to have difficulty due to the line breaks. With aggregator you mean the aggregate field widget [1]? Can you show some code? Joerg [1] http://cocoon.apache.org/2.2/blocks/forms/1.0/486_1_1.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebContinuation is null when using a custom Generator
On 14.05.2008 21:08, shai200 wrote: I'm trying to use a flowscript with a custom generator (not a JXTemplate), so I'm trying to get access to the continuation Id. But when I invoke WebContinuation kont = FlowHelper.getWebContinuation(objectModel); in the setup() method, kont is null... how do I retrieve it? Do I need to work with a org.apache.cocoon.components.flow.ContinuationsManagerImpl ? From what I understand you just try to retrieve it in the Java code of your custom generator? For the continuation you don't need the JXTemplateGenerator, but something that puts it into the object model. Since I don't know what your application I can't really recommend how to do it but you might want to take a look at the callers of FlowHelper.setWebContinuation(..). Maybe that helps you. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImageReader displays path instead of image. Very annoying.
On 11.05.2008 20:19, shai200 wrote:
I'm using the following ImageReader component configuration:
map:components
map:readers default=resource
map:reader name=image src=org.apache.cocoon.reading.ImageReader
logger=sitemap.reader.image pool-max=32/
/map:readers
/map:components
And the following pipelines:
map:match pattern=img/*.jpg
map:read type=image src=resource/img/{1}.jpg mime-type=image/jpeg /
/map:match
map:match pattern=img/*.gif
map:read type=image src=resource/img/{1}.gif mime-type=image/gif
/
/map:match
And instead of showing me the image, it shows me the absolute path of the
image... This is very annoying. How do I fix this?
http://www.nabble.com/file/p17179690/image.jpg
Can you try it with the standard ResourceReader? ImageReader is for
transforming images rather than just passing them to the client (though
it also should work).
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 24.04.2008 16:08, Bruce Atherton wrote: Thanks for the response. About setting the buffer size, this looks like it could be what I am looking for. A few questions: 1. Do I have to set the buffer size on each transformer and the serializer as well as the generator? What about setting it on the pipeline? It is on the pipeline and only there. You can set it on the map:pipe element in the map:components section, so that it is applied to each pipeline of that type. Or on any individual map:pipeline element in the map:pipelines section. 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? On an unrelated note, is there some way to configure caching so that nothing is cached that is larger than a certain size? I'm worried that this might be a caching issue rather than a buffer issue. Not that I'm aware of. Why do you think it's caching? Caching is at least configurable in terms of number of cache entries and I also think in terms of max cache size. But beyond a certain cache size the cache entries are written to disk anyway so it's unlikely resulting in a memory issue. How do you read the object graph from the heap dump? To tell you the truth, I'm not sure. This is the hierarchy generated by the Heap Analyzer tool from IBM, and is from a heap dump on an AIX box running the IBM JRE. My guess as to the Object referencing the ComponentsSelector is that the ArrayList is not generified, so the analyzer doesn't know the actual type of the Object being referenced. What the object actually is would depend on what CachingProcessorPipeline put into the ArrayList. That is just a guess, though. And I have no explanation for the link between FOM_Cocoon$CallContext and ConcreteCallProcessor. Perhaps things were different in the 2.1.9 release? No serious changes since 2.1.9 which is rev 392241 [2]. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168 [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java?view=log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem after trunk update
On 25.04.2008 07:33, Robin Rigby wrote: Updated trunk. Rebuild OK. Then mvn jetty:run gives this first ERROR [main] (ContextLoader.java:214) - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.VerifyError: (class: org/apache/cocoon/generation/ServerPagesGenerator, method: generate signature: ()V) Incompatible object argument for function call Just a guess: Something in the ServerPagesGenerator has changed and it is not binary compatible. The hierarchy is now inconsistent if not everything has been recompiled. Does mvn clean install fix this? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HELP] SitemapEvenListener
On 23.04.2008 05:48, Patrick Heiden wrote: Still no ideas/solutions to share (Jörg?). I can't hide, can I? ;) A have read [1] and assume that one of your aforementioned colleagues is Jörg Heinicke ( maybe you have a solution meanwhile, Jörg? Especially: How are you able to use declarative transaction demarciation within this jungle? ;) ) Declarative transaction demarcation indeed used to work nicely for me. But I have never tried it in the context of Cocoon. And it's now a year ago that I worked with that stuff the last time. You need at least to elaborate a bit more. Maybe I'm still able to help you :) Joerg [1] http://forum.springframework.org/showthread.php?t=32270page=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.1]change response http status
On 16.04.2008 07:24, nanomonk wrote: Hmm.. no, I need to set status code according to some events during executing my own serializer, for example: if all ok done - status code 1, some error - 2, another error - 3... so, can I to access to Response object from serializer(exactly via response.setStatus(1) in a code)? if not - maybe another true-way is exist? Isn't the serializer rather late for such logic? Can you determine this value beforehands, e.g. in an Action? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do I use multiple custom generators for a single page?
On 23.04.2008 18:49, James 7 wrote:
The xml is not written to file so I cannot simply include them as parts of
an aggregate, at least as far as I know.
You can, using the cocoon:/ pseudo protocol in map:aggregate causing a
sub request in the same sitemap:
map:match pattern=test
map:aggregate element=site
map:part src=cocoon:/book-{1}.xml/
map:part src=cocoon:/body-{1}.xml/
/map:aggregate
map:transform/
map:serialize/
/map:match
map:match pattern=book-*
map:generate src=generator1/
map:serialize type=xml/
/map:match
map:match pattern=body-*
map:generate src=generator2/
map:serialize type=xml/
/map:match
This is documented at [1], section Aggregating.
Joerg
[1] http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 23.04.2008 20:56, Bruce Atherton wrote: Here are some specifics, in case they are relevant. One heap analysis showed 1.5 Gigabytes of memory being held by the object at the end of this tree (package names suppressed to keep this readable): - ScriptableObject - FOM_Cocoon - FOM_Cocoon$CallContext - ConcreteTreeProcessor - InvokeContext - CachingProcessorPipeline - ArrayList - Object - ComponentsSelector - ComponentsSelector - Collections$SynchronizedMap - HashMap - Array of HashMap$Entry - HashMap$Entry (size including children = 1.5Gig) How do I read this? I tried to reproduce it in the code but it does not make sense to me. FOM_Cocoon$CallContext has no reference to the ConcreteTreeProcessor or the other way around. Object can neither have a reference to ArrayList or ComponentsSelector. So what does it mean? That HashMap$Entry object had the following child tree, each one a bit smaller than its parent. Only the largest child shown at each level: - HashMap$Entry (a different one) - TraxTransformer - TransformerHandlerImpl - SAXResult - JxTemplateTransformer - JxTemplateGenerator$TranformerAdapter$TemplateConsumer After this there are two JxTemplateGenerators that split the size. The bigger one goes to FormsTemplateTransformer, CIncludeTransformer, and on and on into a long loop of JxTemplateGenerator$StartElement and JxTemplateGenerator$EndElement. Do you run into the OOME just by one request or only after certain number of requests since the content is stored somewhere? It seems to me that it should be possible to put a limiter on the transformers that says that if more than a certain volume of data is put through, an exception is thrown. I know that part of the page may have been rendered before the error page shows up, but I am fine with that. I'd be happy to limit each part of the pipeline to outputting no more than 10Meg. Does it mean you want to flush the OutputStream after certain amount of data? What about [1] and [2]? Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168 [2] http://marc.info/?l=xml-cocoon-devm=120477640924395w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NEWBIE question: HTML Generator
On 16.04.2008 07:48, Heather Rankin wrote: Browser's configured to use an HTTP Proxy. Can I configure anything on the cocoon end to deal with this? You can configure the JVM to use a proxy by setting system properties: http://java.sun.com/j2se/1.5.0/docs/guide/net/proxies.html Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: date bug related to leap year?
On 12.04.2008 07:40, Paul Joseph wrote: Do you know what I need to do to switch it to the JDK lib.? Any thing to grep for that I then need to replace with its equivalent JDK call? I can't answer your questions directly right now, but I searched for ICU4J on our changes page [1] and found following entries: - Version 2.1.7 (March 23 2005) CForms: separate FormattingDateConvertor that uses java.text.SimpleDateFormat and Icu4jDateFormatter that uses ICU4J. There was previously an automatic switch to ICU4J if the library was present in the classpath, which sometimes caused some strange results as it behaves a bit differently. Committed by SW. - Version 2.1.6 (November 19 2004) The daylight time cause error when timezone is CST. Updated icu4j to 3.0. Committed by AG. Thanks to Johnson Hsu. See Issue 30372. See second one might be exactly what you are looking for. It seems we fixed it only by upgrading ICU4J. Hope this helps, Joerg [1] http://cocoon.apache.org/2.1/changes.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: date bug related to leap year?
On 10.04.2008 06:01, Paul Joseph wrote: In short, I see this problem only for the date datatype for a field widget that is used in a repeater type widget on a Windows platform. Could it be related to the date library? As far as I know we used to use or still use IBM's ICU4J but there should be an option to switch to JDK library. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
footh footh at yahoo.com writes: Ok, I applied all the changes in order. Since some changes affect the same class, I'm assuming the latter change contains any changes from a previous revision. I don't know how exactly you mean this, but one *change* does definitely not include the former changes since it is always a diff against the latest revision. If I were you I would just grab the latest revisions of the mentioned files. Those ones also have all the former changes. There should be no incompatibility introduced between 2.1.10 and latest code in the 2.1 SVN branch. I'm getting this error when building: \src\java\org\apache\cocoon\components \flow\ContinuationsManagerImpl.java:538: clone() has protected access in java.lang.Object clonedRootWebContinuations.add(rootContinuation.clone()); Did I mess up applying the changes? Have you successfully built the revised version? That's more or less my fault. I made another commit where I did not separate clearly the issues and part of the fixes you are actually interested in got into that commit. It's http://svn.apache.org/viewvc?rev=643294view=rev, but what you actually only need from this commit are part of the changes to WebContinuation: add Cloneable to its implements list, get the two methods toString() and clone(). Leave the rest just as it is if you are not interested in Flowscript. Hope this helps, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple or single cocoon instances
On 03.04.2008 18:44, Shahriar Aghajani wrote: I'd like to know about this too. How do people run a fleet of disparate Cocoon applications/websites on a single server? I have a hand full of Cocoon sites that I'm running on the same server, under Tomcat, each as a separate virtual host. We are running one application per Cocoon instance per Tomcat service. Anyway to minimize the memory usage? Can I move portions of the cocoon 2.2 libraries under Tomcat, and if so, will tomcat share the objects across the contexts? The only way to minimize memory is to have multiple applications running in one Cocoon instance. You can move libraries to Tomcat's shared classloader but this does save you hardly any memory since the objects are still per web application. And unless I'm forced to do this (for portals for example) I would not get started these things due to potential classloading issues. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 02.04.2008 12:24, footh wrote: Yes, I only applied 642694 as it was the only the link in your previous post. I altered the three files: AbstractContinuable.java Continuation.java ContinuationContext.java to the files in the links and rebuilt Cocoon, only switching out the javaflow library on my test instance. Nothing else changed in my test environment from the calculable results I got last time. I'm using YourKit profiler and the Apache JMeter testing tool with debugging turned off. Should I have applied all the fixes you described below? 642694 was supposed to give you the first improvements by limiting the continuation's memory footprint. 642756 is a better fix for the same problem cleaning up even more. In the latter revision I reverted the changes to AbstractContinuable and ContinuationContext and made new changes to Continuation and JavaInterpreter (as outlined below in more details). The other fixes are not necessary and I don't know if you would see improvements from them. BUT your version of the ContinuationsManagerImpl has serious threading issues. Depending on your tests it might happen that you shoot the expired continuations clean up thread by creating new continuation at the same time (leads to ConcurrentModificationException). Again for more details read below. COCOON-2109 solves another problem with cleaning up the expired continuations. If this one has effects depends on your actual tests. And again for more details read below :) The best is to have all fixes, yes. Otherwise a certain test run could just have bad luck and does not show the improvements. Also do you wait exactly 10 minutes? That's only the time when the first continuations get invalidated, so the clean up thread had hardly any chance to jump in. Do you have better results waiting let's say 15 or 20 minutes? Joerg --- Joerg Heinicke [EMAIL PROTECTED] wrote: On 01.04.2008 18:52, footh wrote: Just ran a very simple test using the changes from revision 642694 and had unusual results. Byte arrays, and consequently the BufferedOutputStream still took up large amounts of retained space in the total memory usage. So, this didn't change. However, the memory did not clean up neatly like it did before...after about 10 minutes. Before, I would do, say 1000 samples, and total Tomcat memory would balloon to a point. Then I'd wait 10 minutes and would observe the byte array data cleaning up in the profiler with total Tomcat memory staying the same. After that, I'd run another 1000 samples and the total Tomcat memory would not increase again until hitting around the 1000th sample and the cycle would repeat. With these new changes, the memory cleaned up a little bit, but not nearly as much as before. And the total memory would start increasing before I hit the control sample size. The BufferedOutputStream path appears to be the same as well - flowing up to ContinuationsManagerImpl. Perhaps I'm doing something wrong? I did make this changes to version 2.1.10 NOT 2.1.11 since I haven't upgraded my site to the new version yet. That's no good news :( And I can't see how this should be possible. Which changes exactly did you apply? Only rev 642694 [1]? The actual two files changed are ContinuationContext (added method onSuspend()) and AbstractContinuable (calling context.onSuspend() right before Continuation.suspend()). The method only nulls out some values, so I can't see how this should have worsen the situation. Both files had not changed between 2.1.10 and 2.1.11, so this can neither be a reason. Second, this was only the first approach. After Torsten's review I did a more brave approach setting the complete context to null before the continuation gets suspended [2]. Here I reverted the above 2 changes to AbstractContiuable and ContinuationsContext. The fix went into Continuation (storing functionName and setting context to null in suspend()) and JavaInterpreter (instantiating Continuation with functionName and retrieving it from there later on). Again I can't see how this should have worsen the situation. Both files had again not changed since 2.1.10. Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that one helps you at all pretty much depends on whether you access old continuations or not (when using a wizard you not only go forward along the expected path (page 1, page 2, etc.) but also go back). The last important fix is for synchronization issues in ContinuationsManagerImpl [5]. This definitely has some impact, it's usually unlikely that fixing synchronization improves performance. If you don't have this fix I can imagine that the situation is as bad as you describe it for the following reasons: If something creates a new continuation while the clean up thread for removing expired continuations is active it kicks the latter one with a ConcurrentModificationException - and the clean up just stops. This would
Re: Javaflow - major memory issue
On 01.04.2008 18:52, footh wrote: Just ran a very simple test using the changes from revision 642694 and had unusual results. Byte arrays, and consequently the BufferedOutputStream still took up large amounts of retained space in the total memory usage. So, this didn't change. However, the memory did not clean up neatly like it did before...after about 10 minutes. Before, I would do, say 1000 samples, and total Tomcat memory would balloon to a point. Then I'd wait 10 minutes and would observe the byte array data cleaning up in the profiler with total Tomcat memory staying the same. After that, I'd run another 1000 samples and the total Tomcat memory would not increase again until hitting around the 1000th sample and the cycle would repeat. With these new changes, the memory cleaned up a little bit, but not nearly as much as before. And the total memory would start increasing before I hit the control sample size. The BufferedOutputStream path appears to be the same as well - flowing up to ContinuationsManagerImpl. Perhaps I'm doing something wrong? I did make this changes to version 2.1.10 NOT 2.1.11 since I haven't upgraded my site to the new version yet. That's no good news :( And I can't see how this should be possible. Which changes exactly did you apply? Only rev 642694 [1]? The actual two files changed are ContinuationContext (added method onSuspend()) and AbstractContinuable (calling context.onSuspend() right before Continuation.suspend()). The method only nulls out some values, so I can't see how this should have worsen the situation. Both files had not changed between 2.1.10 and 2.1.11, so this can neither be a reason. Second, this was only the first approach. After Torsten's review I did a more brave approach setting the complete context to null before the continuation gets suspended [2]. Here I reverted the above 2 changes to AbstractContiuable and ContinuationsContext. The fix went into Continuation (storing functionName and setting context to null in suspend()) and JavaInterpreter (instantiating Continuation with functionName and retrieving it from there later on). Again I can't see how this should have worsen the situation. Both files had again not changed since 2.1.10. Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that one helps you at all pretty much depends on whether you access old continuations or not (when using a wizard you not only go forward along the expected path (page 1, page 2, etc.) but also go back). The last important fix is for synchronization issues in ContinuationsManagerImpl [5]. This definitely has some impact, it's usually unlikely that fixing synchronization improves performance. If you don't have this fix I can imagine that the situation is as bad as you describe it for the following reasons: If something creates a new continuation while the clean up thread for removing expired continuations is active it kicks the latter one with a ConcurrentModificationException - and the clean up just stops. This would mean though that it was just bad luck in your new test. I don't know how exactly you profiled your system. You should definitely NOT run on debug log level. I fixed the synchronization issues in favor of the debug log level: There are no longer two sets maintained but the second set (which was for debugging purposes only) gets recreated on demand, i.e. debug log level, which locks the manager for that time. But it should improve the overall situation though. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=642694 [2] http://svn.apache.org/viewvc?view=revrevision=642756 [3] https://issues.apache.org/jira/browse/COCOON-2109 [4] http://svn.apache.org/viewvc?view=revrevision=642843 [5] http://svn.apache.org/viewvc?view=revrevision=643295 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 27.03.2008 00:31, Joerg Heinicke wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? I committed a fix [1] that limits the data that is stored with the ContinuationContext which at least removes the redirector and so the BufferedOutputStream instances from the Continuation's memory footprint. This should give you a big improvement if the BufferedOutputStream took 50% of the memory for you. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=642694 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character escaping problem with custom generator
On 30.03.2008 03:39, shai200 wrote:
I have a custom generator with a generate() method that looks like this:
public void generate() throws IOException, SAXException, ProcessingException
{
contentHandler.startDocument();
contentHandler.startElement(, content, content,
emptyAttr);
contentHandler.characters(xhtml_output.toCharArray(), 0,
xhtml_output.length());
contentHandler.endElement(,content,content);
contentHandler.endDocument();
}
where xhtml_output is some html code.
My sitemap entry looks like this:
map:match pattern=xmlaction
map:generate type=skunk /
map:serialize type=xml/
/map:match
The problem is that this returns HTML code with escaped characters ( i.e.
lt; and gt; instead of and , etc.)
You have to actually parse the XHTML, not pass its content as
characters. I came across a class today, StringXMLizable, that can help
you if you don't want to do the parsing yourself:
new StringXMLizable(xhtml_output).toSAX(contentHandler);
If you have a ServiceManager available (Serviceable) you can also do the
parsing yourself:
SAXParser parser = null;
try {
parser = (SAXParser) manager.lookup(SAXParser.ROLE);
InputSource is = new InputSource(new StringReader(xhtml_output));
parser.parse(is, contentHandler);
} finally {
manager.release(parser);
}
The second approach is definitely preferable, especially since
StringXMLizable has a questionable implementation [1] not using Cocoon's
infrastructure.
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=120685987703854w=4
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 27.03.2008 04:39, Torsten Curdt wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by environment ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 18.03.2008 03:07, footh wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: i18n:text stored in an xsl:variable
On 20.03.2008 13:29, Rainer Koschnick wrote:
It seems that the results of a i18n:text/ translation cannot be stored
in a xsl:variable/.
That has nothing to do with i18n. What you are trying to do just does
not work with XSLT 1.0.
xsl:template match=paramText
xsl:variable name=param0
i18n:text key=[EMAIL PROTECTED]/
/xsl:variable
span
i18n:translate
i18n:text key={text()} /
i18n:param
xsl:value-of select=$param0 /
/i18n:param
/i18n:text
/i18n:translate
/span
/xsl:template
But in the output $param0 is not shown (since it's empty).
It's not empty, but it contains only a more or less unusable result tree
fragment in it. You can only access it with xsl:copy-of
select=$param0/. That's why XSLT processors usually provide an
extension function to convert a RTF into a nodeset (on which you can
operate again as usually).
This does not help with your problem, but it seems you figured out
yourself to get what you want.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: i18n:text stored in an xsl:variable
On 20.03.2008 15:43, [EMAIL PROTECTED] wrote: SOLUTION 2: Pass i18n elements as text to remain in results for later transforms. xsl:variable name=param0 xsl:text disable-output-escaping=yeslt;i18n:text key=[EMAIL PROTECTED]/gt;/xsl:text /xsl:variable This will very likely not work. The escaped XML remains text in the pipeline up to serialization. disable-output-escaping is only a hint for the serializer. So a I18nTransformer run after that stylesheet will never get to see that escaped XML as XML but only as text - and just pass it on. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inject the result of an action into a generator
On 25.03.2008 00:31, shai200 wrote:
This doesn't work for me for some reason. I get an error (see end of this
message).
My code snippet is:
public class XMLInjectAction extends AbstractAction {
public Map act (Redirector redirector,SourceResolver resolver, Map
objectModel, String source, Parameters params) {
Map sitemapParams = new HashMap();
String xml=contenth1Automatically Generated By Action:
Hello/h1/content;
sitemapParams.put(paramAction, xml);
return sitemapParams;
}
}
And my sitemap entry is:
map:match pattern=xmlaction
map:act type=xml-injection
map:generate
map:parameter name=param
value={paramAction}/
/map:generate
/map:act
map:transform src=demo/welcome.xslt/
map:serialize type=xhtml/
/map:match
Additionally to Vadim's comment, your approach of injecting XML from an
action into a generator is wrong. An action is for deciding sitemap
paths, constructing pipelines, not for creating or working with the
actual data. A solution to your problem might be flowscript but you
better might explain what you actually try to do, your requirements.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inject the result of an action into a generator
On 25.03.2008 18:46, shai200 wrote:
This requirement is the primary function that I'll need from Cocoon,
otherwise it's not good for me and I'll have to find some other servlet
generating framework.
It's not that Cocoon does not support this functionality in general.
What we said so far only means you picked the wrong component types.
Actions are for different purpose than data generation. Look at Vadim's
post regarding the alternatives.
What I require is an Action Generator (rather than the existing
FileGenerator) that takes XHTML output that a POJO (i.e. and Action class)
returns and then moves it down the pipeline.
From what I understand you are looking for a component converting
Strings into XML without coping with the parsing - otherwise you could
just implement a generator. But even parsing is totally easy, an
implementation of your own generator could be:
InputSource source = new InputSource(new StringReader(xmlString);
SAXParser parser = null;
try {
parser = (SAXParser) manager.lookup(SAXParser.ROLE);
parser.parse(source, xmlConsumer);
} finally {
manager.release(parser);
}
xmlConsumer is available in a generator.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compiled vs. Interpreted Sitemap Engine (Cocoon 2.x)
On 25.03.2008 21:00, Robert La Ferla wrote: btw - this applies to Cocoon 2.1 as well. Anyone know how exactly it works? See Carsten's reply on the dev list: http://marc.info/?l=xml-cocoon-devm=120644301119918w=4 Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inject the result of an action into a generator
On 25.03.2008 22:45, shai200 wrote: Alright, so since you're already in the groove of answering my questions (thanks btw), I would need my generator class to also have access to the entire Request Map (preferably in the form MapString,String[] where the String[] key is the set of values in case a value is declared twice, but that's not so crucial) as well as the Session object / map... how would I go about that? Generators are SitemapModelComponents [1] and so have access to a map that we call object model in the setup(..) method. If you extend from an existing generator (ServiceableGenerator [2] is mostly a reasonable choice) you only have to override the setup(..) method and the generate(..) method. You can access request from the object model using the ObjectModelHelper [3]: ObjectModelHelper.getRequest(objectModel); Disclaimer: What I explained is pretty much the Cocoon 2.1 way. If you use 2.2 this will still work but there might be better ways to do that like component setup through Spring. But I guess this does not make setup(..) obsolete, only additional component configurations. Joerg [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/sitemap/SitemapModelComponent.html [2] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/ServiceableGenerator.html [3] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/ObjectModelHelper.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.5 and cocoon
On 24.03.2008 21:03, Robert La Ferla wrote: Cocoon is Java 5 or even Java 6 compatible. I think this is true for Cocoon 2.1 and above but not for 2.0 which has a package with enum in the namespace. I'm tempted to say of course not thinking that this should be obvious. I mean when did we stop to support 2.0? Must have been at least 4 years ago (last release 2.0.4 was end of 2002). Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.5 and cocoon
On 22.03.2008 11:07, Patrick Heiden wrote: Some parts of my domainmodel rely on java-1.5 specific stuff like Generics and so on. Within my first cocoon steps I don't have changed the source=1.3 attribute and of course get the 'generics are not supported in -source 1.3'-build-error. Is this the only thing I have to change to use java 1.5? Depends on what you are using to build your project. In my ant projects I have both 'source' and 'target' attributes set to 1.5. See http://ant.apache.org/manual/CoreTasks/javac.html I am using maven to build my project and cocoon 2.2 as my web-tier. I've read that it is also necessary to change some cocoon src-files wich use 'enum' as identifier because since 1.5 it is a keyword. Is this right? So what do I actually have to change when using 1.5 and cocoon 2.2? Nothing except for the build configs mentioned above. Cocoon is Java 5 or even Java 6 compatible. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inject the result of an action into a generator
On 18.03.2008 01:50, shai200 wrote: I am wondering about another option: is it possible to generate a JSP and then from within the JSP call a to a bean to which I'll pass the request object? Or will the JSP not have access to the request? Generate a JSP? Sounds horrible ;-) In general the JSP integration in Cocoon is not the best - to put it mildly. Can you describe what you actually want to do before getting into implementation details. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 17.03.2008 20:50, footh wrote: Thanks for all the replies. I did some more digging into the profiling data. It turns out that the ContinuationsManagerImpl is at the top of the object path of the byte arrays where org.apache.cocoon.environment.util.BufferedOutputStream is the actual parent of the arrays. Wait, does the ContinuationsManagerImpl store the complete pipeline output? That's the only usage of Cocoon's BufferedOutputStream. Can you show the object hierarchy? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
