Re: Forms enum selection list order
Simone Gianni wrote: Hi Ugo, yes, i checked that apache enums are in commons, so we already have that dependency. We should only add it to forms block dependencies in gump.xml (I think, tell me if there is something more to do for this). You don't need to add the dependency in gump.xml. Cforms already depends on commons-lang. :-) Best Regards, Antonio Gallardo. Simone Ugo Cei wrote: Il giorno 02/mar/06, alle ore 00:35, Simone Gianni ha scritto: I developed an ApacheEnumSelectionList class and I'm ready to contribute it, but i think it would be nicer to "merge" this code in the actual EnumSelectionList, so that if the given enum is an apache enum, the getList method is used instead of the getDeclaredFields method. Jakarta Commons enum are already in commons-lang, right? If so, it's a dependency we already have, so why not? Ugo
[jira] Closed: (COCOON-1206) [PATCH] Cleanup transformer
[ http://issues.apache.org/jira/browse/COCOON-1206?page=all ] David Crossley closed COCOON-1206: -- Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Thanks, applied to both trunk and 2.1 branch. > [PATCH] Cleanup transformer > --- > > Key: COCOON-1206 > URL: http://issues.apache.org/jira/browse/COCOON-1206 > Project: Cocoon > Type: Improvement > Components: Blocks: (Undefined) > Versions: 2.1.8 > Environment: Operating System: All > Platform: All > Reporter: Miles Elam > Assignee: Cocoon Developers Team > Priority: Minor > Fix For: 2.1.9-dev (current SVN), 2.2-dev (Current SVN) > Attachments: CleanupTransformer.java > > Cleanup transformer: removes excess whitespace while adding some where needed > for legibility. Also > strips unwanted namespace prefix mappings. The following attachment, if > accepted, is donated to the > Apache Software Foundation to license and use as they see fit. -- 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: Cocoon developers opensource license YourKit Java Profiler
David Crossley wrote: > > Cocoon developers who would like to use YourKit Java Profiler > during their work on the Cocoon project, are entitled to an > Open Source license. > > Here is their response to my request for clarification. > I defined exactly what we mean by "developer" and "committer" > and then asked what was their meaning ... > > " > "developer" is a person who will use profiler during his > work in Forrest/Cocoon project. > " Last call. Any more Cocoon developers wanting a license key? -David
Re: [jira] Closed: (COCOON-649) [PATCH] Made SQLTransformer paginatable
It looks like the patch was made against the old CVS for Cocoon. My did you Close, rather than just ask for a new patch? -David > Jean-Baptiste Quenot closed COCOON-649: > --- > > Resolution: Invalid > > This is a good idea. However patch does not apply. Feel free to reopen if > you can provide an updated patch. > > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |Index: > src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java > |=== > |RCS file: > /home/cvspublic/cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java,v > |retrieving revision 1.6 > |diff -u -r1.6 SQLTransformer.java > |--- > src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java > 11 Jun 2003 00:28:31 - 1.6 > |+++ > src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java > 11 Jun 2003 15:35:17 - > -- > Patching file SQLTransformer.java using Plan A... > Hunk #1 failed at 52. > Hunk #2 failed at 87. > Hunk #3 failed at 178. > Hunk #4 failed at 186. > Hunk #5 failed at 231. > Hunk #6 failed at 251. > Hunk #7 failed at 304. > Hunk #8 failed at 333. > Hunk #9 failed at 348. > Hunk #10 failed at 361. > Hunk #11 failed at 390. > Hunk #12 failed at 407. > Hunk #13 failed at 461. > Hunk #14 failed at 480. > Hunk #15 failed at 499. > Hunk #16 failed at 518. > Hunk #17 failed at 562. > Hunk #18 failed at 601. > Hunk #19 failed at 627. > Hunk #20 failed at 669. > Hunk #21 failed at 696. > Hunk #22 failed at 720. > Hunk #23 succeeded at 747 with fuzz 2 (offset 15 lines). > Hunk #24 failed at 766. > Hunk #25 failed at 817. > Hunk #26 failed at 848. > Hunk #27 failed at 922. > 26 out of 27 hunks failed--saving rejects to SQLTransformer.java.rej > done > > > > [PATCH] Made SQLTransformer paginatable > > --- > > > > Key: COCOON-649 > > URL: http://issues.apache.org/jira/browse/COCOON-649 > > Project: Cocoon > > Type: Improvement > > Components: - Components: Avalon > > Versions: 2.1.8 > > Environment: Operating System: All > > Platform: All > > Reporter: Boon Hian Tek > > Assignee: Jean-Baptiste Quenot > > Priority: Minor > > Attachments: contrib-2003_37_11.tar.gz, sql_transformer_2003_04_28.tar.gz, > > sqlpatch.tar, sqltransformer.patch.tar.gz > > > > Hi, > > Thanks to idea and code from Irv Salisbury III, I made some > > changes to src/blocks/database/.../transformation/SQLTransformer > > and made it "Paginator"able. > > With this patch, you can set page-size and current-page via > > the sitemap and have paging done via result set controls rather > > than filtering through a Paginator Transformer. > > While that transformer works, in the case of a database query, > > it just seemed a tad wasteful not to do the paging at a lower > > level. > > I have made some changes to the Paginator code as well to allow > > calls from PagingSQLTransformer to spit out paging related tags. > > This will ease any transition of switching from using the > > paginator transformer to using this PagingSQLTransformer. > > Before using PagingSQLTransformer, > >> type="regexp"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using PagingSQLTransformer, > >> type="regexp"> > > > > > > > > > > > > > >> value="pagesheets/display.xml"/> > > > > > > > > > > > > > > > > > > > > > > > > I made some patch to the Paginator code that should fix bug > > #13865. > > Further changes to the Paginator code now allows, multiple > > range-links too. > > One of the inconsistency (maybe) from all these changes is that > > I make it so that "page-size" is configured for the SQLTransformer > > and the pagesheet/rules/count/num is ignored. I have not figure > > out a way to use both easily. I will have to do some more thinking > > on that. What is easier to understand? Comments? > > This is my first time contributing in a "patch" sort of way to > > any open source project, so excuse me if I get any procedure > > wrong. > > Boon > > -- > 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: Block deployment
Jean-Baptiste Quenot wrote:
* Daniel Fagerstrom:
These artifact is newer than the latest update of the snapshot
repository, you need to compile and install cocoon-blocks-fw and
cocoon-sitemap in you local repository to get it to work.
And in general you need to get all Cocoon blocks from your
local repository as the one from the snapshot repository are
obsolete. Do a
$ mvn -Dmaven.test.skip=true clean install from cocoon-trunk.
OK thanks.
Now the mvn clean cocoon:simple-deploy in
cocoon-block-deployer/cocoon-deployer-plugin-demo works.
I'm wondering why installing library is so slow, like one second
for each of these lines:
[INFO] Installing library WEB-INF/lib/commons-jci-r306555.jar
Because transactional file acces of the commons-transaction project is used. I
plan to make this configureable (http://issues.apache.org/jira/browse/COCOON-1773)
And BTW I read the tutorials about Cocoon block deployer, maybe it
would be worth adding a TODO list to be sure what feature is
available. For example, 795.html states that one of the Primary
features is to define which blocks are installed. But is it
really the case?
sorry, the sentence was misleading. I changed it to "define which blocks are to
be installed" or IOW, which blocks to you want to install.
And I have a more general question: what concrete usecase and
existing blocks have motivated the design and development of the
wiring feature? Do we have several blocks implementing the same
interface?
see http://wiki.apache.org/cocoon/BlockIntroduction, which was the originally
written by Stefano long time ago.
The wiki documents mainly deal with what we call "sitemap blocks". The last
missing piece is how component dependencies will finally look like. That's
pretty much undefined. Declarative services in OSGi could be the answer.
I could imagine that if we had an eXist block, one
would choose between eXist and Xindice, both implementing the same
contract... could you please give an example?
If the link above and my (short) explanation is not enough, feel free to ask :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
* Daniel Fagerstrom: > These artifact is newer than the latest update of the snapshot > repository, you need to compile and install cocoon-blocks-fw and > cocoon-sitemap in you local repository to get it to work. > > And in general you need to get all Cocoon blocks from your > local repository as the one from the snapshot repository are > obsolete. Do a > > $ mvn -Dmaven.test.skip=true clean install from cocoon-trunk. OK thanks. Now the mvn clean cocoon:simple-deploy in cocoon-block-deployer/cocoon-deployer-plugin-demo works. I'm wondering why installing library is so slow, like one second for each of these lines: [INFO] Installing library WEB-INF/lib/commons-jci-r306555.jar And BTW I read the tutorials about Cocoon block deployer, maybe it would be worth adding a TODO list to be sure what feature is available. For example, 795.html states that one of the Primary features is to define which blocks are installed. But is it really the case? And I have a more general question: what concrete usecase and existing blocks have motivated the design and development of the wiring feature? Do we have several blocks implementing the same interface? I could imagine that if we had an eXist block, one would choose between eXist and Xindice, both implementing the same contract... could you please give an example? Maybe you can point me to relevant cocoon-dev archives? TIA, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: repository block
* Max Pfingsthorn: > I want to refactor the repository block so that SourceProperty > is an interface. Or at least implement readObject() and > writeObject(), so it can be serialized. SourceProperty not > being Serializable makes the WebDAVSource (and any other > which implements InspectableSource) not cacheable via the > CachingSourceFactory from the scratchpad. Hello Max, Does CachingSourceFactory give an error? How do you observe that WebDAVSource is not cacheable? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Closed: (COCOON-1371) [Patch] Allow ImageReader to process other image formats than JPEG
[ http://issues.apache.org/jira/browse/COCOON-1371?page=all ] Jean-Baptiste Quenot closed COCOON-1371: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Committed, thanks! > [Patch] Allow ImageReader to process other image formats than JPEG > -- > > Key: COCOON-1371 > URL: http://issues.apache.org/jira/browse/COCOON-1371 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.5 > Environment: Operating System: All > Platform: All > Reporter: george georgovassilis > Assignee: Jean-Baptiste Quenot > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: ImageReader.java.diff, ImageReader.java.diff > > Changed org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to > accept any input image type supported by the j2se. Of course, due to the lack > of > available encoders the output is still jpeg. Instead of the JPEGDecoder used > previously this now uses classes from java.awt and java.swing. In order for > this > to work on environments without graphics support, use -Djava.awt.headless=true -- 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] Commented: (COCOON-1371) [Patch] Allow ImageReader to process other image formats than JPEG
[ http://issues.apache.org/jira/browse/COCOON-1371?page=comments#action_12368520 ] Jean-Baptiste Quenot commented on COCOON-1371: -- The patch still applies, you're lucky :-) > [Patch] Allow ImageReader to process other image formats than JPEG > -- > > Key: COCOON-1371 > URL: http://issues.apache.org/jira/browse/COCOON-1371 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.5 > Environment: Operating System: All > Platform: All > Reporter: george georgovassilis > Assignee: Jean-Baptiste Quenot > Attachments: ImageReader.java.diff, ImageReader.java.diff > > Changed org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to > accept any input image type supported by the j2se. Of course, due to the lack > of > available encoders the output is still jpeg. Instead of the JPEGDecoder used > previously this now uses classes from java.awt and java.swing. In order for > this > to work on environments without graphics support, use -Djava.awt.headless=true -- 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] Subscription: COCOON-open-with-patch
It would be still better if you could list only *Unassigned* bug reports, or assigned to « Cocoon Developers Team ». -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Assigned: (COCOON-1371) [Patch] Allow ImageReader to process other image formats than JPEG
[ http://issues.apache.org/jira/browse/COCOON-1371?page=all ] Jean-Baptiste Quenot reassigned COCOON-1371: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) > [Patch] Allow ImageReader to process other image formats than JPEG > -- > > Key: COCOON-1371 > URL: http://issues.apache.org/jira/browse/COCOON-1371 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.5 > Environment: Operating System: All > Platform: All > Reporter: george georgovassilis > Assignee: Jean-Baptiste Quenot > Attachments: ImageReader.java.diff, ImageReader.java.diff > > Changed org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to > accept any input image type supported by the j2se. Of course, due to the lack > of > available encoders the output is still jpeg. Instead of the JPEGDecoder used > previously this now uses classes from java.awt and java.swing. In order for > this > to work on environments without graphics support, use -Djava.awt.headless=true -- 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] Assigned: (COCOON-1334) [PATCH] FilterTransformer fixed for nondeterministic behavior
[ http://issues.apache.org/jira/browse/COCOON-1334?page=all ] Jean-Baptiste Quenot reassigned COCOON-1334: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) > [PATCH] FilterTransformer fixed for nondeterministic behavior > - > > Key: COCOON-1334 > URL: http://issues.apache.org/jira/browse/COCOON-1334 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.5 > Environment: Operating System: All > Platform: Other > Reporter: Michal Durdina > Assignee: Jean-Baptiste Quenot > Attachments: RELEASE_2_1_6.patch_8.diff, release_2_1_5_1.patch_9.txt > > Nondeterministic behavior for nested elemets with same name was fixed. > New feature : if blocknr is less than zero, then elemets are only splitted to > blocks -- 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] Closed: (COCOON-1334) [PATCH] FilterTransformer fixed for nondeterministic behavior
[ http://issues.apache.org/jira/browse/COCOON-1334?page=all ] Jean-Baptiste Quenot closed COCOON-1334: Resolution: Invalid Seems interesting, but sadly the patch does not apply anymore. Feel free to reopen the bug if you can provide an updated patch. Hmm... Looks like a unified diff to me... The text leading up to this was: -- |diff -Naur -x .svn cocoon-2.1.6.bak\src\java\org\apache\cocoon\transformation\FilterTransformer.java cocoon-2.1.6\src\java\org\apache\cocoon\transformation\FilterTransformer.java |--- cocoon-2.1.6.bak\src\java\org\apache\cocoon\transformation\FilterTransformer.java Thu Nov 25 17:19:47 2004 |+++ cocoon-2.1.6\src\java\org\apache\cocoon\transformation\FilterTransformer.java Sun Dec 12 20:56:38 2004 -- File to patch: src/java/org/apache/cocoon/transformation/FilterTransformer.java Patching file src/java/org/apache/cocoon/transformation/FilterTransformer.java using Plan A... Hunk #1 failed at 15. Hunk #2 failed at 28. Hunk #3 failed at 48. Hunk #4 failed at 68. Hunk #5 failed at 85. Hunk #6 failed at 124. 6 out of 6 hunks failed--saving rejects to src/java/org/apache/cocoon/transformation/FilterTransformer.java.rej > [PATCH] FilterTransformer fixed for nondeterministic behavior > - > > Key: COCOON-1334 > URL: http://issues.apache.org/jira/browse/COCOON-1334 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.5 > Environment: Operating System: All > Platform: Other > Reporter: Michal Durdina > Assignee: Cocoon Developers Team > Attachments: RELEASE_2_1_6.patch_8.diff, release_2_1_5_1.patch_9.txt > > Nondeterministic behavior for nested elemets with same name was fixed. > New feature : if blocknr is less than zero, then elemets are only splitted to > blocks -- 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] Closed: (COCOON-649) [PATCH] Made SQLTransformer paginatable
[ http://issues.apache.org/jira/browse/COCOON-649?page=all ] Jean-Baptiste Quenot closed COCOON-649: --- Resolution: Invalid This is a good idea. However patch does not apply. Feel free to reopen if you can provide an updated patch. Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java |=== |RCS file: /home/cvspublic/cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java,v |retrieving revision 1.6 |diff -u -r1.6 SQLTransformer.java |--- src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java 11 Jun 2003 00:28:31 - 1.6 |+++ src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java 11 Jun 2003 15:35:17 - -- Patching file SQLTransformer.java using Plan A... Hunk #1 failed at 52. Hunk #2 failed at 87. Hunk #3 failed at 178. Hunk #4 failed at 186. Hunk #5 failed at 231. Hunk #6 failed at 251. Hunk #7 failed at 304. Hunk #8 failed at 333. Hunk #9 failed at 348. Hunk #10 failed at 361. Hunk #11 failed at 390. Hunk #12 failed at 407. Hunk #13 failed at 461. Hunk #14 failed at 480. Hunk #15 failed at 499. Hunk #16 failed at 518. Hunk #17 failed at 562. Hunk #18 failed at 601. Hunk #19 failed at 627. Hunk #20 failed at 669. Hunk #21 failed at 696. Hunk #22 failed at 720. Hunk #23 succeeded at 747 with fuzz 2 (offset 15 lines). Hunk #24 failed at 766. Hunk #25 failed at 817. Hunk #26 failed at 848. Hunk #27 failed at 922. 26 out of 27 hunks failed--saving rejects to SQLTransformer.java.rej done > [PATCH] Made SQLTransformer paginatable > --- > > Key: COCOON-649 > URL: http://issues.apache.org/jira/browse/COCOON-649 > Project: Cocoon > Type: Improvement > Components: - Components: Avalon > Versions: 2.1.8 > Environment: Operating System: All > Platform: All > Reporter: Boon Hian Tek > Assignee: Jean-Baptiste Quenot > Priority: Minor > Attachments: contrib-2003_37_11.tar.gz, sql_transformer_2003_04_28.tar.gz, > sqlpatch.tar, sqltransformer.patch.tar.gz > > Hi, > Thanks to idea and code from Irv Salisbury III, I made some > changes to src/blocks/database/.../transformation/SQLTransformer > and made it "Paginator"able. > With this patch, you can set page-size and current-page via > the sitemap and have paging done via result set controls rather > than filtering through a Paginator Transformer. > While that transformer works, in the case of a database query, > it just seemed a tad wasteful not to do the paging at a lower > level. > I have made some changes to the Paginator code as well to allow > calls from PagingSQLTransformer to spit out paging related tags. > This will ease any transition of switching from using the > paginator transformer to using this PagingSQLTransformer. > Before using PagingSQLTransformer, >type="regexp"> > > > > > > > > > > > > > > > > > > Using PagingSQLTransformer, >type="regexp"> > > > > > > > > > > > > > > > > > > > I made some patch to the Paginator code that should fix bug > #13865. > Further changes to the Paginator code now allows, multiple > range-links too. > One of the inconsistency (maybe) from all these changes is that > I make it so that "page-size" is configured for the SQLTransformer > and the pagesheet/rules/count/num is ignored. I have not figure > out a way to use both easily. I will have to do some more thinking > on that. What is easier to understand? Comments? > This is my first time contributing in a "patch" sort of way to > any open source project, so excuse me if I get any procedure > wrong. > Boon -- 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] Assigned: (COCOON-649) [PATCH] Made SQLTransformer paginatable
[ http://issues.apache.org/jira/browse/COCOON-649?page=all ] Jean-Baptiste Quenot reassigned COCOON-649: --- Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) > [PATCH] Made SQLTransformer paginatable > --- > > Key: COCOON-649 > URL: http://issues.apache.org/jira/browse/COCOON-649 > Project: Cocoon > Type: Improvement > Components: - Components: Avalon > Versions: 2.1.8 > Environment: Operating System: All > Platform: All > Reporter: Boon Hian Tek > Assignee: Jean-Baptiste Quenot > Priority: Minor > Attachments: contrib-2003_37_11.tar.gz, sql_transformer_2003_04_28.tar.gz, > sqlpatch.tar, sqltransformer.patch.tar.gz > > Hi, > Thanks to idea and code from Irv Salisbury III, I made some > changes to src/blocks/database/.../transformation/SQLTransformer > and made it "Paginator"able. > With this patch, you can set page-size and current-page via > the sitemap and have paging done via result set controls rather > than filtering through a Paginator Transformer. > While that transformer works, in the case of a database query, > it just seemed a tad wasteful not to do the paging at a lower > level. > I have made some changes to the Paginator code as well to allow > calls from PagingSQLTransformer to spit out paging related tags. > This will ease any transition of switching from using the > paginator transformer to using this PagingSQLTransformer. > Before using PagingSQLTransformer, >type="regexp"> > > > > > > > > > > > > > > > > > > Using PagingSQLTransformer, >type="regexp"> > > > > > > > > > > > > > > > > > > > I made some patch to the Paginator code that should fix bug > #13865. > Further changes to the Paginator code now allows, multiple > range-links too. > One of the inconsistency (maybe) from all these changes is that > I make it so that "page-size" is configured for the SQLTransformer > and the pagesheet/rules/count/num is ignored. I have not figure > out a way to use both easily. I will have to do some more thinking > on that. What is easier to understand? Comments? > This is my first time contributing in a "patch" sort of way to > any open source project, so excuse me if I get any procedure > wrong. > Boon -- 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: a bug in file upload widget
* darcy: > Hey: > > I find a bug when I use the file upload widget in my forms. In the > form, > > I use a repeater , in it, have a file upload widget and an repeater-action > widget. > > When I choose a file from my disk(with the filename in Chinese), and then > save this form(if this validation is fail) or add a new file upload widget > in my repeater, then the file name is wrong(with a incorrect encode), and if > the form is save succeed, the fiel name is alse incorrect. > > What is the matter? Could you please file a testcase on JIRA, our bug tracking system at http://issues.apache.org/jira/browse/COCOON Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
RE: environment errors
...nevermind. that didn't do the trick. max > -Original Message- > From: Max Pfingsthorn > Sent: Thursday, March 02, 2006 13:05 > To: dev@cocoon.apache.org > Subject: RE: environment errors > > > > > Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > Max Pfingsthorn schrieb: > > > Hi! > > > > > > Okay, I traced this one to the > > o.a.c.environment.wrapper.EnvironmentWrapper > > > thank god for debuggers). That one does not implement > > release(Source) > > itself, > > >so the superclass is used, but since it is a wrapper, it is > > not initialized to > > >have a source resolver itself! I am not sure what this class > > is used for, but can I > > >just forward the call to the wrapped environment like some > > of the other > > methods do? > > > > > Hmm, no, I think this is then just a workaround for the > real problem. > > If the source resolver is null in release it either means that the > > resolveURI was never called before, so a source is tried to > > be released > > on a different env than it was looked up from. Or in the other case, > > finishProcessing() has been called prior to the release > > method. Then the > > order of method calls is wrong. > > > > Can you come up with a test case? > > Well, there are two errors here, actually. The one > Jean-Baptiste commented on and the one I traced. Both are > very similar, and seem to be caused by a similar problem... > > In Cocoon.process, in the last finally block, we call > > CocoonComponentManager.leaveEnvironment(); > CocoonComponentManager.endProcessing(environment, key); > > leaveEnvironment pops the environment stack while > endProcessing will call release (which in turn calls recycle) > on all components, which in turn calls > CocoonComponentManager.removeFromAutomaticRelease(Component) > which tries to acces the environment stack, which is empty. > > The other error is caused by endProcessing calling > env.finishingProcessing(); before desc.release();. > > Okay, I think I got it now. The > CocoonComponentManager.addComponentForAutomaticRelease will > actually add this component to the root environment (line > 464, in 2.1.8) because it does stack.get(0), which is the > lowest stack item. This happens for each sitemap source in > the init() method. > Since env.finishingProcessing() is called by each sitemap > source (through CocoonComponentManager.leaveEnvironment()) > and removeFromAutomaticRelease() is done after all the > processing, the environment the components from the deeper > sitemap sources will already have been ended. > It would be better to add them to the top of the stack. > > I think this would solve both problems, because both occur in > EnvironmentDescription.release(). > > I'll try to come up with a simple test case, but right now I > have a headache from two days of sitting in front of the > debugger... I'll let you know if changing this one line in > CocoonComponentManager.addComponentForAutomaticRelease > helped. Actually its changing > > final EnvironmentStack.Item objects = > (EnvironmentStack.Item)stack.get(0); > > into > > final EnvironmentStack.Item objects = > (EnvironmentStack.Item)stack.get(); > > I'll take some painkillers now. > > max >
RE: environment errors
Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Max Pfingsthorn schrieb: > > Hi! > > > > Okay, I traced this one to the > o.a.c.environment.wrapper.EnvironmentWrapper > > thank god for debuggers). That one does not implement > release(Source) > itself, > >so the superclass is used, but since it is a wrapper, it is > not initialized to > >have a source resolver itself! I am not sure what this class > is used for, but can I > >just forward the call to the wrapped environment like some > of the other > methods do? > > > Hmm, no, I think this is then just a workaround for the real problem. > If the source resolver is null in release it either means that the > resolveURI was never called before, so a source is tried to > be released > on a different env than it was looked up from. Or in the other case, > finishProcessing() has been called prior to the release > method. Then the > order of method calls is wrong. > > Can you come up with a test case? Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one I traced. Both are very similar, and seem to be caused by a similar problem... In Cocoon.process, in the last finally block, we call CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(environment, key); leaveEnvironment pops the environment stack while endProcessing will call release (which in turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component) which tries to acces the environment stack, which is empty. The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();. Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0), which is the lowest stack item. This happens for each sitemap source in the init() method. Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment()) and removeFromAutomaticRelease() is done after all the processing, the environment the components from the deeper sitemap sources will already have been ended. It would be better to add them to the top of the stack. I think this would solve both problems, because both occur in EnvironmentDescription.release(). I'll try to come up with a simple test case, but right now I have a headache from two days of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease helped. Actually its changing final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0); into final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(); I'll take some painkillers now. max
Re: Forms enum selection list order
Hi Ugo, yes, i checked that apache enums are in commons, so we already have that dependency. We should only add it to forms block dependencies in gump.xml (I think, tell me if there is something more to do for this). Simone Ugo Cei wrote: Il giorno 02/mar/06, alle ore 00:35, Simone Gianni ha scritto: I developed an ApacheEnumSelectionList class and I'm ready to contribute it, but i think it would be nicer to "merge" this code in the actual EnumSelectionList, so that if the given enum is an apache enum, the getList method is used instead of the getDeclaredFields method. Jakarta Commons enum are already in commons-lang, right? If so, it's a dependency we already have, so why not? Ugo -- Simone Gianni
Re: Forms enum selection list order
Il giorno 02/mar/06, alle ore 00:35, Simone Gianni ha scritto: I developed an ApacheEnumSelectionList class and I'm ready to contribute it, but i think it would be nicer to "merge" this code in the actual EnumSelectionList, so that if the given enum is an apache enum, the getList method is used instead of the getDeclaredFields method. Jakarta Commons enum are already in commons-lang, right? If so, it's a dependency we already have, so why not? Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
