RE: 2.2 samples down
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: woensdag 1 oktober 2008 23:43 To: dev@cocoon.apache.org Subject: Re: 2.2 samples down Grzegorz Kossakowski pisze: Jasha Joachimsthal pisze: Hi there, the samples of 2.2 are (still) down [1]. Does anyone know how to bring them up again? [1] http://cocoon.zones.apache.org/demos/trunk/ Logs[2] do not reveal anything trivial so I guess this might be caused by my last activity on zone related to upgrade of Maven to 2.0.9 and Java to 1.5. [2] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/ I may have a look today's night or tomorrow. Found the cause - Maven starts jetty using wrong (default) port number, see the last line of the log[3]: 2008-10-01 16:11:14.548::INFO: Started [EMAIL PROTECTED]: After quick testing at my local computer it looks like settings from MAVEN_OPTS environment variable are not propagated to jetty:run plug-in. In order to test it try: cd core/cocoon-webapp export MAVEN_OPTS=-Djetty.port=8123 mvn jetty:run and check at which port jetty listens. If it's not 8123 then we have found a bug and we should report it to Maven team. If anyone confirms this problem I'll introduce temporary fix so our demos are online again. [3] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log PS. If someone else could take care of it I would be grateful. I don't have any reliable internet connection in my new flat now. I just tried to start up the My first block with mvn -Djetty.port=8123 jetty:run but it still uses port . Only when I comment the connectors part in the pom.xml it listens to port 8123. So I think the configuration in the pom overrides the commandline port. Jasha Joachimsthal [EMAIL PROTECTED] - [EMAIL PROTECTED] www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
Re: 2.2 samples down
Jasha Joachimsthal wrote: I just tried to start up the My first block with mvn -Djetty.port=8123 jetty:run but it still uses port . This is weird. For me this worked yesterday. Only when setting jetty.port using MAVEN_OPTS Maven ignored that setting. Only when I comment the connectors part in the pom.xml it listens to port 8123. So I think the configuration in the pom overrides the commandline port. Which should be the opposite way. What version of Maven and jetty plugin do you use? -- Grzegorz
RE: 2.2 samples down
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: donderdag 2 oktober 2008 11:21 To: dev@cocoon.apache.org Subject: Re: 2.2 samples down Jasha Joachimsthal wrote: I just tried to start up the My first block with mvn -Djetty.port=8123 jetty:run but it still uses port . This is weird. For me this worked yesterday. Only when setting jetty.port using MAVEN_OPTS Maven ignored that setting. Only when I comment the connectors part in the pom.xml it listens to port 8123. So I think the configuration in the pom overrides the commandline port. Which should be the opposite way. What version of Maven and jetty plugin do you use? Maven 2.0.9, jetty-plugin 6.1.7, Java 5 in Windows XP Jasha
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636361#action_12636361 ] Grzegorz Kossakowski commented on COCOON-2216: -- Imran, It's my time to apologize. I didn't read your previous description carefully enough. Now I could reproduce your problem which is just a sign of much bigger problem. IncludeCacheManager uses thread pooling technique which does not play nicely with ThreadLocals, see: http://java.sys-con.com/node/37241 As I said this problem is not limited to the newly introduced Factory for ObjectModel. Servlet Service Fw and Spring itself use ThreadLocals as well. I think this is a right time to move this discussion to dev@ list so others can comment. I'll be probably in favour of removing thread pooling completely but I don't know performance implications at the moment. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636376#action_12636376 ] imran pariyani commented on COCOON-2216: hi Grzegorz, in the article there was something about Lack of a Standard Thread-Pooling Library .. now there is a standard which comes with the JDK .. i don't know if we are using that or not .. but it is possible that it might take care of the ThreadLocal variables .. just a thought. should i forward this discussion to the dev mailing list ? IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON3-4) Provide an XML generator based on Bean(s)/POJOs
Provide an XML generator based on Bean(s)/POJOs --- Key: COCOON3-4 URL: https://issues.apache.org/jira/browse/COCOON3-4 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 A Bean(s)/POJO(s) generator is a starter component for the pipeline that streams sax events, generated reading/intrsopecting the Object input, to an xml consumer. It could be useful when Objects are retrieved, i.e. from a persistence engine, and they have to be streamed in an XML format to implement a Rest API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON3-4) Provide an XML generator based on Bean(s)/POJOs
[ https://issues.apache.org/jira/browse/COCOON3-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated COCOON3-4: - Attachment: BeanGenerator.patch The provided patch implements a BeanGenerator, using the commons-betwixt library. I know that one of the main scopes of cocoon3 pipeline is limiting the dependencies, but the apache's commons-betwixt already implements a SAX writer that streams xml events to a content handler. Moreover, as reported on http://commons.apache.org/betwixt/guide/output.html (on the bottom), SAXBeanWriter pushes events to a SAX content handler. This allows Betwixt to efficiently participate as a content generator in SAX-based pipelines such as cocoon Provide an XML generator based on Bean(s)/POJOs --- Key: COCOON3-4 URL: https://issues.apache.org/jira/browse/COCOON3-4 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: BeanGenerator.patch A Bean(s)/POJO(s) generator is a starter component for the pipeline that streams sax events, generated reading/intrsopecting the Object input, to an xml consumer. It could be useful when Objects are retrieved, i.e. from a persistence engine, and they have to be streamed in an XML format to implement a Rest API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
imran pariyani (JIRA) pisze: [ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636376#action_12636376 ] imran pariyani commented on COCOON-2216: hi Grzegorz, in the article there was something about Lack of a Standard Thread-Pooling Library .. now there is a standard which comes with the JDK .. i don't know if we are using that or not .. but it is possible that it might take care of the ThreadLocal variables .. just a thought. Had a brief look and I fear that it's not that easy but I'm not an expert in this field. should i forward this discussion to the dev mailing list ? Yes, please. I have a really shaky internet access these days so any help is greatly appreciated. I hope others more experienced with multi-thread problems can give us some hints how finally tackle this problem. -- Grzegorz
[continuum] BUILD ERROR: Cocoon - Apache Cocoon [build root] -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=117756projectId=51 Build statistics: State: Error Previous State: Ok Started at: Thu 2 Oct 2008 16:00:30 -0700 Finished at: Thu 2 Oct 2008 16:01:14 -0700 Total time: 43s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Maven 2.0.9, Java 5, Large Memory Description: Test Summary: Tests: 0 Failures: 0 Total time: 0.0 Build Error: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/repos/asf/cocoon/trunk' svn: PROPFIND of '/repos/asf/cocoon/trunk': could not connect to server (http://svn.apache.org) ---
[continuum] BUILD SUCCESSFUL: Cocoon - Apache Cocoon [build root] -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=117892projectId=51 Build statistics: State: Ok Previous State: Error Started at: Thu 2 Oct 2008 18:24:05 -0700 Finished at: Thu 2 Oct 2008 18:37:39 -0700 Total time: 13m 33s Build Trigger: Schedule Build Number: 351 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Maven 2.0.9, Java 5, Large Memory Description: Test Summary: Tests: 362 Failures: 0 Total time: 91.44399
