Re: Integration tests
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
I'm not sure how to say this but... Guys, there is a lot of to cover
by test
in this module and writing tests in trunk is not painful by any means.
you are right and this particular bug was my fault because I haven't
written any
tests yet. However, if you followed my commit messages, you saw that I
was able
to enable integration tests for trunk ('mvn install -P it' from
cocoon-webapp runs the tests in cocoon-webapp/src/test/java). My next
step on my todo list is covering the SSF with tests.
Yes I was very happy to see your commits. However, I always thought that it's
first that you write
unit tests for covering the most basic functionality and ITs for testing how
different parts
interact with each other.
Doesn't it make sense to write a few unit tests first? What kind of ITs do you
plan to write?
Could somebody with admin rights on vmbuild help me with adding the
integration tests to Continuum?
Sure, tell what command exactly is needed to be fired. Is mvn clean install -P
allbocks,it enough?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
[jira] Created: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[PATCH] Fix for Paginator when accessing out of bounds Pagination page -- Key: COCOON-2162 URL: https://issues.apache.org/jira/browse/COCOON-2162 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.1.11, 2.1.10 Reporter: Drew Buschhorn Priority: Minor Attachments: paginator.diff The Paginator transformer for apache cocoon will allow out of page-range requests. I've added the below logic-test into my own copy of cocoon, and that seems to fix the problem. Please let me know if you think 1. this is valid and 2. that it should be placed into svn for the 2.1.x version of cocoon. Example: http://localhost/samples/paginator/text(5) will return a valid empty file before patch (despite there being only 4 pages worth of data to paginate) after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Buschhorn updated COCOON-2162: --- Attachment: paginator.diff svn diff of Paginator.java [PATCH] Fix for Paginator when accessing out of bounds Pagination page -- Key: COCOON-2162 URL: https://issues.apache.org/jira/browse/COCOON-2162 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.1.10, 2.1.11 Reporter: Drew Buschhorn Priority: Minor Attachments: paginator.diff The Paginator transformer for apache cocoon will allow out of page-range requests. I've added the below logic-test into my own copy of cocoon, and that seems to fix the problem. Please let me know if you think 1. this is valid and 2. that it should be placed into svn for the 2.1.x version of cocoon. Example: http://localhost/samples/paginator/text(5) will return a valid empty file before patch (despite there being only 4 pages worth of data to paginate) after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Integration tests
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
I'm not sure how to say this but... Guys, there is a lot of to cover
by test
in this module and writing tests in trunk is not painful by any means.
you are right and this particular bug was my fault because I haven't
written any
tests yet. However, if you followed my commit messages, you saw that I
was able
to enable integration tests for trunk ('mvn install -P it' from
cocoon-webapp runs the tests in cocoon-webapp/src/test/java). My next
step on my todo list is covering the SSF with tests.
Yes I was very happy to see your commits. However, I always thought that it's
first that you write
unit tests for covering the most basic functionality and ITs for testing how
different parts
interact with each other.
Doesn't it make sense to write a few unit tests first? What kind of ITs do you
plan to write?
Could somebody with admin rights on vmbuild help me with adding the
integration tests to Continuum?
Sure, tell what command exactly is needed to be fired. Is mvn clean install -P
allbocks,it enough?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[jira] Updated: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Buschhorn updated COCOON-2162: --- Attachment: screenshot-1.jpg This is what should happen, I believe. Made after applying patch. [PATCH] Fix for Paginator when accessing out of bounds Pagination page -- Key: COCOON-2162 URL: https://issues.apache.org/jira/browse/COCOON-2162 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.1.10, 2.1.11 Reporter: Drew Buschhorn Priority: Minor Attachments: paginator.diff, screenshot-1.jpg The Paginator transformer for apache cocoon will allow out of page-range requests. I've added the below logic-test into my own copy of cocoon, and that seems to fix the problem. Please let me know if you think 1. this is valid and 2. that it should be placed into svn for the 2.1.x version of cocoon. Example: http://localhost/samples/paginator/text(5) will return a valid empty file before patch (despite there being only 4 pages worth of data to paginate) after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Integration tests
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
I'm not sure how to say this but... Guys, there is a lot of to cover by
test in this module and writing tests in trunk is not painful by any
means.
you are right and this particular bug was my fault because I haven't
written any tests yet. However, if you followed my commit messages, you saw
that I was able to enable integration tests for trunk ('mvn install -P it'
from cocoon-webapp runs the tests in cocoon-webapp/src/test/java). My next
step on my todo list is covering the SSF with tests.
Yes I was very happy to see your commits. However, I always thought that it's
first that you write unit tests for covering the most basic functionality and
ITs for testing how different parts interact with each other.
Doesn't it make sense to write a few unit tests first?
:-) yes, I fully agree. However, I wanted to explore the code by writing unit
tests but I failed. Maybe I invested to less time but I came to the conclustion
that it is easier to write integration tests.
What kind of ITs do you plan to write?
I want to test ...
o absolute and relative connections to servlet services
o connecting to blocks using the servlet:/ protocol
o super connections
o accessing information coming from the original request
o error handling
o postable sources
o servlet-service generator/transformer/serializer
Could somebody with admin rights on vmbuild help me with adding the
integration tests to Continuum?
Sure, tell what command exactly is needed to be fired. Is mvn clean install
-P allbocks,it enough?
yes
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Integration tests
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Yes I was very happy to see your commits. However, I always thought that it's first that you write unit tests for covering the most basic functionality and ITs for testing how different parts interact with each other. Doesn't it make sense to write a few unit tests first? :-) yes, I fully agree. However, I wanted to explore the code by writing unit tests but I failed. Maybe I invested to less time but I came to the conclustion that it is easier to write integration tests. I don't understand what you mean exactly. Do you mean it was too complicated to write unit tests? I haven't taken a closer look at your IT work but I guess it should be always easier to write isolated unit tests than ITs. Am I wrong? What kind of ITs do you plan to write? I want to test ... o absolute and relative connections to servlet services o connecting to blocks using the servlet:/ protocol o super connections o accessing information coming from the original request o error handling o postable sources o servlet-service generator/transformer/serializer I don't want to be pesky but... most of these items looks like perfect cases for unit tests. Don't they? I'm not feeling good about testing basic functionality by using ITs because it introduces too much dependencies, IMHO. It was Daniel who taught me how to keep number of dependencies in tests as small as possible. He was endlessly reminding me when I was working during GSoC to use classes inheriting from pure TestCase and now I see he was perfectly right. Tests are normal code, the more complicated dependencies you introduce the more it's hard to maintain such code... Sure, tell what command exactly is needed to be fired. Is mvn clean install -P allbocks,it enough? yes Configuration at Continuum updated. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Integration tests
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Yes I was very happy to see your commits. However, I always thought that
it's first that you write unit tests for covering the most basic
functionality and ITs for testing how different parts interact with each
other.
Doesn't it make sense to write a few unit tests first?
:-) yes, I fully agree. However, I wanted to explore the code by writing
unit tests but I failed. Maybe I invested to less time but I came to the
conclustion that it is easier to write integration tests.
I don't understand what you mean exactly. Do you mean it was too complicated
to write unit tests? I haven't taken a closer look at your IT work but I
guess it should be always easier to write isolated unit tests than ITs. Am I
wrong?
hmmm, it depends. Integration tests for Cocoon have always been tests at
HTTP/XHTML level. The only difficult part is setting up the environment.
Everything else is checking if an http call produces the right output which is
fairly easy using XPath asserts or XMLDiff.
What kind of ITs do you plan to write?
I want to test ... o absolute and relative connections to servlet services
o connecting to blocks using the servlet:/ protocol o super connections o
accessing information coming from the original request o error handling o
postable sources o servlet-service generator/transformer/serializer
I don't want to be pesky but... most of these items looks like perfect cases
for unit tests. Don't they?
I'm not feeling good about testing basic functionality by using ITs because
it introduces too much dependencies, IMHO.
What kind of dependencies?
It was Daniel who taught me how to
keep number of dependencies in tests as small as possible. He was endlessly
reminding me when I was working during GSoC to use classes inheriting from
pure TestCase and now I see he was perfectly right.
Tests are normal code, the more complicated dependencies you introduce the
more it's hard to maintain such code...
My problem is that the time that I can dedicate to this task is very limited and
I fear that if it gets too complicated (for me) or time-consuming I won't do it.
Sure, tell what command exactly is needed to be fired. Is mvn clean
install -P allbocks,it enough?
yes
Configuration at Continuum updated.
Thanks!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Fw: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
Thanx Grek for your effort, I am allmost satisfied :-) still however ajax doesn't work now. as soon as I request an ajax/browser-update I get an error saying Request failed. Show server response? Some examples: http://cocoon.zones.apache.org/demos/trunk/samples/forms/do-dynaRepeater.flow try to add a repeater row http://cocoon.zones.apache.org/demos/trunk/samples/forms/do-taskTree.flow add a subtask and so on I am sorry, but this seems to be more work (By the way I completly refreshed my browser-cache, so it shouldn't be a problem of old javascript...) thanx gabriel _ Mag. Gabriel Gruber Senior Consultant +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien Grzegorz Kossakowski [EMAIL PROTECTED] wrote on 15.01.2008 02:23:50: Grzegorz Kossakowski pisze: Gabriel Gruber pisze: I am afraid, but all flow-based samples within the trunk demo don't seem to work: see: http://cocoon.zones.apache.org/demos/trunk/samples/forms/do- fileExplorer.flow http://cocoon.zones.apache. org/demos/trunk/samples/forms/form_model_gui.flow http://cocoon.zones.apache.org/demos/trunk/samples/forms/do-multipage.flow It looks like it's caused by latest refactorings of cocoon- servlet-service-components module. I'll have a look at today's night. Fixed in r611986 and samples work ok for me locally. Thanks again for reporting Gabriel. Now it's really time to get back to Math stuff... -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: usage of cocoon.createObject
Hi Carlos, Thanks for spotting the issue, people might get this code as a best practices. Would you file the issue and include a patch in scarab? I will be glad to commit the fix. Thank you in advance. Best Regards, Antonio Gallardo. Carlos Chávez escribió: Hello All, About the usage of the cocoon.createObject, i notice that on two cocoon sample we did not call the method cocoon.disposeObject for the object created before, is this right ? The sample code is on: 1. src/blocks/lucene/samples/flow.js 2. src/blocks/portal/samples/coplets/basket/basket.js We create the objects: org.apache.cocoon.components.flow.util.PipelineUtil and org.apache.cocoon.samples.LuceneUtil. Cheers, Carlos Chávez.
[jira] Commented: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559305#action_12559305 ] Jörg Heinicke commented on COCOON-2162: --- Instead of a 404 I would rather send the last page if the requested page number is greater than the last page number and the first page if it is less than the first page 0 or 1 (depends on whether index is 0 or 1-based). [PATCH] Fix for Paginator when accessing out of bounds Pagination page -- Key: COCOON-2162 URL: https://issues.apache.org/jira/browse/COCOON-2162 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.1.10, 2.1.11 Reporter: Drew Buschhorn Priority: Minor Attachments: paginator.diff, screenshot-1.jpg The Paginator transformer for apache cocoon will allow out of page-range requests. I've added the below logic-test into my own copy of cocoon, and that seems to fix the problem. Please let me know if you think 1. this is valid and 2. that it should be placed into svn for the 2.1.x version of cocoon. Example: http://localhost/samples/paginator/text(5) will return a valid empty file before patch (despite there being only 4 pages worth of data to paginate) after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559314#action_12559314 ] Drew Buschhorn commented on COCOON-2162: Thought about that, but I have two objections: 1. Generally back-ends should be no smarter than necessary: asking for a page that is beyond the created pages should throw an error (not be silently corrected) esp. since one could catch the 404 error in the sitemap and load the last page. 2. I'm not smart enough to know how to access the number of pages created by the paginator outside of the java-class, so I dont know how to find out how many pages it will create without asking it for the largest page that doesnt throw a 404 error. *shrug* tried setting it to catch things 0, but that throws a indexOutOfBounds java error that I didnt feel like learning how to catch. [PATCH] Fix for Paginator when accessing out of bounds Pagination page -- Key: COCOON-2162 URL: https://issues.apache.org/jira/browse/COCOON-2162 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.1.10, 2.1.11 Reporter: Drew Buschhorn Priority: Minor Attachments: paginator.diff, screenshot-1.jpg The Paginator transformer for apache cocoon will allow out of page-range requests. I've added the below logic-test into my own copy of cocoon, and that seems to fix the problem. Please let me know if you think 1. this is valid and 2. that it should be placed into svn for the 2.1.x version of cocoon. Example: http://localhost/samples/paginator/text(5) will return a valid empty file before patch (despite there being only 4 pages worth of data to paginate) after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Grzegorz Kossakowski wrote: Joerg Heinicke pisze: joerg wrote: Modified: cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml Could it be we switched from status.xml to changes.xml? :) Yes, I believe so. I haven't touch any status.xml since I'm committer and nobody complained to date. :) There are still 100 status.xml in trunk. Before I clean them up I want to know if that's correct. File changes.xml is supported by Maven reporting plug-in[1]. I don't know anything about a tool supporting status.xml in trunk so you can be almost sure we have switched. [1] http://maven.apache.org/plugins/maven-changes-plugin/ The status.xml files were used when Forrest generated the Cocoon docs for both 2.1 and trunk. They should still be used for all 2.1 changes. When trunk docs were moved to using Maven, some people kept adding to */status.xml as there was no replacement for generating changes. Now the 2.2 status.xml files need to be migrated. -David
Re: Where is the mirror.html?
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Apparently, it does not work any more. Do you know who has set up this cron job? Sorry, no idea. I'll ask infra folks, then. Grek, i have a cronjob that does 'svn update' the Cocoon site every 12 hours: 08 5,17 * * * sh /x1/home/crossley/bin/cocoon-site-update.sh Remember also that there is an rsync delay described at: http://apache.org/dev/#web = http://apache.org/dev/project-site.html so 12.5 hours should be the maximum wait. I already responded today with the above to your ASF Infrastructure request. I was away for a long weekend. Whoever is now generating the Cocoon docs with Maven should take over this cronjob and i will stop mine. Make sure that it still does 'svn up' for our top-level, so that it catches any 2.1 changes too. The process description doc http://wiki.apache.org/cocoon/CocoonWebsiteUpdate should be updated with respect to the top-level docs (now not generated with Forrest) and for 2.2 docs. -David
Re: svn commit: r612363 - in /cocoon/trunk: blocks/cocoon-ajax/cocoon-ajax-impl/ blocks/cocoon-apples/cocoon-apples-impl/ blocks/cocoon-apples/cocoon-apples-impl/src/changes/ blocks/cocoon-asciiart/co
On 16.01.2008 01:10, [EMAIL PROTECTED] wrote: Author: joerg Date: Tue Jan 15 22:09:53 2008 New Revision: 612363 URL: http://svn.apache.org/viewvc?rev=612363view=rev Log: convert status.xml (Forrest) to changes.xml (Maven), see also http://marc.info/?t=12001912511r=1w=4 Only one missing is the one in commons. These changes probably go to somewhere in core, don't they? Maybe it must be split to all the modules we have now ... Also some names must be cleaned up (JH = joerg etc.) and maybe the markup as mentioned. Joerg
Re: Integration tests
On Jan 15, 2008 9:44 PM, Reinhard Poetz [EMAIL PROTECTED] wrote: Grzegorz Kossakowski wrote: ...I guess it should be always easier to write isolated unit tests than ITs. Am I wrong? hmmm, it depends. Integration tests for Cocoon have always been tests at HTTP/XHTML level Might be just a question of terminology. When you're creating an HTTP servlet, it is not really usable outside of an HTTP environment. So (and test purists might hate me for saying that ;-), one could argue that testing servlets via HTTP is actually a unit test. It's just that it happens over HTTP instead of being just java method calls. -Bertrand
