[jira] Assigned: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2108: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. xmodule:flow-attr Does not accept document objects -- Key: COCOON-2108 URL: https://issues.apache.org/jira/browse/COCOON-2108 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Hugh Sparks Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2 Attachments: Cocoon-2.2-truck-JXPathHelper.java.patch, Cocoon-BRANCH-2.1.X-JXPathHelper.java.patch, xmodulePuzzle.txt Sending document objects from flowscript back to the pipeline using xmodule:flow-attr produces unexpected results. Also, the examples from the documentation do not work as described: http://cocoon.apache.org/2.1/861.daisy.html The most common error reported is: 'The object type: class java.lang.String could not be serialized to XML This issue was discussed recently on the cocoon-users mailing list. The thread was introduced by Kazo Csaba with the subject Sending DOM from flowscript to pipeline. (July 17, 2007) He has attempted to trace this behavior in the source code and believes that a possibly-inappropriate conversion to string occurs in some cases. Jason Johnston suggested moving the issue to JIRA. I've created a demonstration of this apparent bug and some related problems in this very brief example: http://www.csparks.com/xmodulePuzzle.txt I hope someone can fix or explain the correct usage of xmodule:flow-attr. Thanks to all, -Hugh Sparks, h...@csparks.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2087) Upgrade Forms samples' dependency on jDBI to 2.0.x version
[ https://issues.apache.org/jira/browse/COCOON-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2087: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. Upgrade Forms samples' dependency on jDBI to 2.0.x version -- Key: COCOON-2087 URL: https://issues.apache.org/jira/browse/COCOON-2087 Project: Cocoon Issue Type: Task Components: Blocks: Forms Affects Versions: 2.2 Reporter: Grzegorz Kossakowski I reported (http://article.gmane.org/gmane.text.xml.cocoon.devel/73957) recently that we have a trouble with jDBI as dependency because it's not on Maven's repository. I just have found out that it's not true, see: http://repo1.maven.org/maven2/org/jdbi/jdbi/2.0.1/ The task is to add the dependency on jDBI to cocoon-forms-sample module and (possibly) adjust the code so it works with new major version. Old samples used to work with 1.4.x line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2211. Resolution: Fixed Resolved in r668604. Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Attachments: JXtemplateElementPatch JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2216: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/us...@cocoon.apache.org/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2239) Add support for servlet protocol in flow's sendPage
[ https://issues.apache.org/jira/browse/COCOON-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2239: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2212: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Attachments: JXtemplateAttributePatch Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactored the JXTemplateGeneratorTestCase -- 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) 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 reassigned COCOON-2096:
Assignee: (was: Grzegorz Kossakowski)
I don't plan to work on this issue in foreseeable future so I leave it
unassigned.
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
Reporter: Alexander Weber
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:
map:match pattern=filename.txt
map:select type=resource-exists
map:when test=servlet:myBlock3:resource/external/filename.txt
map:read src=servlet:myBlock3:resource/external/filename.txt/
/map:when
map:otherwise
map:read
src=servlet:myBlock2:/resource/external/filename.txt/
/map:otherwise
/map:select
/map:match
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] Assigned: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys
[ https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2044: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. servlet: protocol URIs have to be globally unique for use as cache-keys --- Key: COCOON-2044 URL: https://issues.apache.org/jira/browse/COCOON-2044 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Alexander Klimetschek Priority: Critical All servlet protocol URIs like servlet:/some/thing or servlet:super:/foo/bar or servlet:myblock:/another/path have to be globally unique because they are used in the cache, of which there is only one global with globally acting keys. There are two caches in standard Cocoon configuration (the only ones I know of ;-), both with a different key generation. Here are ideas how to make the keys global: a) EHDefaultStore for caching resources of caching pipelines: they use the uriPrefix of the Enviroment in the key, so providing a uriPrefix (eg. the mount path of the servlet) works here. b) DefaultTransientStore which caches XSLT and JX generator sources (don't know why this is different from a)): they do not use the uriPrefix and much worse, they need correct URIs because they are read by the XSLT processor, who does not like things like servlet:uniqueID34:/xsl/stylesheet.xsl containing arbitrary schemes at the beginning. Appending an ID via a query parameter seems the only working solution (tried it already): servlet:/xsl/stylesheet.xsl?servlet-services-id=12345 Another solution would be to have one cache per sitemap, so that the keys don't have to be unique anymore. But I don't know how to configure that and if this is feasible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2118) Implement map: expression language
[ https://issues.apache.org/jira/browse/COCOON-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2118: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. FYI: This feature has been implemented in C3 and in C2.2 it would be rather hard to implement it due to (still, sight) complicated ObjectModel. I have lost any faith when it comes to this. Implement map: expression language -- Key: COCOON-2118 URL: https://issues.apache.org/jira/browse/COCOON-2118 Project: Cocoon Issue Type: New Feature Components: - Components: Sitemap Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Implement expression language (map:) that let's you to access sitemap variables. Actually, it's already implemented in PreparedVariableResolver for years but the task is about implementing it as class imlementing org.apache.cocoon.components.expression.Expression interface. It was proposed here[1] and clarified here[2]. [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-16) Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer
[ https://issues.apache.org/jira/browse/COCOON3-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667459#action_12667459 ] Grzegorz Kossakowski commented on COCOON3-16: - Steven, I can see some other changes to SaxBuffer. Are they formatting-only? Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer Key: COCOON3-16 URL: https://issues.apache.org/jira/browse/COCOON3-16 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-1 Reporter: Steven Dolg Assignee: Steven Dolg Fix For: 3.0.0-alpha-2 Attachments: consumer.patch The interface o.a.c.p.c.Consumer does not extend o.a.c.p.c.PipelineComponent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666913#action_12666913 ] Grzegorz Kossakowski commented on COCOON3-14: - As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Is this event-based communication guaranteed at PipelineComponent level or it's left to implementation how to design it? If a user knows which type of components (s)he will use, the pipeline can be narrowed down to accept only those type of components. If the exact type is not known or a mixture of different components is to be used, using How it's possible that user is using a component and does not know what kind of input/output this component deals with? I agree with Steven's point on the need for creation of marker interfaces. If they are going to be purely marker interfaces then I'm quite concerned about this solution. Is it only my omission or this patch does not solve a problem with Pipeline results outlined by Reinhard: http://article.gmane.org/gmane.text.xml.cocoon.devel/79362 To sum up my opinion I'm -0 on this patch. In itself it's not bad (and not invading) but I think this patch tries to tweak broken foundations. I would prefer if we could agree on Pipelines and PipelineComponent fundamental design decisions and goals before we move to providing patches. There were two different approaches presented in form of patches that left on or another side unhappy so such an agreement seems to be the best solution. What about a serious discussion on this topic during ApacheCon EU this year? I don't want to suspend the whole discussion for two months, of course. Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
Grzegorz Kossakowski commented on COCOON3-14:
-
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
Use generics for pipeline assembly
--
Key: COCOON3-14
URL: https://issues.apache.org/jira/browse/COCOON3-14
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-pipeline
Reporter: Carsten Ziegeler
Assignee: Cocoon Developers Team
Attachments: generics.patch
This is a simple patch to add generics to the pipeline interface and impl.
With additionally introducing marker interfaces for the component types (SAX,
Stax, dom)
this would allow compile time checks if all components have the correct type
when assembling the pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:41 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:40 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666938#action_12666938 ] Grzegorz Kossakowski commented on COCOON3-14: - Looks like our JIRA set-up sucks and JIRA does not follow comment formatting. I'm moving with discussion to mailing list. Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:42 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636361#action_12636361 ] Grzegorz Kossakowski commented on COCOON-2216: -- Imran, It's my time to apologize. I didn't read your previous description carefully enough. Now I could reproduce your problem which is just a sign of much bigger problem. IncludeCacheManager uses thread pooling technique which does not play nicely with ThreadLocals, see: http://java.sys-con.com/node/37241 As I said this problem is not limited to the newly introduced Factory for ObjectModel. Servlet Service Fw and Spring itself use ThreadLocals as well. I think this is a right time to move this discussion to dev@ list so others can comment. I'll be probably in favour of removing thread pooling completely but I don't know performance implications at the moment. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636201#action_12636201
]
Grzegorz Kossakowski commented on COCOON-2216:
--
Hi Imran,
Sorry for next delay - this time I'm moving to a new flat.
When it comes to your problem I've looked into sources of JX templates and
found:
Attr 1 :${cocoon.request.getParameter('attr1')}br/
I believe it should look like:
Attr 1 :${cocoon.request.getAttribute('attr1')}br/
After applying this change both parameters and attributes works fine for me. Is
there anything else missing? I would like to start polishing of my patch so it
can be applied to trunk.
IncludeCacheManager can not perfom parallel includes
Key: COCOON-2216
URL: https://issues.apache.org/jira/browse/COCOON-2216
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Christoph Gaffga
Assignee: Grzegorz Kossakowski
Attachments: cocoon-trunk.patch,
multi-thread-simple-28.09.2008.patch,
ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip,
test-webapp.zip, test-webapp.zip
Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
sources from other cocoon pipelines into one (similar to the aggregator) is
not working anymore.
We also posted our problem to the mailing list, got little feedback but it
brought us on the right way...
see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
I found out that it's a problem with the DefaultIncludeCacheManager, that can
not do parallel inclusion of cocoon-pipelines anymore. I checked several
classes where inclusion is used. In the aggregator parallel inclusion is not
an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
but it can't do parallel inclusion. In the new IncludeTransfomer parallel
inclusion is supported, but it does not use caching as it does not use the
IncludeCacheManager...
But we needed caching AND parallel processing, so I tried to find out what's
broken in the DefaultIncludeCacheManager:
and it seems that the ThreadLocal variables are not initialized for the child
threads that do the inclusion. Neither the spring context nor the old
environment stuff was initialized. And all the source resolving was done
outside the child thread and that way using the wrong thread context.
We were able to fix that issue by small changes to DefaultIncludeCacheManager
and IncludeCacheManagerSession. It would be great if somebody could apply
this patch so we don'T have to patch every cocoon version again and again...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635591#action_12635591 ] Grzegorz Kossakowski commented on COCOON-2216: -- I'm glad to hear that it works for you. Is your test-case covering the issue with request attributes? How can I see this problem myself? At the moment I have no clue on what might be happening when it comes to request attributes. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2216: - Attachment: multi-thread-simple-28.09.2008.patch Hello, I just wanted to let you know that I've finally tackled this problem using much more simpler approach than the one I planned to use. Anyway, it looks like this patch fixes the specific problem you have. There are two important notes, though: 1. This patch was tested using your test-case and regular Cocoon samples only 2. This patch is still not a *complete* solution to all OM-related problems that I'm aware off but brings us much closer to final solution because it at least fixes issue with multi-thread environments. I'd would appreciate any feedback on it (testing) before I continue to work in this direction. Also, I've published my local Git branch established for changes related to this issue, see: http://github.com/gkossakowski/apache-cocoon/tree/COCOON-2216-multi-thread-simple You can easily clone this repo using: git clone git://github.com/gkossakowski/apache-cocoon.git and then switch to my local branch using git gui command. Another method is just using download button so you download the entire source code. I mention this second method of getting my changes (instead of patch) because it's more likely that my repository at GitHub will be up-to-date with my changes compared to patches attached to JIRA. Moreover, it's easier to analyse my changes using GitHub website. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632014#action_12632014 ] Grzegorz Kossakowski commented on COCOON-2216: -- Hello Christoph and Imran. First of all I want to say that I did *not* forget about this issue and I've spent lots of time working on it. Actually I did not report or share anything because I felt somehow embarrassed by the fact that I've taken four different (from scratch) attempts to tackle this issue without any significant success. This problem is even more difficult (at least to me) than I thought, unfortunately. Right now I'm working on fifth attempt which is probably the ugliest design I've ever made but I have really no clue how to make it better. I'm just in process of fixing broken ITs and test cases. I hope to have something workable tomorrow (I expect to have a whole day free so I should spend some time on testing and polishing the code) but this will be far from being something acceptable for trunk. I guess I'll need some help of other folks but first I'll need to explain in detail what's the actual problem which is not the easiest task as well... Grzegorz (hating Cocoon's Core with even bigger passion and starting to wonder if my GSoC work on ObjectModel does not share bad design with Cocoon Core...) IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632028#action_12632028 ] Grzegorz Kossakowski commented on COCOON-2216: -- Small update: I've just realized that the reason for my troubles *might* be caused by the fact that I insisted on clean isolation between different stages of pipeline (or in general sitemap, or even more in general request processing) execution so no data is being transferred from one stage to another. We all think that globals are bad, don't we? However, it looks like that was my major mistake because Cocoon internals were never designed this way and thus my changes introduced endless stream of bugs or quirks. I'll try to check my findings tomorrow. Actually... today as it's already 2am here. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12624370#action_12624370
]
Grzegorz Kossakowski commented on COCOON-2216:
--
Hi Imran,
I worked on this issue for a few hours but this turned out to be even more
complicated than I thought so I have no working code yet and tomorrow I won't
be able to work on this. :(
As I said, the idea is to create custom bean factory, I've started to write a
prototype of it:
package org.apache.cocoon.components.pipeline.spring;
import java.util.Stack;
public class ObjectModelFactoryBean implements
FactoryBean {
private InheritableThreadLocalStackObjectModel objectModelStack = new
InheritableThreadLocalStackObjectModel() {
protected StackObjectModel initialValue() {
StackObjectModel newStack = new StackObjectModel();
newStack.push(createObjectModel());
return newStack;
};
protected StackObjectModel childValue(StackObjectModel parentValue)
{
StackObjectModel newStack = new StackObjectModel();
try {
newStack.push((ObjectModel)parentValue.peek().clone());
} catch (CloneNotSupportedException e) {
// TODO Have to add some logging
e.printStackTrace();
}
return newStack;
};
};
public Object getObject() throws Exception {
synchronizeStack();
return objectModelStack.get().peek();
}
public ClassObjectModel getObjectType() {
return ObjectModel.class;
}
public boolean isSingleton() {
return false;
}
/**
* This method is heart of this class.
* It's purpose is to synchronize its own internal stack with stack
maintained by Servlet Service Framework
* for servlet: calls and stack maintained by Cocoon Core for cocoon:
calls.
*/
protected void synchronizeStack() {
//no implementation at the moment
}
protected ObjectModel createObjectModel() {
//here we'll need to create ObjectModelImpl instance
//and inject all initial values
return null;
}
}
Only once I started to write it I realized that there is a problem with cyclic
dependencies caused by this class. The point is that, synchronizeStack must
have an access to both Cocoon Core and Servlet Service Framework classes and
itself must be placed in Cocoon Core.
But, by design, Cocoon core cannot depend on SSF. If I decide to put it
somewhere then cyclic dependencies are starting to appear. I have some ideas
how to create two different object factories and design whole thing in layered
why so layers can be independent but this will take me some time.
On the other hand, this issue has got a higher priority for me because my
company that I'm working at want to have it fixed as well so at least you can
be sure that it will get fixed sooner or later.
I'll continue my work on this issue on monday and I'll have to fix it until
Friday because later on I'll be busy with completely Cocoon-unrelated stuff.
IncludeCacheManager can not perfom parallel includes
Key: COCOON-2216
URL: https://issues.apache.org/jira/browse/COCOON-2216
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Christoph Gaffga
Assignee: Grzegorz Kossakowski
Attachments: cocoon-trunk.patch,
ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip
Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
sources from other cocoon pipelines into one (similar to the aggregator) is
not working anymore.
We also posted our problem to the mailing list, got little feedback but it
brought us on the right way...
see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
I found out that it's a problem with the DefaultIncludeCacheManager, that can
not do parallel inclusion of cocoon-pipelines anymore. I checked several
classes where inclusion is used. In the aggregator parallel inclusion is not
an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
but it can't do parallel inclusion. In the new IncludeTransfomer parallel
inclusion is supported, but it does not use caching as it does not use the
IncludeCacheManager...
But we needed caching AND parallel processing, so I tried to find out what's
broken in the DefaultIncludeCacheManager:
and it seems that the ThreadLocal variables are not initialized for the child
threads that do the inclusion. Neither
[jira] Created: (COCOON-2239) Add support for servlet protocol in flow's sendPage
Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623150#action_12623150 ] Grzegorz Kossakowski commented on COCOON-2216: -- After applying your patch I've managed to reproduce your problem. I have some plan how to fix problems with ObjectModel but this will involve: 1. Enforcing that OM implementation implements Cloneable interface (change to API) 2. Implementing custom FactoryBean for OM in cocoon-sitemap-impl that will be aware of issues related to threads (but not only to threads, there some other, even more tricky issues waiting for someone to discover). 3. Making this custom FactoryBean aware of servlet: calls is crucial as well. I've already created a branch in my Git repository for this issue and started to play with code. If nothing unplanned happens, I'll be able to give you some patches for testing upcoming week. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2236) Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2
[ https://issues.apache.org/jira/browse/COCOON-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2236. Resolution: Fixed Fixed in r686261. Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2 Key: COCOON-2236 URL: https://issues.apache.org/jira/browse/COCOON-2236 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Servlet Service Framework was refactored because there was hidden dependency on CocoonSourceResolver (in a fact, there was a hidden cyclic dependency) which was of course a bad situation because SSF is meant to be completely independent from Cocoon. However, these refactorings introduced some back-incompatibility (which is just a bug). In order to handle different protocols in context-path property of servlet bean, SSF installs JNet handlers using AOP from Spring. The problematic part is that this interceptor is disabled for init() method of every bean, including servlet beans. SitemapServlet does some serious work in its init() method and requires protocols (like block-context:) to be working properly so JNet handler must be installed. The solution for this problem will be to manually install JNet handler in ServletFactoryBean where init method is called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2216: Assignee: Grzegorz Kossakowski IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12622964#action_12622964 ] Grzegorz Kossakowski commented on COCOON-2216: -- Sorry for big delay but I was busy with other tasks which got a higher priority. Finally I'm finished and I have some free time to spend on this issue which (to be honest) is not the easiest one. Now I'll at least try to reproduce your problem and try to estimate how much of work is needed to fix this in proper way. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2237) Buffering of response does not work correctly in SSF
[ https://issues.apache.org/jira/browse/COCOON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2237. Resolution: Fixed Fixed in r685544. Buffering of response does not work correctly in SSF Key: COCOON-2237 URL: https://issues.apache.org/jira/browse/COCOON-2237 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Class HttpServletResponseBufferingWrapper contains subtle bug when it comes to buffering of response. It relies its behaviour on HTTP status code and buffers only if it was set to 404. However, in following scenario current implementation won't work: 1. stream = response.getOutputStream() //non buffering output stream is returned because by default status code is set to 200 2. response.setStatusCode(404) 3. stream.write() //write details about error, this is going to be written to response because non-buffering output stream is in use 4. response.resetBufferedResponse() //this fails with IllegalStateException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2236) Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2
Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2 Key: COCOON-2236 URL: https://issues.apache.org/jira/browse/COCOON-2236 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Servlet Service Framework was refactored because there was hidden dependency on CocoonSourceResolver (in a fact, there was a hidden cyclic dependency) which was of course a bad situation because SSF is meant to be completely independent from Cocoon. However, these refactorings introduced some back-incompatibility (which is just a bug). In order to handle different protocols in context-path property of servlet bean, SSF installs JNet handlers using AOP from Spring. The problematic part is that this interceptor is disabled for init() method of every bean, including servlet beans. SitemapServlet does some serious work in its init() method and requires protocols (like block-context:) to be working properly so JNet handler must be installed. The solution for this problem will be to manually install JNet handler in ServletFactoryBean where init method is called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2237) Buffering of response does not work correctly in SSF
Buffering of response does not work correctly in SSF Key: COCOON-2237 URL: https://issues.apache.org/jira/browse/COCOON-2237 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Class HttpServletResponseBufferingWrapper contains subtle bug when it comes to buffering of response. It relies its behaviour on HTTP status code and buffers only if it was set to 404. However, in following scenario current implementation won't work: 1. stream = response.getOutputStream() //non buffering output stream is returned because by default status code is set to 200 2. response.setStatusCode(404) 3. stream.write() //write details about error, this is going to be written to response because non-buffering output stream is in use 4. response.resetBufferedResponse() //this fails with IllegalStateException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2227) Creation of child settings object is broken
Creation of child settings object is broken --- Key: COCOON-2227 URL: https://issues.apache.org/jira/browse/COCOON-2227 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) It seems that there is a problem with creation of child settings object. To reproduce this problem just go to: core/cocoon-webapp and then run Cocoon using following command: mvn jetty:run -Dorg.apache.cocoon.formencoding=UTF-8 Then access: http://localhost:/ and you will get following exception: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.configuration.Settings': Invocation of init method failed; nested exception is java.lang.IllegalStateException: This value can only be changed for the root settings object. [...] Caused by: java.lang.IllegalStateException: This value can only be changed for the root settings object. at org.apache.cocoon.configuration.MutableSettings.checkSubSetting(MutableSettings.java:423) at org.apache.cocoon.configuration.MutableSettings.setFormEncoding(MutableSettings.java:364) at org.apache.cocoon.configuration.MutableSettings.configure(MutableSettings.java:151) at org.apache.cocoon.spring.configurator.impl.AbstractSettingsBeanFactoryPostProcessor.createSettings(AbstractSettingsBeanFactoryPostProcessor.java:258) at org.apache.cocoon.spring.configurator.impl.AbstractSettingsBeanFactoryPostProcessor.init(AbstractSettingsBeanFactoryPostProcessor.java:130) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2225) how to debug xslt in cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder
[ https://issues.apache.org/jira/browse/COCOON-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615903#action_12615903 ] Grzegorz Kossakowski commented on COCOON-2225: -- Just to make things easier I'll add to Joerg's reply mine: Your question is about how to use JBuilder and not how to use Cocoon so chances that you will get any response are very low anyway. how to debug xslt in cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder -- Key: COCOON-2225 URL: https://issues.apache.org/jira/browse/COCOON-2225 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Reporter: student cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder as there is some important xml file that combines with my xslt and display but I am not aware of among so many important which xml it is combining .so I will be thankfulo just let me know how to debug xsl using in jbuilder2008 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
[ https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2226: Assignee: Grzegorz Kossakowski Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator - Key: COCOON-2226 URL: https://issues.apache.org/jira/browse/COCOON-2226 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Abel Muiño Assignee: Grzegorz Kossakowski Attachments: patch.txt The pom for cocoon-servlet-service depends on dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-spring-configurator/artifactId version1.0.3-SNAPSHOT/version scopecompile/scope /dependency (see http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2226) Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator
[ https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2226. Resolution: Fixed Fixed in r678281. Thanks Abel for spotting my obvious mistake here. Build error due to wrong dependency version from cocoon-servlet-service in cocoon-spring-configurator - Key: COCOON-2226 URL: https://issues.apache.org/jira/browse/COCOON-2226 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Abel Muiño Assignee: Grzegorz Kossakowski Attachments: patch.txt The pom for cocoon-servlet-service depends on dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-spring-configurator/artifactId version1.0.3-SNAPSHOT/version scopecompile/scope /dependency (see http://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml) But the cocoon-spring-configuration has version 1.1.0-SNAPSHOT, which causes an error when building the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606864#action_12606864 ] Grzegorz Kossakowski commented on COCOON-2214: -- The file has been committed in r669964, the file is available at http://cocoon.apache.org/archetype-catalog.xml David, would you like to take care of updating the documentation? Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2212: Assignee: Grzegorz Kossakowski jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: JXtemplateAttributePatch Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactored the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2214: Assignee: Grzegorz Kossakowski Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606267#action_12606267 ] Grzegorz Kossakowski commented on COCOON-2214: -- David, I've previously missed three important issues about your achetype-catalog.xml: 1. It should contain Apache header but since you have attached it as contribution that's not a show-stopper. 2. Versions listed in the file are SNAPSHOT ones coming from building the Cocoon from trunk. That's a mistake as other people won't be able to use them because SNAPSHOTs are never released to central repository. Here you can consult versions of Cocoon artifacts that has been released: http://repo1.maven.org/maven2/org/apache/cocoon/ 3. The description of archetypes is little bit misleading. The best option is to borrow them from http://cocoon.apache.org/2.2/maven-plugins/ Even though I can fix those myself I'll have time for this tomorrow. If you don't mind upload improved file please so it'll faster get uploaded. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605545#action_12605545 ] Grzegorz Kossakowski commented on COCOON-2211: -- Patch applied to trunk in r668604. Thanks Kamal for providing it. I'm not sure if it should go into 2.1.x line. I would really like to see it as maintenance branch where no new features are being added. Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Attachments: JXtemplateElementPatch JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2211: Assignee: Grzegorz Kossakowski Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Attachments: JXtemplateElementPatch JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605062#action_12605062 ] Grzegorz Kossakowski commented on COCOON-2211: -- Kamal, I've taken a brief look at your patch and it looks very good to me. Thanks for providing extensive tests for the functionality this patch introduces. I'm going to test it and commit it to trunk as soon as its possible (probably before Monday). Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Attachments: JXtemplateElementPatch JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2197) Making the cocoon-auth-block acegi-security-sample work
[ https://issues.apache.org/jira/browse/COCOON-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592655#action_12592655 ] Grzegorz Kossakowski commented on COCOON-2197: -- Patrick, I've tried to apply your patch and it looks good to me (I just removed SNAPSHOT suffix). However, I would like to know if you ran successfully this block? I have a feeling that it's somehow not finished and needs more polish. Making the cocoon-auth-block acegi-security-sample work --- Key: COCOON-2197 URL: https://issues.apache.org/jira/browse/COCOON-2197 Project: Cocoon Issue Type: Wish Components: - Samples Affects Versions: 2.2 Reporter: Patrick Heiden Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-acegi-sample-svn-diff.patch The current acegi-security-sample doesn't work with acegi version used! So an update to spring-security (2.0.0-SNAPSHOT) fixed that problem. Following steps need to be performed: 1) get the latest trunk from spring-security (acegi) (see [1] for details) 2) compile and install that trunk (mvn install, maybe skip the more than 1000 tests ;) 3) change the pom.xml of cocoon-acegisecurity-sample block: replace the acegi dependency with: dependency groupIdorg.springframework.security/groupId artifactIdspring-security-core/artifactId version2.0.0-SNAPSHOT/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion /exclusions /dependency 4) replacements in META-INF/cocoon/xpatch/acegi-filter-patch.xweb: every org.acegi. ... should be replaced by org.springframework.security 5) the same needs to be done for all bean's class attribute inside META-INF/cocoon/spring/cocoon-acegisecurity.xml 6) mvn install; mvn jetty:run I would guess, that by making acegi a spring portfolio project, the rework on that project contains better adoption of spring bean-lifecycles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2197) Making the cocoon-auth-block acegi-security-sample work
[ https://issues.apache.org/jira/browse/COCOON-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2197: Assignee: Grzegorz Kossakowski Making the cocoon-auth-block acegi-security-sample work --- Key: COCOON-2197 URL: https://issues.apache.org/jira/browse/COCOON-2197 Project: Cocoon Issue Type: Wish Components: - Samples Affects Versions: 2.2 Reporter: Patrick Heiden Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-acegi-sample-svn-diff.patch The current acegi-security-sample doesn't work with acegi version used! So an update to spring-security (2.0.0-SNAPSHOT) fixed that problem. Following steps need to be performed: 1) get the latest trunk from spring-security (acegi) (see [1] for details) 2) compile and install that trunk (mvn install, maybe skip the more than 1000 tests ;) 3) change the pom.xml of cocoon-acegisecurity-sample block: replace the acegi dependency with: dependency groupIdorg.springframework.security/groupId artifactIdspring-security-core/artifactId version2.0.0-SNAPSHOT/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion /exclusions /dependency 4) replacements in META-INF/cocoon/xpatch/acegi-filter-patch.xweb: every org.acegi. ... should be replaced by org.springframework.security 5) the same needs to be done for all bean's class attribute inside META-INF/cocoon/spring/cocoon-acegisecurity.xml 6) mvn install; mvn jetty:run I would guess, that by making acegi a spring portfolio project, the rework on that project contains better adoption of spring bean-lifecycles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2197) Making the cocoon-auth-block acegi-security-sample work
[ https://issues.apache.org/jira/browse/COCOON-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592597#action_12592597 ] Grzegorz Kossakowski commented on COCOON-2197: -- Hi Patrick, it looks like Acegi (known as Spring Security) has been officially released so there is no need for depending on SNAPSHOT version. Could you adapt your patch, please? I'm willing to commit it as soon as it reflects the fact that final version has been released. Making the cocoon-auth-block acegi-security-sample work --- Key: COCOON-2197 URL: https://issues.apache.org/jira/browse/COCOON-2197 Project: Cocoon Issue Type: Wish Components: - Samples Affects Versions: 2.2 Reporter: Patrick Heiden Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-acegi-sample-svn-diff.patch The current acegi-security-sample doesn't work with acegi version used! So an update to spring-security (2.0.0-SNAPSHOT) fixed that problem. Following steps need to be performed: 1) get the latest trunk from spring-security (acegi) (see [1] for details) 2) compile and install that trunk (mvn install, maybe skip the more than 1000 tests ;) 3) change the pom.xml of cocoon-acegisecurity-sample block: replace the acegi dependency with: dependency groupIdorg.springframework.security/groupId artifactIdspring-security-core/artifactId version2.0.0-SNAPSHOT/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion /exclusions /dependency 4) replacements in META-INF/cocoon/xpatch/acegi-filter-patch.xweb: every org.acegi. ... should be replaced by org.springframework.security 5) the same needs to be done for all bean's class attribute inside META-INF/cocoon/spring/cocoon-acegisecurity.xml 6) mvn install; mvn jetty:run I would guess, that by making acegi a spring portfolio project, the rework on that project contains better adoption of spring bean-lifecycles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2176: Assignee: Grzegorz Kossakowski Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Attachments: COCOON-2176-Webapp.tar.gz The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2176. Resolution: Fixed Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.1.0-dev(10351). Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Attachments: COCOON-2176-Webapp-25.04.2008.tar.gz, COCOON-2176-Webapp.tar.gz The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2176: - Attachment: COCOON-2176-Webapp-25.04.2008.tar.gz Attaching modified test-case that depends on refactored SSF that is free of CocoonSourceResolver dependencies. This test-case passes so the bug can be closed. Many thanks to Reinhard for his work that made this happen! Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Attachments: COCOON-2176-Webapp-25.04.2008.tar.gz, COCOON-2176-Webapp.tar.gz The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2170) Update selection list document page to reflect change to @cache from @dynamic
[ https://issues.apache.org/jira/browse/COCOON-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2170: Assignee: Grzegorz Kossakowski Update selection list document page to reflect change to @cache from @dynamic -- Key: COCOON-2170 URL: https://issues.apache.org/jira/browse/COCOON-2170 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: D Hohls Assignee: Grzegorz Kossakowski Priority: Trivial In the deprecation log this message: http-8080-Processor10/Deprecation.LoggerWrapper: '@dynamic' mailto:'@dynamic' is deprecated in fd:selection-list and replaced by '@cache' mailto:'@cache' However, on the docs page: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html There is no mention of the @cache attribute. Can someone please update the page to relfect the discussion shown on: http://svn.apache.org/viewvc?view=revrevision=179906 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2170) Update selection list document page to reflect change to @cache from @dynamic
[ https://issues.apache.org/jira/browse/COCOON-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2170. Resolution: Fixed Update selection list document page to reflect change to @cache from @dynamic -- Key: COCOON-2170 URL: https://issues.apache.org/jira/browse/COCOON-2170 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: D Hohls Assignee: Grzegorz Kossakowski Priority: Trivial In the deprecation log this message: http-8080-Processor10/Deprecation.LoggerWrapper: '@dynamic' mailto:'@dynamic' is deprecated in fd:selection-list and replaced by '@cache' mailto:'@cache' However, on the docs page: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html There is no mention of the @cache attribute. Can someone please update the page to relfect the discussion shown on: http://svn.apache.org/viewvc?view=revrevision=179906 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2170) Update selection list document page to reflect change to @cache from @dynamic
[ https://issues.apache.org/jira/browse/COCOON-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591029#action_12591029 ] Grzegorz Kossakowski commented on COCOON-2170: -- Fixed in Daisy. The fixed version will be published soon. Thanks Derek for reporting! Update selection list document page to reflect change to @cache from @dynamic -- Key: COCOON-2170 URL: https://issues.apache.org/jira/browse/COCOON-2170 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: D Hohls Assignee: Grzegorz Kossakowski Priority: Trivial In the deprecation log this message: http-8080-Processor10/Deprecation.LoggerWrapper: '@dynamic' mailto:'@dynamic' is deprecated in fd:selection-list and replaced by '@cache' mailto:'@cache' However, on the docs page: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html There is no mention of the @cache attribute. Can someone please update the page to relfect the discussion shown on: http://svn.apache.org/viewvc?view=revrevision=179906 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2043) Thien Luh's new design of the Cocoon website
[ https://issues.apache.org/jira/browse/COCOON-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591042#action_12591042 ] Grzegorz Kossakowski commented on COCOON-2043: -- Helma, since we are already happily using Thien's work at our site we can close this issue. Right? Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assignee: Helma van der Linden Attachments: Cocoon Site - Elements.zip, Home V2 - Final.psd, icons.rar, warning.gif Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2195) Additional components and features.
[ https://issues.apache.org/jira/browse/COCOON-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588221#action_12588221 ] Grzegorz Kossakowski commented on COCOON-2195: -- @Steven: Smaller patches make sense only if they are focused on one change (e.g. adding new component) and each one is annotaed with one-two sentences of description. I would love to see your patches applied in similar fasion it was done for COCOON-1993. Then it's easier to review patches because you focus on one thing only at the mmoment. @Reinhard: Sure. I wanted to review this code and the best way is to apply it but if you are want to do this I won't stop you. :-) Additional components and features. --- Key: COCOON-2195 URL: https://issues.apache.org/jira/browse/COCOON-2195 Project: Cocoon Issue Type: Improvement Components: Corona (experimental) Reporter: Steven Dolg Assignee: Grzegorz Kossakowski Attachments: patch.txt Additional components: * XSLT Transformer * first attempt at Controllers Additional features: * JNet integration (not finished, but working) * Mime-Type handling (not finished, but working) * Input parameters provided for all pipeline components * Controller can redirect to the sitemap (somewhat experimental) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2195) Additional components and features.
[ https://issues.apache.org/jira/browse/COCOON-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2195: Assignee: (was: Grzegorz Kossakowski) Additional components and features. --- Key: COCOON-2195 URL: https://issues.apache.org/jira/browse/COCOON-2195 Project: Cocoon Issue Type: Improvement Components: Corona (experimental) Reporter: Steven Dolg Attachments: patch.txt Additional components: * XSLT Transformer * first attempt at Controllers Additional features: * JNet integration (not finished, but working) * Mime-Type handling (not finished, but working) * Input parameters provided for all pipeline components * Controller can redirect to the sitemap (somewhat experimental) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2195) Additional components and features.
[ https://issues.apache.org/jira/browse/COCOON-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587771#action_12587771 ] Grzegorz Kossakowski commented on COCOON-2195: -- Thanks Steven for your work! One problem strikes me: it's 113kb of patch. This will be quite hard to review but I hope to have a look at it over the weekend. Could you split your patches into smaller chunks in a future? For this time I'll try to divide it into smaller commits. Additional components and features. --- Key: COCOON-2195 URL: https://issues.apache.org/jira/browse/COCOON-2195 Project: Cocoon Issue Type: Improvement Components: Corona (experimental) Reporter: Steven Dolg Attachments: patch.txt Additional components: * XSLT Transformer * first attempt at Controllers Additional features: * JNet integration (not finished, but working) * Mime-Type handling (not finished, but working) * Input parameters provided for all pipeline components * Controller can redirect to the sitemap (somewhat experimental) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2195) Additional components and features.
[ https://issues.apache.org/jira/browse/COCOON-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2195: Assignee: Grzegorz Kossakowski Additional components and features. --- Key: COCOON-2195 URL: https://issues.apache.org/jira/browse/COCOON-2195 Project: Cocoon Issue Type: Improvement Components: Corona (experimental) Reporter: Steven Dolg Assignee: Grzegorz Kossakowski Attachments: patch.txt Additional components: * XSLT Transformer * first attempt at Controllers Additional features: * JNet integration (not finished, but working) * Mime-Type handling (not finished, but working) * Input parameters provided for all pipeline components * Controller can redirect to the sitemap (somewhat experimental) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2190) Add caching to corona
[ https://issues.apache.org/jira/browse/COCOON-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2190: - Component/s: (was: * Cocoon Core) Corona (experimental) Add caching to corona -- Key: COCOON-2190 URL: https://issues.apache.org/jira/browse/COCOON-2190 Project: Cocoon Issue Type: New Feature Components: Corona (experimental) Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: caching.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583088#action_12583088
]
Grzegorz Kossakowski commented on COCOON-2187:
--
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583088#action_12583088
]
grek edited comment on COCOON-2187 at 3/28/08 9:38 AM:
---
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Actually, the test-case for cocoon-template-impl would be the best. We have
planty of them already so it should be quite easy to provide one testing this
problem.
was (Author: grek):
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
[ https://issues.apache.org/jira/browse/COCOON-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582339#action_12582339 ] Grzegorz Kossakowski commented on COCOON-2181: -- FYI: You can monitor build status here: http://vmbuild.apache.org/continuum/buildResults.action?projectGroupId=23projectId=51 POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Assignee: Reinhard Poetz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at
[jira] Commented: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581072#action_12581072 ] Grzegorz Kossakowski commented on COCOON-2179: -- Reinhard, as you are busy with preparing the release I decided to give this one a shoot. :-) Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2179: Assignee: Grzegorz Kossakowski Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581095#action_12581095 ] Grzegorz Kossakowski commented on COCOON-2179: -- First observations: it looks like it's problem with recycling poolable components (AbstractProcessingPipeline in this case). I constantly see something like that in logs: [ERROR] PoolableFactoryBean - Exception while putting component '[EMAIL PROTECTED]' back into the pool. java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:102) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:61) at $Proxy11.putBackIntoAvalonPool(Unknown Source) at org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.release(AvalonServiceManager.java:73) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:686) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:74) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:1017) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean.enteringPool(PoolableFactoryBean.java:259) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean.putIntoPool(PoolableFactoryBean.java:229) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.run(PoolableProxyHandler.java:84) at org.springframework.web.context.request.AbstractRequestAttributes.executeRequestDestructionCallbacks(AbstractRequestAttributes.java:76) [...] I'm still not sure where is the real cause of this problem in Spring logic or in Avalon Bridge or in RCL. Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2179. Resolution: Duplicate Affects version (Component): Parent values: Cocoon Core(10151). Level 1 values: 2.2.0-RC2(10309). Fix version (Component): Parent values: Cocoon Core(10227). Level 1 values: 2.2.0-RC2(10303). It turns out that commit made by Carsten in r543066 did not incorporate essential change proposed originally by Alexander Klimetschek. This problem turns out to be the reincarnation of COCOON-2070 that has never been fixed. Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reopened COCOON-2070: -- Assignee: Grzegorz Kossakowski (was: Carsten Ziegeler) In r543066 slightly modified patch from Alexander has been committed but this small modification lead to the situation that original problem has *never* been fixed. Line: RequestContextHolder.currentRequestAttributes().removeAttribute(this.attributeName, RequestAttributes.SCOPE_REQUEST); has been *copied* to the enclosing if clause but it should has been *moved*. See diff available at http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java?r1=490762r2=543066diff_format=h Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions) -- Key: COCOON-2070 URL: https://issues.apache.org/jira/browse/COCOON-2070 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Priority: Blocker Fix For: 2.2-dev (Current SVN) Attachments: poolable-recycle-bug.patch There is a serious bug in o.a.c.core.container.spring.avalon.PoolableProxyHandler (and PoolableFactoryBean) that can lead to exceptions like Cannot set reader. Generator already set. This is because the pipeline impl bean is reused from the pool, but was never recycle()d. The recycle() call is skipped in cases when an exception is thrown by Spring inside PoolableProxyHandler.invoke(putBackIntoAvalonPool) - this exception is simply swalled by both PoolableProxyHandler.run() and PoolableFactoryBean.putIntoPool(). The typical behaviour is that the first call to the pipeline works, but because the components are put back into the pool unrecycled, the next call will fail. If there is lots of activity, you might get a fresh component from the pool and it might work again, so the error seems quite random. The problematic exception happens when RequestContextHolder.currentRequestAttributes() is called when the attributes for the request are null: IllegalStateException(No thread-bound request found:.). The call to that method happens in the putBackIntoAvalonPool case in PoolableProxyHandler.invoke(). The problem is that this code will also be called *after* the request attributes were set to null by the RequestContextListener, because it is registered as a destruction callback, that gets called by Spring after the attribute reset. The real chain of calls is as follows: RequestContextListener.requestDestroyed() RequestContextHolder.setRequestAttributes(null) callDestructionCallbacks() PoolableProxyHandler.run() - which is a destruction callback PoolableFactoryBean.putIntoPool() PoolableFactoryBean.enteringPool() component.recycle() AvalonServiceManager/Selector.release(childComponent) - component releases its childComponent AvalonPoolable.putBackIntoAvalonPool() PoolableProxyHandler.invoke() - intercepts the putBackIntoAvalonPool() call RequestContextHolder.currentRequestAttributes() -- Exception !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2070. Resolution: Fixed Affects version (Component): Parent values: Components: Sitemap(10152). Level 1 values: 1.0.0-RC3-dev(10312). Fix version (Component): Parent values: Components: Sitemap(10229). Level 1 values: 1.0.0-RC3-dev(10306). Fixed *definitively* in r639686. Thanks again Alexander for your patch! Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions) -- Key: COCOON-2070 URL: https://issues.apache.org/jira/browse/COCOON-2070 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Priority: Blocker Fix For: 2.2-dev (Current SVN) Attachments: poolable-recycle-bug.patch There is a serious bug in o.a.c.core.container.spring.avalon.PoolableProxyHandler (and PoolableFactoryBean) that can lead to exceptions like Cannot set reader. Generator already set. This is because the pipeline impl bean is reused from the pool, but was never recycle()d. The recycle() call is skipped in cases when an exception is thrown by Spring inside PoolableProxyHandler.invoke(putBackIntoAvalonPool) - this exception is simply swalled by both PoolableProxyHandler.run() and PoolableFactoryBean.putIntoPool(). The typical behaviour is that the first call to the pipeline works, but because the components are put back into the pool unrecycled, the next call will fail. If there is lots of activity, you might get a fresh component from the pool and it might work again, so the error seems quite random. The problematic exception happens when RequestContextHolder.currentRequestAttributes() is called when the attributes for the request are null: IllegalStateException(No thread-bound request found:.). The call to that method happens in the putBackIntoAvalonPool case in PoolableProxyHandler.invoke(). The problem is that this code will also be called *after* the request attributes were set to null by the RequestContextListener, because it is registered as a destruction callback, that gets called by Spring after the attribute reset. The real chain of calls is as follows: RequestContextListener.requestDestroyed() RequestContextHolder.setRequestAttributes(null) callDestructionCallbacks() PoolableProxyHandler.run() - which is a destruction callback PoolableFactoryBean.putIntoPool() PoolableFactoryBean.enteringPool() component.recycle() AvalonServiceManager/Selector.release(childComponent) - component releases its childComponent AvalonPoolable.putBackIntoAvalonPool() PoolableProxyHandler.invoke() - intercepts the putBackIntoAvalonPool() call RequestContextHolder.currentRequestAttributes() -- Exception !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2176: - Description: The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. was: The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon. Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2176: - Attachment: COCOON-2176-Webapp.tar.gz Added test-case for this problem. Just enter main directory and call mvn package jetty:run. You will see following exception: 2008-03-17 16:31:20.728::WARN: Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.servletservice.demo1.servlet': Cannot resolve reference to bean 'org.apache.cocoon.servletservice.demo2.servlet' while setting bean property 'connections' with key [TypedStringValue: value [demo2], target type [null]]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.servletservice.demo2.servlet': Invocation of init method failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.apache.excalibur.source.SourceResolver' is defined: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.apache.excalibur.source.SourceResolver' is defined at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:378) [...] Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Attachments: COCOON-2176-Webapp.tar.gz The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2150. Resolution: Fixed Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). (was: Parent values: Servlet Service Framework(10247). ) Fixed (hopefully) definitively in r637416, r637417, r637418 and r637419. 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 Assignee: Grzegorz Kossakowski 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.
[jira] Created: (COCOON-2174) Add XSD Schema for Forms XML grammars and adapt documentation and samples
Add XSD Schema for Forms XML grammars and adapt documentation and samples - Key: COCOON-2174 URL: https://issues.apache.org/jira/browse/COCOON-2174 Project: Cocoon Issue Type: Task Components: Blocks: Forms Reporter: Grzegorz Kossakowski Priority: Minor We should provide XSD Schema for Forms grammars and once we have such Schema available we should adapt our samples and documentation so the adoption of this Schema can be hastened. -- 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=12578986#action_12578986 ] Grzegorz Kossakowski commented on COCOON-2150: -- FYI: I've been working on this today and I have implemented everything I planned in order to resolve this issue. The only remaining problem is that even our test-cases covering this issue pass there are some edge cases when I observe that Cocoon puts my proxy class into illegal state. It's already very late here in Poland so I'll have a look at this tomorrow. 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 Assignee: Grzegorz Kossakowski 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.
[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=12577797#action_12577797 ] Grzegorz Kossakowski commented on COCOON-2150: -- @Reinhard: I agree that it would be the best to fix this one before final release. Unfortunately, this involves implementing special proxy class for HttpResponse that will buffer whole response. It's not that hard but it demands a little of work and testing. I could have a look at this on Friday (unfortunely, I have a lot of subjects at my university in this term...). @Rice: No, this is not a good fix because response must be always discarded no matter if it's been already comitted or not. Hence the need for buffering response that will not commit anything to proxied response object until it's explicitly asked by ServletServiceContext class. 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 Assignee: Grzegorz Kossakowski 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.
[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=12577905#action_12577905 ] Grzegorz Kossakowski commented on COCOON-2150: -- @Joerg: See my response to Vadim who raised exactly the same concerns like some of you: http://article.gmane.org/gmane.text.xml.cocoon.devel/77006 I'll buffer only response if the response code has been set to 404 and will set sane default (like 1MB) of a buffer to avoid OOMEs. If you are generating more than 1MB response with 404 code then it's definitively a problem with your application and FATAL ERROR will be logged. Does it sound fine? 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 Assignee: Grzegorz Kossakowski 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.
[jira] Assigned: (COCOON-2171) The settings object is not available in the JXTemplate generator.
[ https://issues.apache.org/jira/browse/COCOON-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2171: Assignee: Grzegorz Kossakowski The settings object is not available in the JXTemplate generator. - Key: COCOON-2171 URL: https://issues.apache.org/jira/browse/COCOON-2171 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Luca Morandini Assignee: Grzegorz Kossakowski It seems that settings are passed to the CocoonEntryObjectModelProvider class, but not put into the cocoonMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2171) The settings object is not available in Object Model (it can't be obtained using expressions)
[ https://issues.apache.org/jira/browse/COCOON-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2171: - Affects version (Component): Parent values: Components: Sitemap(10152). Level 1 values: 1.0.0-RC2(10311). Fix version (Component): Parent values: Components: Sitemap(10229). Level 1 values: 1.0.0-RC3-dev(10306). Summary: The settings object is not available in Object Model (it can't be obtained using expressions) (was: The settings object is not available in the JXTemplate generator.) The settings object is not available in Object Model (it can't be obtained using expressions) - Key: COCOON-2171 URL: https://issues.apache.org/jira/browse/COCOON-2171 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Luca Morandini Assignee: Grzegorz Kossakowski It seems that settings are passed to the CocoonEntryObjectModelProvider class, but not put into the cocoonMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2171) The settings object is not available in Object Model (it can't be obtained using expressions)
[ https://issues.apache.org/jira/browse/COCOON-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2171. Resolution: Fixed Fixed in r636423. Thanks Luca for reporting! The settings object is not available in Object Model (it can't be obtained using expressions) - Key: COCOON-2171 URL: https://issues.apache.org/jira/browse/COCOON-2171 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Luca Morandini Assignee: Grzegorz Kossakowski It seems that settings are passed to the CocoonEntryObjectModelProvider class, but not put into the cocoonMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2171) The settings object is not available in Object Model (it can't be obtained using expressions)
[ https://issues.apache.org/jira/browse/COCOON-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2171: - Component/s: (was: Blocks: Templating) - Components: Sitemap The settings object is not available in Object Model (it can't be obtained using expressions) - Key: COCOON-2171 URL: https://issues.apache.org/jira/browse/COCOON-2171 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Luca Morandini Assignee: Grzegorz Kossakowski It seems that settings are passed to the CocoonEntryObjectModelProvider class, but not put into the cocoonMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2150: - Fix version (Component): Parent values: Servlet Service Framework(10247). (was: Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). ) Priority: Major (was: Critical) I confirmed that my fix was wrong in this thread: http://article.gmane.org/gmane.text.xml.cocoon.devel/76831 Switching back to Major priority because, with reverted commit, this issue no longer breaks people's applications. At least, in general. 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 Assignee: Grzegorz Kossakowski 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.
[jira] Closed: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2150. Resolution: Fixed 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 Assignee: Grzegorz Kossakowski 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.
[jira] Assigned: (COCOON-2118) Implement map: expression language
[ https://issues.apache.org/jira/browse/COCOON-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2118: Assignee: Grzegorz Kossakowski Implement map: expression language -- Key: COCOON-2118 URL: https://issues.apache.org/jira/browse/COCOON-2118 Project: Cocoon Issue Type: New Feature Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Implement expression language (map:) that let's you to access sitemap variables. Actually, it's already implemented in PreparedVariableResolver for years but the task is about implementing it as class imlementing org.apache.cocoon.components.expression.Expression interface. It was proposed here[1] and clarified here[2]. [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2150: Assignee: Grzegorz Kossakowski 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 Assignee: Grzegorz Kossakowski 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.
[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=12563024#action_12563024 ] Grzegorz Kossakowski commented on COCOON-2150: -- FYI: I'm going to work on fix described in a comment https://issues.apache.org/jira/browse/COCOON-2150?focusedCommentId=12558427#action_12558427 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 Assignee: Grzegorz Kossakowski 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.
[jira] Updated: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2150: - Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). It looks like I fixed this issue rr615697. Please test and reopen if there are still any problems. 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 Assignee: Grzegorz Kossakowski 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.
[jira] Created: (COCOON-2161) URI returned by ServletConnection.getURI() is not properly resolved afterwards
URI returned by ServletConnection.getURI() is not properly resolved afterwards -- Key: COCOON-2161 URL: https://issues.apache.org/jira/browse/COCOON-2161 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Priority: Critical URI returned by o.a.c.servletservice.RelativeServletConnection does not conform our definition of absolute URI for servlet source. It does not contain plus (+) sign after servlet's bean id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2161) URI returned by ServletConnection.getURI() is not properly resolved afterwards
[ https://issues.apache.org/jira/browse/COCOON-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2161. Resolution: Fixed Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). Fixed in r611986. Thanks to Gabriel Gruber for reporting this bug. URI returned by ServletConnection.getURI() is not properly resolved afterwards -- Key: COCOON-2161 URL: https://issues.apache.org/jira/browse/COCOON-2161 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Priority: Critical URI returned by o.a.c.servletservice.RelativeServletConnection does not conform our definition of absolute URI for servlet source. It does not contain plus (+) sign after servlet's bean id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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.
[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.
[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2133: - Affects version (Component): Parent values: Blocks: ImageOp(10334). Level 1 values: 1.0.0-M1-SNAPSHOT(10335). Fix version (Component): Parent values: Blocks: ImageOp(10336). Level 1 values: 1.0.0-M1-SNAPSHOT(10337). Affects Version/s: (was: 2.2-dev (Current SVN)) (was: 2.1.11) Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Reporter: Robin Wyles Assignee: Grzegorz Kossakowski Priority: Minor Attachments: 4x2.jpg, cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2133. Resolution: Fixed Patch comitted in r610567. Thanks Robin for providing test-case! The fact that your improvement is covered by tests moved your patch to the top of my personal patches-to-review-and-apply queue. :) Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Reporter: Robin Wyles Assignee: Grzegorz Kossakowski Priority: Minor Attachments: 4x2.jpg, cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2133: Assignee: Grzegorz Kossakowski Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Assignee: Grzegorz Kossakowski Priority: Minor Attachments: 4x2.jpg, cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2133: - Attachment: cocoon-core-SitemapComponentTestCase-read-method.patch Having some spare time while waiting for a bus I opened my laptop and created this patch. It adds missing read() method to be used for testing Readers. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2133: - Attachment: cocoon-imageop-impl-no-effects-test.patch Here comes a patch adding very simple test for ImageOp reader. I have not given both patches too much testing but I hope you will find it helpful. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555080 ] Grzegorz Kossakowski commented on COCOON-1985: -- Is it still a problem in 2.1.x branch? Why fix from trunk was not applied to 2.1.x branch? AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: caching-trials.patch, includer.xsl, patch.txt, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1995) Can't mount sitemap from using resource:// - cocoon-spring-configurator/avalon bridge doesn't support SourceResolver sources
[ https://issues.apache.org/jira/browse/COCOON-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-1995: - Urgency: Low Fix Version/s: (was: 2.2-dev (Current SVN)) I set Fix version to none because there is no fix available at the moment and I don't consider this issue as blocker for Cocoon 2.2 release. Can't mount sitemap from using resource:// - cocoon-spring-configurator/avalon bridge doesn't support SourceResolver sources Key: COCOON-1995 URL: https://issues.apache.org/jira/browse/COCOON-1995 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Avalon Affects Versions: 2.2-dev (Current SVN) Reporter: Bart Molenkamp It isn't possible to just mount sitemaps from locations other than file:// and http://, because the cocoon-spring-configurator/avalon bridge doesn't support loading resources from the SourceResolver. Mounting a sitemap using resource:// protocol throws the following exception (trying to mount the sitemap resource://test.xmap): org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:12:83 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:11:33 at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:17:80 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:16:31 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:6:30 at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:164:67 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:163:28 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:111) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:233) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:233) at
[jira] Updated: (COCOON-2153) DaslTransformer fails because of conflicting http client dependencies
[ https://issues.apache.org/jira/browse/COCOON-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2153: - Fix Version/s: (was: 2.2-dev (Current SVN)) This issue certainly should not block 2.2 final release. DaslTransformer fails because of conflicting http client dependencies - Key: COCOON-2153 URL: https://issues.apache.org/jira/browse/COCOON-2153 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Jeroen Reijn Assignee: Jeroen Reijn While using the webdav block in your cocoon 2.2 application the DaslTransformer will fill fail with a NoSuchMehtod exception on the setCredentials in the DASL transformer. After further investigation it appeared the the 'slide' dependency has a dependency on commons-httpclient version 2.0.2 and the webdav block has a dependency for 3.0.1. These two dependencies conflict with each other. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
