Re: Javaflow - major memory issue
On 27.03.2008 10:33, Torsten Curdt wrote: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660&view=markup The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. Joerg
Re: Exploring Corona
Carsten Ziegeler wrote: Intersting stuff - thanks Reinhard and Steven for starting this and sharing it with us. Finally I had time to have a *brief* look at it and I have some remarks :) I think the pipeline api and sitemap api should be separate things. So the invocation should rather be in the pipeline api as the base of executing pipelines. We could than split this into two modules. I'm not sure if actions belong to the pipeline api; i think they are rather sitemap specific. All they do wrt to the pipeline is to change the invocation perhaps. So this could also be done before starting the pipeline and get the action stuff out of the pipeline api. Yes, actions definitely don't belong to the pipeline API. They are sitemap control structures, just like matchers and selectors. The main difference between matcher and action (besides the pattern/src attribute) is that actions are allowed to have side effects while matchers should not. The classes should be put into different packages: we should separate between the pure api, helper classes and implementations. This makes it easier to use the stuff in an osgi environment. Ok, final comment for today, the idea of abstracting the consumer and the producer seems appealing. It's like the javax.xml stuff (Result, Source); the javax.xml stuff has the advantage that the implementation knows which results and sources are possible: there are only a handfull of subsclasses; adding own results or sources simply is not supported. I fear we will have to follow the same path (which might not be bad). Reminds me of some old thoughts I had about a Cocoon 3. This can be the role of a collection of adapters that would convert data for components that can't directly talk to each other. This complexifies the picture a bit, but would allow for advanced things such as non-XML pipelines, mixing SAX, DOM and StAX transparently to e.g. perform some content-aware construction of the pipeline, etc. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Exploring Corona
On Mar 27, 2008, at 19:14, Carsten Ziegeler wrote: Intersting stuff - thanks Reinhard and Steven for starting this and sharing it with us. Finally I had time to have a *brief* look at it and I have some remarks :) I think the pipeline api and sitemap api should be separate things. +1 So the invocation should rather be in the pipeline api as the base of executing pipelines. We could than split this into two modules. I'm not sure if actions belong to the pipeline api; i think they are rather sitemap specific. All they do wrt to the pipeline is to change the invocation perhaps. So this could also be done before starting the pipeline and get the action stuff out of the pipeline api. +1 cheers -- Torsten
Re: Exploring Corona
Intersting stuff - thanks Reinhard and Steven for starting this and sharing it with us. Finally I had time to have a *brief* look at it and I have some remarks :) I think the pipeline api and sitemap api should be separate things. So the invocation should rather be in the pipeline api as the base of executing pipelines. We could than split this into two modules. I'm not sure if actions belong to the pipeline api; i think they are rather sitemap specific. All they do wrt to the pipeline is to change the invocation perhaps. So this could also be done before starting the pipeline and get the action stuff out of the pipeline api. The classes should be put into different packages: we should separate between the pure api, helper classes and implementations. This makes it easier to use the stuff in an osgi environment. Ok, final comment for today, the idea of abstracting the consumer and the producer seems appealing. It's like the javax.xml stuff (Result, Source); the javax.xml stuff has the advantage that the implementation knows which results and sources are possible: there are only a handfull of subsclasses; adding own results or sources simply is not supported. I fear we will have to follow the same path (which might not be bad). Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: unable to build cocoon forms 1.0 branch
On Mar 27, 2008, at 1:18 PM, Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Anybody knowledgeable about maven? Anybody at all? :) Is it still a problem? Yes. Empty .repository/org/apache/cocoon, latest trunk, cocoon forms branch had no modifications: [INFO] Installing ~/cocoon-forms-1.0.x/cocoon-forms-impl/target/cocoon- forms-impl-1.0.0-RC2-SNAPSHOT.jar to ~/.m2/repository/org/apache/ cocoon/cocoon-forms-impl/1.2.0-SNAPSHOT/cocoon-forms-impl-1.2.0- SNAPSHOT.jar So now it overwrites 1.2.0-SNAPSHOT with 1.0.0 jar file. Vadim
Re: unable to build cocoon forms 1.0 branch
Vadim Gritsenko pisze: Anybody knowledgeable about maven? Anybody at all? :) Is it still a problem? -- Grzegorz
[jira] Commented: (COCOON-2183) "mvn site" fails (missing artifact org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT)
[ https://issues.apache.org/jira/browse/COCOON-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582715#action_12582715 ] Reinhard Poetz commented on COCOON-2183: I've just incremented the version numbers of cocoon-core in trunk/parent/pom.xml. Today I don't have time to run the ultimate test that removes all cocoon artifacts from the local repository but if there are still problems with the build, I will fix them tomorrow. > "mvn site" fails (missing artifact > org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT) > > > Key: COCOON-2183 > URL: https://issues.apache.org/jira/browse/COCOON-2183 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven, - Documentation >Affects Versions: 2.2-dev (Current SVN) >Reporter: Andreas Kuckartz >Assignee: Reinhard Poetz > Fix For: 2.2-dev (Current SVN) > > > $ mvn site > for revision 641709 results in: > ... > [INFO] snapshot org.apache.cocoon:cocoon-configuration-api:1.0.3-SNAPSHOT: > checking for updates from apache.snapshots > Downloading: > http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-configuration-api/1.0.3-SNAPSHOT/cocoon-configuration-api-1.0.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > 2) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > from the specified remote repositories: > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2183) "mvn site" fails (missing artifact org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT)
[ https://issues.apache.org/jira/browse/COCOON-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz reassigned COCOON-2183: -- Assignee: Reinhard Poetz > "mvn site" fails (missing artifact > org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT) > > > Key: COCOON-2183 > URL: https://issues.apache.org/jira/browse/COCOON-2183 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven, - Documentation >Affects Versions: 2.2-dev (Current SVN) >Reporter: Andreas Kuckartz >Assignee: Reinhard Poetz > Fix For: 2.2-dev (Current SVN) > > > $ mvn site > for revision 641709 results in: > ... > [INFO] snapshot org.apache.cocoon:cocoon-configuration-api:1.0.3-SNAPSHOT: > checking for updates from apache.snapshots > Downloading: > http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-configuration-api/1.0.3-SNAPSHOT/cocoon-configuration-api-1.0.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > 2) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > from the specified remote repositories: > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2183) "mvn site" fails (missing artifact org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT)
[ https://issues.apache.org/jira/browse/COCOON-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuckartz updated COCOON-2183: - Summary: "mvn site" fails (missing artifact org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT) (was: Missing artifact: org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT) Now $ mvn site fails like this: [INFO] Building Cocoon Linkrewriter Block Implementation [INFO]task-segment: [site] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-RC3-SNAPSHOT/cocoon-core-2.2.0-RC3-SNAPSHOT.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-RC3-SNAPSHOT/cocoon-core-2.2.0-RC3-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-core -Dversion=2.2.0-RC3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-core -Dversion=2.2.0-RC3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cocoon:cocoon-linkrewriter-impl:jar:1.1.0-SNAPSHOT 2) org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-linkrewriter-impl:jar:1.1.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2) > "mvn site" fails (missing artifact > org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT) > > > Key: COCOON-2183 > URL: https://issues.apache.org/jira/browse/COCOON-2183 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven, - Documentation >Affects Versions: 2.2-dev (Current SVN) >Reporter: Andreas Kuckartz > Fix For: 2.2-dev (Current SVN) > > > $ mvn site > for revision 641709 results in: > ... > [INFO] snapshot org.apache.cocoon:cocoon-configuration-api:1.0.3-SNAPSHOT: > checking for updates from apache.snapshots > Downloading: > http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-configuration-api/1.0.3-SNAPSHOT/cocoon-configuration-api-1.0.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-configuration-api -Dversion=1.0.3-SNAPSHOT > -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > 2) org.apache.cocoon:cocoon-configuration-api:jar:1.0.3-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > org.apache.cocoon:cocoon-spring-configurator:jar:1.0.3-SNAPSHOT > from the specified remote repositories: > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2184) "mvn test" fails
[ https://issues.apache.org/jira/browse/COCOON-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuckartz updated COCOON-2184: - Summary: "mvn test" fails (was: Missing artifact: org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.1.0-SNAPSHOT) Now $ mvn test fails like this: [INFO] Building Cocoon Linkrewriter Block Implementation [INFO]task-segment: [site] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-RC3-SNAPSHOT/cocoon-core-2.2.0-RC3-SNAPSHOT.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-RC3-SNAPSHOT/cocoon-core-2.2.0-RC3-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-core -Dversion=2.2.0-RC3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-core -Dversion=2.2.0-RC3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cocoon:cocoon-linkrewriter-impl:jar:1.1.0-SNAPSHOT 2) org.apache.cocoon:cocoon-core:jar:2.2.0-RC3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-linkrewriter-impl:jar:1.1.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2) > "mvn test" fails > > > Key: COCOON-2184 > URL: https://issues.apache.org/jira/browse/COCOON-2184 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Andreas Kuckartz > Fix For: 2.2-dev (Current SVN) > > > $ mvn test > for revision 641713 results in: > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.1.0-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-pipeline-impl -Dversion=1.1.0-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=org.apache.cocoon > -DartifactId=cocoon-pipeline-impl -Dversion=1.1.0-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) org.apache.cocoon:cocoon-pipeline-components:jar:1.1.0-SNAPSHOT > 2) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.1.0-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > org.apache.cocoon:cocoon-pipeline-components:jar:1.1.0-SNAPSHOT > from the specified remote repositories: > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2185) Build failure: SourceResource is not abstract
[
https://issues.apache.org/jira/browse/COCOON-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kuckartz closed COCOON-2185.
Resolution: Fixed
> Build failure: SourceResource is not abstract
> --
>
> Key: COCOON-2185
> URL: https://issues.apache.org/jira/browse/COCOON-2185
> Project: Cocoon
> Issue Type: Bug
> Components: - Build System: Maven, - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Andreas Kuckartz
>Assignee: Reinhard Poetz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
>
> $ mvn install -P allblocks
> still does not work. It now results in:
> [INFO] Building Cocoon Sitemap Implementation
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 63 source files to
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/target/classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Javaflow - major memory issue
On Mar 27, 2008, at 15:33, Torsten Curdt wrote: On Mar 27, 2008, at 15:13, Joerg Heinicke wrote: Torsten Curdt apache.org> writes: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660&view=markup Weird... What cocoon version are we talking about anyway?
[jira] Commented: (COCOON-2185) Build failure: SourceResource is not abstract
[
https://issues.apache.org/jira/browse/COCOON-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582665#action_12582665
]
Reinhard Poetz commented on COCOON-2185:
sorry, I was testing without doing a clean before. Now it should work again
after my upgrade to Spring 2.5.2.
Please close this issue if it is fixed for you. Thanks (for reporting)!
> Build failure: SourceResource is not abstract
> --
>
> Key: COCOON-2185
> URL: https://issues.apache.org/jira/browse/COCOON-2185
> Project: Cocoon
> Issue Type: Bug
> Components: - Build System: Maven, - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Andreas Kuckartz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
>
> $ mvn install -P allblocks
> still does not work. It now results in:
> [INFO] Building Cocoon Sitemap Implementation
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 63 source files to
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/target/classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2185) Build failure: SourceResource is not abstract
[
https://issues.apache.org/jira/browse/COCOON-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz reassigned COCOON-2185:
--
Assignee: Reinhard Poetz
> Build failure: SourceResource is not abstract
> --
>
> Key: COCOON-2185
> URL: https://issues.apache.org/jira/browse/COCOON-2185
> Project: Cocoon
> Issue Type: Bug
> Components: - Build System: Maven, - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Andreas Kuckartz
>Assignee: Reinhard Poetz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
>
> $ mvn install -P allblocks
> still does not work. It now results in:
> [INFO] Building Cocoon Sitemap Implementation
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 63 source files to
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/target/classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
> /home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
> org.apache.cocoon.core.container.spring.avalon.SourceResource is not
> abstract and does not override abstract method isReadable() in
> org.springframework.core.io.Resource
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Javaflow - major memory issue
On Mar 27, 2008, at 15:13, Joerg Heinicke wrote: Torsten Curdt apache.org> writes: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660&view=markup Weird...
Re: Javaflow - major memory issue
Torsten Curdt apache.org> writes: > > Just have a look at the quote from the original. It gives the object > > relationships in the memory. BufferedOutputStream takes 50% and is > > hold in HttpEnvironment which is hold in TreeProcessorRedirector > > which is hold in ContinuationContext. I wondered why it is there. > > Ah ...well, the ContinuationContext should be short living. Maybe > there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext context of org.apache.cocoon.components.flow.java.Continuation continuation of org.apache.cocoon.components.flow.WebContinuation Joerg [1] http://marc.info/?l=xml-cocoon-users&m=120582409910104&w=4
Re: Javaflow - major memory issue
On Mar 27, 2008, at 13:18, Joerg Heinicke wrote: On 27.03.2008 04:39, Torsten Curdt wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by "environment" ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? (Let's stop cross posting and move over to the dev list) cheers -- Torsten
Re: Javaflow - major memory issue
On 27.03.2008 04:39, Torsten Curdt wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by "environment" ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Joerg
Re: Layered software designs
On 27.03.2008 02:25, Steven Dolg wrote:
What I want to see is a concise pipeline API that comes with only
little overhead in terms of its learning curve and its dependencies
on third-party software. Usually this means that we stick with
standard APIs as much as possible - and I think this rule applies for
our situation too.
See, one thing that I just don't get (and already asked) is how the
pipeline API has anything to do with uri resolving. For me the latter
(using java.net or source resolve) is an implementation detail. Our
current pipeline interface [1] has no relationship to uri resolving.
It only has a reference to SourceValidity because of caching [2].
If all this discussion is about removing this method (and the related
getKeyForEventPipeline()) to get rid of this dependency I'm ok with
it. The caching concern could be implemented in a separate Cacheable
interface which should then also be decoupled from uri resolving
(which seems to point to Peter's approach [3]).
Just as a general observation:
I'm starting to believe that I do not understand (anymore) what this is
all about.
We're jumping from high-level concepts ("caching", "layering") straight
down to the lowest level ("it's just method a in class B") and then
right back.
I have had the same problem from the beginning [1] and expressed it in
my question above again. What is this discussion about - if uri
resolving has nothing to do with the pipeline API? And what do we win
when replacing source resolve with java.net except that we have one less
dependency - when nobody really gets in contact with uri resolving
anyway? I have only received half an answer to only the second question
(standard API). Only then I started to look at the relationship between
uri resolving and pipeline API and found only this one reference to the
source resolve package.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=120649777119480&w=4
Re: Layered software designs
Yes, using Cocoon pipelines in Ant is one of my long-time favorits ;-)
Reinhard
Bruce Atherton wrote:
I'm with you, too.
Just as an example, I think it might be useful to use Corona as the
basis for a new Ant task called Pipeline. That task could do any number
text transformations to a set of files as part of a build process. Here,
caching is a non-issue for the most part since the point of using a
pipeline would be to process each file only once. Rather than either
java.net.URL or SourceResolve, we'd probably want to feed the pipeline
based on Ant resources[1], just as the existing XSLT task is fed.
It may be that SourceResolver and an AntResourceSource is the best way
to solve the problem, but on a cursory glance it sure looks like it is
difficult to separate the banana from the gorilla[2] that is Avalon.
[1] http://ant.apache.org/manual/CoreTypes/resources.html
[2] http://www.ddj.com/architect/184408251
Torsten Curdt wrote:
On Mar 26, 2008, at 14:44, Ralph Goers wrote:
Reinhard Poetz wrote:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap
Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2
- here you are:
Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine
+ Spring
XML-SAX
componnents
This layered approach makes Cocoon easily embeddable in any Java
application and Cocoon's learning curve becomes more gradual.
Is such a situation only appealing to Carsten, Steven and me?
Just lurking but I am with you guys.
Appealing? yes. Actually implementable in Java so that it isn;t even
more complicated than what we have? I don't know.
IMO this would simplify a lot as it separates concerns and the inner
guts can be used in other projects without the pain of dependencies we
have right now. People have been asking for this for years. I really
think think this is the right direction.
--
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] Created: (COCOON-2185) Build failure: SourceResource is not abstract
Build failure: SourceResource is not abstract
--
Key: COCOON-2185
URL: https://issues.apache.org/jira/browse/COCOON-2185
Project: Cocoon
Issue Type: Bug
Components: - Build System: Maven, - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Andreas Kuckartz
Priority: Blocker
Fix For: 2.2-dev (Current SVN)
$ mvn install -P allblocks
still does not work. It now results in:
[INFO] Building Cocoon Sitemap Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 63 source files to
/home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
org.apache.cocoon.core.container.spring.avalon.SourceResource is not abstract
and does not override abstract method isReadable() in
org.springframework.core.io.Resource
/home/andreas/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/SourceResource.java:[36,7]
org.apache.cocoon.core.container.spring.avalon.SourceResource is not abstract
and does not override abstract method isReadable() in
org.springframework.core.io.Resource
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2182) Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl
[ https://issues.apache.org/jira/browse/COCOON-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuckartz closed COCOON-2182. Resolution: Fixed > Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl > -- > > Key: COCOON-2182 > URL: https://issues.apache.org/jira/browse/COCOON-2182 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven, Blocks: Databases >Affects Versions: 2.2-dev (Current SVN) >Reporter: Andreas Kuckartz >Priority: Blocker > Fix For: 2.2-dev (Current SVN) > > > $ mvn install -P allblocks > for revision 641707 results in: > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: org.apache.cocoon:cocoon-databases-impl > POM Location: > /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml > Validation Messages: > [0] 'dependencies.dependency.version' is missing for > org.springframework:spring-dao > Reason: Failed to validate POM for project > org.apache.cocoon:cocoon-databases-impl at > /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for > project org.apache.cocoon:cocoon-databases-impl at > /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to > validate POM for project org.apache.cocoon:cocoon-databases-impl at > /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:996) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:799) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:525) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:525) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) > ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: JNet integration
> > To be honest, I don't care about caching or how complex it > is. It has > > to work and it does it nicely in Cocoon. If your name isn't > Ard ( ;-) :-) > > ) you usually don't need to know more details. And that's > what it is > > as Vadim pointed out: implementation details. > > > My name is not Ard but I care; knowing how the caching works > and fine tuning it (by changing parameters or choosing the > right strategy) makes a big difference. I agree that you should care Carsten, butyou have been a Cocoon committer for the last zillion years: should a fresh new cocoon user from the start know how to do everything correct to have the best of Cocoon's caching? I do not agree the former Cocoon caching was ultra complex (to use!!): I started working with Cocoon, and only after some months I noticed: heeey, what is that caching vs noncaching doing in the top of my pipelines :-) So...how hard and complex is it? I used it without ever noticing it And in the end, when you want to push Cocoon to its limits, and you hit some performance issues, then you can take a look how the caching actually works: that is IMHO the way how it should be implemented, and, how it used to be implemented -Ard > > Carsten >
Re: Javaflow - major memory issue
On Mar 27, 2008, at 05:31, Joerg Heinicke wrote: On 18.03.2008 03:07, footh wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by "environment" ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. cheers -- Torsten
Re: Layered software designs
David Crossley wrote: Reinhard Poetz wrote: David Crossley wrote: Reinhard Poetz wrote: A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine Is "sourceresolve" where the Apache XML Commons Resolver is hooked up? no, I was talking about the Excalibur Sourceresolve component. Yes, i know. However that might involve the Catalog Entity Resolver too. This configuration used to be done in Cocoon, then we moved it to Excalibur so that it would be more widely used. And now we have a better version back in Cocoon for 2.2 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JNet integration
Joerg Heinicke wrote: CachingFileGenerator was something Reinhard came up with - I only explained why I considered this as starting point for a "mess" which you disagreed with. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? To be honest, I don't care about caching or how complex it is. It has to work and it does it nicely in Cocoon. If your name isn't Ard ( ;-) ) you usually don't need to know more details. And that's what it is as Vadim pointed out: implementation details. My name is not Ard but I care; knowing how the caching works and fine tuning it (by changing parameters or choosing the right strategy) makes a big difference. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[continuum] BUILD FAILURE: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=69621&projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Thu 27 Mar 2008 00:38:33 -0700 Finished at: Thu 27 Mar 2008 00:40:44 -0700 Total time: 2m 10s Build Trigger: Schedule Build Number: 234 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.4.2_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 4 Failures: 0 Total time: 225 Output: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Cocoon [INFO] Cocoon Tools [modules] [INFO] Cocoon 2.2 Archetype: Block [INFO] Cocoon 2.2 Archetype: Block (plain) [INFO] Cocoon 2.2 Archetype: Web Application [INFO] Cocoon Integration Test Framework [maven-plugin] [INFO] Cocoon Maven Reports [INFO] Cocoon Maven 2 Plugin [INFO] Cocoon Maven Javadocs Script Report [INFO] Cocoon Maven Javadocs Script Report [INFO] Cocoon Reloading ClassLoader - Webapp Wrapper [INFO] Cocoon Reloading ClassLoader - Spring reloader [INFO] Cocoon Configuration API [INFO] Cocoon Spring Configurator [INFO] Cocoon Core [modules] [INFO] Cocoon Pipeline API [INFO] Cocoon Util [INFO] Cocoon XML API [INFO] Cocoon Expression Language API [INFO] Cocoon Pipeline Implementation [INFO] Cocoon XML Implementation [INFO] Cocoon Pipeline Components [INFO] Cocoon Sitemap API [INFO] Cocoon XML Utilities [INFO] Cocoon Expression Language Implementation. [INFO] Cocoon Thread API [INFO] Cocoon Sitemap Implementation [INFO] Cocoon Sitemap Components [INFO] Cocoon XML Resolver [INFO] Cocoon Store Implementation [INFO] Cocoon Thread Implementation [INFO] Cocoon Core [INFO] Cocoon Servlet Service Implementation [INFO] Cocoon Blocks [modules] [INFO] Cocoon Linkrewriter Block Implementation [INFO] Cocoon Servlet Service Components [INFO] Cocoon Ajax Block Implementation [INFO] Cocoon Template Framework Block Implementation [INFO] Cocoon Samples Style Default Block [INFO] Cocoon Ajax Block Sample [INFO] Cocoon Apples Block Implementation [INFO] Session Framework Implementation [INFO] XSP Block Implementation [INFO] Cocoon Main Core Sample Block [INFO] Cocoon Flowscript Block Implementation [INFO] Cocoon Forms Block Implementation [INFO] Cocoon Apples Block Samples [INFO] Cocoon Additional Sample Block [INFO] Cocoon Batik Block Implementation [INFO] Cocoon Forms Block Samples [INFO] Cocoon Integration Tests Block [INFO] Cocoon Linkrewriter Block Samples [INFO] Cocoon Template Block Samples [INFO] Cocoon Batik Block Samples [INFO] Cocoon Welcome (Samples) [INFO] Asciiart Block Implementation [INFO] Asciiart Block Samples [INFO] cocoon-acegisecurity [INFO] Cocoon Authentication Block API [INFO] Cocoon Authentication Block Implementation [INFO] Cocoon Authentication Block Sample [INFO] Authentication Framework Implementation [INFO] Authentication Framework Sample Application [INFO] Axis Block Implementation [INFO] Axis Block Samples [INFO] Bsf Block Implementation [INFO] Bsf Block Samples [INFO] Cocoon Captcha Block Implementation [INFO] Cocoon Captcha Block Sample [INFO] Chaperon Block Implementation [INFO] Chaperon Block Samples [INFO] Cron block implementation [INFO] Cron Block Samples [INFO] Cocoon Database Block Mocks [INFO] Cocoon Database Block Bridge for Avalon components [INFO] Cocoon Database Block Implementation [INFO] Cocoon Hsqldb Server Block Implementation [INFO] Cocoo
Re: Layered software designs
Reinhard Poetz wrote:
> David Crossley wrote:
> >Reinhard Poetz wrote:
> >>A simple scenario could be:
> >>
> >> Pipeline API + java.net.URL + XML-SAX components
> >>
> >>A more advanced scenario could consist of
> >>
> >> Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
> >
> >Is "sourceresolve" where the Apache XML Commons Resolver
> >is hooked up?
>
> no, I was talking about the Excalibur Sourceresolve component.
Yes, i know. However that might involve the Catalog Entity Resolver too.
This configuration used to be done in Cocoon, then we
moved it to Excalibur so that it would be more widely used.
> >I would be concerned if our base offering enabled
> >mis-use of net resources, e.g. processing an xml file
> >which declares a DTD, causes an extra network trip if
> >we don't have the xml entity resolver.
>
> Resolving XML entities is important and we will definitly offer solutions
> for it in the future too.
>
> Corona, Steven's and my proposal of a Cocoon reimplementation, is about
> doing things differently so that Cocoon becomes easily embeddable and
> reuseable from within as many environments as possible. We think that a
> "layered design" is the key to achive this goal. When you put all layers
> together, the result (= a web application framework) should be nearly[1] as
> powerful as that what we have today.
>
> For that purpose Steven and I have also started to reimplement existing
> concepts instead of doing everything from the scratch. First, we believe
> that many of the existing concepts are good as they are and second, this
> makes it easier for others to chime in because if you see Corona as a black
> box, it should (more or less) provide the same results as 2.x.
>
> HTH
Yes it does.
-David
> [1] The only exceptions are things that we want to remove, e.g. sub
> sitemaps etc. -> see the Micro-Cocoon discussion:
> http://marc.info/?l=xml-cocoon-dev&m=119903256406947&w=2
>
> --
> 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: Layered software designs
David Crossley wrote:
Reinhard Poetz wrote:
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
Is "sourceresolve" where the Apache XML Commons Resolver
is hooked up?
no, I was talking about the Excalibur Sourceresolve component.
I would be concerned if our base offering enabled
mis-use of net resources, e.g. processing an xml file
which declares a DTD, causes an extra network trip if
we don't have the xml entity resolver.
Resolving XML entities is important and we will definitly offer solutions for it
in the future too.
Corona, Steven's and my proposal of a Cocoon reimplementation, is about doing
things differently so that Cocoon becomes easily embeddable and reuseable from
within as many environments as possible. We think that a "layered design" is the
key to achive this goal. When you put all layers together, the result (= a web
application framework) should be nearly[1] as powerful as that what we have today.
For that purpose Steven and I have also started to reimplement existing concepts
instead of doing everything from the scratch. First, we believe that many of the
existing concepts are good as they are and second, this makes it easier for
others to chime in because if you see Corona as a black box, it should (more or
less) provide the same results as 2.x.
HTH
[1] The only exceptions are things that we want to remove, e.g. sub sitemaps
etc. -> see the Micro-Cocoon discussion:
http://marc.info/?l=xml-cocoon-dev&m=119903256406947&w=2
--
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: Layered software designs
Steven Dolg wrote:
Joerg Heinicke schrieb:
On 26.03.2008 09:14, Reinhard Poetz wrote:
What I want to see is a concise pipeline API that comes with only
little overhead in terms of its learning curve and its dependencies
on third-party software. Usually this means that we stick with
standard APIs as much as possible - and I think this rule applies for
our situation too.
See, one thing that I just don't get (and already asked) is how the
pipeline API has anything to do with uri resolving. For me the latter
(using java.net or source resolve) is an implementation detail. Our
current pipeline interface [1] has no relationship to uri resolving.
It only has a reference to SourceValidity because of caching [2].
If all this discussion is about removing this method (and the related
getKeyForEventPipeline()) to get rid of this dependency I'm ok with
it. The caching concern could be implemented in a separate Cacheable
interface which should then also be decoupled from uri resolving
(which seems to point to Peter's approach [3]).
Joerg
[1]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html
[2]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html#getValidityForEventPipeline()
[3] http://marc.info/?l=xml-cocoon-dev&m=120654005017297&w=4
Just as a general observation:
I'm starting to believe that I do not understand (anymore) what this is
all about.
We're jumping from high-level concepts ("caching", "layering") straight
down to the lowest level ("it's just method a in class B") and then
right back.
We're arguing that a certain feature is already existing and working,
while talking about a rewrite-experiment that definitely does not have
this feature.
But back to caching:
Caching appears to be incredibly important. Even to the point where "no
caching" means "not acceptable".
On the other hand, when trying to find out what is really necessary and
wanted, there isn't much left. Suddenly it's "just an implementation
detail", "not really important", "makes no difference for the user".
Forgive me for being blunt, but all this appears to me like "I need that
feature. I do not care how it is implemented or how it works. I just
have to have it."
I did not expect this kind of discussion on a dev list. (I even have a
hard time accepting this from a paying customer).
But since it's just a not very important implementation detail, I added
a (simple) caching approach to Corona. (I hope to get a patch ready today)
Perhaps this is all just too abstract and far fetched without any common
basis (iow. code).
Steven,
one of the greatest strengths of community-driven opensource development (I
don't talk about projects like Spring, Eclipse or many other company-driven
projects but about those projects here at the Apache Software Foundation) is the
diversity of the people who participate. At the same time it is also one of its
weaknesses because things need time to grow.
In addition, we people here have different development and language skills and,
don't forget that we both have already had many discussions about what a
reimplementation is about and how we intend to implement this layered design.
I'm happy that people are catching up and participate in the discussion on
different levels. I'm sure that we will become more focused in the future - and
I think that you are right that code will help. At least people will finally
come up with their requirements in more detail ("I need caching" is too
general!) finally so that terms like "layered design" and "caching" become more
conrete.
--
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]
_
