Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Joerg Heinicke pisze: On 12.01.2008 21:20, [EMAIL PROTECTED] wrote: Modified: cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml Could it be we switched from status.xml to changes.xml? :) Yes, I believe so. I haven't touch any status.xml since I'm committer and nobody complained to date. :) There are still 100 status.xml in trunk. Before I clean them up I want to know if that's correct. File changes.xml is supported by Maven reporting plug-in[1]. I don't know anything about a tool supporting status.xml in trunk so you can be almost sure we have switched. [1] http://maven.apache.org/plugins/maven-changes-plugin/ -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Assigned: (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 reassigned COCOON-2036:
Assignee: Grzegorz Kossakowski
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
Assignee: Grzegorz Kossakowski
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
servlet-foobar.
---
[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.init(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) Throw an exception when circular dependencies in servlet connections are detected.
[
https://issues.apache.org/jira/browse/COCOON-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2036:
-
Affects version (Component): Parent values: Servlet Service
Framework(10175). Level 1 values: 1.0.0-RC1(10313).
Fix version (Component): Parent values: Servlet Service
Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316).
Priority: Minor (was: Major)
Summary: Throw an exception when circular dependencies
in servlet connections are detected. (was: Handle circular dependencies in
servlet connections)
Throw an exception when circular dependencies in servlet connections are
detected.
--
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
Assignee: Grzegorz Kossakowski
Priority: Minor
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
servlet-foobar.
---
[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.init(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] Closed: (COCOON-2036) Throw an exception when circular dependencies in servlet connections are detected.
[
https://issues.apache.org/jira/browse/COCOON-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski closed COCOON-2036.
Resolution: Fixed
Applied in r611562. Thanks Alexander for providing a patch.
Throw an exception when circular dependencies in servlet connections are
detected.
--
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
Assignee: Grzegorz Kossakowski
Priority: Minor
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
servlet-foobar.
---
[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.init(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] Commented: (COCOON-2114) fix sorting in TraversableGenerator
[ https://issues.apache.org/jira/browse/COCOON-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558391#action_12558391 ] Grzegorz Kossakowski commented on COCOON-2114: -- Hi Daniel I would like to apply your patch but it needs a test-coverage. Could you provide a simple test checking if sorting works as expected? fix sorting in TraversableGenerator --- Key: COCOON-2114 URL: https://issues.apache.org/jira/browse/COCOON-2114 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Daniel Naber Attachments: TraversableGenerator.diff The sort in TraversableGenerator.java doesn't work, because the array which is sorted is actually never used. The attached patch fixes that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Joerg Heinicke wrote:
On 12.01.2008 21:20, [EMAIL PROTECTED] wrote:
Modified:
cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Could it be we switched from status.xml to changes.xml? :)
yes. We had some discussion about it when I switched our doc generation to be
based on Maven 2. The only disadvantage is that changes.xml only allows text in
the description element and not mixed content. I tried to fix it in the Maven
Changes plugin but without success :-(
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Reinhard Poetz pisze: Joerg Heinicke wrote: On 12.01.2008 21:20, [EMAIL PROTECTED] wrote: Could it be we switched from status.xml to changes.xml? :) yes. We had some discussion about it when I switched our doc generation to be based on Maven 2. The only disadvantage is that changes.xml only allows text in the description element and not mixed content. I tried to fix it in the Maven Changes plugin but without success :-( It's not entirely true. You can use CDATA section and put HTML tags into it. See[1] [1] http://jira.codehaus.org/browse/MCHANGES-9 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Joerg Heinicke wrote:
On 12.01.2008 21:20, [EMAIL PROTECTED] wrote:
Could it be we switched from status.xml to changes.xml? :)
yes. We had some discussion about it when I switched our doc generation to
be based on Maven 2. The only disadvantage is that changes.xml only allows
text in the description element and not mixed content. I tried to fix it in
the Maven Changes plugin but without success :-(
It's not entirely true. You can use CDATA section and put HTML tags into it.
See[1]
great! It's not as comfortable as in status.xml files but at least a work around
that is good enough :-)
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
On 13.01.2008 05:17, Grzegorz Kossakowski wrote: cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml Could it be we switched from status.xml to changes.xml? :) Yes, I believe so. I haven't touch any status.xml since I'm committer and nobody complained to date. :) For me it is the other way around. I still have put all changes into status.xml and nobody complained :) Joerg
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Joerg Heinicke pisze: On 13.01.2008 05:17, Grzegorz Kossakowski wrote: cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml Could it be we switched from status.xml to changes.xml? :) Yes, I believe so. I haven't touch any status.xml since I'm committer and nobody complained to date. :) For me it is the other way around. I still have put all changes into status.xml and nobody complained :) Hehe, funny :) I must have missed that so I didn't ask earlier. Anyway, Reinhard dissipated any doubts. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
On 13.01.2008 09:30, Grzegorz Kossakowski wrote: You can use CDATA section and put HTML tags into it. See[1] It's a pain that they disable output escaping! Why not allowing free markup? Wherever we put escaped markup into our changes to show them to the user they will end up as markup in the actual HTML - and screw up the page. Joerg
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
On 13.01.2008 09:20, Reinhard Poetz wrote: Could it be we switched from status.xml to changes.xml? :) yes. We had some discussion about it when I switched our doc generation to be based on Maven 2. I'm going to move changes put into status.xml to corresponding changes.xml and get rid of status.xml. It was only me and Carsten who still used status.xml :) One is different though. There is a status.xml in commons directory and I don't see a corresponding changes.xml. What about it? Joerg
[jira] Created: (COCOON-2160) Wrong element structure in schema file for cocoon-spring-configurator
Wrong element structure in schema file for cocoon-spring-configurator - Key: COCOON-2160 URL: https://issues.apache.org/jira/browse/COCOON-2160 Project: Cocoon Issue Type: Bug Components: Blocks: (Undefined) Reporter: Grzegorz Kossakowski Priority: Minor Schema located at http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd allows to put configurator:include-beans/ element as top-level which results in following exception: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionParser for element [include-beans] Closer look at schema reveals that element is supposed to be child of configurator:settings/. Schema file must be restructured a little bit in order to avoid ambiguity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2150) Error on resetting response
[
https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558427#action_12558427
]
Grzegorz Kossakowski commented on COCOON-2150:
--
I isolated the problem and committed additional checks that if uncommented will
exhibit the problematic behaviour.
The offending code snippet is (ServletServiceContext:507):
if (se != null || (status 200 || status = 400)) {
wrappedResponse.reset();
NamedDispatcher _super = (NamedDispatcher)
ServletServiceContext.this.getNamedDispatcher(SUPER);
if (_super != null) {
_super.forward(request, wrappedResponse);
} else {
wrappedResponse.getWriter().println(Resource not
found);
wrappedResponse.setStatus(HttpServletResponse.SC_NOT_FOUND);
throw se;
}
}
Since this code resets response (which is unavoidable) I think we will need to
buffer response and let it commit until ServletServiceContext checks are done.
At least we would need to buffer response if status code is 404 (and possibly
other of similar meaning).
WDYT?
Error on resetting response
---
Key: COCOON-2150
URL: https://issues.apache.org/jira/browse/COCOON-2150
Project: Cocoon
Issue Type: Bug
Components: - Servlet service framework
Affects Versions: 2.2-dev (Current SVN)
Reporter: Jörg Heinicke
Priority: Minor
Fix For: 2.2-dev (Current SVN)
This is the exception shown on the console:
java.lang.IllegalStateException: Committed
at org.mortbay.jetty.Response.resetBuffer(Response.java:855)
at org.mortbay.jetty.Response.reset(Response.java:834)
at
javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:182)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:576)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:545)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy2.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
It seems to be thrown whenever the response object is reseted after the
actual response has been sent by the sitemap error handler. In this case
reset is no longer possible since the response has already been committed as
stated in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2150) Error on resetting response
Vadim Gritsenko pisze:
On Dec 19, 2007, at 2:00 PM, Grzegorz Kossakowski wrote:
The check has been introduced in order to handle polymorphism of
servlet services
Shouldn't it explicitly check for 404 only? And, for Cocoon servlet, for
unhandled ResourceNotFoundException?
Any of 1XX-3XX, 5XX are clearly not an indication for calling super,
IIUC. Seems that only 404 ('The server has not found anything matching
the Request-URI.') should be.
Even then, if 'super' is not available, it should simply return that 404
without messing with it... Right? There should be no
wrappedResponse.reset() is super is null. There also should be no throw
null;, if there were no ServletException.
Sorry for not responding earlier, I must have missed your e-mail somehow.
Yep, Vadim you are right on all of your points. The whole snippet is broken
(I'm not sure why I
committed the patch without noticing it) and as I already pointed out in JIRA
we will probably need
to buffer whole response.
Also, in r611596 I added checks that can easily exhibit bad behaviour in an
isolated environment.
Anyone willing to take care of fixing it? I'm quite busy ATM...
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
Hello dear list members! I am a long term cocoon user and and looking foreward to use cocoon 2.2 in production quite soon. nevertheless the fact that the official demo on the cocoon.zones.apache.org crashes in most samples, doesn't encourage my efforts towards an early migration to 2.2. for instance, i try to start the first sample of the cforms block and get the error below. I am pretty sure that this is just an infrastructure issue, but it would help many interested future cocoon 2.2 users to evaluate the (frontend) features without downloading and trying out. just my thoughts, Gabriel Gruber Workflow EDV GmbH, Vienna HTTP ERROR: 500 javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; RequestURI=/demos/trunk/samples/forms/form1 Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199) at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880) at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39) at org.apache.cocoon.util.location.LocationAttributes$Pipe.setDocumentLocator(LocationAttributes.java:303) at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
Re: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
Gabriel Gruber pisze: Hello dear list members! Hello Gabriel! I am a long term cocoon user and and looking foreward to use cocoon 2.2 in production quite soon. nevertheless the fact that the official demo on the cocoon.zones.apache.org crashes in most samples, doesn't encourage my efforts towards an early migration to 2.2. for instance, i try to start the first sample of the cforms block and get the error below. I am pretty sure that this is just an infrastructure issue, but it would help many interested future cocoon 2.2 users to evaluate the (frontend) features without downloading and trying out. just my thoughts, Thanks for sharing your findings. I'm just investigating into the problem now. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon 2.2 Trunk DEMO at cocon.zones.apache.org crashes at various samples
Grzegorz Kossakowski pisze: Gabriel Gruber pisze: Hello dear list members! Hello Gabriel! I am a long term cocoon user and and looking foreward to use cocoon 2.2 in production quite soon. nevertheless the fact that the official demo on the cocoon.zones.apache.org crashes in most samples, doesn't encourage my efforts towards an early migration to 2.2. for instance, i try to start the first sample of the cforms block and get the error below. I am pretty sure that this is just an infrastructure issue, but it would help many interested future cocoon 2.2 users to evaluate the (frontend) features without downloading and trying out. just my thoughts, Thanks for sharing your findings. I'm just investigating into the problem now. Fixed. It was (again) issue caused by Java 1.4. I modified script at our zone to use Java 1.5 instead. I don't have time and more importantly a will to investigate further into this problem. Thanks Gabriel again for pointing this problem out to us. I hope this will encourage you to upgrade to Cocoon 2.2. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
