Re: XHTML Serializer block/Ajax: Bug
On 3/16/07, Joerg Heinicke [EMAIL PROTECTED] wrote: (moving to dev list) [...] But why not staying with HTML then??? Why is the XHTMLSerializer be used in those cases? IMO we should NOT implement any special case handling in XHTMLSerializer but tell the people to use the HTMLSerializer. As the original author of the code, if you don't want to implement quirks, then, what's the difference between the XHTML serializer and the XML serializer? If you don't need quirks, you don't need to support browsers, then simply use the XMLSerializer and forget about it, the XHTML and HTML do exactly this job of supporting as many browsers as possible, no? Pier
Re: [GT2007] It's that time of the year again...
On 3/16/07, Gianugo Rabellino [EMAIL PROTECTED] wrote: ... Arje Cahn skrev: What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon +7.22 :-) Pier
Fwd: what does this mean?
Cool! :) What bank is it? :-P Pier Begin forwarded message: From: Upayavira [EMAIL PROTECTED] Date: 19 January, 2007 21:00:46 GMT+01:00 To: Adelia Green [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: what does this mean? Adelia Green wrote: I am trying to get logged into my banking site and it keeps showing me this. What the hell does it mean? This means that your bank uses Apache Cocoon to develop their website, and they have a problem with it. We at Apache cannot really help you with a problem on your bank's site - you'll have to find a way to contact them directly. However, letting them see the cryptic message you included below should help them find the source of your problem. Regards, Upayavira Resource not found /content/03/03302/diFiles/layoutXSL/default/portal-page.xsl (Permission denied) org.apache.cocoon.ProcessingException: Unable to get transformer handler for cocoon://webcenter/contentAccess?file=diFiles/ layoutXSL/default/portal-page.xsldiid=03302: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler cause: java.io.FileNotFoundException: /content/03/03302/diFiles/ layoutXSL/default/portal-page.xsl (Permission denied) full exception chain stacktrace[hide] org.apache.cocoon.ProcessingException: Unable to get transformer handler for cocoon://webcenter/contentAccess?file=diFiles/ layoutXSL/default/portal-page.xsldiid=03302: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler at org.apache.cocoon.transformation.TraxTransformer.setup (TraxTransformer.java:320) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setu pPipeline(AbstractProcessingPipeline.java:383) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingP ipeline.setupPipeline(AbstractCachingProcessingPipeline.java: 609) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.prep arePipeline(AbstractProcessingPipeline.java:488) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.proc ess(AbstractProcessingPipeline.java:440) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invo ke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke (ActTypeNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNod e.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invok e(PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invo ke(PipelinesNode.java:89) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc ess(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc ess(ConcreteTreeProcessor.java:180) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:243) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNod e.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invok e(PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo de.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invo ke(PipelinesNode.java:89) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc ess(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc ess(ConcreteTreeProcessor.java:180) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:243) at org.apache.cocoon.Cocoon.process (Cocoon.java:606) at org.apache.cocoon.servlet.CocoonServlet.service (CocoonServlet.java:1119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at
Re: Maven dictatorship and software parasitism (was Re: Maven info wanted)
On 29 Sep, 2006, at 11:53 , Sylvain Wallez wrote: Makes me think we can write a new chapter in the Software Darwinism story: Software Parasitism, where in order to survive, a project needs to plug into existing organisms and suck its vital substance out of them. Some of the host organisms survive and can even take benefit of the parasite (i.e. symbiosis), some suffer badly but survive, some die, and some find ways to get rid of the parasite. ROTFLMAO ... maven == sucker ??? :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: Java SE 6 no longer includes Rhino source code
Maybe this is something that could be tackled by the JCP list. Pier On Jul 4, 2006, at 3:04 PM, Torsten Curdt wrote: Sounds like bad news for those hoping for javascript (continuations) support coming with mustang :-/ -- Forwarded message -- From: Frank O'Neill [EMAIL PROTECTED] Date: July 3, 2006 10:44:12 AM CEDT To: [EMAIL PROTECTED] Subject: Java(TM) SE 6(Mustang) no longer includes Rhino source code Reply-To: [EMAIL PROTECTED] Dear Licensee, This message is to inform you of Sun's decision to remove the Mozilla Rhino (JavaScript for Java) product from the Java Platform, Standard Edition (Java SE) 6. This means that Rhino source code will no longer be available in the weekly source builds posted on the Partner Web site, starting with build 90 which was released on Friday, June 30. All previous builds containing the Rhino source have been removed from the Partner Web site. Sources for Rhino will be made available upon request under the Netscape Public License. The decision to remove Rhino from Java SE 6 is based on differences in the license terms of the two products. We remain committed to enabling standardized integration with scripting languages through our planned implementation of JSR 223, and will continue to encourage developers and ISVs to offer interoperability through their traditional product channels or on java.net at: https://scripting.dev.java.net/ Questions or inquires regarding this change can be sent to your regular contact in Java Licensee Engineering (JLE). Best Regards, Java Licensee Engineering smime.p7s Description: S/MIME cryptographic signature
Re: Flowscript in Spring
On 18 May 2006, at 13:04, Sylvain Wallez wrote: FYI: http://www.theserverside.com/news/thread.tss?thread_id=40522 ??? Isn't Spring supposed to be a container manager a-la Avalon ??? Pier smime.p7s Description: S/MIME cryptographic signature
VNU Europe moves to Cocoon...
It's quite some time since you heard new announcements from me, but I think this is quite important... We just finished launching the first of the EU countries here at VNU, powered by Cocoon: Italy. This follows our very first launch (two years ago) of the UK sites powered by Cocoon, and intensifies the effort and dedication that the VNU team is putting in the Cocoon platform as a whole, producing one of the biggest pool of websites all powered by one excellent technology. So, go and check out http://www.vnunet.it/ (you won't understand much unless you're Italian), and all the sites related to it: http://www.channelonline.it/ http://www.computer-idea.it/ http://www.databusiness.it/ http://www.fotoideaonline.it/ http://www.gdoweb.it/ http://www.networknews.it/ http://www.pcmagazine.it/ http://www.pmi-business.it/ And in the following months, we will take care of the other countries: Belgium, Nederlands, France, Spain, Germany... Once again, I have to thank for this major milestone the people who actually made it happen: - Ross McDonald (my favorite slave-monkey, you'll hear a lot more about him) - Jeremy Quinn (who, as always, helped us immensely) - Arje and Jeroen Reijn (yes, we _do_ use Hippo as our CMS) and all the Hippo team down in Amsterdam - Gianugo and SourceSense/Pronetics and all the peepz at VNU in the UK, Germany, Spain and France, who picked up the toy and delivered (once again) an _excellent_ set of sites. And last (but not least), all the management team at VNU which believed in the technology and gave us carte-blanche to go ahead and use it... Pier smime.p7s Description: S/MIME cryptographic signature
Re: Problem with XHTMLSerializers
Have you tried the serializers block? I've been hacking around a
lot with it back in the old days and it's the only one I trust to
send stuff to IE. We've been using since we started at VNU.
Pier
On 7 Apr 2006, at 09:34, Jeroen Reijn wrote:
Hi,
eventough this topic is quite old, I was wondering if Helma got it
working?
I'm looking at the same problem now.
Regards,
Reijn
hepabolu wrote:
On 11/3/05, *Jeroen Reijn* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Helma,
We have the same problem with our sites. As far is I know they
only
workaround
is by putting a space between the script tags like
script#160;/script
Thanks. I already did that, but it's really not that elegant. BTW
I somehow managed to get this fixed but I have no clue what I did
different now.
Another problem that cropped up with the exhtml serializer is
that ' are changed to apos; so all my little java scripts
suddenly became useless:
script src=bla.jsdoSomething('xsl:value-of select=someparam/
');/script turned into
script src=bla.jsdoSomething(apos;paramvalueapos;);/script
any idea?
Bye, Helma
--
Met vriendelijke groet,
Kind regards,
Jeroen Reijn
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
smime.p7s
Description: S/MIME cryptographic signature
Re: [Vote] Release plan for 2.1.9
On 21 Mar 2006, at 08:20, Carsten Ziegeler wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 please! Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Release plan for 2.1.9
On 21 Mar 2006, at 17:42, Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Although we already agreed informaly on the release plan, we should do a formal vote. +0 I don't see the point of voting for such an obvious decision. Is there a rule requiring new releases to be first approved by a vote? I mean new releases should be automatic. IMHO it's not very useful to cast any vote for a maintenance release in a stable branch. http://cocoon.apache.org/devinfo/releasing.html Pier smime.p7s Description: S/MIME cryptographic signature
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier smime.p7s Description: S/MIME cryptographic signature
Re: [zone] apache2 restarts automatically now
On 10 Mar 2006, at 07:24, Bertrand Delacretaz wrote: I have configured apache2 to start automatically for http:// cocoon.zones.apache.org/ , so at least that page should come up when the zone is restarted. Not being familiar with Solaris's smf, I did it the old /etc/init.d way. Did you put a link from /etc/init.d/... to the Runlevel 2 scripts? ln -sf /etc/init.d/apache /etc/rc2.d/S99apache You can use apachectl directly in there as well ln -sf /usr/local/apache/apachectl /etc/init.d/apache ln -sf /etc/init.d/apache /etc/rc2.d/S99apache But remember the link in 'rc2.d', called S99. (which means start with order 99). Pier The live Cocoon demos are still restarted via crontab only, so they might come up later, for now. I haven't touched the Daisy config, so it still needs a manual start when the zone restarts. If one of our Daisyists could write a script to start it and put it in /home/daisy (I think it needs some delay between starting the various components?), it would be easy to run that automatically from /etc/init.d. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: new Jira filter: COCOON-open-with-patch
On 1 Mar 2006, at 08:12, David Crossley wrote: That filter is COCOON-open-with-patch http://issues.apache.org/jira/secure/IssueNavigator.jspa? requestId=12310771 How can we get Jira to send that to [EMAIL PROTECTED] once per week? Is this all right? Every week starting now... Issue Subscription Filter: COCOON-open-with-patch (101 issues) Subscriber: cocoon Key Summary COCOON-1785 I18nMessage - null parameter values causes NPE http://issues.apache.org/jira/browse/COCOON-1785 COCOON-1782 [PATCH] Support for CSS classes in cocoon forms XSL http://issues.apache.org/jira/browse/COCOON-1782 COCOON-1781 Processing phase listener cannot be configured from form definitio http://issues.apache.org/jira/browse/COCOON-1781 COCOON-1779 [PATCH] JUnit tests for LocaleAction http://issues.apache.org/jira/browse/COCOON-1779 Pier smime.p7s Description: S/MIME cryptographic signature
Re: new Jira filter: COCOON-open-with-patch
On 1 Mar 2006, at 17:59, Antonio Gallardo wrote: Follow the Edit link of the issue you want to change. There is a section Other Info containing a checkbox field Patch available. IIRC edit option is available to committers. Is this correct, Pier? Yep... Can't give it to *world* unfortunately, or the first idiot who checks it out is likely to screw up our entire repo... I'm inclined, though, to give away membership to the Jira group also to non-committers, people working for companies that use Cocoon, subscribers to the mailing list that don't have privileges, and so on and so forth... Or we might give it to all Jira users, at least there's a registration behind it, and the email address must be validated before logging in for the password thinghy... Up to you guys.. Pier smime.p7s Description: S/MIME cryptographic signature
Re: new Jira filter: COCOON-open-with-patch
On 1 Mar 2006, at 22:39, Jason Johnston wrote: On Wed, 2006-03-01 at 11:59 -0600, Antonio Gallardo wrote: Follow the Edit link of the issue you want to change. There is a section Other Info containing a checkbox field Patch available. IIRC edit option is available to committers. Is this correct, Pier? If that is the case then it's a problem for us non-committers who like to contribute by creating and attaching patches to issues. Without permissions to set the Patch Available flag, our contributions are likely to go unnoticed. I guess this was already a problem when you used the [PATCH] keyword in the issue title, as that would require permissions to edit the issue as well, correct? Yeah, it's not fantastic let's say... There should be really an option to search for issues with attachments, rather than relying on a patched flag in the issue itself... Pier smime.p7s Description: S/MIME cryptographic signature
Re: HTMLSerializer problem
On 21 Feb 2006, at 09:41, Josias Thoeny wrote: Hi, I didn't get any feedback on the user list for this one... I updated my local copy of cocoon 2.1.x and now I'm getting an exception when I serialize with the HTMLSerializer (serializer block), see the relevant part of the stacktrace: [...] Caused by: java.lang.NullPointerException: Required System ID is NULL at org.apache.cocoon.components.serializers.util.DocType.init (DocType.java:76) at org.apache.cocoon.components.serializers.HTMLSerializer.body (HTMLSerializer.java:158) at org.apache.cocoon.components.serializers.EncodingSerializer.startEleme nt(EncodingSerializer.java:459) at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag (ToXMLSAXHandler.java:204) at org.apache.xml.serializer.ToSAXHandler.flushPending (ToSAXHandler.java:277) at org.apache.xml.serializer.ToXMLSAXHandler.startPrefixMapping (ToXMLSAXHandler.java:348) at org.apache.xalan.templates.ElemElement.constructNode (ElemElement.java:328) at org.apache.xalan.templates.ElemElement.execute(ElemElement.java:288) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes (ElemApplyTemplates.java:393) at org.apache.xalan.templates.ElemApplyTemplates.execute (ElemApplyTemplates.java:176) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates (TransformerImpl.java:2411) ... 101 more I didn't configure a default doctype for the serializer, so it uses the following one (defined in HTMLSerializer.java): public static final DocType HTML401_DOCTYPE_COMPATIBLE = new SGMLDocType( HTML, -//W3C//DTD HTML 4.01 Transitional//EN, null); The system ID is null, which causes the mentioned problem when the following code is executed (around line 158 in HTMLSerializer.java): this.doctype = new DocType(this.doctype.getName().toUpperCase(), this.doctype.getPublicId(), this.doctype.getSystemId()); When I change new DocType(...) to new SGMLDoctype(...) it works. Here is my configuration of the serializer: map:serializer logger=sitemap.serializer.html mime-type=text/html; charset=utf-8 name=html pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.components.serializers.HTMLSerializer encodingUTF-8/encoding /map:serializer Is there something wrong with my configuration or is this a bug? Anybody else having this problem? Ah... That might be something I committed last week, as I was working exactly on doctype behavior... That said, it works on my local host here, so, I'll try to replicate your error... Pier smime.p7s Description: S/MIME cryptographic signature
Backporting patch? (Was: Re: svn commit: r376354)
How do I apply this to TRUNK now? Sorry, completely clueless about SVN Externals! :-P Pier On 9 Feb 2006, at 17:17, [EMAIL PROTECTED] wrote: Author: pier Date: Thu Feb 9 09:17:45 2006 New Revision: 376354 URL: http://svn.apache.org/viewcvs?rev=376354view=rev Log: Better handling of DocTypes. Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/ apache/cocoon/components/serializers/EncodingSerializer.java cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/ apache/cocoon/components/serializers/HTMLSerializer.java cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/ apache/cocoon/components/serializers/XHTMLSerializer.java cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/ apache/cocoon/components/serializers/XMLSerializer.java smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r376379 - in /cocoon/blocks/serializers/trunk: charsets/ charsets/src/org/apache/cocoon/components/serializers/encoding/ java/org/apache/cocoon/components/serializers/
On 9 Feb 2006, at 19:37, Antonio Gallardo wrote: [EMAIL PROTECTED] wrote: Author: pier Date: Thu Feb 9 10:49:12 2006 New Revision: 376379 URL: http://svn.apache.org/viewcvs?rev=376379view=rev Log: Backporting changes from BRANCH_2_1_X Backporting? You are foreporting, right? ;-) E sta` a guarda` er capello! (loosely translated for the non Italians, picky, are you! :-) Pier smime.p7s Description: S/MIME cryptographic signature
Re: In for a beer tomorrow in London?
I'll have to pass... The wife has a flu (fourth day at almost 40º today) and I'm the nurse! Pier On 23 Jan 2006, at 15:23, Gianugo Rabellino wrote: Hi, I'm coming to London tomorrow, staying overnight. Is anyone willing to join me for a beer or two, some curry and whatever comes to mind? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: (Re)Licensing question
On 10 Jan 2006, at 17:22, Andrew Stevens wrote: From: Helma van der Linden [EMAIL PROTECTED] Date: Tue, 10 Jan 2006 17:31:25 +0100 Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? Given that GNU [1] list the Apache licenses as GPL-Incompatible, Free Software Licenses, I've always interpreted that to mean that you can't link to (i.e. make use of) Apache-licensed libraries (jars) in a project that you're releasing under the GPL. They don't appear to have an equivalent list for LGPL compatibility, unfortunately. I do recall that previous discussions on this list have stated that Apache-hosted projects aren't allowed to [L]GPL libraries in their CVS repositories. If I've got this all backwards, someone please let me know; I've a project of my own [2] that I would have licensed under GPL if not for the fact that I made use of libraries that were released under Apache and BSD licenses. Instead I went for LGPL on the grounds that I can find a lot of other LGPL'd projects that use the same libraries, so it looks like that's okay... I personally think you've got it upside down... You can write a piece of software distributed with a (L)GPL license and using ASL licensed software... The main problem for us (the ASF) is to incorporate software based on GPL/LGPL licenses (not the other way around). Basically, as we (ASF) don't impose any restriction on our software (it's a kind of do-whatever-you-want-with-it), if we were to include (L)GPL software we would force you (end user of Cocoon) to redistribute your project under a (L)GPL license: the ASF doesn't permit it, so that's why you won't find any reliance or use of (L)GPL software in ASL licensed projects. The other way around, is, on the other hand (and in my very personal non-lawyer idea), totally possible (Mr. Stallman still says it's not, but I don't believe he's right on this one). As your software is going to be (L)GPLed, yours is the choice of how to re-license the changes you make to OUR (cocoon's) classes: if you choose to distribute the changes you make to the Cocoon classes under the (L)GPL, then we (as the ASF) won't be able to redistribute them and you'll have to maintain your changes yourself. If you re-license your chages under the Apache Software License and we (as the ASF) are able to include them, we'll integrate them and ship them in our next release (hopefully). I know that in the past there were some issues dealing with the advertising clause in the Apache license 1.1 that Mr. Stallman didn't particularly like (and claimed were uncompatible), and now he's claiming that the version 2.0 of the Apache license is incompatible because of some patenting issue: those are subjective issues that were never tried in a court of law. Personally, not being a lawyer, I think the GNU approach (Mr. Stallman's) is over-zealous onto those issues, but, at the end-of-the- day, it's your gut-feeling that will have to tell you whether you can combine the two licenses or not. As far as my personal instinct goes, I wouldn't release anything under the (L)GPL, go straight to the ASL (or even better, BSD) and not care about it... Try to Google up ASL LGPL GPL: you'll find links to a number of blogs on this subject, especially by those who are on the licensing committee in the ASF (they might explain you in more legal terms what my gut feeling is all about!!!) :-P :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: (Re)Licensing question
On 10 Jan 2006, at 16:31, Helma van der Linden wrote: Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? It definitely is... The ASF doesn't pose any whatsoever restriction when its code is being re-distributed by a third party (you could virtually sell the ASF sources, and noone would be able to stop you). In this particular case, the entire project you methion is GPL licensed, thus, any modifications made to it will be (as well) have to be GPLed. This will guarantee that whoever inherits any of the files from that project will have to redistribute them using the same license (in case of any modification). The problem might arise for those willing to modify code based on that project and re-publish those changes: If they submit changes to (let's say) Cocoon's sources back to the project you're mentioning. The person modifying those sources can either choose to submit them back to us (the real source) or to the project they downloaded (the distributor). In the first case, we'll accept those modifications only if we can make them our own (copyright is assigned and transfered to the ASF) and will include them (hopefully) in our next release. In the second, those changes will be in the hands of the distributor (and thus GPLed). There are two options, either the copyright of those changes is transfered to the ASF by the distributor (and then we'll follows what's described above) or they'll have to maintain those patches themselves as we're not going to include GPL licensed code in our repository... I hope this clears it a little bit... Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1722) Testing...
[ http://issues.apache.org/jira/browse/COCOON-1722?page=all ] Pier Fumagalli updated COCOON-1722: --- Urgency: Blocker Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1722) Testing...
Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Deleted: (COCOON-1722) Testing...
[ http://issues.apache.org/jira/browse/COCOON-1722?page=all ] Pier Fumagalli deleted COCOON-1722: --- Testing... -- Key: COCOON-1722 URL: http://issues.apache.org/jira/browse/COCOON-1722 Project: Cocoon Type: Test Reporter: Pier Fumagalli -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jira: better use of the Priority field
On 22 Dec 2005, at 09:20, David Crossley wrote: Reinhard Poetz wrote: Each block is a component in JIRA and I can get a summary of all open issues for a component. Hmm, I think that I don't understand completly the problem that you want to solve ... Basically that it is difficult for people to get an idea of which are the urgent issues to be solved for a release. If they have some time, what should they solve next. Looking at the reports from http://issues.apache.org/jira/browse/COCOON We have Open Issues : By Priority but that is actually perceived severity. Looking at the FOR tracker is even worse. There are some issues listed as Blocker on that front-page listing and on our Roadmap, but they are only blockers for that particular plugin/Component. I want to add an extra field fix-priority to our issue entry/edit screens in Jira. Then we can create a report of Open issues : By fix-priority. It's called Urgency and it's there now (2 minutes job) :-) Pier smime.p7s Description: S/MIME cryptographic signature
Re: Jira: better use of the Priority field
On 22 Dec 2005, at 22:49, David Crossley wrote: Pier Fumagalli wrote: It's called Urgency and it's there now (2 minutes job) :-) Yeah, it is for someone who knows what they are up to. Thanks. However there is more to it. We need to redefine the instruction text for the existing Priority field. If no-one beats me to it, then i will try. That's a system wide issue, I don't think it can be changed on a project-by-project basis: I would have liked something like Gravity and Urgency (or Severity and Priority) but I didn't find a way to play around with global pre-defined fields in Jira (only show or hide them). And there are some procedural questions. For example, i presume that this Urgency field will be available to the person who enters the bug and that the committers will follow up and assign the project's actual Urgency. Alternatively it could be not available to the issue creation screen and is only something that people with Edit permissions can add. For now it's available to anyone (in other words, no security associated with it) but it can be restricted if you need to. Pier smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon 2.1.7 hang
On 22 Dec 2005, at 18:16, Ralph Goers wrote: We finally got some thread dumps from our production server. It shows something very different than what we were seeing in testing. First, this happens under light load after running for days. To summarize, many threads are waiting for the ResourceLimitingPool and several are waiting for the class loader. This system hasn't had the pools tuned so I'm not surprised about pool contention, but I don't believe that is the issue. That is because the thread holding the lock is simply waiting for the class loader. We took two traces and both were similar, but not identical. Different threads were holding the class loader lock in both. However, in both cases the threads holding the class loader lock were called from Castor while creating the portal layout. So far, we have been speculating that the problem is due to a problem with the NPTL threads on Enterprise Linux 3. However, I'm wondering if perhaps castor is having problems and simply calling the class loader over and over. I'd appreciate any ideas. Ok, as far as I can see down the dumps you might have some problems with Catalina's classloader implementation locking up at 0x60b19148: at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1255) That seems odd though... I thought that code was debugged pretty thoroughly, unless, a seconday lock at 0x60cd9970 prevents the first one to be released... Anyhow, from my experience, NPTL don't cause any whatsoever problem under Linux, but that said, I'm running on Jetty 4 with BEA JRockit 1.4.2. What VM and what container are you actually using? Pier smime.p7s Description: S/MIME cryptographic signature
Re: Bug report for Cocoon 2 [2005/12/18]
On 18 Dec 2005, at 23:00, Jorg Heymans wrote: I've asked infra@ for this report to be switched off. It will no longer run as of today. Shall we re-create one from Jira? Pier smime.p7s Description: S/MIME cryptographic signature
Re: rejuvenating the webdav block
Since you're looking into it, can you also take a shot at http://issues.apache.org/jira/browse/COCOON-1696 It's just a matter of copying sources in different directories and modifying descriptors slightly... Pier On 16 Dec 2005, at 10:42, Max Pfingsthorn wrote: Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl - smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-1704) Error Message brokenness when SAXON is used as the XSLT transformer.
Error Message brokenness when SAXON is used as the XSLT transformer. Key: COCOON-1704 URL: http://issues.apache.org/jira/browse/COCOON-1704 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Attachments: patch.txt SAXON 8.x always fails with a message Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor no matter what error it encounters. This is because it emits this as a warning to its configured ErrorHandler, and o.a.c.c.xslt.TraxErrorListener is configured to handler XALAN's brokenness, and caches warnings. Also, the o.a.c.c.xslt.TraxProcessor class does not allow to set generic attributes in the wrapped SAXTransformerFactory class, so, this can't be solved with configurations. And the only way I found to have SAXON to ignore those warnings is by setting the http://saxon.sf.net/feature/version-warning; attribute to false. This simple patch makes this behavior mandatory when using SAXON, so that error messages work back again no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Planning 2.2
On 23 Nov 2005, at 21:34, Joerg Heinicke wrote: On 23.11.2005 16:33, Antonio Fiol Bonnín wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. svn blame http://svnbook.red-bean.com/en/1.0/re02.html And if someone submits a patch, we can track the contribution in Jira. Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ] Pier Fumagalli updated COCOON-1694: --- Attachment: (was: patch.txt) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ] Pier Fumagalli updated COCOON-1694: --- Attachment: patch.txt The previous patch wouldn't have fixed the problem in all cases: a race condition might have occurred between checking the status, and actually shutting down the CacheManager. This patch synchronizes on the Cache instance and prevents this from happening. Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Attachments: patch.txt Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1697) Allow request parameters to be used in for (var k in h) kind of Javascript Loops
Allow request parameters to be used in for (var k in h) kind of Javascript
Loops
--
Key: COCOON-1697
URL: http://issues.apache.org/jira/browse/COCOON-1697
Project: Cocoon
Type: Improvement
Components: - Flowscript, * Cocoon Core
Versions: 2.1.8
Reporter: Pier Fumagalli
Priority: Minor
Attachments: patch.txt
As far as I can see, in the cocoon object passed to the flow environment, I
always have to access the request parameter names and all values as Java
Enumeration(s), therefore, I can't use the for (var name in array) kind of
loop.
All I want to do is something extremely simple, like this:
for (var name in cocoon.request.parameters) {
print(PARAMETER - + name);
print(VALUE - + cocoon.request.parameters[name]);
print( LENGTH - + cocoon.request.parameters[name].length);
for (var position in cocoon.request.parameters[name]) {
var value = cocoon.request.parameters[name][position];
print ( @[ + position + ] = + value);
}
}
Apparently, but I might have overlooked something, there's currently no way of
doing this.
I've created a simple patch, that allows the above mentioned flowscript to work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1695) Saxon requires an XML parser that reports the QName of each element
Saxon requires an XML parser that reports the QName of each element --- Key: COCOON-1695 URL: http://issues.apache.org/jira/browse/COCOON-1695 Project: Cocoon Type: Bug Versions: 2.1.8 Reporter: Pier Fumagalli The default AbstractTextSerializer attempts to detect whether the wrapped TransformerFactory supports encoding namespaces by iteself by simply passing the namespace declaration in startPrefixMapping(..) or requires them to be hardcoded into attributes. When Saxon is the default XSLT transformer factory, every time an instance of an AbstractTextSerializer is created, this exception crops up: [2005/11/22 21:39:08.193] WARN [xml] Cannot know if transformer needs namespaces attributes - assuming NO. org.xml.sax.SAXException: Saxon requires an XML parser that reports the QName of each element at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingContentHandler.java:264) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:194) at org.apache.cocoon.serialization.AbstractTextSerializer.needsNamespacesAsAttributes(AbstractTextSerializer.java:333) at org.apache.cocoon.serialization.AbstractTextSerializer.configure(AbstractTextSerializer.java:257) at org.apache.cocoon.serialization.XMLSerializer.configure(XMLSerializer.java:41) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:198) at org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:215) at org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setSerializer(AbstractProcessingPipeline.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:679) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.http.HttpServer.service(Unknown Source) at org.mortbay.http.HttpConnection.service(Unknown Source) at org.mortbay.http.HttpConnection.handleNext(Unknown Source) at org.mortbay.http.HttpConnection.handle(Unknown Source) at org.mortbay.http.SocketListener.handleConnection(Unknown Source) at org.mortbay.util.ThreadedServer.handle(Unknown Source) at org.mortbay.util.ThreadPool$PoolThread.run(Unknown Source) I assume that the detection code is broken. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http
[jira] Created: (COCOON-1696) A humongous number of blocks is required to support the webdav: source
A humongous number of blocks is required to support the webdav: source Key: COCOON-1696 URL: http://issues.apache.org/jira/browse/COCOON-1696 Project: Cocoon Type: Improvement Components: Blocks: WebDAV Versions: 2.1.8 Reporter: Pier Fumagalli As far as I can see, the webdav: source factory (org.apache.cocoon.components.source.impl.WebDAVSourceFActory) only relies on a handful of classes: - org.apache.cocoon.components.source.InspectableSource - org.apache.cocoon.components.source.helpers.SourceProperty - org.apache.cocoon.components.source.impl.WebDAVSource This compiles and works. That said, if I were to include the webdav block, I would have to include through dependancies the following blocks: webdav | +- repository | +- databases || |+- xsp | +- eventcache | +- jms | +- cron | +- databases || |+- xsp | +- hsqldb Don't you think this is a little bit excessive for including 4 classes? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1695) Saxon requires an XML parser that reports the QName of each element
[ http://issues.apache.org/jira/browse/COCOON-1695?page=all ] Pier Fumagalli updated COCOON-1695: --- Component: * Cocoon Core Saxon requires an XML parser that reports the QName of each element --- Key: COCOON-1695 URL: http://issues.apache.org/jira/browse/COCOON-1695 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli The default AbstractTextSerializer attempts to detect whether the wrapped TransformerFactory supports encoding namespaces by iteself by simply passing the namespace declaration in startPrefixMapping(..) or requires them to be hardcoded into attributes. When Saxon is the default XSLT transformer factory, every time an instance of an AbstractTextSerializer is created, this exception crops up: [2005/11/22 21:39:08.193] WARN [xml] Cannot know if transformer needs namespaces attributes - assuming NO. org.xml.sax.SAXException: Saxon requires an XML parser that reports the QName of each element at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingContentHandler.java:264) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:194) at org.apache.cocoon.serialization.AbstractTextSerializer.needsNamespacesAsAttributes(AbstractTextSerializer.java:333) at org.apache.cocoon.serialization.AbstractTextSerializer.configure(AbstractTextSerializer.java:257) at org.apache.cocoon.serialization.XMLSerializer.configure(XMLSerializer.java:41) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:198) at org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:215) at org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setSerializer(AbstractProcessingPipeline.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:679) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.http.HttpServer.service(Unknown Source) at org.mortbay.http.HttpConnection.service(Unknown Source) at org.mortbay.http.HttpConnection.handleNext(Unknown Source) at org.mortbay.http.HttpConnection.handle(Unknown Source) at org.mortbay.http.SocketListener.handleConnection(Unknown Source
[jira] Updated: (COCOON-1695) Saxon requires an XML parser that reports the QName of each element
[ http://issues.apache.org/jira/browse/COCOON-1695?page=all ] Pier Fumagalli updated COCOON-1695: --- Attachment: patch.txt Simple patch solving this issue by correcting the way in which detection is performed. Saxon requires an XML parser that reports the QName of each element --- Key: COCOON-1695 URL: http://issues.apache.org/jira/browse/COCOON-1695 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Attachments: patch.txt The default AbstractTextSerializer attempts to detect whether the wrapped TransformerFactory supports encoding namespaces by iteself by simply passing the namespace declaration in startPrefixMapping(..) or requires them to be hardcoded into attributes. When Saxon is the default XSLT transformer factory, every time an instance of an AbstractTextSerializer is created, this exception crops up: [2005/11/22 21:39:08.193] WARN [xml] Cannot know if transformer needs namespaces attributes - assuming NO. org.xml.sax.SAXException: Saxon requires an XML parser that reports the QName of each element at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingContentHandler.java:264) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:194) at org.apache.cocoon.serialization.AbstractTextSerializer.needsNamespacesAsAttributes(AbstractTextSerializer.java:333) at org.apache.cocoon.serialization.AbstractTextSerializer.configure(AbstractTextSerializer.java:257) at org.apache.cocoon.serialization.XMLSerializer.configure(XMLSerializer.java:41) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:198) at org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:215) at org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setSerializer(AbstractProcessingPipeline.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:679) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.http.HttpServer.service(Unknown Source) at org.mortbay.http.HttpConnection.service(Unknown Source) at org.mortbay.http.HttpConnection.handleNext(Unknown Source) at org.mortbay.http.HttpConnection.handle(Unknown Source
[jira] Commented: (COCOON-1696) A humongous number of blocks is required to support the webdav: source
[ http://issues.apache.org/jira/browse/COCOON-1696?page=comments#action_12358312 ] Pier Fumagalli commented on COCOON-1696: I think most dependancies are real (I tried compiling without explicitly including them and samples off, it failed). My thing is, 4 classes to allow Cocoon to use WebDav (for example, using the TraversableGenerator). Those 4 classes should be either in core or we should have a some sort of different block. A humongous number of blocks is required to support the webdav: source Key: COCOON-1696 URL: http://issues.apache.org/jira/browse/COCOON-1696 Project: Cocoon Type: Improvement Components: Blocks: WebDAV Versions: 2.1.8 Reporter: Pier Fumagalli As far as I can see, the webdav: source factory (org.apache.cocoon.components.source.impl.WebDAVSourceFActory) only relies on a handful of classes: - org.apache.cocoon.components.source.InspectableSource - org.apache.cocoon.components.source.helpers.SourceProperty - org.apache.cocoon.components.source.impl.WebDAVSource This compiles and works. That said, if I were to include the webdav block, I would have to include through dependancies the following blocks: webdav | +- repository | +- databases || |+- xsp | +- eventcache | +- jms | +- cron | +- databases || |+- xsp | +- hsqldb Don't you think this is a little bit excessive for including 4 classes? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (COCOON-1695) Saxon requires an XML parser that reports the QName of each element
On 22 Nov 2005, at 22:13, Pier Fumagalli (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1695?page=all ] Pier Fumagalli updated COCOON-1695: --- Attachment: patch.txt Simple patch solving this issue by correcting the way in which detection is performed. This is so brain-stupid as a patch that I am wondering if there was a reason for doing detection in such a broken way... Can someone review- then-commit? I'm flabbergasted that noone saw this before... :-P Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ] Pier Fumagalli updated COCOON-1694: --- Attachment: patch.txt Ok, the problem lied in the fact that each persistent cache registers a shutdown hook in the runtime, and if someone (like me) likes to Kill the JVM as normal unix processes, the hook gets executed before our code can shutdown, and EHCache doesn't like to be disposed twice. This patch fixes the behavior by invoking the shutdown method on the manager only if the current cache instance is still alive. Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Attachments: patch.txt Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
2.1.8 EHCache issue
It seems that EHCache gets closed even if it was never initialized... I think this came out only as a result of start cocoon, shutdown cocoon (no requests made). BTW, this is 2.1.8 final... Pier Begin forwarded message: From: Jose Manuel Urio [EMAIL PROTECTED] Date: 21 November 2005 08:49:11 GMT To: Pier Fumagalli [EMAIL PROTECTED] Cc: Emanuel Schleussinger [EMAIL PROTECTED], Jon Pokroy [EMAIL PROTECTED], Pier Fumagalli [EMAIL PROTECTED], Roberto Solís [EMAIL PROTECTED] Subject: Re: Can you try this out? Hi, Pier I have tested and it works ok but I get this exception when closing. [2005/11/21 09:44:16.339] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose (EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose (ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommis sion(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispo se(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispos e(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose (CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose (ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose (ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon (CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy (CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop (Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop (Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop (Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1667) Generation of documentation
[ http://issues.apache.org/jira/browse/COCOON-1667?page=all ] Pier Fumagalli updated COCOON-1667: --- Fix Version: 2.1.9-dev (current SVN) (was: 2.1.8) Generation of documentation --- Key: COCOON-1667 URL: http://issues.apache.org/jira/browse/COCOON-1667 Project: Cocoon Type: Wish Components: - Documentation Versions: 2.1.8 Reporter: Vadim Gritsenko Assignee: Cocoon Developers Team Fix For: 2.1.9-dev (current SVN) Docs are not generated in 2.1 URI space yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1665) Test release against JVM 1.3/5.0 and different Tomcat versions
[ http://issues.apache.org/jira/browse/COCOON-1665?page=all ] Pier Fumagalli updated COCOON-1665: --- Fix Version: 2.1.9-dev (current SVN) (was: 2.1.8) Test release against JVM 1.3/5.0 and different Tomcat versions -- Key: COCOON-1665 URL: http://issues.apache.org/jira/browse/COCOON-1665 Project: Cocoon Type: Task Versions: 2.1.8 Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Minor Fix For: 2.1.9-dev (current SVN) Before voting on the release, I would like to know if anyone tested on Java 1.3 and 5.0 and on Tomcat amd on what versions. Actually, it would be great if we had a testing matrix of JVMs, Servlet Containers and operating systems that we could check off when doing a release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ http://issues.apache.org/jira/browse/COCOON-1622?page=all ] Pier Fumagalli updated COCOON-1622: --- Fix Version: 2.1.9-dev (current SVN) (was: 2.1.8) [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: http://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Cocoon Developers Team Fix For: 2.1.9-dev (current SVN) Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: jira karma
On 4 Nov 2005, at 12:31, Max Pfingsthorn wrote: Hi all, I just made an account in Jira (mpfingsthorn, email: [EMAIL PROTECTED]), can you add me to the right groups? After two weeks of exams and subsequently needed rest, I am finally ready to dive into cocoon again ;) Dun! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Releasing on friday
On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote: Please cast your votes for releasing 2.1.8 on friday, 4th of November. (if we vote to not release on friday, I can do the release on any day in the next week). What about these three issues targeted for 2.1.8 ??? http://issues.apache.org/jira/secure/IssueNavigator.jspa? pid=12310170resolution=-1fixfor=12310601sorter/ field=issuekeysorter/order=DESCtempMax=25reset=true Unfortunately I'm under deadline and have no time to dig into them ATM. Pier smime.p7s Description: S/MIME cryptographic signature
Would this show up in BugZilla???
As we want to put a comment into all cocoon bugs in BugZilla pointing to Jira, would something like this work? insert into longdescs (bug_id,who,bug_when,thetext) values (X, 1,SYSDATE(),'Issue migrated to Jira: http://issues.apache.org/jira/ bugzillasearch.jsp?id=X'); update bugs set resolution = 'MOVED' where bug_id = X; where X is the Cocoon bug ID (select bug_id from bugs where product_id=8;) We're having people re-opening bugs in Bugzilla, and would like to mark the move in there... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [heads-up] old Cocoon bugzilla is not yet closed (Was: [Bug 36810])
On 31 Oct 2005, at 08:01, David Crossley wrote: Youch, i presumed that when we moved to Jira that the old Bugzilla would be closed and people would need to look for our issues.apache.org/jira This old issue was able to be re-opened and commented. You can't _really_ lock down bugzilla... you can't now enter new issues, but apparently people can reopen or comment the old ones... I've asked infrastructure. Pier -David On Mon, Oct 31, 2005 at 08:41:43AM +0100, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36810 --- Additional Comments From [EMAIL PROTECTED] 2005-10-31 08:41 --- I'm not sure what the bug is in Forest, but I doubt it depends on #32360. JXPath was working correctly (at least until it was broken while someone mistakenly fixed 32360). There might be some problem in how Forest's XPath expressions are designed to handle the default namespace, or it might be something completely different. smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ http://issues.apache.org/jira/browse/COCOON-1622?page=all ] Pier Fumagalli updated COCOON-1622: --- Bugzilla Id: (was: 36949) Fix Version: 2.1.8-dev (Current SVN) Jean-Baptiste Quenot [EMAIL PROTECTED] would like to see this one fixed in 2.1.8 [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: http://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Cocoon Developers Team Priority: Critical Fix For: 2.1.8-dev (Current SVN) Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Would this show up in BugZilla???
On 31 Oct 2005, at 14:52, Sander Temme wrote: On Oct 31, 2005, at 5:53 AM, Pier Fumagalli wrote: As we want to put a comment into all cocoon bugs in BugZilla pointing to Jira, would something like this work? insert into longdescs (bug_id,who,bug_when,thetext) values (X, 1,SYSDATE(),'Issue migrated to Jira: http://issues.apache.org/jira/ bugzillasearch.jsp?id=X'); update bugs set resolution = 'MOVED' where bug_id = X; where X is the Cocoon bug ID (select bug_id from bugs where product_id=8;) At quick glance, that would be the way to hack it. Let me give it a more coomprehensive glance after I get myself a cup of coffee. Coffee is _always_ priority. I don't suppose this could be done in one line of SQL? Dunno, maybe tweaking about with the SQL one can do the select for all cocoon bugs and in-line with the insert and the update statement, but my SQL is not that good when it comes to bulk operations (under Oracle, i'd do that with a stored procedure, but we all agree that Oracle AND stored procedures are the root of all evil)... We're having people re-opening bugs in Bugzilla, and would like to mark the move in there... Yeah, can't have that. I don't have a way to force bugs to stay closed (AFAIK), but a comment might help. In Bugzilla, I'm seeing 'Cocoon 1' and 'Cocoon 2'. Would we do this for both? Nope, only for Cocoon 2. Cocoon 1 is dead and buried... :-P Actually, have you considered that putting the comment in through the web interface, thence triggering the e-mails, would be a very effective way to let folks know the migration is in effect? Yeah, but we have 1655 bugs in the system... :-) That's SPAM (considering the fact that most of those email would go back to the developers). I don't think that we want to generate something like 20/30 k emails in one go, that'd piss people off royally. Pier smime.p7s Description: S/MIME cryptographic signature
Re: Docs now use Daisy-wiki defined URLspace
On 29 Oct 2005, at 17:18, hepabolu wrote: On my brand new Powerbook, the background color of the Apache Cocoon logo (left with feather) has a different shade of blue as background, while I can't remember having seen that on my Windows machine. AFAICT colors are identical. Anyone else seeing this? Yes... I'm seeing it, but I think it's because of the color management done on the Mac... Pier smime.p7s Description: S/MIME cryptographic signature
Re: complete version of form i18n zh_CN file
On 28 Oct 2005, at 08:15, Bertrand Delacretaz wrote: Le 28 oct. 05, à 05:49, roy huang a écrit : ...messages_zh_CN.xml I cannot check the translation though, we trust you on that one! That's when you use http://translate.google.com/translate_t (or a wife who can read chinese)... I triple checked, all is good! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: Using Daisy as Wiki
On 28 Oct 2005, at 12:02, Steven Noels wrote: On 28 Oct 2005, at 11:03, Bertrand Delacretaz wrote: BUT: we should make sure the daisy stuff is backed up, For starters, it would be nice if someone Solaris-knowledgeable figures out why the crontab entry for the daisy user isn't doing what it should. I can give it a shot, but am not in sudoers! Pier smime.p7s Description: S/MIME cryptographic signature
Re: Using Daisy as Wiki
On 28 Oct 2005, at 12:02, Steven Noels wrote: On 28 Oct 2005, at 11:03, Bertrand Delacretaz wrote: BUT: we should make sure the daisy stuff is backed up, For starters, it would be nice if someone Solaris-knowledgeable figures out why the crontab entry for the daisy user isn't doing what it should. It's now correct. The entry in the /etc/shadow file indicated that daisy was a locked user (password *LK*)... I now unlocked it and crons work like a charm... Pier (an old solaris fart) smime.p7s Description: S/MIME cryptographic signature
Re: Using Daisy as Wiki
On 28 Oct 2005, at 15:13, Ralph Goers wrote: 5. How will the system perform? How well does it scale? Will it handle the expected load? Given that I run a fairly big site on Cocoon, I'm fairly scared about possible links from sites such as Slashdot... If we rely on the ASF-Wiki, then it's their problem to make sure it works, but if we're using daisy, well, it's up to us. And maybe a shared Solaris 10 box is not the place where I would like to see massive hits coming through... Pier smime.p7s Description: S/MIME cryptographic signature
Re: Using Daisy as Wiki
On 28 Oct 2005, at 16:03, Upayavira wrote: Mark Lundquist wrote: On Oct 28, 2005, at 7:26 AM, Pier Fumagalli wrote: And maybe a shared Solaris 10 box is not the place where I would like to see massive hits coming through... What do the stats show about the current Wiki, i.e. how high a bar would the Daisy server have to clear (for today + future), and could we run enough of a load test on Daisy to get an idea? JMeter? Extremely high. I wouldn't go near it myself. It took about a month after upgrading to the latest MoinMoin to get it sufficiently stable to not bring down the whole www.apache.org server. We had to block crawlers for some time, and eventually fixed it by placing a new version of mod_cache in front of the Python based MoinMoin wiki for all anonymous requests. I'm afraid I don't have any figures, but can say that Cocoon's wiki is amongst the top three Apache wikis in terms of size. Exactly my thoughts... The only way in which I could see Daisy fit to handle that load, if it were to publish the pages entered as static files, then served off by Apache itself, without involving Cocoon (the same technique used by MovableType, for example). Without that in place, I'd be -1 on hosting anything live of Cocoon on the ASF infrastructure, even with massive caching, because of the maintenance task we'd put on the infrastructure team, and the possible impact this would have on projects other than Cocoon itself (it's a shared infrastructure, we have to play it nice). Pier smime.p7s Description: S/MIME cryptographic signature
Re: Using Daisy as Wiki
On 28 Oct 2005, at 19:05, Steven Noels wrote: On 28 Oct 2005, at 16:26, Pier Fumagalli wrote: 5. How will the system perform? How well does it scale? Will it handle the expected load? Given that I run a fairly big site on Cocoon, I'm fairly scared about possible links from sites such as Slashdot... Cough: http://science.slashdot.org/article.pl?sid=04/11/22/1342203 :) Sorry, it's just me getting nervous when Daisy is being compared to a Python CGI. I'm not saying it's impossible... The current VNUNET sites pump out more than 10 mbps constant now, and we spike to more than 30mbps kinda twice a week... BUT, they're not running on the ASF infrastructure (therefore, when s**t hits the fan, the [EMAIL PROTECTED] people are the first to run, not us), and they're not shared by a number of other projects (therefore when s**t hits the fan, we hurt the wider Apache community). Each project we individually build on Cocoon has the same technical merits inherited from the platform, but has a quite different deployment scenario. My concerns are simply along the lines of let's play this game nicely, not it's impossible... And insofar, no takers on static writing of HTMLs a-la MovableType... Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1663) Release 2.1.8
[ http://issues.apache.org/jira/browse/COCOON-1663?page=all ] Pier Fumagalli updated COCOON-1663: --- Fix Version: 2.1.8-dev (Current SVN) Release 2.1.8 - Key: COCOON-1663 URL: http://issues.apache.org/jira/browse/COCOON-1663 Project: Cocoon Type: Task Versions: 2.1.8-dev (Current SVN) Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team Fix For: 2.1.8-dev (Current SVN) This issue depends on other issues which we consider blocking for the release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1594) SQLTransformer swallowing whitespace on substitute-value
[ http://issues.apache.org/jira/browse/COCOON-1594?page=all ] Pier Fumagalli updated COCOON-1594: --- Bugzilla Id: (was: 36573) Fix Version: 2.1.8-dev (Current SVN) SQLTransformer swallowing whitespace on substitute-value Key: COCOON-1594 URL: http://issues.apache.org/jira/browse/COCOON-1594 Project: Cocoon Type: Bug Components: Blocks: Databases Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Macintosh Reporter: andrew Assignee: Cocoon Developers Team Fix For: 2.1.8-dev (Current SVN) Attachments: example.xmap, param-bug.xml The following code will fail: sql:query SELECT id, name, description from department LIMIT substitute-value sql:name=start/,substitute-value sql:name=count/ /sql:query After the values are substituted, the output is: SELECT id, name, description from department LIMITn,m ... instead of SELECT id, name, description from department LIMIT n,m -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Deleted: (COCOON-1663) Release 2.1.8
[ http://issues.apache.org/jira/browse/COCOON-1663?page=all ] Pier Fumagalli deleted COCOON-1663: --- Release 2.1.8 - Key: COCOON-1663 URL: http://issues.apache.org/jira/browse/COCOON-1663 Project: Cocoon Type: Task Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team This issue depends on other issues which we consider blocking for the release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (COCOON-1663) Release 2.1.8
On 27 Oct 2005, at 15:55, Vadim Gritsenko wrote: Bertrand Delacretaz (JIRA) wrote: Release 2.1.8 - Key: COCOON-1663 URL: http://issues.apache.org/jira/browse/COCOON-1663 Project: Cocoon Type: Task Versions: 2.1.8-dev (Current SVN)Reporter: Bertrand Delacretaz Assigned to: Cocoon Developers Team This issue depends on other issues which we consider blocking for the release IIUC that's not the Jira way to do it... Am I right? Pier? :) No, it is not... But Bertrand was right, as I forgot to add one thing in our reduced configuration. The missing field was Fix Version/s, which basically defines in what version the bug should be fixed. If you look now at this report: http://issues.apache.org/jira/browse/COCOON? report=com.atlassian.jira.plugin.system.project:roadmap-panel This will indicate that we have issue 1483 FIXED in 2.1.8 dev, while issue 1594, which is scheduled for 2.1.8 (the Fix Version/s field is set to that value) hasn't been fixed yet... So, as far as I can see, we're at 50% of our roadmap. I will add also those other bugs that came up in the discussion, with the correct versions, so, keep looking at that report! Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1665) Test release against JVM 1.3/5.0 and different Tomcat versions
Test release against JVM 1.3/5.0 and different Tomcat versions -- Key: COCOON-1665 URL: http://issues.apache.org/jira/browse/COCOON-1665 Project: Cocoon Type: Task Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Priority: Minor Fix For: 2.1.8-dev (Current SVN) Before voting on the release, I would like to know if anyone tested on Java 1.3 and 5.0 and on Tomcat amd on what versions. Actually, it would be great if we had a testing matrix of JVMs, Servlet Containers and operating systems that we could check off when doing a release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1667) Generation of documentation
Generation of documentation --- Key: COCOON-1667 URL: http://issues.apache.org/jira/browse/COCOON-1667 Project: Cocoon Type: Wish Components: - Documentation Versions: 2.1.8-dev (Current SVN) Reporter: Vadim Gritsenko Fix For: 2.1.8-dev (Current SVN) Docs are not generated in 2.1 URI space yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Please choose your bugs...
As we're closing the 2.1.8 release, I'd like to get the bugs you wish were fixed into Jira. Remember that you should set the Fix Version/ s field to 2.1.8-dev, which will become (officially) 2.1.8 when we release. I still have to think slightly about how to do release management... Also, please walk through the bugs list, and if you find something you wish to see fixed for 2.1.8, edit the issue, and mark the Fix Version/s field (as for new issues). If you can't find the field in the bug entry page, it's because you don't have enough privileges, let me know and I'll make sure you're in the cocoon-developers group. Pier smime.p7s Description: S/MIME cryptographic signature
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
On 26 Oct 2005, at 13:58, Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658? page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) You normally can reply to the sender addess of the confirmation message, but that's not yet enabled in the ASF infrastructure... Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Closed: (COCOON-1658) Somewhere output is held...
[ http://issues.apache.org/jira/browse/COCOON-1658?page=all ] Pier Fumagalli closed COCOON-1658: -- Resolution: Invalid For some odd reason, I never saw the prominent documentation in the Cocoon sitemap: If not specified, the value of the outputBufferSize parameter is -1. This will cause Cocoon to buffer all output until processing has finished before sending it to the client... Somewhere output is held... --- Key: COCOON-1658 URL: http://issues.apache.org/jira/browse/COCOON-1658 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Reporter: Pier Fumagalli Priority: Critical Cocoon standard, as of right now, built without any blocks. I modify the default sitemap adding one simple entry: map:match pattern=bigtest map:generate src=bigtest.xml/ map:serialize type=xml/ /map:match The file bigtest.xml is a 100Mb XML file that I simply want to generate and serialize (minimal test, no transformers that can do anything weird). I then open my terminal and do a curl http://localhost:/bigtest /dev/null, to have an idea of the thrughput for this file. Apparently, the output is held for roughly 25 seconds, nothing comes out, no bytes are serialized. All of a sudden, the entire 100 megabytes are serialized in one big lump (and it takes 5 seconds to do so). This happens if the pipeline is configured as being caching or noncaching (nothing changes). In the first 25 seconds, the JVM running Cocoon uses 100% of my processor (so, it's doing something), and the TOP shows something _really_ strange. My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the big request, close cocoon). This is a trace from my TOP: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE - 12498 java 0.1% 0:03.01 19 357 240 25.1M 28.7M 25.4M 735M 12498 java87.2% 0:06.22 19 403 242 54.2M+ 28.7M 55.1M+ 735M- 12498 java75.7% 0:10.88 19 403 242 78.3M 28.7M 79.2M 735M 12498 java80.2% 0:14.78 19 403 242 129M 28.7M 130M 735M 12498 java84.3% 0:19.77 19 403 242 168M+ 28.7M 169M+ 735M 12498 java77.4% 0:23.67 19 403 242 231M 28.7M 232M 735M 12498 java40.7% 0:27.92 19 403 242 231M+ 28.7M 232M+ 735M+ 12498 java 0.1% 0:28.18 20 408 245 231M 28.7M 232M 735M Something tells me that we are indeed caching all the content in a big char[] (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]). Any clue on where this can happen? It's impairing our ability to serve bigger feeds (aka, 2 gigs! :-P) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
On 26 Oct 2005, at 17:49, Carsten Ziegeler wrote: Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658? page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) So, my question is why is the buffer right now set to unlimited? Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... The only reason for unlimited is error handling. If an error happens when some content has already been streamed to the client, we can't roll back the already streamed part. Without buffering you would get corrupted pages. So if you're sure that you don't have exceptions during streaming, you can turn off buffering. We decided a long time ago, to set the default to unlimited just for making error handling work in all cases. If the caching pipeline is used and in the case the serializer needs to set the content length, then the pipeline takes care about buffering. Ahhh!!! I think this outputBuffer is not really needed. I think this is another example of running modes. During development you might want to have an unlimited buffer while in production (where never an error occurs :) ) you can disable it. Sorry, I'm a moron... For some reason I've never seen that it's extremely well documented in the Cocoon default sitemap. !--+ | If not specified, the value of the outputBufferSize parameter is -1. | This will cause Cocoon to buffer all output until processing has finished | before sending it to the client. This has the advantage that in case | an error occurs during the processing of the SAX- pipeline, Cocoon is still | able to reset the response and send an error page instead. Otherwise the | error page will be appended to the output already send to the client. | If you are generating larger pages, it might be benificial to enable | this parameter, so that output is gradually send to the client as it | is being generated. | For more granularity, you can also supply this parameter to | individual map:pipeline elements (using map:parameter syntax). +-- Pier smime.p7s Description: S/MIME cryptographic signature
Re: Closed but unresolved issues
On 25 Oct 2005, at 07:29, Reinhard Poetz wrote: We have 79 closed but unresolved issues in Jira. This is a problem as they show up in all queries (eg the project page) and gives a wrong picture of open issues. Is there any faster possibility to change this but to reopen every issue, change the resolution state and close it? Not as far as I know, unless we don't modify the Workflow temporarily (but that takes quite some time too). Pier smime.p7s Description: S/MIME cryptographic signature
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
On 25 Oct 2005, at 10:08, Jeroen Reijn wrote: - CAPTCHA validation sample is does not make sense. There is no string shown on the right. http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/ captcha/ Uh... That's a 500: HTTP ERROR: 500 Internal Server Error RequestURI=/demos/21branch/samples/blocks/forms/captcha/ captcha-652a63096863.jpg I would suspect that either the X libraries are not installed on our cocoon zone, or the JVM was not started with -Djava.awt.headless=true... Can someone add me to the users in the zone, so that I can check what's wrong with it? Thanks! Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1122) Aggregate Binding Sample doesn't work.
[ http://issues.apache.org/jira/browse/COCOON-1122?page=all ] Pier Fumagalli updated COCOON-1122: --- Reporter: Marc Portier (was: Marc Portier) Aggregate Binding Sample doesn't work. -- Key: COCOON-1122 URL: http://issues.apache.org/jira/browse/COCOON-1122 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Marc Portier Assignee: Cocoon Developers Team The 'month' field set by the binding doesn't get selected correctly in the html form. This is a known issue that needs to be resolved through the refactoring of the cforms code base instead of through yet another quick hack. More reading: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108140728531416w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-737) Simple Generic FormHandler for Repeater
[ http://issues.apache.org/jira/browse/COCOON-737?page=all ] Pier Fumagalli updated COCOON-737: -- Reporter: Marc Portier (was: Marc Portier) Simple Generic FormHandler for Repeater --- Key: COCOON-737 URL: http://issues.apache.org/jira/browse/COCOON-737 Project: Cocoon Type: Improvement Components: - Components: Sitemap Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: All Reporter: Marc Portier Assignee: Bruno Dumon Priority: Minor Attachments: RepeaterHandler.java, RepeaterHandler.patch After making my own form-example using Woody's repeater widget. I realized that the code inside the sample/Form1Handler could be easily factored out to become more widely useable. I will provide the simple new RepeaterHandler.java file that does that. Together with a patch for the existing Form1Handler sample to show how this new class can effectively be used as a delegate. -marc= -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1118) ArrayIndexOutOfBoundsException in cforms Transformer
[ http://issues.apache.org/jira/browse/COCOON-1118?page=all ]
Pier Fumagalli updated COCOON-1118:
---
Reporter: Marc Portier (was: Marc Portier)
ArrayIndexOutOfBoundsException in cforms Transformer
Key: COCOON-1118
URL: http://issues.apache.org/jira/browse/COCOON-1118
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: Marc Portier
Assignee: Cocoon Developers Team
Priority: Minor
The cforms transformer allows to set the form-action from the sitemap using a
'form-action' parameter.
map:transform type=forms
map:parameter name=form-action value={flow-continuation:id}.continue
/
/map:transform
(sample uses the FlowContinuationModule to get the continuation id)
This works fine as long as the ft:form-template has already an action
attribute. (it may be empty) However when the action attribute is not present
the transformation will throw an ArrayIndexOutOfBoundsException.
Simple workaround is to provide the @action of course:
ft:form-template action=
-marc=
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-773) [apples] Sharing the current state of the implementation
[ http://issues.apache.org/jira/browse/COCOON-773?page=all ] Pier Fumagalli updated COCOON-773: -- Reporter: Marc Portier (was: Marc Portier) [apples] Sharing the current state of the implementation Key: COCOON-773 URL: http://issues.apache.org/jira/browse/COCOON-773 Project: Cocoon Type: Improvement Components: - Components: Avalon Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Marc Portier Assignee: Cocoon Developers Team Priority: Minor Attachments: apples-block-src.jar Initial cut of some code (code-named 'apples' and wrapped up as an unstable block) that provides an alternative implementation for the flow according to some comcepts and wild ideas that were originally bundled up here: http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow There remains quite some work to do / issues to tackle and / ascpects to cover but probably some fysical code offers the more meat on the bone to guide us through further discussions. In order to tie this in with the cocoon build process you will probably need to add something like this into the gump.xml: project name=cocoon-block-apples status=unstable packageorg.apache.cocoon/package ant target=gump-block property name=block-name value=apples/ property name=version value=@@DATE@@/ /ant depend project=cocoon inherit=all/ work nested=tools/anttasks/ home nested=build/cocoon-@@DATE@@/ jar name=blocks/apples-block.jar/ nag from=Gump to=dev@cocoon.apache.org/ /project The package in attachment also includes a small sample to be found in the samples area of the webapp. Haven't written no other documentation yet and javadoc is limited... wanted to get this out first. -marc= -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-761) [woody] initial binding framework
[ http://issues.apache.org/jira/browse/COCOON-761?page=all ] Pier Fumagalli updated COCOON-761: -- Reporter: Marc Portier (was: Marc Portier) [woody] initial binding framework - Key: COCOON-761 URL: http://issues.apache.org/jira/browse/COCOON-761 Project: Cocoon Type: Improvement Components: - Components: Avalon Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Marc Portier Assignee: Cocoon Developers Team Priority: Minor Attachments: woody-bind.patch, woody-bind.patch A first functional throw at the implementation of some Binding ideas for connecting Woody forms to actual back-ends. The enhancement is packaged as a patch for the Woody-block where it introduces - code in the o.a.c.woody.binding package - some new BindingManager component to be declared - supporting logging xpatch files - a sample showing the current features. - usage of a new xml-namespace: http://apache.org/cocoon/woody/binding/1.0 for the declarations in the 'binding'-file More explanation/ideas to be found on the mailarchives. - http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105703782520964w=2 - http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105834927217234w=2 Please direct your comments to the list. Known Limitations: - no documentation yet: should get into the wiki with the other woody-docos - no namespace-awareness concerning the xml-backend-objectmodel (how to express in jxpath?) - the repeater requires a unique id -- this calls for a hidden widget inside Woody (actually leaving it out from the template should do as soon as Woody learns how to deal with widgets that are missing on the form) - simple way to address this from flowscript is missing - BindingManager should maintain a cache of the bindings it build (pattern to be copied from woody form-manager, or factored out/reused) - no dataconversions yet: binding strictly 'String' - no binding for booleanfield and multivaluefield - list of builders probably nicer in the xconf in long run - use of jxpath was to enable binding to javabeans (coming from O/R layer) current patch lacks the sample though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-769) [patch][woody] Making WoodyTemplateTransformer Flow-aware.
[ http://issues.apache.org/jira/browse/COCOON-769?page=all ]
Pier Fumagalli updated COCOON-769:
--
Reporter: Marc Portier (was: Marc Portier)
[patch][woody] Making WoodyTemplateTransformer Flow-aware.
---
Key: COCOON-769
URL: http://issues.apache.org/jira/browse/COCOON-769
Project: Cocoon
Type: Bug
Components: - Components: Avalon
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: other
Platform: Other
Reporter: Marc Portier
Assignee: Bruno Dumon
Attachments: woody-template.patch
This patch allows
1/ to have the form/@action dynamically set to a jxpath evalutaion
of the form #{$continuation/id}
2/ to look for the form instance in the flow context model
--
This introduces a jxpath context member in the template transformer that is
used
for evaluating #{--jxpath-expression--} in the text of a wt:form-template tag
Typical usage is in updating your existing woody-templates to hold this tag:
wt:form-template method=POST action=#{$continuation/id}.kont
--
This also lowers the required 'form-attribute' parameter to be an optional
parameter. If it is not set then the flow-context-object will be considered
being a java.util.Map that holds the form instance under the 'woody-form' key
--
Finally this holds some comments/suggestion about how we could extend this
even one step further to actually support multiple woody-forms on one page.
We could allow for multiple wt:form-template tags on one page that each
declare
themselves the form-lookup key in the flow-context-object-HashMap using their
own specific @location=#{/woody-form}
-marc=
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-668) [PATCH] esql:call needs-query=true generate an invalid xsp file
[ http://issues.apache.org/jira/browse/COCOON-668?page=all ] Pier Fumagalli updated COCOON-668: -- Assign To: Torsten Curdt (was: Torsten Curdt) [PATCH] esql:call needs-query=true generate an invalid xsp file --- Key: COCOON-668 URL: http://issues.apache.org/jira/browse/COCOON-668 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Liaw Wei Tjong Assignee: Torsten Curdt Attachments: esql_needs_query.zip, esql_needs_query.zip The patch allows esql to correctly show the resultset returned by stored procedure call using executeQuery() method required by some DBMS, eg. Sybase. The zip contains two unified diff files: 1. esql.xsl.diff Replace '_esql_query.execute(true)' with '_esql_query.executeQuery()'. The 'execute(boolean)' method is no longer available in v2.1. 2. AbstractEsqlQuery.java.diff Initialize the 'hasResultSet' member variable when there is a resultset returned by the 'executeQuery()' method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-696) DatabaseAuthenticatorAction doesn't separate colomn names for sql statement
[ http://issues.apache.org/jira/browse/COCOON-696?page=all ]
Pier Fumagalli updated COCOON-696:
--
Assign To: Torsten Curdt (was: Torsten Curdt)
DatabaseAuthenticatorAction doesn't separate colomn names for sql statement
---
Key: COCOON-696
URL: http://issues.apache.org/jira/browse/COCOON-696
Project: Cocoon
Type: Bug
Components: - Components: Avalon
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: leo leonid
Assignee: Torsten Curdt
I can confirm
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=105343930822231w=4
(apart from the workaround)
the following patch should fix this.
--- DatabaseAuthenticatorAction.javaWed May 21 18:47:13 2003
+++ DatabaseAuthenticatorAction.new.javaWed May 21 18:49:22 2003
@@ -218,6 +218,8 @@
Object[] constraintValues = new Object[columns.length];
int constraints = 0;
for (int i = 0; i columns.length; i++) {
+if (i != 0)
+queryBuffer.append (, );
String dbcol = columns[i].getAttribute(dbcol);
boolean nullable = false;
queryBuffer.append(dbcol);
/leo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-640) AbstractEsqlConnection: fix for Sybase ASE
[ http://issues.apache.org/jira/browse/COCOON-640?page=all ]
Pier Fumagalli updated COCOON-640:
--
Assign To: Torsten Curdt (was: Torsten Curdt)
AbstractEsqlConnection: fix for Sybase ASE
--
Key: COCOON-640
URL: http://issues.apache.org/jira/browse/COCOON-640
Project: Cocoon
Type: Bug
Components: - Components: Avalon
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: other
Platform: All
Reporter: Neil Bacon
Assignee: Torsten Curdt
Here's a patch for
cocoon-
2.1/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/A
bstractEsqlConnection.java
to:
- fix an error with Sybase ASE (unlike Sybase ASA, ASE doesn't support
select
top)
- enhance behavior with MS Sql Server (it supports select top like Sybase
ASA)
--- AbstractEsqlConnection.java-1.2 2003-04-01 14:20:08.0 +1000
+++ AbstractEsqlConnection.java 2003-04-01 14:12:48.0 +1000
@@ -147,12 +147,26 @@
/**
+ * Sybase has 2 RDBMS products. The Sybase JDBC driver uses a url
starting
with jdbc:sybase: for both.
+ * Here are the product names and versions returned from the Sybase JDBC
driver:
+ * getMetaData().getDatabaseProductName() getMetaData
().getDatabaseProductVersion()
+ * --
-
+ * Adaptive Server Anywhere7.0.4.3373
+ * Sybase SQL Server Adaptive Server
Enterprise/12.0.0.3/P/SWR 9777 ESD 4/NT (IX86)/OS 4.0/1699/32bit/OPT/Wed Sep
05
21:14:50 2001
+ * The first supports select TOP as used by SybaseEsqlQuery, but the
second does not.
+ */
+private boolean isSybaseAdaptiveServerAnywhere() throws SQLException {
+ String databaseProductName = getConnection().getMetaData
().getDatabaseProductName().toLowerCase();
+ return databaseProductName.indexOf(anywhere) -1;
+}
+
+/**
* Factory method for creating an EsqlQuery object. If type is set to
* or auto it will try to find type from the JDBC connection URL.
* If this does not succeed the generic JDBC type will be assumed.
* (This type does not work for some databases like mssql though)
*
- * @param type {sybase|postgresql|mysql|oracle|jdbc}
+ * @param type {sybase|sybase-ase|ms-
sqlserver|postgresql|mysql|oracle|jdbc}
* @param queryString
* @return implementation of the AbstractEsqlQuery
* @throws SQLException
@@ -169,6 +183,15 @@
query = new MysqlEsqlQuery(getConnection(),queryString);
}
else if (url.startsWith(jdbc:sybase:)) {
+if (isSybaseAdaptiveServerAnywhere()) {
+ query = new SybaseEsqlQuery(getConnection(),queryString);
+ } else {
+ query = new JdbcEsqlQuery(getConnection(),queryString);
+ }
+}
+else if (url.startsWith(jdbc:microsoft:sqlserver:)) {
+ // MS SQL Server also supports select TOP like Sybase ASA
+ // Maybe SybaseEsqlQuery should be renamed to something like
SelectTopEsqlQuery?
query = new SybaseEsqlQuery(getConnection(),queryString);
}
else if (url.startsWith(jdbc:oracle:)) {
@@ -182,7 +205,7 @@
query = new JdbcEsqlQuery(getConnection(),queryString);
}
}
-else if (sybase.equalsIgnoreCase(type)) {
+else if (sybase.equalsIgnoreCase(type) || ms-
sqlserver.equalsIgnoreCase(type)) {
query = new SybaseEsqlQuery(getConnection(),queryString);
}
else if (postgresql.equalsIgnoreCase(type)) {
@@ -200,7 +223,7 @@
else if (pervasive.equalsIgnoreCase(type)) {
query = new PervasiveEsqlQuery(getConnection(),queryString);
}
-else if (jdbc.equalsIgnoreCase(type)) {
+else if (jdbc.equalsIgnoreCase(type) ||
sybase-ase.equalsIgnoreCase
(type)) {
query = new JdbcEsqlQuery(getConnection(),queryString);
}
else {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-669) [Patch] STX block
[ http://issues.apache.org/jira/browse/COCOON-669?page=all ] Pier Fumagalli updated COCOON-669: -- Assign To: Torsten Curdt (was: Torsten Curdt) [Patch] STX block - Key: COCOON-669 URL: http://issues.apache.org/jira/browse/COCOON-669 Project: Cocoon Type: Improvement Components: - Components: Sitemap Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Daniel Fagerstrom Assignee: Torsten Curdt Priority: Minor Attachments: page2html.stx, stx-block.tgz Block containing the STX implementation Joost, http://joost.sourceforge.net, and some simple samples. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1284) [PATCH] Serializers: NPE in constructor of CharSetFactory
[ http://issues.apache.org/jira/browse/COCOON-1284?page=all ] Pier Fumagalli updated COCOON-1284: --- Assign To: Torsten Curdt (was: Torsten Curdt) [PATCH] Serializers: NPE in constructor of CharSetFactory - Key: COCOON-1284 URL: http://issues.apache.org/jira/browse/COCOON-1284 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1 Environment: Operating System: All Platform: All Reporter: Johan Stuyts Assignee: Torsten Curdt Priority: Minor Attachments: serializers-npe.patch If the charsets are not on the class path a NPE will be thrown during the initialization of the CharSetFactory. This patch checks for a null value of the URL and throws a more specific exception if the URL is null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1270) Javaflow can't call inherited methods
[ http://issues.apache.org/jira/browse/COCOON-1270?page=all ]
Pier Fumagalli updated COCOON-1270:
---
Assign To: Torsten Curdt (was: Torsten Curdt)
Javaflow can't call inherited methods
-
Key: COCOON-1270
URL: http://issues.apache.org/jira/browse/COCOON-1270
Project: Cocoon
Type: Bug
Components: - Flowscript
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: Linux
Platform: PC
Reporter: Nikolaus Rath
Assignee: Torsten Curdt
A class named FlowHandler contains this method:
public void doInvokeMain()
{
try {
setParent(null);
doInvoke();
} catch (CommandException e) {
// Because we are the top level handler, something bad
// must have happened
throw new RuntimeException(Unhandled command: +
e.getCommand());
}
}
MenuBarHandler is a class inherited from FlowHandler. The following does *not*
work (from sitemap.xmap):
map:flow language=java
map:script src=org.rath.votra.MenuBarHandler/
/map:flow
[...]
map:match pattern=start
map:call function=invokeMain /
/map:match
When accessing the start URI, cocoon produces an InstantiationException.
When I add the doInvokeMain method directly to the MenuBarHandler class,
everything works fine:
/* If we do not define this method here, we get an
java.lang.InstantiationException
from cocoon. Seems to be a bug. */
public void doInvokeMain() {
super.doInvokeMain();
}
It seems that cocoon can't call inherited methods as flow handlers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-677) iText Serializer not working
[ http://issues.apache.org/jira/browse/COCOON-677?page=all ] Pier Fumagalli updated COCOON-677: -- Assign To: Torsten Curdt (was: Torsten Curdt) iText Serializer not working Key: COCOON-677 URL: http://issues.apache.org/jira/browse/COCOON-677 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.1 Milestone 1 Environment: Operating System: Linux Platform: PC Reporter: Michael Enke Assignee: Torsten Curdt Attachments: iTextSerializer.java.diff-u, iTextSerializerLandscape.java In my actual project I found that Apache FOP is not suitable for the requirements I have to fullfill. I can not generate huge documents, I can not create documents with Asian Fonts from Adobe so I was looking on itext. With itext I can do both. So I was looking into itext in Cocoon: The itext serializer as it is now can not be used. I only get the example page one times generated. If I reload, I get the page from the cache. But if I change hello.xml or page2itext.xsl I get com.lowagie.text.DocumentException: The document has been closed. You can't add any Elements The reason is: For every iText document you need to create a new Document. But with current itext serializer there is only one time a Document created, at configure. This is wrong. The new Document() must go into setOutputStream (or startDocument?). There is also the need for open and close the itext document. I attach a patch how this is possible. But for this a newer version for itext is required. The actual version is 0.99. iText itself has some support for xml but not all is configurable with xml. It is a java library and needs e.g. for landscape output a method call. That means: We can only output in portrait mode. On my system I added a second serializer for landscape. I add the file but should also be added in sitemap. I will work on itext source to get all info through xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1253) PartInMemory has protected constructor
[ http://issues.apache.org/jira/browse/COCOON-1253?page=all ] Pier Fumagalli updated COCOON-1253: --- Assign To: Torsten Curdt (was: Torsten Curdt) PartInMemory has protected constructor -- Key: COCOON-1253 URL: http://issues.apache.org/jira/browse/COCOON-1253 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Grzegorz Sikora Assignee: Torsten Curdt PartInMemory has protected constructor. This constructor should be public like it was just before svn migration. This bug touches setValue Upload widget problem ... With public PartInMemory it's possible to create initial state value for Upload widget. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
On 25 Oct 2005, at 14:17, Jorg Heymans wrote: Torsten Curdt wrote: The javaflow forms binding example is broken due to a cforms change. I assume it's an easy fix. The first time i click on any of the javaflow samples I get 15:13:40.556 WARN!! Error for /samples/blocks/javaflow/calculator.do java.lang.UnsatisfiedLinkError: /usr/lib/j2sdk1.4.2_09/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory Is this from the cocoon.zones.apache.org server? Because if so, I can see why CAPTCHA failed as well... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
On 25 Oct 2005, at 14:34, Jorg Heymans wrote: Pier Fumagalli wrote: 15:13:40.556 WARN!! Error for /samples/blocks/javaflow/calculator.do java.lang.UnsatisfiedLinkError: /usr/lib/j2sdk1.4.2_09/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory Is this from the cocoon.zones.apache.org server? Because if so, I can see why CAPTCHA failed as well... no this is tested local , any ideas ? The JVM can't see X11 libraries required for the AWT to function properly... I bet this is a linux box, and either you don't have X11 installed, or the libraries are in a place where they can't be dynamically linked (a directory not in your LD_LIBRARY_PATH variable or in the / etc/ld.so.conf file). Pier smime.p7s Description: S/MIME cryptographic signature
Re: How much longer for the issue spamming?
On 25 Oct 2005, at 15:23, Berin Loritsch wrote: On Tuesday 25 October 2005 10:18 am, hepabolu wrote: Berin Loritsch wrote: In the period of about 12 hours there has been over 120 messages generated by JIRA. All to do with opening and closing issues, etc. While it is to be expected that the introduction of the new tool is going to require some rampup time, Its hard to see the real mail traffic. Is there any way to have the messages sent to this list in digest form? That would cut down on the traffic allot. I'm done now. So traffic should be lower now. Bye, Helma Thanks. Is it still possible to have digest emails sent to the dev list instead of one per alteration? I think that is the most sensible option to minimize the signal to noise ratio on the list. Once all this cleanup of issues is done, Jira should not generate more messages than bugzilla. (And no, no digest are possible) Pier smime.p7s Description: S/MIME cryptographic signature
Re: Jira-Component changes
On 25 Oct 2005, at 15:54, Reinhard Poetz wrote: yes, that's a bit confusing; so much text for only changing a property. OTOH this won't happen in the future that often, after we have corrected all the components. As far as I can see, there's not (yet) a way to customize Jira email templates on a per-project basis... http://www.atlassian.com/software/jira/docs/v3.2/emailcontent.html They seem to be shared amongst all projects. We can on the other hand change what emails are sent and when. Currently we send notifications for these events: Issue Created Issue Updated Issue Assigned Issue Resolved Issue Closed Issue Commented Issue Reopened Issue Deleted Issue Moved Notified with emails are: All Watchers Reporter Current Assignee dev@cocoon.apache.org Pier smime.p7s Description: S/MIME cryptographic signature
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
On 25 Oct 2005, at 16:06, Jorg Heymans wrote: Pier Fumagalli wrote: The JVM can't see X11 libraries required for the AWT to function properly... I bet this is a linux box, and either you don't have X11 installed, or the libraries are in a place where they can't be dynamically linked (a directory not in your LD_LIBRARY_PATH variable or in the / etc/ld.so.conf file). you're probably correct in assuming that there is something wrong with X11 libs, I'm just puzzled as to why this is a problem when running the JDO samples. oh well :) Well, no :-) Do you have the full exception stacktrace from the logs? I'd like to see who tries to initialize the AWT... Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1508) [PATCH] Avalonize TranscoderFactory
[ http://issues.apache.org/jira/browse/COCOON-1508?page=all ] Pier Fumagalli updated COCOON-1508: --- Bugzilla Id: (was: 34784) Component: Blocks: Batik (was: Blocks: (Undefined)) Description: TranscoderFactory configures itself in the constructor, where the available Transcoders are added through Java code. This patch avalonizes TranscoderFactory, so it can be configured in cocoon.roles and cocoon.xconf. Basically you can do transcoder-factory transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpeg/ transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpg/ transcoder class=org.apache.batik.transcoder.image.PNGTranscoder mime-type=image/png/ transcoder class=org.apache.batik.transcoder.image.TIFFTranscoder mime-type=image/tiff/ /transcoder-factory in cocoon.xconf was: TranscoderFactory configures itself in the constructor, where the available Transcoders are added through Java code. This patch avalonizes TranscoderFactory, so it can be configured in cocoon.roles and cocoon.xconf. Basically you can do transcoder-factory transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpeg/ transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpg/ transcoder class=org.apache.batik.transcoder.image.PNGTranscoder mime-type=image/png/ transcoder class=org.apache.batik.transcoder.image.TIFFTranscoder mime-type=image/tiff/ /transcoder-factory in cocoon.xconf [PATCH] Avalonize TranscoderFactory --- Key: COCOON-1508 URL: http://issues.apache.org/jira/browse/COCOON-1508 Project: Cocoon Type: Improvement Components: Blocks: Batik Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Priority: Minor Attachments: conf.zip, patch2.txt TranscoderFactory configures itself in the constructor, where the available Transcoders are added through Java code. This patch avalonizes TranscoderFactory, so it can be configured in cocoon.roles and cocoon.xconf. Basically you can do transcoder-factory transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpeg/ transcoder class=org.apache.batik.transcoder.image.JPEGTranscoder mime-type=image/jpg/ transcoder class=org.apache.batik.transcoder.image.PNGTranscoder mime-type=image/png/ transcoder class=org.apache.batik.transcoder.image.TIFFTranscoder mime-type=image/tiff/ /transcoder-factory in cocoon.xconf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1467) ESQL exception handling problem
[ http://issues.apache.org/jira/browse/COCOON-1467?page=all ]
Pier Fumagalli updated COCOON-1467:
---
Bugzilla Id: (was: 33922)
Component: Blocks: Databases
(was: Blocks: (Undefined))
Description:
the esql logicsheet
/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
has an exception handling block that catches an exception but then just logs the
error and does nothing. This is a problem as I need the exception to come out.
This is inside the esql:connection template. Here's svn diff for my patch:
C:\localsvn diff
src\blocks\databases\java\org\apache\cocoon\components\language\markup\xsp\java\esql.xsl
Index:
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
===
---
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(revision 46070)
+++
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(working copy)
@@ -306,7 +306,7 @@
xsl:apply-templates/
}
catch (SQLException _esql_exception_xsl:value-of select=generate-id(.)/
) {
- getLogger().error(,_esql_exception_xsl:value-of select=generate-id(.)
/);
+ throw new RuntimeException(Error connecting to db to execute query: +
_esql_exception_xsl:value-of select=generate-id(.)/);
}
finally {
try {
was:
the esql logicsheet
/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
has an exception handling block that catches an exception but then just logs the
error and does nothing. This is a problem as I need the exception to come out.
This is inside the esql:connection template. Here's svn diff for my patch:
C:\localsvn diff
src\blocks\databases\java\org\apache\cocoon\components\language\markup\xsp\java\esql.xsl
Index:
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
===
---
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(revision 46070)
+++
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(working copy)
@@ -306,7 +306,7 @@
xsl:apply-templates/
}
catch (SQLException _esql_exception_xsl:value-of select=generate-id(.)/
) {
- getLogger().error(,_esql_exception_xsl:value-of select=generate-id(.)
/);
+ throw new RuntimeException(Error connecting to db to execute query: +
_esql_exception_xsl:value-of select=generate-id(.)/);
}
finally {
try {
ESQL exception handling problem
---
Key: COCOON-1467
URL: http://issues.apache.org/jira/browse/COCOON-1467
Project: Cocoon
Type: Bug
Components: Blocks: Databases
Versions: 2.1.6
Environment: Operating System: Windows XP
Platform: PC
Reporter: Oliver Powell
Assignee: Cocoon Developers Team
Priority: Minor
the esql logicsheet
/src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
has an exception handling block that catches an exception but then just logs
the
error and does nothing. This is a problem as I need the exception to come out.
This is inside the esql:connection template. Here's svn diff for my patch:
C:\localsvn diff
src\blocks\databases\java\org\apache\cocoon\components\language\markup\xsp\java\esql.xsl
Index:
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
===
---
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(revision 46070)
+++
src/blocks/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
(working copy)
@@ -306,7 +306,7 @@
xsl:apply-templates/
}
catch (SQLException _esql_exception_xsl:value-of
select=generate-id(.)/
) {
- getLogger().error(,_esql_exception_xsl:value-of
select=generate-id(.)
/);
+ throw new RuntimeException(Error connecting to db to execute query:
+
_esql_exception_xsl:value-of select=generate-id(.)/);
}
finally {
try {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1449) soap logicsheet doesn't work (xscriptManager component cannot be resolved)
[ http://issues.apache.org/jira/browse/COCOON-1449?page=all ] Pier Fumagalli updated COCOON-1449: --- Bugzilla Id: (was: 33616) Component: Blocks: XSP (was: Blocks: (Undefined)) Description: Running a xsp using the soap logicsheet will result in the following compile error: // start error (lines 80-80) Component cannot be resolved or is not a type manager.release((Component)xscriptManager); // end error This is my xsp, which worked without problems on cocoon 2.1.6: ?xml version=1.0? xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; page html head titleSOAP Test/title /head body h1Cocoon SOAP Test/h1 p soap:call url=http://localhost:9090/SOLICY_SOAP/services/HelloWorld; ns:hello xmlns:ns=http://soap.solicy.foo.com/ /soap:call /p /body /html /page /xsp:page was: Running a xsp using the soap logicsheet will result in the following compile error: // start error (lines 80-80) Component cannot be resolved or is not a type manager.release((Component)xscriptManager); // end error This is my xsp, which worked without problems on cocoon 2.1.6: ?xml version=1.0? xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; page html head titleSOAP Test/title /head body h1Cocoon SOAP Test/h1 p soap:call url=http://localhost:9090/SOLICY_SOAP/services/HelloWorld; ns:hello xmlns:ns=http://soap.solicy.foo.com/ /soap:call /p /body /html /page /xsp:page soap logicsheet doesn't work (xscriptManager component cannot be resolved) -- Key: COCOON-1449 URL: http://issues.apache.org/jira/browse/COCOON-1449 Project: Cocoon Type: Bug Components: Blocks: XSP Versions: 2.1.8-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Bastian Bowe Assignee: Cocoon Developers Team Running a xsp using the soap logicsheet will result in the following compile error: // start error (lines 80-80) Component cannot be resolved or is not a type manager.release((Component)xscriptManager); // end error This is my xsp, which worked without problems on cocoon 2.1.6: ?xml version=1.0? xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; page html head titleSOAP Test/title /head body h1Cocoon SOAP Test/h1 p soap:call url=http://localhost:9090/SOLICY_SOAP/services/HelloWorld; ns:hello xmlns:ns=http://soap.solicy.foo.com/ /soap:call /p /body /html /page /xsp:page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1333) [PATCH] MultipartActionRequest.getParameterNames() skips query-string request parameters
[ http://issues.apache.org/jira/browse/COCOON-1333?page=all ] Pier Fumagalli updated COCOON-1333: --- Bugzilla Id: (was: 32160) Component: * Cocoon Core Blocks: Portal (was: Blocks: (Undefined)) Description: Methods getParameterNames() and getParameterMap() modified to return also parameter names of parameters from url query string. Methods getParameter() and getParameterValues() already return values for query-string request parameters. I suppose this must be always valid: For any n: getParameter(n) != null getParameterValues(n) != null: n in getParameterNames() n in getParameterMap() Also this TODO has been done :-) // TODO: Test multipart form with parameter in action= attribute was: Methods getParameterNames() and getParameterMap() modified to return also parameter names of parameters from url query string. Methods getParameter() and getParameterValues() already return values for query-string request parameters. I suppose this must be always valid: For any n: getParameter(n) != null getParameterValues(n) != null: n in getParameterNames() n in getParameterMap() Also this TODO has been done :-) // TODO: Test multipart form with parameter in action= attribute [PATCH] MultipartActionRequest.getParameterNames() skips query-string request parameters Key: COCOON-1333 URL: http://issues.apache.org/jira/browse/COCOON-1333 Project: Cocoon Type: Bug Components: * Cocoon Core, Blocks: Portal Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Assignee: Cocoon Developers Team Attachments: release_2_1_5_1.patch_6.txt, release_2_1_5_1.patch_7.txt Methods getParameterNames() and getParameterMap() modified to return also parameter names of parameters from url query string. Methods getParameter() and getParameterValues() already return values for query-string request parameters. I suppose this must be always valid: For any n: getParameter(n) != null getParameterValues(n) != null: n in getParameterNames() n in getParameterMap() Also this TODO has been done :-) // TODO: Test multipart form with parameter in action= attribute -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1302) [Patch] Word Document Generator
[ http://issues.apache.org/jira/browse/COCOON-1302?page=all ] Pier Fumagalli updated COCOON-1302: --- Bugzilla Id: (was: 31724) Component: Blocks: POI (was: Blocks: (Undefined)) Description: hy , i developed a word generator with the POI scratchpad for Word document (HWSF). So for use it , you must include the poi-scratchpad.jar + my code. Nicolas Maisonneuve was: hy , i developed a word generator with the POI scratchpad for Word document (HWSF). So for use it , you must include the poi-scratchpad.jar + my code. Nicolas Maisonneuve [Patch] Word Document Generator --- Key: COCOON-1302 URL: http://issues.apache.org/jira/browse/COCOON-1302 Project: Cocoon Type: Improvement Components: Blocks: POI Versions: 2.1.5 Environment: Operating System: other Platform: Other Reporter: Nicolas Maisonneuve Assignee: Cocoon Developers Team Priority: Minor Attachments: WordGenerator.zip, poi-scratchpad.jar, poi-word-sample.patch, wordgenerator.patch hy , i developed a word generator with the POI scratchpad for Word document (HWSF). So for use it , you must include the poi-scratchpad.jar + my code. Nicolas Maisonneuve -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1151) BlobSource cannot get datasource
[ http://issues.apache.org/jira/browse/COCOON-1151?page=all ] Pier Fumagalli updated COCOON-1151: --- Bugzilla Id: (was: 28803) Component: Blocks: Databases (was: Blocks: (Undefined)) Description: I've tested BlobSource on versions 2.0.4 and 2.1.2 and it works after adding the proper items to cocoon.xconf, web.xml and a proper pipeline to a sitemap (as well as having the oracle classes12.jar in the lib directory). Following the same configuration changes, version 2.1.3 and 2.1.4 give an error that the datasource can't be found. org.apache.cocoon.ProcessingException: Exception during source resolving.: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' Original Exception: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' at org.apache.cocoon.components.source.impl.BlobSource.getConnection (BlobSource.java:361) at org.apache.cocoon.components.source.impl.BlobSource.getInputStream (BlobSource.java:206) at org.apache.cocoon.components.source.SourceUtil.getInputSource (SourceUtil.java:382) at org.apache.cocoon.components.source.SourceUtil.parse (SourceUtil.java:266) at org.apache.cocoon.generation.FileGenerator.generate (FileGenerator.java:141) .. was: I've tested BlobSource on versions 2.0.4 and 2.1.2 and it works after adding the proper items to cocoon.xconf, web.xml and a proper pipeline to a sitemap (as well as having the oracle classes12.jar in the lib directory). Following the same configuration changes, version 2.1.3 and 2.1.4 give an error that the datasource can't be found. org.apache.cocoon.ProcessingException: Exception during source resolving.: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' Original Exception: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' at org.apache.cocoon.components.source.impl.BlobSource.getConnection (BlobSource.java:361) at org.apache.cocoon.components.source.impl.BlobSource.getInputStream (BlobSource.java:206) at org.apache.cocoon.components.source.SourceUtil.getInputSource (SourceUtil.java:382) at org.apache.cocoon.components.source.SourceUtil.parse (SourceUtil.java:266) at org.apache.cocoon.generation.FileGenerator.generate (FileGenerator.java:141) .. BlobSource cannot get datasource Key: COCOON-1151 URL: http://issues.apache.org/jira/browse/COCOON-1151 Project: Cocoon Type: Bug Components: Blocks: Databases Versions: 2.1.3 Environment: Operating System: Windows XP Platform: PC Reporter: Charlie Irrgang Assignee: Cocoon Developers Team I've tested BlobSource on versions 2.0.4 and 2.1.2 and it works after adding the proper items to cocoon.xconf, web.xml and a proper pipeline to a sitemap (as well as having the oracle classes12.jar in the lib directory). Following the same configuration changes, version 2.1.3 and 2.1.4 give an error that the datasource can't be found. org.apache.cocoon.ProcessingException: Exception during source resolving.: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' Original Exception: org.apache.excalibur.source.SourceException: Cannot get datasource 'dirt' at org.apache.cocoon.components.source.impl.BlobSource.getConnection (BlobSource.java:361) at org.apache.cocoon.components.source.impl.BlobSource.getInputStream (BlobSource.java:206) at org.apache.cocoon.components.source.SourceUtil.getInputSource (SourceUtil.java:382) at org.apache.cocoon.components.source.SourceUtil.parse (SourceUtil.java:266) at org.apache.cocoon.generation.FileGenerator.generate (FileGenerator.java:141) .. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1131) Caching inoperative in modular DatabaseAction
[ http://issues.apache.org/jira/browse/COCOON-1131?page=all ] Pier Fumagalli updated COCOON-1131: --- Bugzilla Id: (was: 28495) Component: Blocks: Databases (was: Blocks: (Undefined)) Description: In org.apache.cocoon.acting.modular.DatabaseAction, the implemented query caching is inoperative. In the processTable() method a new LookUpKey is created for every request, and since the equals/hashKey methods are not overriden in LookUpKey, this means that the getQuery() method will be called for all requests and no caching is used, since the HashMap get will always return null. Andrzej was: In org.apache.cocoon.acting.modular.DatabaseAction, the implemented query caching is inoperative. In the processTable() method a new LookUpKey is created for every request, and since the equals/hashKey methods are not overriden in LookUpKey, this means that the getQuery() method will be called for all requests and no caching is used, since the HashMap get will always return null. Andrzej Caching inoperative in modular DatabaseAction - Key: COCOON-1131 URL: http://issues.apache.org/jira/browse/COCOON-1131 Project: Cocoon Type: Bug Components: Blocks: Databases Versions: 2.1.4 Environment: Operating System: All Platform: All Reporter: Andrzej Taramina Assignee: Cocoon Developers Team In org.apache.cocoon.acting.modular.DatabaseAction, the implemented query caching is inoperative. In the processTable() method a new LookUpKey is created for every request, and since the equals/hashKey methods are not overriden in LookUpKey, this means that the getQuery() method will be called for all requests and no caching is used, since the HashMap get will always return null. Andrzej -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1103) JSP content type overrides serializer
[ http://issues.apache.org/jira/browse/COCOON-1103?page=all ] Pier Fumagalli updated COCOON-1103: --- Bugzilla Id: (was: 27957) Component: Blocks: Java Server Pages (was: Blocks: (Undefined)) Description: When the JSPGenerator is used to provide XML to cocoon pipelines, any call to setContentType() from the JSP page (including the default of text/html), overrides the content type specified by the pipeline's serializer. Thus if the JSP page sets the content type, which by default is text/html, and the cocoon pipeline serializes to XML, the resulting content type is text/html. was: When the JSPGenerator is used to provide XML to cocoon pipelines, any call to setContentType() from the JSP page (including the default of text/html), overrides the content type specified by the pipeline's serializer. Thus if the JSP page sets the content type, which by default is text/html, and the cocoon pipeline serializes to XML, the resulting content type is text/html. JSP content type overrides serializer - Key: COCOON-1103 URL: http://issues.apache.org/jira/browse/COCOON-1103 Project: Cocoon Type: Bug Components: Blocks: Java Server Pages Versions: 2.1.5 Environment: Operating System: Linux Platform: Other Reporter: Garrick Dasbach Assignee: Cocoon Developers Team When the JSPGenerator is used to provide XML to cocoon pipelines, any call to setContentType() from the JSP page (including the default of text/html), overrides the content type specified by the pipeline's serializer. Thus if the JSP page sets the content type, which by default is text/html, and the cocoon pipeline serializes to XML, the resulting content type is text/html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1658) Somewhere output is held...
Somewhere output is held... --- Key: COCOON-1658 URL: http://issues.apache.org/jira/browse/COCOON-1658 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Reporter: Pier Fumagalli Priority: Critical Cocoon standard, as of right now, built without any blocks. I modify the default sitemap adding one simple entry: map:match pattern=bigtest map:generate src=bigtest.xml/ map:serialize type=xml/ /map:match The file bigtest.xml is a 100Mb XML file that I simply want to generate and serialize (minimal test, no transformers that can do anything weird). I then open my terminal and do a curl http://localhost:/bigtest /dev/null, to have an idea of the thrughput for this file. Apparently, the output is held for roughly 25 seconds, nothing comes out, no bytes are serialized. All of a sudden, the entire 100 megabytes are serialized in one big lump (and it takes 5 seconds to do so). This happens if the pipeline is configured as being caching or noncaching (nothing changes). In the first 25 seconds, the JVM running Cocoon uses 100% of my processor (so, it's doing something), and the TOP shows something _really_ strange. My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the big request, close cocoon). This is a trace from my TOP: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE - 12498 java 0.1% 0:03.01 19 357 240 25.1M 28.7M 25.4M 735M 12498 java87.2% 0:06.22 19 403 242 54.2M+ 28.7M 55.1M+ 735M- 12498 java75.7% 0:10.88 19 403 242 78.3M 28.7M 79.2M 735M 12498 java80.2% 0:14.78 19 403 242 129M 28.7M 130M 735M 12498 java84.3% 0:19.77 19 403 242 168M+ 28.7M 169M+ 735M 12498 java77.4% 0:23.67 19 403 242 231M 28.7M 232M 735M 12498 java40.7% 0:27.92 19 403 242 231M+ 28.7M 232M+ 735M+ 12498 java 0.1% 0:28.18 20 408 245 231M 28.7M 232M 735M Something tells me that we are indeed caching all the content in a big char[] (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]). Any clue on where this can happen? It's impairing our ability to serve bigger feeds (aka, 2 gigs! :-P) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
