Docs for 2.1.10
Could someone please assemble the docs archive for the 2.1.10 release? Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Docs for 2.1.10
On 12/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Could someone please assemble the docs archive for the 2.1.10 release? The generated docs are available as a tar.gz archive from the cocoon-docs.tar.gz direct download link at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate, IIUC this is what we ship with the release. Were you thinking of something else? -Bertrand
Re: Trunk does not compile (pipeline refactoring related?)
I got the same problem after I update from svn.And I never build svn successfully. roy huang
Re: Docs for 2.1.10
Bertrand Delacretaz wrote: On 12/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Could someone please assemble the docs archive for the 2.1.10 release? The generated docs are available as a tar.gz archive from the cocoon-docs.tar.gz direct download link at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate, IIUC this is what we ship with the release. Were you thinking of something else? Thanks Bertrand, this is exactly what I'm looking for. Is the download up to date? Or do I have to follow the procedure mentioned there? Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Docs for 2.1.10
On 12/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...this is exactly what I'm looking for. Is the download up to date? Or do I have to follow the procedure mentioned there?.. According to http://forrest.zones.apache.org/, the docs are built every twelve hours, and the file dates in the archive contents confirm this. -Bertrand
Re: Docs for 2.1.10
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: On 12/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Could someone please assemble the docs archive for the 2.1.10 release? The generated docs are available as a tar.gz archive from the cocoon-docs.tar.gz direct download link at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate, IIUC this is what we ship with the release. Were you thinking of something else? Thanks Bertrand, this is exactly what I'm looking for. Is the download up to date? Or do I have to follow the procedure mentioned there? The download mentioned on that site is generated by Forrest every 12 hours. You only need to update the site manually if you don't want to wait for the next automated update. You can preview what is in the download by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html You can also verify that there are no broken links by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml (it should be empty of course). Ross
Re: Docs for 2.1.10
Ross Gardler schrieb: Carsten Ziegeler wrote: Bertrand Delacretaz wrote: On 12/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Could someone please assemble the docs archive for the 2.1.10 release? The generated docs are available as a tar.gz archive from the cocoon-docs.tar.gz direct download link at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate, IIUC this is what we ship with the release. Were you thinking of something else? Thanks Bertrand, this is exactly what I'm looking for. Is the download up to date? Or do I have to follow the procedure mentioned there? The download mentioned on that site is generated by Forrest every 12 hours. You only need to update the site manually if you don't want to wait for the next automated update. You can preview what is in the download by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html You can also verify that there are no broken links by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml (it should be empty of course). Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Docs for 2.1.10
Carsten Ziegeler wrote: Ross Gardler schrieb: ... Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Fairly important I suppose... http://cocoon.zones.apache.org/daisy/documentation/659.html Ross
FORTRESS-22: may effect people using AJAX block
Hi,
I've just filed this issue against Excalibur:
https://issues.apache.org/jira/browse/FORTRESS-22
ResourceSource.getInfos() leaves URLConnection open, resulting in
'too may open files' condition
This affected us on a busy live system serving dojo files from the jar
in the ajax block; it's really dependent on how often GC kicks in, how
busy your server is (serving ajax-using pages), and how many descriptors
you've got per-process. It doesn't matter if the pipeline is cached or
uncached, the validity checking is enough to trigger the 'leak'.
A configuration 'glitch' meant we had only 1024 file-descriptors
available, which meant we hit this bug earlier than we might otherwise
have. A work-around (other than to increase the number of
file-descriptors and keep your fingers crossed) is to pick up files
directly from where they are automatically de-archived:
map:match pattern=resources/*/**
map:select type=resource-exists
map:when test={0}
map:read src={0}
map:parameter name=byte-ranges
value=false/
/map:read
/map:when
!-- test to see if resource has already been
unarchived (saves file-descriptors); tomcat specific --
map:when
test={system-property:catalina.base}/work/contexts/localhost/_/loader/org/apache/cocoon/{1}/resources/{2}
map:read
src={system-property:catalina.base}/work/contexts/localhost/_/loader/org/apache/cocoon/{1}/resources/{2}
map:parameter name=byte-ranges
value=false/
/map:read
/map:when
map:otherwise
!-- read resource from classpath --
map:read
src=resource://org/apache/cocoon/{1}/resources/{2}
map:parameter name=byte-ranges
value=false/
/map:read
/map:otherwise
/map:select
/map:match
That is, if possible, the files are picked up from the work directory,
relative to catalina.base, rather than the jar. This will have to be
adapted for other containers, unless there's some other way to do it (I
don't think there's a context input-module so I can get at
work-directory parameter?).
Hope this is useful to someone else!
Ellis.
Re: Docs for 2.1.10
Ross Gardler wrote: Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Fairly important I suppose... http://cocoon.zones.apache.org/daisy/documentation/659.html Hmm, that does not look like the docs I find at http://cocoon.apache.org/2.1/ Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Docs for 2.1.10
Carsten Ziegeler said the following on 21/12/06 12:38: Ross Gardler wrote: Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Fairly important I suppose... http://cocoon.zones.apache.org/daisy/documentation/659.html Hmm, that does not look like the docs I find at http://cocoon.apache.org/2.1/ If you haven't found it yet: the Legacy docs in Daisy are the current 2.1 docs. It starts about here: http://cocoon.zones.apache.org/daisy/legacydocs/about/index.html Bye, Helma
Re: getComponent with JavaFlow 2.1.9
Sorry I am not sure if I missed the answer to the questions. But this is very
important information for us so I will ask them again.
Is the version of Java Flow in 2.1.10 an updated version?
Is the updated version only in 2.2.0? If so can it be back ported to 2.1.10?
Thanks,
Doug
-Original Message-
From: [EMAIL PROTECTED]
To: dev@cocoon.apache.org
Sent: Wed, 13 Dec 2006 3:51 AM
Subject: Re: getComponent with JavaFlow 2.1.9
Thanks all for your inputs.
2.1.9 is the latest released version, that's why I am using it. I didn't know
javaflow version there was quite old.
Do I have to grab the javaflow block from the 2.2.0 and use it ?
Or wait for the 2.1.10 release which will contain an updated version of
javaflow ?
Cheers,
Nicolas
Torsten Curdt a écrit :
Please note that javaflow in 2.1.9 is a quite old version
...unless I missed that someone updated it.
cheers
-- Torsten
On 12/13/06, Bart Molenkamp [EMAIL PROTECTED] wrote:
I've had problems with JavaFlow and classes compiled with debug
information (in Eclipse). You could try to compile without debug
information, and see if it works.
Bart.
-Oorspronkelijk bericht-
Van: Nicolas BOUSSUGE [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 13 december 2006 10:00
Aan: dev@cocoon.apache.org
Onderwerp: getComponent with JavaFlow 2.1.9
Hello,
The users list was maybe not the appropriate list to post my message.
This seems to be a known bug of JavaFlow, according to the TODO.txt
I
saw in the javaflow source.
Have the mentionned patches been applied to the jakarta-bcel project
in
the 2.1.10 upcoming release ?
Is there a trick to get it to work with the current version ?
Thanks a lot
Best Regards,
Nicolas
Nicolas BOUSSUGE a écrit :
Hello,
I got the following problem in JavaFlow (Cocoon 2.1.9) when trying
to
lookup a custom component :
Instruction GETSTATIC constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may
be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 1: getstatic[178](3) 15
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4.
com.test.flow.java.AdminFlow (Size: 1) Execution flow: 0: aload_0
[InstructionContext] 1: getstatic 15 [InstructionContext]
Then I replaced the lookup as suggested by Torsten in a message on
the
mailing list (use a literal String instead of the ROLE), which
results
in the following exception :
Instruction CHECKCAST constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may
be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 6: checkcast[192](3) 21
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4. java.lang.Object
(Size: 1) Execution flow: 0: aload_0 [InstructionContext] 1: ldc 15
[InstructionContext] 3: invokevirtual 17 [InstructionContext] 6:
checkcast 21 [InstructionContext]
Is that a known bug of JavaFlow ? Or did I do something wrong ?
My webapp is running under Tomcat 5.5.20.
Thanks a lot.
Regards,
Nicolas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- ---
Nicolas BOUSSUGE
Atos Origin - Agence Sud-Ouest
18 av de l escadrille Normandie-Niemen BP 20
31701 Blagnac Cedex
Bureau : 05.62.74.59.69
Télécopie: 05.62.74.59.00
mailto :[EMAIL PROTECTED]
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam
and email virus protection.
Re: getComponent with JavaFlow 2.1.9
Is the version of Java Flow in 2.1.10 an updated version? No, I don't think anyone bothered backporting. Is the updated version only in 2.2.0? If so can it be back ported to 2.1.10? Yes, 2.2 has the current version. cheers -- Torsten
Re: Docs for 2.1.10
Helma wrote: If you haven't found it yet: the Legacy docs in Daisy are the current 2.1 docs. It starts about here: http://cocoon.zones.apache.org/daisy/legacydocs/about/index.html Thanks Helma, that's exactly what I was looking for. I looked in most docs in Daisy except the legacy stuff... Thanks! Carsten
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/ cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/ cocoon-common/src/mai
danielf wrote: Author: danielf Date: Wed Dec 20 15:35:57 2006 New Revision: 489224 URL: http://svn.apache.org/viewvc?view=revrev=489224 Log: Further work on splitting the core so that it becomes layered. Created a number of new modules: * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies. * cocoon-configuration - The Settings interface and implementation. * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes. * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above. Hmm, I'm not sure but it seems to me that this is the far opposite to our old monolithic structure. What is the difference between common and util? We should rethink our environment abstraction as well. As we have discussed in the past, it would make sense to forget about it and use the servlet api instead. So I think we should not make this available in a separate module which will be obsolete soon again. What about adding this to the pipeline api? Carsten
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/ cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/ cocoon-common/src/mai
Carsten Ziegeler skrev: danielf wrote: Author: danielf Date: Wed Dec 20 15:35:57 2006 New Revision: 489224 URL: http://svn.apache.org/viewvc?view=revrev=489224 Log: Further work on splitting the core so that it becomes layered. Created a number of new modules: * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies. * cocoon-configuration - The Settings interface and implementation. * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes. * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above. Hmm, I'm not sure but it seems to me that this is the far opposite to our old monolithic structure. I agree that the current split is a little bit to fine grained. I started by just factoring out a pipeline implementation, but there are so many interdependencies so it didn't work that well. My current idea is to continue splitting up the core with the goal of making the core layered so that the pipeline can be used separately without needing to include all of the tree-processor code. This will lead to more modules than what we would like to have in the end. But it will make it clear how everything is connected. Then in a next step we can start refactoring things so that we get rid of unnecessary dependencies. And after that we probably can merge some of the modules. It will also be much easier for us to see and be able to discuss about what layers we want Cocoon to be split into. So see the current split as a temporary state, (and be prepared on that it will become even worse ;) ) What is the difference between common and util? Probably not that much. It might be that common, configuration and util should be merged. We should rethink our environment abstraction as well. As we have discussed in the past, it would make sense to forget about it and use the servlet api instead. Agree. So I think we should not make this available in a separate module which will be obsolete soon again. What about adding this to the pipeline api? I made the environment a separate module as both pipeline and the container code depends on it. Otherwise it would be unclear if the pipeline should depend on the container or the opposite way around. If we can get rid of the dependency of the container on the environment, we could merge the environment ant the pipeline module. == So please bear with a too fine grained splitting of the core during a short period. It shouldn't affect use of Cocoon during that period as cocoon-core will depend on all that is needed. If we don't do enough progress into splitting Cocoon core in reasonable layers, it is very easy to merge everything together again. /Daniel
[2.2] NPE when using block: protocol, caused by a ResourceNotFoundException
Hi, While using the block: protocol, I got NullPointerExceptions because a resource could not be found in the target block. This was due to a ResourceNotFoundException, and when Cocoon tries to report the exception, the NPE occurs. It seems that the outputStream member is null. Has anybody any idea where this should be set? The exception is quite confusing, because I can't see the original ResourceNotFoundException. Here is the stacktrace: java.lang.NullPointerException at org.apache.cocoon.blocks.util.BlockCallHttpServletResponse$1.write(Block CallHttpServletResponse.java:158) at java.io.OutputStream.write(OutputStream.java:99) at java.io.OutputStream.write(OutputStream.java:58) at org.apache.cocoon.components.notification.Notifier.notifyHTML(Notifier.j ava:104) at org.apache.cocoon.components.notification.Notifier.notify(Notifier.java: 49) at org.apache.cocoon.servlet.RequestProcessor.manageException(RequestProces sor.java:306) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java :176) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:461) at org.apache.cocoon.blocks.BlockContext$NamedDispatcher.forward(BlockConte xt.java:404) at org.apache.cocoon.blocks.BlockConnection.getInputStream(BlockConnection. java:115) at org.apache.cocoon.blocks.components.BlockSource.getInputStream(BlockSour ce.java:51) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:32 7) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy4.generate(Unknown Source) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe line.processReader(AbstractCachingProcessingPipeline.java:878) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:429) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy3.process(Unknown Source) at org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadN ode.java:94) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(Matc hNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:152) 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:239) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:170) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:233) at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java :377) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java :155) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:461) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:443) at org.apache.cocoon.blocks.BlockServlet.service(BlockServlet.java:123) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.DispatcherServlet.service(DispatcherServlet.jav a:128) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/ cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/ cocoon-common/src/mai
Hi Daniel, thanks for the explanations. I'm fine with that approach and wait for further things to come :) Carsten Daniel Fagerstrom wrote: Carsten Ziegeler skrev: danielf wrote: Author: danielf Date: Wed Dec 20 15:35:57 2006 New Revision: 489224 URL: http://svn.apache.org/viewvc?view=revrev=489224 Log: Further work on splitting the core so that it becomes layered. Created a number of new modules: * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies. * cocoon-configuration - The Settings interface and implementation. * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes. * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above. Hmm, I'm not sure but it seems to me that this is the far opposite to our old monolithic structure. I agree that the current split is a little bit to fine grained. I started by just factoring out a pipeline implementation, but there are so many interdependencies so it didn't work that well. My current idea is to continue splitting up the core with the goal of making the core layered so that the pipeline can be used separately without needing to include all of the tree-processor code. This will lead to more modules than what we would like to have in the end. But it will make it clear how everything is connected. Then in a next step we can start refactoring things so that we get rid of unnecessary dependencies. And after that we probably can merge some of the modules. It will also be much easier for us to see and be able to discuss about what layers we want Cocoon to be split into. So see the current split as a temporary state, (and be prepared on that it will become even worse ;) ) What is the difference between common and util? Probably not that much. It might be that common, configuration and util should be merged. We should rethink our environment abstraction as well. As we have discussed in the past, it would make sense to forget about it and use the servlet api instead. Agree. So I think we should not make this available in a separate module which will be obsolete soon again. What about adding this to the pipeline api? I made the environment a separate module as both pipeline and the container code depends on it. Otherwise it would be unclear if the pipeline should depend on the container or the opposite way around. If we can get rid of the dependency of the container on the environment, we could merge the environment ant the pipeline module. == So please bear with a too fine grained splitting of the core during a short period. It shouldn't affect use of Cocoon during that period as cocoon-core will depend on all that is needed. If we don't do enough progress into splitting Cocoon core in reasonable layers, it is very easy to merge everything together again. /Daniel -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: getComponent with JavaFlow 2.1.9
Can someone give some input as to what would be involved in back porting the Java Flow code to the 2.1.10 code base? For my project at least 2.2 is worlds away. Thanks, Doug -Original Message- From: [EMAIL PROTECTED] To: dev@cocoon.apache.org Sent: Thu, 21 Dec 2006 7:24 AM Subject: Re: getComponent with JavaFlow 2.1.9 Is the version of Java Flow in 2.1.10 an updated version? No, I don't think anyone bothered backporting. Is the updated version only in 2.2.0? If so can it be back ported to 2.1.10? Yes, 2.2 has the current version. cheers -- Torsten Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/ cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/ cocoon-common/src/mai
Carsten Ziegeler wrote:
Hi Daniel,
thanks for the explanations. I'm fine with that approach and wait for
further things to come :)
+1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] NPE when using block: protocol, caused by a ResourceNotFoundException
Hi Bart, I had the same problem and fixed it with a patch: https://issues.apache.org/jira/browse/COCOON-1954 Unfortunately it is not committed yet, because it was unclear if this might break some specific old problem. The problem is that the original exception is swallowed, so the called block tries to write the error page into the blockconnection stream, which is not possible due to a difficult (and currently wrong) implementation of BlockCallHttpServletResponse.reset(). But this is no problem, since the caller (the calling block) cannot handle the error page anyway, it might be expecting xml anyway. So the exception should be passed on so that it is catched in the exception handler of the calling block - which then can write the error page into the response to the browser. Alex Bart Molenkamp schrieb: Hi, While using the block: protocol, I got NullPointerExceptions because a resource could not be found in the target block. This was due to a ResourceNotFoundException, and when Cocoon tries to report the exception, the NPE occurs. It seems that the outputStream member is null. Has anybody any idea where this should be set? The exception is quite confusing, because I can't see the original ResourceNotFoundException. Here is the stacktrace: java.lang.NullPointerException at org.apache.cocoon.blocks.util.BlockCallHttpServletResponse$1.write(Block CallHttpServletResponse.java:158) at java.io.OutputStream.write(OutputStream.java:99) at java.io.OutputStream.write(OutputStream.java:58) at org.apache.cocoon.components.notification.Notifier.notifyHTML(Notifier.j ava:104) at org.apache.cocoon.components.notification.Notifier.notify(Notifier.java: 49) at org.apache.cocoon.servlet.RequestProcessor.manageException(RequestProces sor.java:306) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java :176) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:461) at org.apache.cocoon.blocks.BlockContext$NamedDispatcher.forward(BlockConte xt.java:404) at org.apache.cocoon.blocks.BlockConnection.getInputStream(BlockConnection. java:115) at org.apache.cocoon.blocks.components.BlockSource.getInputStream(BlockSour ce.java:51) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:32 7) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy4.generate(Unknown Source) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe line.processReader(AbstractCachingProcessingPipeline.java:878) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:429) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy3.process(Unknown Source) at org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadN ode.java:94) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(Matc hNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:152) 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:239) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:170) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:233) at
Re: getComponent with JavaFlow 2.1.9
Can someone give some input as to what would be involved in back porting the Java Flow code to the 2.1.10 code base? For my project at least 2.2 is worlds away. Well, in 2.2 we use a different approach in regards to the integration. (via jci) For various reasons the rewriting is not done by the classloader anymore. (but via jci) So the javaflow classes themself can probably stay untouched ...but in 2.2 this is all integrated with the auto-reloading. So basically you would have to backport that as well to get the same behavior and features. What should be possible is to just use the commons javaflow library with the old integration though. Should be reasonable simple. I would have to dig into the code to work out some action items though. Has been ages since I last looked at 2.1. cheers -- Torsten
Re: Trunk does not compile (pipeline refactoring related?)
Daniel Fagerstrom napisał(a): The trunk is supposed to be compilable at all times. It compiles for me. From the error messages it seem like the cocoon-core dependency on cocoon-pipeline-api isn't handled properly. It might be that you need to do a mvn clean or that something isn't updated as it should from svn. It must have been some svn quirk, I've done complete now check-out and everything compiled smoothly. Sorry for the noise. -- Grzegorz Kossakowski
Re: Problem with running cocoon-core-2.2.0-M2
Grzegorz Kossakowski napisał(a): Hello, [...] After doing some investigation on spring forums it seems that src/main/resources/META-INF/spring.handlers from cocoon-core is not being seen. What is also interesting, jar of cocoon-core is mentioned two times in classpath. Is it expected situation? Any hints, clues? I'm not sure what really changed but now it works without any problems. Blocks responded correctly. Cocoons' jars are still mentioned in classpath but no I don't have any problem with that (and hopefully won't have) -- Grzegorz Kossakowski
RE: ContextAttributeSelector
Jörg, thanks for your reply. I think I kind of missed that thread. I will have a look into that and possibly convert it to an input module. Regards, Jeroen Reijn -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Posted At: Thursday, December 21, 2006 1:13 AM Posted To: Cocoon Dev List Conversation: ContextAttributeSelector Subject: Re: ContextAttributeSelector Isn't their a thread on the users list about creating generic components using input and output modules for such tasks? Wouldn't be your to-be-donated component one of the first to be deprecated? So what about contributing an InputModuleSelector and a ContextAttributeInputModule ;) Regards Jörg On 20.12.2006 14:32, Jeroen Reijn wrote: Hi all, for one of our project I needed to create selector that could read attributes from the current context (ContextAttributeSelector). I would like to donate the selector. Is there any interest in such a selector or should I just provide the patch in JIRA? Kind regards, Jeroen Reijn
RE: ContextAttributeSelector
Mark, the improved sitemap looks very interesting. I guess that the ServletContext.. is a better name for the component. I've modified some code so it would still fit into cocoon without getting deprecated ;-) I'll test it some more and send in the InputModule tonight. Kind regards, Jeroen Reijn -Original Message- From: Mark Lundquist [mailto:[EMAIL PROTECTED] Posted At: Thursday, December 21, 2006 5:21 AM Posted To: Cocoon Dev List Conversation: ContextAttributeSelector Subject: Re: ContextAttributeSelector On Dec 20, 2006, at 4:13 PM, Joerg Heinicke wrote: Isn't their a thread on the users list about creating generic components using input and output modules for such tasks? Wouldn't be your to-be-donated component one of the first to be deprecated? If I get my way [1], all matchers and selectors as we know them now will be deprecated :-). I hope to contribute that code fairly soon. So what about contributing an InputModuleSelector and a ContextAttributeInputModule ;) We have today an input module selector, it's called SimpleSelector (hopefully, soon also to be deprecated! :-). But a ContextAttributeInputModule would certainly be appreciated. (Would ServletContextInputModule be a better name?) —ml— [1] http://marc.theaimsgroup.com/?t=11651813411r=1w=2
[jira] Created: (COCOON-1974) Donating ContextAttributeInputModule
Donating ContextAttributeInputModule Key: COCOON-1974 URL: http://issues.apache.org/jira/browse/COCOON-1974 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Jeroen Reijn Priority: Minor Attachments: CAIM.cocoon.xconf.patch, ContextAttributeInputModule.java.patch I was in need of something like this, so I created the ContextAttribute Input module. I would like to donate it to the Cocoon project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1974) Donating ContextAttributeInputModule
[ http://issues.apache.org/jira/browse/COCOON-1974?page=all ] Jeroen Reijn updated COCOON-1974: - Attachment: ContextAttributeInputModule.java.patch Donating ContextAttributeInputModule Key: COCOON-1974 URL: http://issues.apache.org/jira/browse/COCOON-1974 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Jeroen Reijn Priority: Minor Attachments: CAIM.cocoon.xconf.patch, ContextAttributeInputModule.java.patch I was in need of something like this, so I created the ContextAttribute Input module. I would like to donate it to the Cocoon project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1974) Donating ContextAttributeInputModule
[ http://issues.apache.org/jira/browse/COCOON-1974?page=all ] Jeroen Reijn updated COCOON-1974: - Attachment: CAIM.cocoon.xconf.patch Donating ContextAttributeInputModule Key: COCOON-1974 URL: http://issues.apache.org/jira/browse/COCOON-1974 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Jeroen Reijn Priority: Minor Attachments: CAIM.cocoon.xconf.patch, ContextAttributeInputModule.java.patch I was in need of something like this, so I created the ContextAttribute Input module. I would like to donate it to the Cocoon project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Docs for 2.1.10
The content is in Daisy, and the Forrestbot on our zone retrieves it from there and generates the docs. This process is then followed to get them on to c.a.o/2.1 http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Take the quick route of unpacking the tar.gz and commit to the cocoon/site SVN. The top-level docs for c.a.o are also explained there. Sorry i cannot help more, going away. -David
[continuum] BUILD ERROR: Pipeline API
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/51/buildId/1173 Build statistics: State: Error Previous State: Failed Started at: Fri, 22 Dec 2006 00:21:20 + Finished at: Fri, 22 Dec 2006 00:21:29 + Total time: 8s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD FAILURE: Cocoon Core
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/31/buildId/1174 Build statistics: State: Failed Previous State: Failed Started at: Fri, 22 Dec 2006 00:22:15 + Finished at: Fri, 22 Dec 2006 00:22:43 + Total time: 27s Build Trigger: Schedule Exit code: 1 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes danielf Moved thread and store components to the thread and store modules. Removed the cocoon-store-api as it isn't needed, the the module implements the Excalibur store api. Moved some util classes that are needed in the store implementation to the util module. /cocoon/trunk/core/cocoon-core/pom.xml /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/store /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/util/IOUtils.java /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/util/StringUtils.java /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/thread /cocoon/trunk/core/cocoon-store/cocoon-store-api /cocoon/trunk/core/cocoon-store/cocoon-store-impl/pom.xml /cocoon/trunk/core/cocoon-store/cocoon-store-impl/src/main/java/org/apache/cocoon/components/store /cocoon/trunk/core/cocoon-store/cocoon-store-impl/src/main/java/org/apache/cocoon/components/store/impl (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/store/impl:489440) /cocoon/trunk/core/cocoon-store/pom.xml /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/pom.xml /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/src/main/java/org/apache/cocoon/components/thread /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/src/main/java/org/apache/cocoon/components/thread/Queue.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread/Queue.java:489440) /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/src/main/java/org/apache/cocoon/components/thread/RunnableManager.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread/RunnableManager.java:489440) /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/src/main/java/org/apache/cocoon/components/thread/ThreadFactory.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread/ThreadFactory.java:489440) /cocoon/trunk/core/cocoon-thread/cocoon-thread-api/src/main/java/org/apache/cocoon/components/thread/ThreadPool.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread/ThreadPool.java:489440) /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/pom.xml /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/thread:489440) /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/Queue.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/RunnableManager.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/ThreadFactory.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/ThreadPool.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread (from /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/thread:489440) /cocoon/trunk/core/cocoon-util/src/main/java/org/apache/cocoon/util/IOUtils.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/util/IOUtils.java:489440) /cocoon/trunk/core/cocoon-util/src/main/java/org/apache/cocoon/util/StringUtils.java (from /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/util/StringUtils.java:489440)
