Re: Repository block and C2.2
Hi... On 5 Jan 2008, at 13:18, Robin Wyles wrote: On 4 Jan 2008, at 04:03, Joerg Heinicke wrote: On 02.01.2008 11:26 Uhr, Robin Wyles wrote: Looking at the pom I don't see any version numbers, but the dependencies seem to be: cocoon-core cocoon-eventcache-impl excalibur-datasource servlet-api From what I know in this case these versions are in the parent POM. And all these dependencies should be releases. You might need to convert cocoon-eventcache-impl first though - or get rid of the dependency. It was always quite big dependency tree for repository block if I remember correctly. See 2.1 blocks.properties [1]. The dependency on cocoon-eventcache-impl is from SimpleJdbcSourceDescriptor [1] which itself needs cocoon-database- impl if it is to be used [2]. As you say the dependency tree is quite large, and the following may be tricky... cocoon-repository-impl - cocoon-eventcache-impl - cocoon-jms-impl - cocoon-cron-impl ... as cocoon-cron-impl is apparently deprecated. I haven't looked into cocoon-jms-impl to see where the dependencies on cocoon-cron- impl are, so I'm not sure what the best course of action is here, any advice would be welcome. After looking a bit deeper into this I can't see why the following dependencies exist: cocoon-eventcache-impl - cocoon-jms-impl cocoon-jms-impl - cocoon-cron-impl Removing these dependencies from the block POMs doesn't cause any build errors. Could someone with more knowledge of the eventcache and jms blocks tell me if these dependencies are still valid? Thanks, Robin For final I would like to see some samples (repository block lacks any) and at least minimal coverage by tests. Grek is really pushing hard for getting better test coverage :) Well, if you aim for the stars you might reach the moon :) Me too, after going through your points below my plan is to write initial tests for SourceRepository to test all repository operations using a local file:// based repository. Ultimately I would like to see this block springified (sprung?) too - I envisage us creating our own Repository implementations and would much prefer to do this using Spring. I wonder if we are going the same way as for forms block: 1.0 for the 2.2-converted block, 1.1 for the next step, the springification. This means we should do this migration in 2 steps. Agreed. I think that the best strategy would be to create configuration of sitemap components in order to get them running then try to run rest of components. Will do this and set up some tests for these components - I'm still figuring out how some of the other components in this block are used and so how they can be tested. I guess it's not that much work left in order to prepare first milestone release of repository block but having even few samples would be highly appreciated. I'll report back after I've taken a look at the above and will hopefully have an idea of what the samples could contain. Maybe it does not make much sense to have samples for this block, especially if it does only provide basic functionality. I don't know the scope of the repository block though. But maybe it's up to blocks like webdav to provide the actual samples. The test coverage is probably more important. There are a couple of sitemap components, TraversableSourceDescriptionGenerator and SourcePropsWritingTransformer, that could be used for samples. Although the latter needs a suitable SourceDescriptor - the only one present is SimpleJdbcSourceDescriptor which has the dependency issues outlined above. I'm not quite sure how tests for SourcePropsWritingTransformer can be written though - used in conjunction with SimpleJdbcSourceDescriptor it will need a test database. I think SourceRepository might also be worthy of a sample - this could be wrapped around a FileSource repository and show basic manipulation of repository content. I'll certainly be writing tests for this component as it's the one which will be using first. If anyone more familiar with the repository block can provide more info on what else should be covered by tests then please let me know. Robin [1] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon- repository/cocoon-repository-impl/src/main/java/org/apache/cocoon/ components/source/impl/SimpleJdbcSourceDescriptor.java? revision=587761view=markup [2] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon- repository/cocoon-repository-impl/src/main/resources/META-INF/ cocoon/avalon/cocoon-repository.xconf?revision=588098view=markup Joerg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/ blocks.properties?revision=488038view=markup smime.p7s Description: S/MIME cryptographic signature
Re: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
_ Thanks for sharing your findings. I'm just investigating into the problem now. Fixed. It was (again) issue caused by Java 1.4. I modified script at our zone to use Java 1.5 instead. I don't have time and more importantly a will to investigate further into this problem. Thanks Gabriel again for pointing this problem out to us. I hope this will encourage you to upgrade to Cocoon 2.2. Thanx a lot grek, this error is away, however I found another one :-( when adding a repeater row within sample one, I get this error: HTTP ERROR: 500 Unable to get transformer handler for file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/resources/forms-samples-styling.xsl at map:serialize - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:174:26 at map:transform type=servletLinkRewriter - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:173:53 at map:transform type=i18n - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:172:36 at map:transform - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:168:66 at map:transform type=i18n - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:167:36 at map:transform - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:166:98 at map:transform type=i18n - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:165:36 at map:transform type=forms - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:162:54 at map:generate - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:158:61 at map:match - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:124:34 RequestURI=/demos/trunk/samples/forms/form1 Caused by: org.apache.cocoon.ProcessingException: Unable to get transformer handler for file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/resources/forms-samples-styling.xsl at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:174:26 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:173:53 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:172:36 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:168:66 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:167:36 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:166:98 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:165:36 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:162:54 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:158:61 at - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:124:34 at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:315) at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) thanx for your effort in advance Gabriel
Fw: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
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 Error is always: HTTP ERROR: 500 Unable to get transformer handler for file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/resources/forms-samples-styling.xsl at map:serialize type=html - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:279:42 at map:transform type=servletLinkRewriter - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:264:53 at map:transform type=i18n - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:261:36 at map:transform - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:255:66 at map:transform - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:254:98 at map:transform type=i18n - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:251:36 at map:transform type=browser-update - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:250:48 at map:generate type=jx - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:247:79 at map:match - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:246:50 at servlet:org.apache.cocoon.forms.impl.servlet:/resource/internal/flow/javascript/Form.js:259 at do_multipage - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/flow/forms_flow_example.js:209 at map:call - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:189:39 at map:match - file:///home/cdemos/demos/trunk/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-sample/sitemap.xmap:188:38 RequestURI=/demos/trunk/samples/forms/do-multipage.flow Gabriel - Forwarded by Gabriel Gruber/Workflow on 14.01.2008 11:21 - Grzegorz Kossakowski [EMAIL PROTECTED] wrote on 13.01.2008 20:28:43: Grzegorz Kossakowski pisze: Gabriel Gruber pisze: Hello dear list members! Hello Gabriel! I am a long term cocoon user and and looking foreward to use cocoon 2.2 in production quite soon. nevertheless the fact that the official demo on the cocoon.zones.apache.org crashes in most samples, doesn't encourage my efforts towards an early migration to 2.2. for instance, i try to start the first sample of the cforms block and get the error below. I am pretty sure that this is just an infrastructure issue, but it would help many interested future cocoon 2.2 users to evaluate the (frontend) features without downloading and trying out. just my thoughts, Thanks for sharing your findings. I'm just investigating into the problem now. Fixed. It was (again) issue caused by Java 1.4. I modified script at our zone to use Java 1.5 instead. I don't have time and more importantly a will to investigate further into this problem. Thanks Gabriel again for pointing this problem out to us. I hope this will encourage you to upgrade to Cocoon 2.2. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Fw: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
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. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Updated the release demo to 2.1.11 on cocoon.zones.apache.org
FYI, I have updated the release demo at http://cocoon.zones.apache.org/ to run the latest 2.1.11 release of the 2.1.x branch. For more info about how those demos are setup, see /home/cdemos/README.txt on that host. -Bertrand
Re: Updated the release demo to 2.1.11 on cocoon.zones.apache.org
Thanks Bertrand. Best Regards, Antonio Gallardo. Bertrand Delacretaz escribió: FYI, I have updated the release demo at http://cocoon.zones.apache.org/ to run the latest 2.1.11 release of the 2.1.x branch. For more info about how those demos are setup, see /home/cdemos/README.txt on that host. -Bertrand
usage of cocoon.createObject
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] Created: (COCOON-2161) URI returned by ServletConnection.getURI() is not properly resolved afterwards
URI returned by ServletConnection.getURI() is not properly resolved afterwards -- Key: COCOON-2161 URL: https://issues.apache.org/jira/browse/COCOON-2161 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Priority: Critical URI returned by o.a.c.servletservice.RelativeServletConnection does not conform our definition of absolute URI for servlet source. It does not contain plus (+) sign after servlet's bean id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r611986 - in /cocoon/trunk/core/cocoon-servlet-service: cocoon-servlet-service-components/ cocoon-servlet-service-components/src/ cocoon-servlet-service-components/src/main/java/org/ap
[EMAIL PROTECTED] pisze: Author: gkossakowski Date: Mon Jan 14 17:19:28 2008 New Revision: 611986 URL: http://svn.apache.org/viewvc?rev=611986view=rev Log: COCOON-2161: Fixed bug in creation of absolute URI and added test case covering this functionality. 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. This bug clearly positively proves we need to have strong test-coverage for cocoon-servlet-service-components as it actually impacts every bit of Cocoon. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Fw: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
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/
[jira] Closed: (COCOON-2161) URI returned by ServletConnection.getURI() is not properly resolved afterwards
[ https://issues.apache.org/jira/browse/COCOON-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2161. Resolution: Fixed Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). Fixed in r611986. Thanks to Gabriel Gruber for reporting this bug. URI returned by ServletConnection.getURI() is not properly resolved afterwards -- Key: COCOON-2161 URL: https://issues.apache.org/jira/browse/COCOON-2161 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Priority: Critical URI returned by o.a.c.servletservice.RelativeServletConnection does not conform our definition of absolute URI for servlet source. It does not contain plus (+) sign after servlet's bean id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Integration tests
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: gkossakowski Date: Mon Jan 14 17:19:28 2008 New Revision: 611986
URL: http://svn.apache.org/viewvc?rev=611986view=rev Log: COCOON-2161:
Fixed bug in creation of absolute URI and added test case covering this
functionality.
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.
Could somebody with admin rights on vmbuild help me with adding the integration
tests to Continuum?
--
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]
_
