[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524448 ] Carsten Ziegeler commented on COCOON-1765: -- Can we have such discussions in the mailing list please? > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524447 ] Ralph Goers commented on COCOON-1765: - Daniel, all you did was repeat back what I said. It hasn't answered my concern. In Cocoon 2.1 we use the Avalon logger API. We provide a couple of implementation but anyone can write an implementation of this API to plug in their own logging framework (as I have done). As I understand the pages referenced above PAX will bind the client using a particular API with the implementation of that API in a separate bundle. So it looks to me that if Cocoon used the log4j api that it would be tied to the log4j pax bundle, which is unacceptable. If this is correct then it is a requirement that Cocoon 2.2 continue to use an abstract logging api such as the Avalon logger. Is this clear or do I misunderstand what PAX does? > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524437 ] Daniel Fagerstrom commented on COCOON-1765: --- When I look at the same link I find client code examples for Log4J, Jakarta Commons Logging, SLF4J, Avalon Logging, JDK Logging, Knopflerfish Log and Pax Logging in the client code section. Also they are moving their documentation to Confluence, a newer version of the document can be found here http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1831) Finish blocks-fw implementation
[ https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rice Yeh updated COCOON-1831: - Attachment: cocoon-servlet-service-impl.patch The previous patch does not include the modification in ServletServiceContextTestCase that is subject to the change in BlockCallHttpServletRequest. Attached patch has this modification included. Rice > Finish blocks-fw implementation > --- > > Key: COCOON-1831 > URL: https://issues.apache.org/jira/browse/COCOON-1831 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524405 ] Ralph Goers commented on COCOON-1765: - I looked at the link posted by Reinhard. While the doc clealy states that it supports several different logging frameworks the examples still have the client code using a particular implementation. In other words, it looks to me like I could create my own PAX implementation but if the client has coded to log4j's api then my implementation wouldn't work. Please correct me if I misunderstand how it works, but if that is the case then it doesn't meet the requirements. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524403 ] Daniel Fagerstrom commented on COCOON-1765: --- Pax logging supports all major logging framework in an OSGi friendly way. Currently I just use it as an (better) implementation of Commons Logging. All the classloading tricks of the ordinary Commons Logging implementation makes it frustrating to use in an OSGi environment. The point with using the Pax OSGi logging service from OPS4J in combination with the Commons Logging implementation would be that the logging output would be available though the API of the OSGi logging service. But at this point I don't know whether that would be useful or not, so it can wait. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524400 ] Ralph Goers commented on COCOON-1765: - I don't care what is used as long as it is an interface that can have any implementation (including a proprietary logging framework) plugged in. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi integration component in JIRA
Daniel Fagerstrom pisze: > Grzegorz Kossakowski skrev: >> Hello, >> >> I tried to take a look at open issues for "Servlet Service Framework" >> component[1] and found out >> that most of these issues are not directly related to SSF at all. >> >> It's consequence of the fact that SSF component was Blocks-fw >> component and was renamed as most of >> blocks capabilities are handled by SSF now. However, when thinking >> about blocks-fw we had broader >> range of affairs in mind like creation of OSGi integration. Issues >> covering this integration are >> attributed to SSF which is wrong IMO. >> >> Therefore, I propose to create new component called OSGi integration >> and move all issues related to >> OSGi there. >> >> WDYT? > > +1 Done. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Closed: (COCOON-1838) Always use 3-digit version number
[ https://issues.apache.org/jira/browse/COCOON-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-1838. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) I think this issue is fairly old and we have stabilized builds including versions in our poms so it is safe to close this issue as Ben already said more than a year ago. > Always use 3-digit version number > - > > Key: COCOON-1838 > URL: https://issues.apache.org/jira/browse/COCOON-1838 > Project: Cocoon > Issue Type: Improvement > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Ben Pope >Priority: Trivial > Fix For: 2.2-dev (Current SVN) > > Attachments: version.patch > > > Continuing the theme of Carsten in commit 394739 > (This sits on top of my other patch JIRA 1837, so 1 or two files might fail > if that one is not commited) > License granted to ASF. > The patch is essentially a search and replace of > 1-SNAPSHOT and 1.0-SNAPSHOT to > 1.0.0-SNAPSHOT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1765: - Component/s: (was: - Servlet service framework) - OSGi integration > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1833) Make OSGi-based Cocoon useable from within servlet containers
[ https://issues.apache.org/jira/browse/COCOON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1833: - Component/s: (was: - Servlet service framework) - OSGi integration > Make OSGi-based Cocoon useable from within servlet containers > - > > Key: COCOON-1833 > URL: https://issues.apache.org/jira/browse/COCOON-1833 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > We are not the first having this need :-) > We just have to use http://www.eclipse.org/equinox/incubator/server/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1830) Implement OSGiSpringBridge
[ https://issues.apache.org/jira/browse/COCOON-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1830: - Component/s: (was: - Servlet service framework) - OSGi integration > Implement OSGiSpringBridge > -- > > Key: COCOON-1830 > URL: https://issues.apache.org/jira/browse/COCOON-1830 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1834) Integrate OSGi extensions into build system
[ https://issues.apache.org/jira/browse/COCOON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1834: - Component/s: (was: - Servlet service framework) - OSGi integration > Integrate OSGi extensions into build system > --- > > Key: COCOON-1834 > URL: https://issues.apache.org/jira/browse/COCOON-1834 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Make Cocoon block artifacts valid OSGi bundles at build time (of course using > Maven 2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1829) OSGI-based Cocoon architecture
[ https://issues.apache.org/jira/browse/COCOON-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1829: - Component/s: (was: - Servlet service framework) - OSGi integration > OSGI-based Cocoon architecture > -- > > Key: COCOON-1829 > URL: https://issues.apache.org/jira/browse/COCOON-1829 > Project: Cocoon > Issue Type: Sub-task > Components: - OSGi integration >Reporter: Reinhard Poetz > > - whiteboard pattern / dispatcher > - component handling with Spring + OSGi services > - inter-block communication (block protocol, block context) > - declarative services > Based on http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114237414521595&w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1827) Howto: How to get OSGi-based Cocoon running?
[ https://issues.apache.org/jira/browse/COCOON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1827: - Component/s: (was: - Servlet service framework) - OSGi integration > Howto: How to get OSGi-based Cocoon running? > > > Key: COCOON-1827 > URL: https://issues.apache.org/jira/browse/COCOON-1827 > Project: Cocoon > Issue Type: Sub-task > Components: - OSGi integration >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1828) Tutorial: Rewrite the blocks tutorials
[ https://issues.apache.org/jira/browse/COCOON-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1828: - Component/s: (was: - Servlet service framework) - OSGi integration > Tutorial: Rewrite the blocks tutorials > -- > > Key: COCOON-1828 > URL: https://issues.apache.org/jira/browse/COCOON-1828 > Project: Cocoon > Issue Type: Sub-task > Components: - OSGi integration >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > - developing a block (using Maven 2 and Eclipse) > - assemble blocks using Maven 2 and the deployer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1835) Deployment bundle
[ https://issues.apache.org/jira/browse/COCOON-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1835: - Component/s: (was: - Servlet service framework) - OSGi integration > Deployment bundle > - > > Key: COCOON-1835 > URL: https://issues.apache.org/jira/browse/COCOON-1835 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Write a bundle that can install, start, update and stop Cocoon blocks. It is > configured by a deployment descriptor. > Internally it works based on the OSGi configuration service. > Some notes: > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - read Jeff McAffer on [EMAIL PROTECTED]: Installing bundles by reference > (Feb 2006) > - make it configureable which bundles you want to install > a) create an OSGi application > b) create a WAR file that internally uses OSGi > - make the deployer check if all contracts are fullfilled (mail on [EMAIL > PROTECTED] by Jeff McAffer, 30th of August) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1826) OSGi-based Cocoon documentation
[ https://issues.apache.org/jira/browse/COCOON-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1826: - Component/s: (was: - Servlet service framework) - OSGi integration > OSGi-based Cocoon documentation > --- > > Key: COCOON-1826 > URL: https://issues.apache.org/jira/browse/COCOON-1826 > Project: Cocoon > Issue Type: Task > Components: - OSGi integration >Reporter: Reinhard Poetz > > Container task for blocks-fw documentation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2036) Handle circular dependencies in servlet connections
[
https://issues.apache.org/jira/browse/COCOON-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2036:
-
Component/s: (was: - OSGi integration)
- Servlet service framework
Sorry, I moved wrong issue.
> Handle circular dependencies in servlet connections
> ---
>
> Key: COCOON-2036
> URL: https://issues.apache.org/jira/browse/COCOON-2036
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: circular-servlet-connections-warning.patch
>
>
> Circular dependencies in servlet connections lead to a Spring exception [1]
> in [2] that does not provide any help. The previous implementation (block:)
> did allow circular dependencies because they were not handled by spring but
> by custom code.
> Solution would be either to allow them (probably difficult to implement with
> spring) or, if not, to provide a helpful warning message, that skips this
> problem. The latter could be a check for embeddedServlet==null and, if not,
> throw an exception saying "you might have a circular dependency in
> ".
> ---
> [1]:
> The exception is thrown after ServletFactoryBean.getObject() tries to create
> a proxy for the embeddedServlet, which is null in the case of a circular
> dependency (one of the circle endpoints is created, but the other will be
> null).
> Caused by: org.springframework.aop.framework.AopConfigException: Can't proxy
> null object
> at
> org.springframework.aop.framework.ProxyFactory.(ProxyFactory.java:49)
> at
> org.apache.cocoon.servletservice.spring.ServletFactoryBean.getObject(ServletFactoryBean.java:194)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectFromFactoryBean(AbstractBeanFactory.java:1211)
> [2]:
> public Object getObject() throws Exception {
> ProxyFactory proxyFactory = new ProxyFactory(this.embeddedServlet);
> proxyFactory.addAdvice(new ServiceInterceptor());
> if (this.mountPath != null) {
> proxyFactory.addAdvisor(new MountableMixinAdvisor());
> }
> proxyFactory.addAdvisor(new ServletServiceContextMixinAdvisor());
> return proxyFactory.getProxy();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2036) Handle circular dependencies in servlet connections
[
https://issues.apache.org/jira/browse/COCOON-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2036:
-
Component/s: (was: - Servlet service framework)
- OSGi integration
> Handle circular dependencies in servlet connections
> ---
>
> Key: COCOON-2036
> URL: https://issues.apache.org/jira/browse/COCOON-2036
> Project: Cocoon
> Issue Type: Bug
> Components: - OSGi integration
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: circular-servlet-connections-warning.patch
>
>
> Circular dependencies in servlet connections lead to a Spring exception [1]
> in [2] that does not provide any help. The previous implementation (block:)
> did allow circular dependencies because they were not handled by spring but
> by custom code.
> Solution would be either to allow them (probably difficult to implement with
> spring) or, if not, to provide a helpful warning message, that skips this
> problem. The latter could be a check for embeddedServlet==null and, if not,
> throw an exception saying "you might have a circular dependency in
> ".
> ---
> [1]:
> The exception is thrown after ServletFactoryBean.getObject() tries to create
> a proxy for the embeddedServlet, which is null in the case of a circular
> dependency (one of the circle endpoints is created, but the other will be
> null).
> Caused by: org.springframework.aop.framework.AopConfigException: Can't proxy
> null object
> at
> org.springframework.aop.framework.ProxyFactory.(ProxyFactory.java:49)
> at
> org.apache.cocoon.servletservice.spring.ServletFactoryBean.getObject(ServletFactoryBean.java:194)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectFromFactoryBean(AbstractBeanFactory.java:1211)
> [2]:
> public Object getObject() throws Exception {
> ProxyFactory proxyFactory = new ProxyFactory(this.embeddedServlet);
> proxyFactory.addAdvice(new ServiceInterceptor());
> if (this.mountPath != null) {
> proxyFactory.addAdvisor(new MountableMixinAdvisor());
> }
> proxyFactory.addAdvisor(new ServletServiceContextMixinAdvisor());
> return proxyFactory.getProxy();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: OSGi integration component in JIRA
Grzegorz Kossakowski skrev: Hello, I tried to take a look at open issues for "Servlet Service Framework" component[1] and found out that most of these issues are not directly related to SSF at all. It's consequence of the fact that SSF component was Blocks-fw component and was renamed as most of blocks capabilities are handled by SSF now. However, when thinking about blocks-fw we had broader range of affairs in mind like creation of OSGi integration. Issues covering this integration are attributed to SSF which is wrong IMO. Therefore, I propose to create new component called OSGi integration and move all issues related to OSGi there. WDYT? +1 /Daniel
Re: Release Cocoon 2.2RC2
Reinhard Poetz pisze: > > I plan to release following artifacts: > > org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M3 > org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M3 I thought that we are going to release RC1 of servlet-service stuff. At least, we have RC1-SNAPSHOT versions in poms. Why plans have changed? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
OSGi integration component in JIRA
Hello, I tried to take a look at open issues for "Servlet Service Framework" component[1] and found out that most of these issues are not directly related to SSF at all. It's consequence of the fact that SSF component was Blocks-fw component and was renamed as most of blocks capabilities are handled by SSF now. However, when thinking about blocks-fw we had broader range of affairs in mind like creation of OSGi integration. Issues covering this integration are attributed to SSF which is wrong IMO. Therefore, I propose to create new component called OSGi integration and move all issues related to OSGi there. WDYT? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Commented: (COCOON-1833) Make OSGi-based Cocoon useable from within servlet containers
[ https://issues.apache.org/jira/browse/COCOON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524391 ] Daniel Fagerstrom commented on COCOON-1833: --- The current work is based on Felix. So a webapp embedding of the Felix framework corresponding to the Eclipse one (http://www.eclipse.org/equinox/server/http_in_container.php) would be nice. Felix is designed to be easily embedded (http://felix.apache.org/site/launching-and-embedding-apache-felix.html) so with some inspiration from the Eclipse work it would probably not be to complicated to implement. Now, the OSGi-ification of the Cocoon blocks is supposed to work with any OSGi framework. But for builds and examples it is easier to focus on one framework. > Make OSGi-based Cocoon useable from within servlet containers > - > > Key: COCOON-1833 > URL: https://issues.apache.org/jira/browse/COCOON-1833 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > > We are not the first having this need :-) > We just have to use http://www.eclipse.org/equinox/incubator/server/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2050) Basic implementation of postable source
[ https://issues.apache.org/jira/browse/COCOON-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2050. Resolution: Fixed Basic implementation of postable source is already in place. More sophisticated tasks should be tracked by separate issues. Closing that one. > Basic implementation of postable source > --- > > Key: COCOON-2050 > URL: https://issues.apache.org/jira/browse/COCOON-2050 > Project: Cocoon > Issue Type: Sub-task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > Implementation of basic postable source will be tracked in this task. Basic > means that it will not cover: > * caching > * SAX events forwarding - all data exchanged with service will be serialized > * environment sharing/forwarding - there will be no access to the original > environment (request, session etc.) > However it will include: > * postable implementation of servlet: source > * pipeline components (generator, transformer, serializer and reader) for > calling service > * service-consumer: source that makes data POSTed to the called service > available -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CocoonGT hotels
Gianugo Rabellino pisze: > On 8/27/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: >> The GT website doesn't have much to say about recommended hotels yet >> (http://www.cocoongt.org/Venue.html). Will there be some updates by the end >> of >> the weekend? (I will be offline afterwards and would like to have a >> reservation >> before my holidays.) > > Indeed. I expect to finalize that tomorrow. > > Thanks for your patience, Any chance for concrete names of hotels you recommend? It would be much easier for us... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Commented: (COCOON-2096) Servlet source's exists() method always returns true
[
https://issues.apache.org/jira/browse/COCOON-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524388
]
Grzegorz Kossakowski commented on COCOON-2096:
--
FYI: I'm going to fix this issue before next release (not sure if M3 or RC1) of
cocoon-servlet-service, see
http://article.gmane.org/gmane.text.xml.cocoon.devel/74996
> Servlet source's exists() method always returns true
>
>
> Key: COCOON-2096
> URL: https://issues.apache.org/jira/browse/COCOON-2096
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Weber
>Assignee: Grzegorz Kossakowski
>
> sitemap from myBlock1-the filename.txt exist at
> resource/external/filename.txt - the myBlock2 is a bean id - myBlock3 id does
> not exist or the file does not exists in myBlock3:
>
>
>
>
>
>
> src="servlet:myBlock2:/resource/external/filename.txt"/>
>
>
>
> Since myBlock3 does not exist, i am expecting that "test=" returns false and
> map:otherwise is used. But unfortunately it _always_ returns true. It is
> acting as if the "servlet:myBlock3:" part is completely ignored.
> Grzegorz reported back on the User-maillist:
> [quote]
> Alex, I've just checked sources of servlet: protocl (source) that it looks[1]
> like this:
> /**
> * Returns true always.
> *
> * @see org.apache.excalibur.source.Source#exists()
> */
> public boolean exists() {
> return true;
> }
> [/quote]
> reported on maillist:
> http://www.nabble.com/-cocoon-2.2.x--site-can-check-for-file-exists--t4040666.html
> Alexander Weber
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524387 ] Daniel Fagerstrom commented on COCOON-1765: --- I use Pax Logging in the whiteboard and it works well. But there is work left to do on logging configuration and on decide if the OSGi logiing service from OPS4J should be used or not. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2096) Servlet source's exists() method always returns true
[
https://issues.apache.org/jira/browse/COCOON-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2096:
-
Component/s: (was: - Components: Sitemap)
- Servlet service framework
Urgency: Urgent
Summary: Servlet source's exists() method always returns true (was:
https://issues.apache.org/jira/browse/COCOON-2096
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Weber
>Assignee: Grzegorz Kossakowski
>
> sitemap from myBlock1-the filename.txt exist at
> resource/external/filename.txt - the myBlock2 is a bean id - myBlock3 id does
> not exist or the file does not exists in myBlock3:
>
>
>
>
>
>
> src="servlet:myBlock2:/resource/external/filename.txt"/>
>
>
>
> Since myBlock3 does not exist, i am expecting that "test=" returns false and
> map:otherwise is used. But unfortunately it _always_ returns true. It is
> acting as if the "servlet:myBlock3:" part is completely ignored.
> Grzegorz reported back on the User-maillist:
> [quote]
> Alex, I've just checked sources of servlet: protocl (source) that it looks[1]
> like this:
> /**
> * Returns true always.
> *
> * @see org.apache.excalibur.source.Source#exists()
> */
> public boolean exists() {
> return true;
> }
> [/quote]
> reported on maillist:
> http://www.nabble.com/-cocoon-2.2.x--site-can-check-for-file-exists--t4040666.html
> Alexander Weber
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1834) Integrate OSGi extensions into build system
[ https://issues.apache.org/jira/browse/COCOON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524386 ] Daniel Fagerstrom commented on COCOON-1834: --- Currently this is done in wrappers in the whiteboard for some of the core Cocoon blocks. When the work stabilizes and there is more community involvement the OSGi builds could be moved to the affected blocks in the trunk. > Integrate OSGi extensions into build system > --- > > Key: COCOON-1834 > URL: https://issues.apache.org/jira/browse/COCOON-1834 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Make Cocoon block artifacts valid OSGi bundles at build time (of course using > Maven 2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1830) Implement OSGiSpringBridge
[ https://issues.apache.org/jira/browse/COCOON-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524384 ] Daniel Fagerstrom commented on COCOON-1830: --- This task is much easier and maybe not needed at all as we use Spring-OSGi http://www.springframework.org/osgi in the current Cocoon-OSGi integration. A possible problem with Spring-OSGi is that explicit references to all used services are needed for using beans from other bundles. This might be to much configuration and to unflexible when used with the sitemap that dynamically imports services. Here we maybe should use the idea from earlier Cocoon-OSGi integration work with having a root Spring context in bundles that use sitemaps, that ask the OSGi framework directly for non local beans. > Implement OSGiSpringBridge > -- > > Key: COCOON-1830 > URL: https://issues.apache.org/jira/browse/COCOON-1830 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2096)
[
https://issues.apache.org/jira/browse/COCOON-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2096:
Assignee: Grzegorz Kossakowski
> https://issues.apache.org/jira/browse/COCOON-2096
> Project: Cocoon
> Issue Type: Bug
> Components: - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Weber
>Assignee: Grzegorz Kossakowski
>
> sitemap from myBlock1-the filename.txt exist at
> resource/external/filename.txt - the myBlock2 is a bean id - myBlock3 id does
> not exist or the file does not exists in myBlock3:
>
>
>
>
>
>
> src="servlet:myBlock2:/resource/external/filename.txt"/>
>
>
>
> Since myBlock3 does not exist, i am expecting that "test=" returns false and
> map:otherwise is used. But unfortunately it _always_ returns true. It is
> acting as if the "servlet:myBlock3:" part is completely ignored.
> Grzegorz reported back on the User-maillist:
> [quote]
> Alex, I've just checked sources of servlet: protocl (source) that it looks[1]
> like this:
> /**
> * Returns true always.
> *
> * @see org.apache.excalibur.source.Source#exists()
> */
> public boolean exists() {
> return true;
> }
> [/quote]
> reported on maillist:
> http://www.nabble.com/-cocoon-2.2.x--site-can-check-for-file-exists--t4040666.html
> Alexander Weber
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1835) Deployment bundle
[ https://issues.apache.org/jira/browse/COCOON-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524383 ] Daniel Fagerstrom commented on COCOON-1835: --- During development Peter Kriens fileInstall bundle http://www.aqute.biz/Code/FileInstall could be convenient to use. It watches a directory and install and starts bundles that are added to the directory, stops and uninstalls those that are removed and updates those that are changed. Maybe the fileInstall could somehow be extended with mechanisms from the RCL stuff for more fine grained bundle updating. > Deployment bundle > - > > Key: COCOON-1835 > URL: https://issues.apache.org/jira/browse/COCOON-1835 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Write a bundle that can install, start, update and stop Cocoon blocks. It is > configured by a deployment descriptor. > Internally it works based on the OSGi configuration service. > Some notes: > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - read Jeff McAffer on [EMAIL PROTECTED]: Installing bundles by reference > (Feb 2006) > - make it configureable which bundles you want to install > a) create an OSGi application > b) create a WAR file that internally uses OSGi > - make the deployer check if all contracts are fullfilled (mail on [EMAIL > PROTECTED] by Jeff McAffer, 30th of August) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1836) Cocoon blocks development support
[ https://issues.apache.org/jira/browse/COCOON-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-1836. - Resolution: Fixed See last comment. > Cocoon blocks development support > - > > Key: COCOON-1836 > URL: https://issues.apache.org/jira/browse/COCOON-1836 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > some ideas (DF/RP) > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - Talk to Equinox and Felix how they manage the development process > - Talk to the Eclipse PDE community as all resources need to be in the root > directory > - Create a Mojo that creates the target platform containing all bundles out > of a pom.xml or > a deployment descriptor. Make it configureable so that you can easily > switch between bundled > versions and exploded bundles mounted as projects in Eclipse > - Create a Mojo that copies all needed external libraries into > ./target/osgi/lib so that they > can be seen by the PDE (a bit of a hack but well ...) > - extend the Felix OSGi plugin so that you can change the path for integrated > plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1836) Cocoon blocks development support
[ https://issues.apache.org/jira/browse/COCOON-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524381 ] Daniel Fagerstrom commented on COCOON-1836: --- The current Cocoon-OSGi development in the white board uses the Felix Maven bundle plugin that makes it fairly easy to create bundles from ordinary jars. But it doesn't work that well together with the PDE that (at least a year ago) required that the manifest.mf is fixed rather than generated. It seem like the Eclipse developers and large parts of the rest OSGi-community has different philosophy about manifest generation so there is probably not much to do about it. The assembly plugin is used in the whiteboard for collecting together all needed bundles, so there is no need for some special purpose Mojo for that. So all the items above is either solved or less relevant with the current development strategy. > Cocoon blocks development support > - > > Key: COCOON-1836 > URL: https://issues.apache.org/jira/browse/COCOON-1836 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > some ideas (DF/RP) > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - Talk to Equinox and Felix how they manage the development process > - Talk to the Eclipse PDE community as all resources need to be in the root > directory > - Create a Mojo that creates the target platform containing all bundles out > of a pom.xml or > a deployment descriptor. Make it configureable so that you can easily > switch between bundled > versions and exploded bundles mounted as projects in Eclipse > - Create a Mojo that copies all needed external libraries into > ./target/osgi/lib so that they > can be seen by the PDE (a bit of a hack but well ...) > - extend the Felix OSGi plugin so that you can change the path for integrated > plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1831) Finish blocks-fw implementation
[ https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rice Yeh updated COCOON-1831: - Attachment: cocoon-servlet-service-impl.patch I think that Interblock communication mechanism is a must prerequisite to close this bug. see http://www.mail-archive.com/dev@cocoon.apache.org/msg52252.html. Attached is a patch for interblock communication. It works for me and one user who used this patch attached in cocoon-2066, which does not include attributes support in session. see http://www.mail-archive.com/[EMAIL PROTECTED]/msg39396.html Rice > Finish blocks-fw implementation > --- > > Key: COCOON-1831 > URL: https://issues.apache.org/jira/browse/COCOON-1831 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > Attachments: cocoon-servlet-service-impl.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1831) Finish blocks-fw implementation
[ https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524362 ] Grzegorz Kossakowski commented on COCOON-1831: -- I think current version of servlet-service-fw is quite satisfying when it comes to handling Cocoon blocks. Could this issues be closed? > Finish blocks-fw implementation > --- > > Key: COCOON-1831 > URL: https://issues.apache.org/jira/browse/COCOON-1831 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1836) Cocoon blocks development support
[ https://issues.apache.org/jira/browse/COCOON-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524360 ] Grzegorz Kossakowski commented on COCOON-1836: -- How much of these plans is still relevant? Creation of Cocoon blocks is handled by Maven archetypes and we have no OSGi in Cocoon, yet. Could someone more involved in this comment? > Cocoon blocks development support > - > > Key: COCOON-1836 > URL: https://issues.apache.org/jira/browse/COCOON-1836 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > some ideas (DF/RP) > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - Talk to Equinox and Felix how they manage the development process > - Talk to the Eclipse PDE community as all resources need to be in the root > directory > - Create a Mojo that creates the target platform containing all bundles out > of a pom.xml or > a deployment descriptor. Make it configureable so that you can easily > switch between bundled > versions and exploded bundles mounted as projects in Eclipse > - Create a Mojo that copies all needed external libraries into > ./target/osgi/lib so that they > can be seen by the PDE (a bit of a hack but well ...) > - extend the Felix OSGi plugin so that you can change the path for integrated > plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: True OO for servlet service
Rice Yeh pisze: > Hi Grek, > Attached is the patch that is based on the present > cocoon-servlet-service-impl implementation. cocoon-servlet-service-impl > has some change since I posted my patch on COCOON-2038, which has > already too many files attached to it. In order not to confuse you, I > have the the patch attached to this mail. So you do not need to patch > the files in COCOON-2038. I find you already have written a test case > class ServletServiceContextTestCase for ServletServiceContext. I add one > more test case in it to test COCOON-1939. All the test cases in > ServletServiceContextTestCase are passed. > So after applying this patch, you might close COCOON-2038 by referring > back to this mail if there are no further problems. I closed both issues and applied your patch. Many thanks for your invaluable work! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Affects Version/s: 2.2-dev (Current SVN) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2038. Resolution: Fixed > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524356 ] Grzegorz Kossakowski commented on COCOON-2038: -- Actually, it was my fault that caused tests to not pass so everything is ok now. Many thanks to Rice Yeh for providing patch that (little bit reworked) has been committed in r572015. > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: (was: cocoon-servlet-service-2007-09-02.patch) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ https://issues.apache.org/jira/browse/COCOON-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-1939. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Fixed in r572015. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: https://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: cocoon-servlet-service-2007-09-02.patch Attaching simplified Rice's patch that still does not pass tests. > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-2007-09-02.patch, > cocoon-servlet-service-impl.patch, cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ https://issues.apache.org/jira/browse/COCOON-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-1939: Assignee: Grzegorz Kossakowski > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: https://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek >Assignee: Grzegorz Kossakowski > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rice Yeh updated COCOON-2038: - Attachment: cocoon-servlet-service-impl.patch refer to mail http://www.mail-archive.com/dev@cocoon.apache.org/msg53636.html. Rice > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch, > cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: True OO for servlet service
Rice Yeh pisze: > Hi Grek, Hi Rice :) > Attached is the patch that is based on the present > cocoon-servlet-service-impl implementation. cocoon-servlet-service-impl > has some change since I posted my patch on COCOON-2038, which has > already too many files attached to it. In order not to confuse you, I > have the the patch attached to this mail. So you do not need to patch > the files in COCOON-2038. There is a legal problem with such approach. When attaching patch to a JIRA issue you check the option that you intend this file for inclusion to the source codes licensed by Apache License. This agreement is a must in order to commit your patch. I already cleaned up COCOON-2038 so you can safely attach your patch as cocoon-servlet-service-impl-with-tests.patch. > I find you already have written a test case > class ServletServiceContextTestCase for ServletServiceContext. Yes and I wanted to know if testContextInServletCalledFromExplicitSuperCall covers the bug we were talking about in COCOON-2038 as I'm not sure. > I add one > more test case in it to test COCOON-1939. All the test cases in > ServletServiceContextTestCase are passed. > So after applying this patch, you might close COCOON-2038 by referring > back to this mail if there are no further problems. Great, thanks Rice for your work! As long as all doubts are dispelled I'll commit your patch. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: (was: BlockCallHttpServletResponse.java.patch) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: (was: ServletServiceContext.java.patch) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: (was: DispatcherServlet.java.patch) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2038: - Attachment: (was: StatusRetrievableResponse.java) > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-servlet-service-impl.patch > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
