RE: 2.2 is not building
org.apache.cocoon:cocoon-pipeline-impl:jar:1.1.0-SNAPSHOT is still missing, see attached log if you want Sorry, actually it's a little different now. The missing artifact now is org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT I'm testing this locally. BTW. What version of Maven do you use? You might try without allblock profile first. I've built latest trunk (allblocks) without any trouble so this must be something specific to your configuration. Do you use latest Maven release? Grzegorz, I was using Maven 2.0.7 and I tried it with latest (2.0.9) and I tried plain 'mvn install' (with Java 1.6.0_02), it still gives build error because of missing 'org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT'. I've tried this for now r664664. One really confusing thing is that it does work (!) with a backup version (from May) of ~/.m2/repository and it fails if this directory is empty. Appreciating your help, Alexander
[jira] Reopened: (COCOON-2152) EventAware cache does not persist correctly when using the StoreEventRegistryImpl
[ https://issues.apache.org/jira/browse/COCOON-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reopened COCOON-2152: --- What about trunk? Ellis indicated it's an issue there as well. EventAware cache does not persist correctly when using the StoreEventRegistryImpl - Key: COCOON-2152 URL: https://issues.apache.org/jira/browse/COCOON-2152 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10, 2.1.11, 2.2 Reporter: Ellis Pritchard Assignee: Andrew Savory Fix For: 2.1.12-dev (Current SVN) When using the DefaultEventRegistryImpl the functionality now works as expected (events are persisted and restored) after the patch applied in COCOON-2146. However, there's still a problem with StoreEventRegistryImpl. The behaviour is that it doesn't seem to actually write/restore any event entries: the maps in the EventRegistryDataWrapper are empty (but not null) after restart, even though the actual cache entry (key EVENTREGWRAPPER) was found in the Store, and the entries were present when persist() was called. The effect of this is to correctly restore the cached entries, but discard all the events, which means that event-flushes don't work any more, which is not a good thing. I've tracked this down to the fact that AbstractDoubleMapEventRepository#dispose() which performs the persist(), then immediately clear()s the maps, WHICH HAVEN'T YET BEEN WRITTEN TO DISK BY EHCACHE SHUTDOWN! This code has probably never worked :) Patches to follow; I propose modifying dispose() to null the map fields, but not perform clear() on them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1703) A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter
[ https://issues.apache.org/jira/browse/COCOON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-1703: -- Status: Continued (was: On Hold) A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - Key: COCOON-1703 URL: https://issues.apache.org/jira/browse/COCOON-1703 Project: Cocoon Issue Type: Bug Components: Blocks: POI Reporter: Krystian Nowak Attachments: psnc-v3.1.patch, psnc-v3.patch A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - in attachment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1958) Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without)
[ https://issues.apache.org/jira/browse/COCOON-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-1958: -- Status: Continued (was: On Hold) Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without) - Key: COCOON-1958 URL: https://issues.apache.org/jira/browse/COCOON-1958 Project: Cocoon Issue Type: Bug Components: Blocks: POI Affects Versions: 2.1.9 Reporter: Rolf Metternich Attachments: patch.txt For building an Excel-Sheet, I have to generate an Excel-Sheet by HSSFGenerator, manulpulate the values by a transformer and serialize as an Excel-Sheet. The first test are: generating an Excel-Sheet and serialize direct. Then, in the optimal case, the Excel-Sheet looks like the original. But there raised some error for which I made a workaround. First there was a NPE for fore- and background-colors by generation. I made a try-catch and set 'new HSSFColor.BLACK().getHexString()' for the foreground-color and 'new HSSFColor.WHITE().getHexString()' for the background when an error occures. This error occures only in cells, where the fore- and background-settings in Excel are automatic and none. patternColor (error on serializing) I set to 'attribute(PatternColor, new HSSFColor.WHITE().getHexString())'; Bold (error on serializing) I set the attribute from 'Short.toString(font.getBoldweight())' to ((font.getBoldweight()=font.BOLDWEIGHT_BOLD ) ? 1:0). With this workaround, the generation-serialization of the Excel-Sheet work, but no images are imported, like a logo-jpg. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1606) [BUG+PATCH] FormattingDecimalConvertor.java does not parse in BigDecimal mode
[ https://issues.apache.org/jira/browse/COCOON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-1606: -- Status: Continued (was: On Hold) No feedback, but issue shouldn't be on hold. [BUG+PATCH] FormattingDecimalConvertor.java does not parse in BigDecimal mode - Key: COCOON-1606 URL: https://issues.apache.org/jira/browse/COCOON-1606 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8 Environment: Operating System: other Platform: All Reporter: Thomas Lutz Assignee: Cocoon Developers Team Attachments: FormattingDecimalConvertor.java.tar.gz This patch enables BigDecimal parsing in FormattingDecimalConvertor. Basically if you have a widget with datatype decimal and enter a very large number, something like 1919191 and submit the form you'll get someting like a rounded value in technical notation. same thing with datatype long, to be seen in the samples at http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/form1 click NumberFields to change tab and enter 1919191 into Enter another number, larger than the other number: submit, then you get as value for the same field: 9,223,372,036,854,775,807 which is quite the same, though its no BigDecimal problem. at least some kind of validation error should occur... but a webapp changing user submitted values without a hint is a rather hot thing :-). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1740) Modular DatabaseSelectAction incorrectly handles multiple rows
[ https://issues.apache.org/jira/browse/COCOON-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-1740: -- Status: Continued (was: On Hold) Missing test case isn't really a reason for on hold. Modular DatabaseSelectAction incorrectly handles multiple rows -- Key: COCOON-1740 URL: https://issues.apache.org/jira/browse/COCOON-1740 Project: Cocoon Issue Type: Bug Components: Blocks: Databases Affects Versions: 2.1.8, 2.1.9, 2.2 Reporter: Tuomo Lesonen Priority: Minor Attachments: 20060310-cocoon-databases, DatabaseAction.java, DatabaseSelectAction.java When one needs to select multiple rows from a table, and the keys used to identify the rows vary, for example when request-param inputmodule is used with parameter-value of id[*], the outputted parameters are not unique. For example, when there are 3 different variations of the keys, and every variation returns a single row, the following is outputted: == row #0 o.a.c.components.modules.output.OutputModule:user.id[0] o.a.c.components.modules.output.OutputModule:user.username[0] o.a.c.components.modules.output.OutputModule:user.password[0] == row #1 o.a.c.components.modules.output.OutputModule:user.id[1] o.a.c.components.modules.output.OutputModule:user.username[0] o.a.c.components.modules.output.OutputModule:user.password[0] == row #2 o.a.c.components.modules.output.OutputModule:user.id[2] o.a.c.components.modules.output.OutputModule:user.username[0] o.a.c.components.modules.output.OutputModule:user.password[0] What happens is that on every row the names of the previous output-parameters from the value-fields (in descriptor) are overwritten with the new names, since the index is always forced back to zero. Because of this, the values from matching rows cannot be forwarded to other actions for additional processing (ie. DatabaseDeleteAction). The correct output should be: == row #0 o.a.c.components.modules.output.OutputModule:user.id[0] o.a.c.components.modules.output.OutputModule:user.username[0] o.a.c.components.modules.output.OutputModule:user.password[0] == row #1 o.a.c.components.modules.output.OutputModule:user.id[1] o.a.c.components.modules.output.OutputModule:user.username[1] o.a.c.components.modules.output.OutputModule:user.password[1] == row #2 o.a.c.components.modules.output.OutputModule:user.id[2] o.a.c.components.modules.output.OutputModule:user.username[2] o.a.c.components.modules.output.OutputModule:user.password[2] The only way this output can be achieved is when the keys do not vary, and multiple rows are returned. But this is not always the case, as the example above demonstrates. Here's the descriptor-snippet from the previous example: table name=user keys key name=id type=int set=master mode name=request-param parameter=id* type=all/ /key /keys values value name=username type=string/ value name=password type=string/ /values /table I have fixed this by adding a class variable sumIndex to DatabaseAction.java, which is incremented in DatabaseSelectAction.java in method processRow. sumIndex is then used to produce unique names for the output-parameters. Finally sumIndex contains the total rows selected. Patched files (2) attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1858) [PATCH]on-value-change does not work on suggestion list
[
https://issues.apache.org/jira/browse/COCOON-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603751#action_12603751
]
Jörg Heinicke commented on COCOON-1858:
---
What's missing here? Is it still an issue after all? We are using more recent
Dojo versions, Jeremy is working on the next one as far as I remember.
[PATCH]on-value-change does not work on suggestion list
---
Key: COCOON-1858
URL: https://issues.apache.org/jira/browse/COCOON-1858
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: Vincent Demay
Attachments: ComboBox.js, ComboBox.js
on-value-change does not work on suggestion list : there are to issues :
1 - submit on change is not setted on the widget in
form-advanced-field-styling.xsl :
Here is the patch :
--- sample/forms-advanced-field-styling.xsl 2006-06-07 14:51:27.809216500
+0
200
+++ sample/forms-advanced-field-styling.new.xsl 2006-06-07 14:52:04.293358000
+0
200
@@ -272,6 +272,7 @@
xsl:template match=fi:field[fi:styling/@type='suggest' and
@state='active']
span id=[EMAIL PROTECTED]
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} dojoType=CFormsSuggest
+xsl:apply-templates select=. mode=styling/
xsl:if test=fi:suggestion
xsl:attribute name=suggestionxsl:value-of
select=fi:suggestion//xsl:attribute
/xsl:if
2 - dojo Widget does not support onchange (see bug :
http://trac.dojotoolkit.org/ticket/897)
So I change the dojo file src/widget/html/ComboBox.js
The new file is in Attachement (and patch in dojo tracker)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r665954 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/environment/ src/java/org/apache/cocoon/environment/wrapper/ src/java/org/apache/cocoon/util/ src/test/org/apa
On 09.06.2008 22:40, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Jun 9 19:40:16 2008
New Revision: 665954
URL: http://svn.apache.org/viewvc?rev=665954view=rev
Log:
as a follow-up of COCOON-2168 (http://marc.info/?t=12089986853r=1w=4):
Cocoon's pipeline buffer increases from an initial buffer size of 8192 bytes to
the configurable flush buffer size rather than allocating the complete buffer
beforehand.
I'm still working on making initial buffer size configurable in sitemap.
+public OutputStream getOutputStream(int bufferSize) throws IOException {
// This method could be called several times during request processing
// with differing values of bufferSize and should handle this situation
// correctly.
+// FIXME (JH): Question is what correctly means. The current behavior
+// seems to be inconsistent: On a second call with bufferSize == 0 we
+// discard whatever the first called set up. With a bufferSize != 0 the
+// first call's setup is preserved. Why not always creating new
+// BufferedOutputStream in the else block replacing a potentially
+// existing one?
Any idea/comment on this? If the current behavior is correct or expected
it should probably commented appropriately.
Joerg
XSP block (was: Type 'serverpages' does not exist for 'map:generate')
Moving this discussion from users list (for reference [1]) to dev list. On 06.06.2008 19:02, Alfred Nathaniel wrote: Warning: I'm stating my own opinion here, nothing official or something like that. There are at least three problems with XSP: 1. No active committer is interested in XSP anymore, and even more, hardly anyone wants to invest her time in technology that seems to be deprecated in every dev's head but still block is not officially marked as deprecated. I may be not as active as you but I am a committer who is still very interested in XSP. In may daytime job we have 1000+ XSPs in production and no intention to drop that technology in the forseeable future. XSP has its shortcomings and pitfalls but after 7 years experience we know how to handle that. 2. The only reason why people keep trying to use XSP is that it has decent documentation on our site and this documentation has no information about XSP status. We should really explain people that Templates + Flowscript is much better approach. I think the reason why XSP appeals to newcomer is that the concept is familiar from JSP, and it is a combination of the three core technologies which Cocoon handles extremely well: XSP = XML + XSLT + Java. Personally, I still do not consider Flowscript an alternative for enterprise websites for three reasons: a.) Serverside JavaScript is an additional level in the technology stack you and your team have to master. b.) I would not bet my head on Rhino being threadsafe, and it is such a big beast to debug it yourself. c.) Continuations are a great idea, but how do you know when it is safe to free the memory? 3. XSP is really old technique and is not maintained by anyone (again officially, at dev/commits list). I'm not the one willing to take costs of XSP maintenance in C2.2 therefore I'll probably vote -1 for any actions leading to release of XSP block for C2.2. This is my first such a strong voice in this case but I firmly believe it's a high time have a concrete opinion. XSP is a really mature technology which hardly needs any maintenance any more. The reason why the XSP block (as many other blocks) is not released yet is actually more of a C2.2 issue than an XSP problem. Still, I'm open for discussion of course. I'd prefer to have this sort of discussion on the dev-list. I completely agree with Alfred. I don't see any reason for not releasing XSP block. Yes, somebody has to do the actual work. But why blocking it when somebody puts in the effort? You can estimate the maintenance costs by looking at the changes in the last years in the 2.1 branch. Joerg [1] http://marc.info/?t=12124988641r=1w=4
[jira] Commented: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603768#action_12603768 ] Jörg Heinicke commented on COCOON-2168: --- The allocated memory for the buffer will now be increasing starting from an initial buffer size of 8KB rather than allocating the whole memory for the potentially big buffer (like 1MB) beforehand. ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Felix Knecht Assignee: Jörg Heinicke Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: BufferedOutputStream
On 07.06.2008 03:13, Andy Stevens wrote: Out of interest, have you raised an enhancement request and/or a patch with the OpenJDK project[1]? It seems to me this increasing buffer behaviour would be useful more generally... Done. Joerg
