Re: New Cocoon 2.1.10 live site: www.derecho.com
Hola Ignacio ("Living fossil" according to Cocoon use time ;-)
it's great seeing a Cocoon site in action, but as it is completely in
spanish language it's hard for most of us to have a deeper look at it.
At least I see some english errors when clicking on "Registrate" or
"Entrar"...
Do you plan to translate or do you have some documentation? This would
be great as you surely have had much work to get there!
Bye,
Florian
Nacho (Derecho.com) wrote:
> Hola a todos:
>
> The past day 03/09/2007 we've put a Cocoon 2.1.10 only live site online, with
> big success, we all want to share our success with all of the developers of
> Cocoon, and give a big big thanks to all of you..
>
> We are extensively and intensively using Flow ( thanks god we have flow :),
> SQL Transformer, aggregator, definitely almost anything of the Cocoon
> standard blocks dist, and if not using it, for sure we have plans to use it
> in short..
>
> The old site was done in an ancient cocoon 1.8.2 for 1997-99, backed by a
> tomcat 3.3.. So we are proud to say that we are using cocoon for about 10
> years now ;)
>
> The new site need some work to have all the bell and twistles working, but we
> think is by now a great example on wath can be done with cocoon.. Another
> time thanks to all, including ancient cocoon Heros ;)..
>
> And for the work, where can we found a brief description of 2.2? the build
> process, the new features, etc.
>
> We need to have a peek at the next cocoon version as we want to stay with
> cocoon for next ten years ;).. But until now didnt found any relevant infos
> about it.. Apart from the maillist, where the infos are a little scattered
> and distributed all over the days and months..
>
> Thanks in advance..
>
>
> Ignacio J. Ortega
> Departamento técnico
> http://www.derecho.com
>
[jira] Created: (COCOON-2131) Write migration guide (Avalon -> Spring) for Cocoon components
Write migration guide (Avalon -> Spring) for Cocoon components -- Key: COCOON-2131 URL: https://issues.apache.org/jira/browse/COCOON-2131 Project: Cocoon Issue Type: Task Components: - Documentation Reporter: Grzegorz Kossakowski We should provide documentation that would help our users to migrate their components from Avalon to Sprng. I think that whoever takes burden of migrating cocoon-template could document her work. Block cocoon-template is an excellent example for explaining all issues involved in migration that include: * replacing use of ServiceManager with dependency injection (where possible) * obtaining dependencies dynamically at runtime * migrating test cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2130) Migrate cocoon-template from Avalon to Spring
Migrate cocoon-template from Avalon to Spring - Key: COCOON-2130 URL: https://issues.apache.org/jira/browse/COCOON-2130 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Priority: Minor We should migrate cocoon-template from Avalon to Spring for several reasons: * migration to Spring is our long-term goal in general * we could reduce cocoon-template block depedencies greatly and maybe even completely remove dependency on cocoon-core Second point is quite important because it would allow people to use cocoon-template outside Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1978) JXTemplate often fail a method call without giving any error
[
https://issues.apache.org/jira/browse/COCOON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526587
]
Grzegorz Kossakowski commented on COCOON-1978:
--
Simone, can you test if this issue is still present? I've been debugging JEXL
many times lately so I know internals of JEXL quite well and maybe could do
something with it.
> JXTemplate often fail a method call without giving any error
>
>
> Key: COCOON-1978
> URL: https://issues.apache.org/jira/browse/COCOON-1978
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Templating
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Simone Gianni
>
> When calling a method on an instance in JXTemplate, if that method does not
> exist (or JX cannot find the proper method based on parameters), it fails
> without any error. IMO it should raise an error, or at least should raise it
> in dev mode, because not having a debugger it takes hours to figure out why
> it's not working.
> As an example, take a JX and try to call a method that does not exist :
> value="${obj.getSomethingThatDoesNotExist(cocoon.request)}"/>
> Any will simply be null. Moreover, even if "any" is then used :
> ${any.getSomethingElse()}
> Again it will fail without any error, resulting simply in an empty string,
> making it even harder.
> Being a non compiled language already makes it difficult to make sure calls
> are correct, having this "silent fail" behavior makes it even harder, and if
> you add also the non typized nature it can make it a nightmare.
> Anyway, I don't know if there is a way to fix this in cocoon or if it is a
> Jexl design problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1816) JEXL Does not support full cocoon object model on its own
[ https://issues.apache.org/jira/browse/COCOON-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-1816. Resolution: Fixed Fix Version/s: 2.1.9 2.2-dev (Current SVN) > JEXL Does not support full cocoon object model on its own > - > > Key: COCOON-1816 > URL: https://issues.apache.org/jira/browse/COCOON-1816 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Templating >Affects Versions: 2.1.8 >Reporter: Berin Loritsch >Priority: Critical > Fix For: 2.2-dev (Current SVN), 2.1.9 > > > JEXL will not allow you to access cocoon.request or cocoon.session and > company unless a flowscript performs a sendPage related request. This > violates the principle of least surprise, and caused over four hours of > productivity loss just trying to figure out why something that _should_ work > wasn't. All the documentation suggests that I could access the full cocoon > object model without any reference to flowscript. > The cocoon object model should be set up in a way where it is accessible > directly in JEXL as well as in the flowscript. In short, it should be set up > properly as a core feature so that it is accessible and usable in a > consistent way throughout the entire application. JEXL, Flowscript, or any > other new technology that comes along. One component should not depend on > another to set things up if you can't reasonably expect them to be completely > coupled. In short, JEXL should be usable independantly from Flowscript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1816) JEXL Does not support full cocoon object model on its own
[ https://issues.apache.org/jira/browse/COCOON-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526579 ] Grzegorz Kossakowski commented on COCOON-1816: -- Yes, I think that this has been fixed in refactored template generator/transformer. Use "newjx" generator in your sitemaps in order to utilize refactored code. > JEXL Does not support full cocoon object model on its own > - > > Key: COCOON-1816 > URL: https://issues.apache.org/jira/browse/COCOON-1816 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Templating >Affects Versions: 2.1.8 >Reporter: Berin Loritsch >Priority: Critical > > JEXL will not allow you to access cocoon.request or cocoon.session and > company unless a flowscript performs a sendPage related request. This > violates the principle of least surprise, and caused over four hours of > productivity loss just trying to figure out why something that _should_ work > wasn't. All the documentation suggests that I could access the full cocoon > object model without any reference to flowscript. > The cocoon object model should be set up in a way where it is accessible > directly in JEXL as well as in the flowscript. In short, it should be set up > properly as a core feature so that it is accessible and usable in a > consistent way throughout the entire application. JEXL, Flowscript, or any > other new technology that comes along. One component should not depend on > another to set things up if you can't reasonably expect them to be completely > coupled. In short, JEXL should be usable independantly from Flowscript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: pipelineComponent scope troubles
Giacomo Pati pisze: >> Yes, I'm almost sure that's the reason why pipelineComponent scope is >> freaking. > > Guess what ;-) didn't help removing all map:mount from the sitemap. Exception > still exists and I > have still no clue what has caused this incompatability with existing code. Are you sure that there is no map:mount in whole call stack? Is your sitemap managed by Servlet Service Framework? > > To be honest, I see no reason for me to dig into something I have not a > single clue where to look > at. But still questioning who has put this backward incompatability into it > and how to migrate from it. I think it's shared responsibility but the most significant part must be taken by me. I gave you description of current state of our code to help you get involved but only if you want to, of course. Nevertheless, I really, really want to avoid one-man shows as we both know that it's not how open source works. I can fix this myself (as soon as time permits) but this will not help situation that I and Daniel to some extent will have a any clue about this code. Implementing this sitemap scope is just a must in order to support old Cocoon code. In order to help you with migration I must get some details about your current setup and structure of application. >> If you want to make a quick test if it's the only problem with current trunk >> and work-around NPE >> mentioned by you just change scope of ObjectModel from "pipelineComponent" >> to "call" in this >> file[1]. Be warned that it's only a quick work-around and implementation of >> sitemap scope is the >> only reliable solution. > > Uhh, this give a even more ugly stacktrace (deep into template, el, and jexl) > I wouldn't even think > of pasting it into this mail. It's your turn to be more informative, dear ;-) Paste this ugly stack trace, it may really help me to understand what's the real cause of your troubles. Take into account most (I haven't tested every single one) samples work with current code so it's something specific to your application/setup. Most important: can you reproduce this behaviour when developing some simple test based on our archetype? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Issue Comment Edited: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[
https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472
]
pariyani edited comment on COCOON-1579 at 9/11/07 10:26 AM:
--
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816
i just tried the same with cocoon-2.1.10 samples .. in the
blocks/forms/flow/binding_example.js
change in the method form2bean(form) the line with sendpage
cocoon.sendPage("form2bean.flow", { "form2bean": bean });
send it to any pipeline with cforms and the if u try to submit that form u get
to following exception in the method jsGet_request:
Sitemap: error calling continuation
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:575)
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:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161)
at
org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
at
org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159)
at org.mozilla.javascript.Context.call(Context.java:489)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:839)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:124)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
was (Author: pariyani):
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
[jira] Issue Comment Edited: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[
https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472
]
pariyani edited comment on COCOON-1579 at 9/11/07 10:26 AM:
--
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816
i just tried the same with cocoon-2.1.10 samples .. in the
blocks/forms/flow/binding_example.js
change in the method form2bean(form) the line with sendpage
cocoon.sendPage("form2bean.flow", { "form2bean": bean });
send it to any pipeline with cforms and the if u try to submit that form u get
to following exception in the method jsGet_request:
Sitemap: error calling continuation
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:575)
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:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161)
at
org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
at
org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159)
at org.mozilla.javascript.Context.call(Context.java:489)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:839)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:124)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
was (Author: pariyani):
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
[jira] Commented: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[ https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472 ] imran pariyani commented on COCOON-1579: I am also facing a similar problem but in my case the scenario is a bit different . I have a form which i submit and if everything is ok then in the flowscript i use sendpage(some pipeline).. this pipeline is again with a form and it calls the flowscript which generates a new continuation .. now if i try to submit this form i get a nullpointerexception .. below is the stacktrace .. i tried the workaround mentioned here .. but still i get the same error :( Any help would be appreciated java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578) at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159) at org.mozilla.javascript.Context.call(Context.java:489) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter .java:839) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java :124) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:47) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :235) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :177) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:47) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :235) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :177) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253) at org.apache.cocoon.Cocoon.process(Cocoon.java:699) at org.apache.cocoon.servlet.Cocoo
Re: pipelineComponent scope troubles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: >> >> Grzegorz Kossakowski wrote: >>> >> >> >> >> >> Is that causing the troubles? > > Yes, I'm almost sure that's the reason why pipelineComponent scope is > freaking. Guess what ;-) didn't help removing all map:mount from the sitemap. Exception still exists and I have still no clue what has caused this incompatability with existing code. > Both cocoon: source and are considered old-fashioned if we have > Servlet Service > Framework that does the same in more clear and powerful way. Independently > from our preferences, we > need to support both cocoon: and , obviously. In order to provide > back-compatibility we > need to implement sitemap scope (see COCOON-2099). > If you are going to make effort of implementing this scope, don't forget to > assign that issue to > yourself. I unassigned it because my list of assigned issues is already long > and I'm overwhelmed > with other affairs. To be honest, I see no reason for me to dig into something I have not a single clue where to look at. But still questioning who has put this backward incompatability into it and how to migrate from it. > If you want to make a quick test if it's the only problem with current trunk > and work-around NPE > mentioned by you just change scope of ObjectModel from "pipelineComponent" to > "call" in this > file[1]. Be warned that it's only a quick work-around and implementation of > sitemap scope is the > only reliable solution. Uhh, this give a even more ugly stacktrace (deep into template, el, and jexl) I wouldn't even think of pasting it into this mail. > HTH. Unfortunately it didn't at all! > [1] > http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG5n2kLNdJvZjjVZARAk5HAKCfC+Hfr5kDy8FCzbJLfCcYIyVOugCgsZzL Dlm9N6TITh9tfjAyvflMpzY= =6XNV -END PGP SIGNATURE-
