Re: pom poms
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Got a question about poms... Is there any reason why versions of some artifacts are hardcoded in some of the poms? Specific examples are [1]: org.apache.cocoon cocoon-spring-configurator 1.0.0 And [2]: org.apache.cocoon cocoon-configuration-api 1.0.0 And there is one more. When trying to build Cocoon [3], this causes 'artifact not found' errors. And as soon as I remove these lines, everything becomes peachy. Any reason to keep these lines? If yes, why versions are hardcoded only in these three places? We should depend on released stuff whereever possible. I don't think it is, in this case. There is a new element - configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot must be used. As the configuration stuff is nearly the only stuff which has a final release, it just there that we use the version. Now, why it fails, I don't know as these artifacts should be in public repositories. (see -o flag, forces complete local build) Vadim Using the mvn dep mgmt for dependencies that come out of the same project is imho bad and doesn't work as soon as every module has separate release cycles. So while it is general useful to have all third party versions in the root pom, it doesn't work for artifacts of the same project. So this is the reason why they are hard-coded in some poms. HTH Carsten
Re: cocoon-deployer-plugin?
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Hi All, Does anybody know where cocoon-deployer-plugin is? It is referenced from poms but I don't see where its source is.. It has been merged[1] with RCL plugin and renamed to cocoon-maven-plugin. The source of old cocoon-deployer-plugin can be found in our whiteboard. If you see any references to the cocoon-deployer-plugin I think you should just remove them without any harm. Ok, done. Vadim [1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/24155
[jira] Updated: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Cave updated COCOON-2104: Attachment: baseFixup-2.2-r561499.diff Patch for trunk. > [PATCH] Add base URI fixup support to XIncludeTransformer > - > > Key: COCOON-2104 > URL: https://issues.apache.org/jira/browse/COCOON-2104 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Andrew Cave >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff > > > As discussed at [1], the XIncludeTransformer fails to perform the base URI > fixup specified in the W3C's XInclude spec [2]. The spec says that the base > URIs of elements do not change when passed through a conformant XInclude > processor. Meaning, xml:base attributes must be added to the result set. The > reason being that relative URIs in the included document should not break; > this provides a mechanism to resolve them properly. > This patch results in the XIncludeTransformer adding xml:base attributes to > top-level included elements. It does this only when the the base URI of the > included element differs from the base URI of the parent element (meaning: > for almost every case except where the included document is the current > document). > The XIncludeTransformer's JUnit test is also updated by this patch to reflect > the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base > attribute added. > [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html > [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the > W3C's XInclude specification -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Cave updated COCOON-2104: Attachment: baseFixup-2.1-r561455.diff Patch for the 2.1.X branch. > [PATCH] Add base URI fixup support to XIncludeTransformer > - > > Key: COCOON-2104 > URL: https://issues.apache.org/jira/browse/COCOON-2104 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Andrew Cave >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff > > > As discussed at [1], the XIncludeTransformer fails to perform the base URI > fixup specified in the W3C's XInclude spec [2]. The spec says that the base > URIs of elements do not change when passed through a conformant XInclude > processor. Meaning, xml:base attributes must be added to the result set. The > reason being that relative URIs in the included document should not break; > this provides a mechanism to resolve them properly. > This patch results in the XIncludeTransformer adding xml:base attributes to > top-level included elements. It does this only when the the base URI of the > included element differs from the base URI of the parent element (meaning: > for almost every case except where the included document is the current > document). > The XIncludeTransformer's JUnit test is also updated by this patch to reflect > the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base > attribute added. > [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html > [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the > W3C's XInclude specification -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andrew Cave Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2103) Replace Initialization of Object Model by helper classes with more solid mechanisms
Replace Initialization of Object Model by helper classes with more solid mechanisms --- Key: COCOON-2103 URL: https://issues.apache.org/jira/browse/COCOON-2103 Project: Cocoon Issue Type: Sub-task Components: * Cocoon Core, - Expression language, Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Currently initialization of Object Model is spread on various helper classes like: * org.apache.cocoon.template.environment.FlowObjectModelHelper * org.apache.cocoon.environment.TemplateObjectModelHelper that use some static methods and variables. I'm going to slim down these (and other) classes to absolute minimum or remove them completely in the end. Most initialization will be moved to ObjectModel providers classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2102) Fix StatusPage layout
[ https://issues.apache.org/jira/browse/COCOON-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen Reijn closed COCOON-2102. Resolution: Fixed > Fix StatusPage layout > - > > Key: COCOON-2102 > URL: https://issues.apache.org/jira/browse/COCOON-2102 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Reporter: Jeroen Reijn >Assignee: Jeroen Reijn > Fix For: 2.2-dev (Current SVN) > > > The status page (found through the samples) has an xslt defined that does not > show all information due to a namespace declaration for attributes. The > namespace declaration is not necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2102) Fix StatusPage layout
Fix StatusPage layout - Key: COCOON-2102 URL: https://issues.apache.org/jira/browse/COCOON-2102 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Reporter: Jeroen Reijn Assignee: Jeroen Reijn Fix For: 2.2-dev (Current SVN) The status page (found through the samples) has an xslt defined that does not show all information due to a namespace declaration for attributes. The namespace declaration is not necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2101) Spring sample in core block is broken
[ https://issues.apache.org/jira/browse/COCOON-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen Reijn closed COCOON-2101. Resolution: Fixed > Spring sample in core block is broken > - > > Key: COCOON-2101 > URL: https://issues.apache.org/jira/browse/COCOON-2101 > Project: Cocoon > Issue Type: Bug > Components: - Samples >Affects Versions: 2.2-dev (Current SVN) >Reporter: Jeroen Reijn >Assignee: Jeroen Reijn > Fix For: 2.2-dev (Current SVN) > > > The Spring sample is the core block is broken due to an undefined method in > flowscript. The function getUploadFolder is not defined in the object which > it's trying to retreive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2101) Spring sample in core block is broken
Spring sample in core block is broken - Key: COCOON-2101 URL: https://issues.apache.org/jira/browse/COCOON-2101 Project: Cocoon Issue Type: Bug Components: - Samples Affects Versions: 2.2-dev (Current SVN) Reporter: Jeroen Reijn Assignee: Jeroen Reijn Fix For: 2.2-dev (Current SVN) The Spring sample is the core block is broken due to an undefined method in flowscript. The function getUploadFolder is not defined in the object which it's trying to retreive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: cocoon-deployer-plugin?
Vadim Gritsenko pisze: Hi All, Does anybody know where cocoon-deployer-plugin is? It is referenced from poms but I don't see where its source is.. It has been merged[1] with RCL plugin and renamed to cocoon-maven-plugin. The source of old cocoon-deployer-plugin can be found in our whiteboard. If you see any references to the cocoon-deployer-plugin I think you should just remove them without any harm. [1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/24155 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: pom poms
Vadim Gritsenko wrote: > Hi All, > > Got a question about poms... Is there any reason why versions of some > artifacts are hardcoded in some of the poms? Specific examples are [1]: > > > org.apache.cocoon > cocoon-spring-configurator > 1.0.0 > > > And [2]: > > > org.apache.cocoon > cocoon-configuration-api > 1.0.0 > > > And there is one more. When trying to build Cocoon [3], this causes > 'artifact not found' errors. And as soon as I remove these lines, > everything becomes peachy. Any reason to keep these lines? If yes, why > versions are hardcoded only in these three places? > We should depend on released stuff whereever possible. As the configuration stuff is nearly the only stuff which has a final release, it just there that we use the version. Now, why it fails, I don't know as these artifacts should be in public repositories. Using the mvn dep mgmt for dependencies that come out of the same project is imho bad and doesn't work as soon as every module has separate release cycles. So while it is general useful to have all third party versions in the root pom, it doesn't work for artifacts of the same project. So this is the reason why they are hard-coded in some poms. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
cocoon-deployer-plugin?
Hi All, Does anybody know where cocoon-deployer-plugin is? It is referenced from poms but I don't see where its source is.. Thanks Vadim
pom poms
Hi All, Got a question about poms... Is there any reason why versions of some artifacts are hardcoded in some of the poms? Specific examples are [1]: org.apache.cocoon cocoon-spring-configurator 1.0.0 And [2]: org.apache.cocoon cocoon-configuration-api 1.0.0 And there is one more. When trying to build Cocoon [3], this causes 'artifact not found' errors. And as soon as I remove these lines, everything becomes peachy. Any reason to keep these lines? If yes, why versions are hardcoded only in these three places? Vadim [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/pom.xml [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-store/cocoon-store-impl/pom.xml [3] rm -rf ~/.m2/repository/org/apache/cocoon; mvn -o install
[jira] Updated: (COCOON-2100) Retrieving mimeType returned by pipeline executed from Flow
[ https://issues.apache.org/jira/browse/COCOON-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Kaiser updated COCOON-2100: Attachment: SitemapSource-PipelineUtil.patch Added patch for the second solution. Includes patch to SitemapSource. > Retrieving mimeType returned by pipeline executed from Flow > --- > > Key: COCOON-2100 > URL: https://issues.apache.org/jira/browse/COCOON-2100 > Project: Cocoon > Issue Type: Improvement > Components: - Flowscript, Blocks: Java Flow >Affects Versions: 2.1.10 >Reporter: Nils Kaiser >Priority: Minor > Attachments: SitemapSource-PipelineUtil.patch > > > It is impossible to access the mimetype when executing a pipeline using > PipelineUtil.processToStream. Inside this method, the mimetype should be > accessible via the method Source.getMimeType(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2100) Retrieving mimeType returned by pipeline executed from Flow
[ https://issues.apache.org/jira/browse/COCOON-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Kaiser updated COCOON-2100: Other Info: [Patch available] > Retrieving mimeType returned by pipeline executed from Flow > --- > > Key: COCOON-2100 > URL: https://issues.apache.org/jira/browse/COCOON-2100 > Project: Cocoon > Issue Type: Improvement > Components: - Flowscript, Blocks: Java Flow >Affects Versions: 2.1.10 >Reporter: Nils Kaiser >Priority: Minor > Attachments: SitemapSource-PipelineUtil.patch > > > It is impossible to access the mimetype when executing a pipeline using > PipelineUtil.processToStream. Inside this method, the mimetype should be > accessible via the method Source.getMimeType(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2100) Retrieving mimeType returned by pipeline executed from Flow
[ https://issues.apache.org/jira/browse/COCOON-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516687 ] Nils Kaiser commented on COCOON-2100: - I could fix this issue as we have built a work-around here. But it is not a clean solution, and I could need some help on how to solve it. Here is what I could imagine: 1) - Create a class PipelineResult, with methods byte[] getContent() and String getMimeType(). - Add a method to PipelineUtil: public PipelineResult processToResult(String uri, Object viewData) 2) - Add a method to PipelineUtil with a different name, allowing to retrieve the mimetype: public String processToStreamEx(String uri, Object viewData, OutputStream output) I had to patch SitemapSource in order to access the mimetype as the member was not set. Patch submitted. > Retrieving mimeType returned by pipeline executed from Flow > --- > > Key: COCOON-2100 > URL: https://issues.apache.org/jira/browse/COCOON-2100 > Project: Cocoon > Issue Type: Improvement > Components: - Flowscript, Blocks: Java Flow >Affects Versions: 2.1.10 >Reporter: Nils Kaiser >Priority: Minor > > It is impossible to access the mimetype when executing a pipeline using > PipelineUtil.processToStream. Inside this method, the mimetype should be > accessible via the method Source.getMimeType(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2100) Retrieving mimeType returned by pipeline executed from Flow
Retrieving mimeType returned by pipeline executed from Flow --- Key: COCOON-2100 URL: https://issues.apache.org/jira/browse/COCOON-2100 Project: Cocoon Issue Type: Improvement Components: - Flowscript, Blocks: Java Flow Affects Versions: 2.1.10 Reporter: Nils Kaiser Priority: Minor It is impossible to access the mimetype when executing a pipeline using PipelineUtil.processToStream. Inside this method, the mimetype should be accessible via the method Source.getMimeType(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Site creation for cocoon-servlet-service subproject
On 7/31/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: > ...My key is in the $HOME/.ssh on people.apache.org I have copied that to the user's daisy's .ssh directory on the zone, Grek confirmed that he can login as "daisy" there now. -Bertrand
Re: Docs into SVN?
Bertrand Delacretaz wrote:
On 7/30/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
...While following the infrastructure@ mailing list I get the impression that
all
projects that use Confluence (+ Pier's autoexport plugin) as CMS, don't put the
docs into SVN
It would be interesting to verify this, maybe via [EMAIL PROTECTED]
Or maybe ask infra first, if the policy still stands.
Some more thoughts: Confluence is managed by Apache Infra, Daisy not.
Anyway, I will ask on [EMAIL PROTECTED] Thanks Grek and Bertrand.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Docs into SVN?
On 7/30/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > ...While following the infrastructure@ mailing list I get the impression that > all > projects that use Confluence (+ Pier's autoexport plugin) as CMS, don't put > the > docs into SVN It would be interesting to verify this, maybe via [EMAIL PROTECTED] Or maybe ask infra first, if the policy still stands. -Bertrand
Re: Sitemap scope
Grzegorz Kossakowski wrote: > > Do you think all three pieces are always needed? My answer would be: no, > usually they are not. > :) In my use cases, I often need all three of them and sometimes request and context. > I have no strong preference on ProcessInfoProvider or on direct > dependencies. Daniel's argument that it is a less APIs to learn is right > and I would add another one: it's easier to see what particular > component really needs. Well, fine - although I hate to write to much code, we could remove the interface all together. > >> Today, the object model is still of great value as we messed up the >> implementation and the semantics of internal pipeline calls: request >> attributes are shared between the original request and all child >> requests - therefore setting one in a child request overwrites it in all >> related requests. This is something we can't change for compatibility. >> The object model, however, is a per request map which inherits values >> from the parent request. So some components rely on this behaviour. > > Which object model? I'm not sure what exactly you are talking about. The object model map which is passed to each and every sitemap component in the setup() method. This is the only way of storing per request information. > > Despite things you have pointed out I'm wondering about the type > returned by methods from ProcessInfoProvider. > > If we want ProcessInfoProvider to return request object aware of sitemap > sub-calls I think it makes sense to switch to our own Request interface > just after we make it extending HttpServletRequest. > On the other hand, we want to get rid of extensive use of Request so it > would make sense to stay with HttpServletRequest but returned object > would implement Request interface. This way it would be possible to cast > where it's really needed (there are only few such places) and we could > stay with clean interfaces. Yes, let's use HttpServletRequest etc. - this makes the code usable "outside" of Cocoon without any problems. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (COCOON-2094) Get rid of ExpressionContext usage
[ https://issues.apache.org/jira/browse/COCOON-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2094. Resolution: Fixed Goal has been achieved, closing the issue. > Get rid of ExpressionContext usage > -- > > Key: COCOON-2094 > URL: https://issues.apache.org/jira/browse/COCOON-2094 > Project: Cocoon > Issue Type: Sub-task > Components: - Expression language, Blocks: Templating >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > New ObjectModel implementation should replace any usage of ExpressionContext > that is going to be removed in the end. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sitemap scope
Carsten Ziegeler pisze: Daniel Fagerstrom wrote: Now, I understand if you feel that what I write above seem overly pedantic and that ProcessorInfoProvider should be a good enough solution to the environment handling problems. I have spent so much times fighting the internals of Cocoon, and IMO one of the main reasons that the code is so hard to follow is that the handling of the current context is based on a patchwork of "good enough" hacks, rather than a overall design. So I am strongly convinced that we should spend some effort on getting it right. The greatest advantage with the "sitemap scope" idea, is that it is non intrusive and isolates the user components from the environment handling subtleness. I think we are mixing things a little bit - one is the interface and the other one is the implementation. The sitemap scope is definitly an implementation detail which is irrelevant for the user of the interface. The main idea of the ProcessInfoProvider was to have one single interface to get all relevant information. If we forget about the object model for a moment, I think it makes sense to have one interface for getting the request, the response and the context. Instead of having to implement three setter methods to get all pieces of information. Do you think all three pieces are always needed? My answer would be: no, usually they are not. I have no strong preference on ProcessInfoProvider or on direct dependencies. Daniel's argument that it is a less APIs to learn is right and I would add another one: it's easier to see what particular component really needs. Today, the object model is still of great value as we messed up the implementation and the semantics of internal pipeline calls: request attributes are shared between the original request and all child requests - therefore setting one in a child request overwrites it in all related requests. This is something we can't change for compatibility. The object model, however, is a per request map which inherits values from the parent request. So some components rely on this behaviour. Which object model? I'm not sure what exactly you are talking about. We should therefore define what the behaviour of the request/response is that you get from the ProcessInfoProvider. If it's similar to the current object model and if I get a request object for the current request (being it interal or the original one) than we can remove this method from the interface. We can even rename the interface in need of a better name. (For implementing this behaviour) we might need the sitemap scope :) But let's define the interfaces and contracts first. Despite things you have pointed out I'm wondering about the type returned by methods from ProcessInfoProvider. If we want ProcessInfoProvider to return request object aware of sitemap sub-calls I think it makes sense to switch to our own Request interface just after we make it extending HttpServletRequest. On the other hand, we want to get rid of extensive use of Request so it would make sense to stay with HttpServletRequest but returned object would implement Request interface. This way it would be possible to cast where it's really needed (there are only few such places) and we could stay with clean interfaces. WDYT? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Sitemap scope
Daniel Fagerstrom wrote: > > Now, I understand if you feel that what I write above seem overly > pedantic and that ProcessorInfoProvider should be a good enough solution > to the environment handling problems. I have spent so much times > fighting the internals of Cocoon, and IMO one of the main reasons that > the code is so hard to follow is that the handling of the current > context is based on a patchwork of "good enough" hacks, rather than a > overall design. So I am strongly convinced that we should spend some > effort on getting it right. The greatest advantage with the "sitemap > scope" idea, is that it is non intrusive and isolates the user > components from the environment handling subtleness. > I think we are mixing things a little bit - one is the interface and the other one is the implementation. The sitemap scope is definitly an implementation detail which is irrelevant for the user of the interface. The main idea of the ProcessInfoProvider was to have one single interface to get all relevant information. If we forget about the object model for a moment, I think it makes sense to have one interface for getting the request, the response and the context. Instead of having to implement three setter methods to get all pieces of information. Today, the object model is still of great value as we messed up the implementation and the semantics of internal pipeline calls: request attributes are shared between the original request and all child requests - therefore setting one in a child request overwrites it in all related requests. This is something we can't change for compatibility. The object model, however, is a per request map which inherits values from the parent request. So some components rely on this behaviour. We should therefore define what the behaviour of the request/response is that you get from the ProcessInfoProvider. If it's similar to the current object model and if I get a request object for the current request (being it interal or the original one) than we can remove this method from the interface. We can even rename the interface in need of a better name. (For implementing this behaviour) we might need the sitemap scope :) But let's define the interfaces and contracts first. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
