Re: cocoon 3 and Google appengine
- A dedicated server with single ip address :-) - (no personal experience) but amazon cloud, or any provider who offers virtual machines. that would deliver you the necessary freedom to run servlets of your own choice On Mon, Feb 9, 2015 at 8:58 AM, Wicket und Cocoon hansheinrichbr...@yahoo.de wrote: what is a good place to upload a cocoon application? Am 09.02.2015 um 08:37 schrieb Jos Snellings: Hi, I remember having done some exploratory tests. They date back to 2010 so things might be different. I can confirm that there were problems at the time (cocoon was a nogo). The root cause seemed to be that certain basic classes are forbidden in AppEngine. AppEngine does not want you to take control on a very low level. Cheers, Jos On Mon, Feb 9, 2015 at 8:32 AM, Wicket und Cocoon hansheinrichbr...@yahoo.de wrote: i am evaluating to transfer my applications to Google Cloud. Is it a good idea and is there already some experience with it. Regards Heiner -- Confucius said way too much ... -- Confucius said way too much ...
Re: cocoon 3 and Google appengine
Hi, I remember having done some exploratory tests. They date back to 2010 so things might be different. I can confirm that there were problems at the time (cocoon was a nogo). The root cause seemed to be that certain basic classes are forbidden in AppEngine. AppEngine does not want you to take control on a very low level. Cheers, Jos On Mon, Feb 9, 2015 at 8:32 AM, Wicket und Cocoon hansheinrichbr...@yahoo.de wrote: i am evaluating to transfer my applications to Google Cloud. Is it a good idea and is there already some experience with it. Regards Heiner -- Confucius said way too much ...
[jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
[ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713647#comment-13713647 ] Jos Snellings commented on COCOON3-126: --- True, so here is a solution that uses the injection in cocoon-sitemap. Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: cocoon3-126.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
[ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-126: -- Attachment: CachingXSLTTransformer.java The XLSTTransformer with internal LRU cache. Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, cocoon-sax-COCOON3-126.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
[ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-126: -- Attachment: cocoon-sitemap-COCOON3-126-2.patch Changes to PrototypePipelineComponentFactory Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, cocoon-sax-COCOON3-126.patch, cocoon-sitemap-COCOON3-126-1.patch, cocoon-sitemap-COCOON3-126-2.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
[ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-126: -- Attachment: cocoon-sitemap-COCOON3-126-1.patch Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, cocoon-sax-COCOON3-126.patch, cocoon-sitemap-COCOON3-126-1.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: COCOON3-126, xslt cache
Hi Simo (et al), 1. I do not get the point defining the 'cache' interface. The simplest would be to allow a switch in the constructor: In that case, forget the injection: @Autowire private Settings settings; public XSLTTransformer(boolean enableLRUCache) public XSLTTransformer(final URL url, boolean enableLRUCache) If the behaviour 'without LRU Cache' is only desired from within the sitemap, the first constructor is enough. The parameter can be passed through through setConfiguration or setup(). Aren't 'settings' already a part of the cocoon object that comes with the setup parameters. 2. Alternative: create two classes: public class XSLTTransformerLRU extends AbstractSAXTransformer implements CachingPipelineComponent public class XSLTTransformer extends AbstractSAXTransformer implements CachingPipelineComponent I would say: the first is simpler. Cheers, Jos On Tue, Jul 2, 2013 at 11:38 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Jos, the most important thing is IMHO having the XSLT transformer dependencies-less as much as we can - I suggest to define a cache interface (with a basic implementation) provided to XSLT transformer (via constructor), then users are free to use whatever implementation they need/prefer. Having a default implementation would be a strict constraint, while users should be able to plug their integration module depending to their use case. Does it sound reasonable? I have ~0 spare cycles to OSS ATM, but I promise to have a look at your patch during the WE, so I can at least provide you more feedbacks. Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings jos.snelli...@upperware.biz wrote: Hi Francesco et al, I proposed a patch for COCOON3-126, on the configurability of using an LRU cache for xslt transformations. I am not too happy with it though. I would like to have a member function to set isCacheEnabled, or to set this at setup. However, the resource is loaded in the constructor. Would it be better to add a boolean isCacheEnabled' to a constructor, leaving the default to yes? What do you think? Kind regards, Jos -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: [jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
I completely agree ! (see also Simo's idea) On Wed, Jul 3, 2013 at 12:30 AM, Thorsten Scherler (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698330#comment-13698330] Thorsten Scherler commented on COCOON3-126: --- I do not think it is a good idea to use the spring injection here. Have a look at http://svn.apache.org/viewvc?view=revisionrevision=r1447255 I think passing the config via parameter is much more flexible and do not force to use spring. Can you attach a patch that is more in the spirit of the commit I linked above? Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: cocoon3-126.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: COCOON3-126, xslt cache
Yes, Simo, that is a good approach! I think it is worth the work in order to keep the cocoon base classes tidy. We can work out a proposal during the weekend, (though it will be very nice weather in Belgium). Cheers, Jos On Tue, Jul 2, 2013 at 11:38 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Jos, the most important thing is IMHO having the XSLT transformer dependencies-less as much as we can - I suggest to define a cache interface (with a basic implementation) provided to XSLT transformer (via constructor), then users are free to use whatever implementation they need/prefer. Having a default implementation would be a strict constraint, while users should be able to plug their integration module depending to their use case. Does it sound reasonable? I have ~0 spare cycles to OSS ATM, but I promise to have a look at your patch during the WE, so I can at least provide you more feedbacks. Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings jos.snelli...@upperware.biz wrote: Hi Francesco et al, I proposed a patch for COCOON3-126, on the configurability of using an LRU cache for xslt transformations. I am not too happy with it though. I would like to have a member function to set isCacheEnabled, or to set this at setup. However, the resource is loaded in the constructor. Would it be better to add a boolean isCacheEnabled' to a constructor, leaving the default to yes? What do you think? Kind regards, Jos -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: COCOON3-126, xslt cache
Yet, as a Roman, you enjoy a different likelihood for sunny weather :-). Nonetheless, getting inspiration is very important! Jos On Tue, Jul 2, 2013 at 1:12 PM, Simone Tripodi simonetrip...@apache.orgwrote: We can work out a proposal during the weekend, (though it will be very nice weather in Belgium). we are having sunny days in Rome as well (finally!) so I'll do some work in the night on the terrace :) have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
[jira] [Created] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
Jos Snellings created COCOON3-126: - Summary: Make configurable whether xslt transformer component uses LRU cache or not Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not
[ https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-126: -- Attachment: cocoon3-126.patch Patch solving the issue from xslt transformer alone. Not too happy with it: Should it not be chosen in cocoon-sitemap if an lru cache is to be used? Leave it up to you. Make configurable whether xslt transformer component uses LRU cache or not -- Key: COCOON3-126 URL: https://issues.apache.org/jira/browse/COCOON3-126 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: cocoon3-126.patch The XSLT pipeline component should be aware of the following setting in configurator:settings configurator:property name=org.apache.cocoon.sax.lrucache-enabled value=true|false|True|False/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Use LRU cache
Hi, Just reported the issue and proposed a patch, though I am not very happy with it. + : it intervenes only in cocoon-sax - : it introduces a new dependency (on spring). Question: would it be better to decide in cocoon-sitemap if an LRU cache is used? The constructor would have an extra parameter then. the template is loaded (or not) in the constructor, which is a bit early. What do you think? Cheers, Jos -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: Getting Exception.getMessage in map:handle-errors
Hi Ivan, Please try : jexl:cocoon.exception.messsage I don't have my cocoon environment handy here, but odds are good that it works. Jos On Wed, Apr 17, 2013 at 5:35 PM, Ivan Lagunov lagi...@gmail.com wrote: Hello, ** ** Is it possible to access fields of the thrown Exception inside map:handle-errors? ** ** I want to do something like this: map:handle-errors map:select type=exception map:when test=processing map:generate src=page/exception.jx type=jx map:parameter name=errorMessage value=want to extract Exception.getMessage() here/ /map:generate map:serialize type=xhtml/ /map:when /map:select /map:handle-errors ** ** Where selector is defined as following: map:selector name=exception src=org.apache.cocoon.selection.ExceptionSelector exception name=processing class=org.apache.cocoon.ProcessingException/ /map:selector ** ** Any ideas how to achieve this? ** ** Best regards, Ivan Lagunov ** ** ** ** -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: [DISCUSS] Fix for COCOON3-105
In shorthand: What are the implications then? Bottomline: - a block context is addressable within the sitemap load resource from another block context is possible via 'classpath'. The root of every block is available on the classpath? - different web applications relying on cocoon3 can deploy blocks with the same name they won't interfere with each other? Best, Jos On Fri, Dec 7, 2012 at 12:56 PM, Robby Pelssers robby.pelss...@nxp.comwrote: I might have time to check this weekend but I can't guarantee it. Robby -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Friday, December 07, 2012 12:50 PM To: dev@cocoon.apache.org Subject: Re: [DISCUSS] Fix for COCOON3-105 Hi all, any reaction on this? Shall I just apply such huge patch without anyone else's confirmation??!? Regards. On 03/12/2012 16:38, Francesco Chicchiriccò wrote: Hi all, I have finally elaborated a fix for COCOON3-105 and now I am able to run more C3-based webapps in the same servlet container. I have also added a comment explaining the way I have fixed the issue: as you can see, it is a considerable change, so I'd like to get your feedback before applying. Please take a look and let me know. Regards. On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian. jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1 3508800#comment-13508800 ] Francesco Chicchiriccò commented on COCOON3-105: Please evaluate the attached patch (COCOON3-105.patch). The patch is quite pervasive and I've seen that it might also cause some troubles when applying: if you find any .rej or .orig files (after application), please remove. This patch basically removes any reference to the blockcontext:/ protocol - as you can see there is no more dependency on cocon-block-deployment. The blockcontext:/ protocol has been replaced by a classpath:/ protocol implementation, working together with the JVM's jar:/ protocol. I have also prepared a demo project for this [1]: after having mvn clean install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and compile by running mvn clean package then launch via mvn cargo:run You will get an Apache Tomcat instance listening on containing two distinct C3 webapps; access URLs are http://localhost:/mywebapp/ http://localhost:/mywebapp2/mysite/ http://localhost:/mywebapp2/mysite2/ e.g. 3 distinct blocks across 2 distinct webapps. Please note that this fix should also work for C2.2, as far as the ClasspathURLStreamHandlerFactory class is provided - I've put this class in cocoon-servlet but we can think to move it to cocoon-servlet-service-impl, for example. [1] https://github.com/ilgrosso/cocoon3EmptyProject webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running - Key: COCOON3-105 URL: https://issues.apache.org/jira/browse/COCOON3-105 Project: Cocoon 3 Issue Type: Bug Components: cocoon-webapp Affects Versions: 3.0.0-beta-1 Reporter: Thorsten Scherler Assignee: Francesco Chicchiriccò Priority: Blocker Fix For: 3.0.0-beta-1 Attachments: COCOON3-105.npe.diff, COCOON3-105.patch, COCOON3-105.patch, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch I noticed that you cannot run 2 c3 based war in a tomcat. To reproduce: - seed parent via archetype - seed block in parent via archetype - seed block2 in parent via archetype - seed webapp in parent via archetype - seed webapp2 in parent via archetype where webapp depends on block one and webapp2 depends on block2. My sample was: [INFO] Reactor Summary: [INFO] [INFO] myparent .. SUCCESS [1.163s] [INFO] myblock ... SUCCESS [3.611s] [INFO] mywebapp .. SUCCESS [1.924s] [INFO] myblock2 .. SUCCESS [1.498s] [INFO] mywebapp2 . SUCCESS [1.230s] [INFO] Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it before you start to webapp or if you have it enable deploy it on a running instance. You should see the welcome page under something like http://localhost:8080/mywebapp-1.0-SNAPSHOT/ side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a StringIndexOutOfBoundsException but that is another ticket I
Re: avalon version
Hi Francesco,
This is my problem: I use FOP, and that is where the problem arises:
Path to dependency:
1) org.herein:thesaurus:jar:1.0.0-SNAPSHOT
2) org.apache.xmlgraphics:fop:jar:LATEST
3) org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
Jos
On Mon, Oct 22, 2012 at 9:11 AM, Francesco Chicchiriccò ilgro...@apache.org
wrote:
On 22/10/2012 07:50, Jos Snellings wrote:
Dear cocooners,
Since today, it is not possible to package cocoon 3 apps via maven
anymore.
Build is requesting:
org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
as well as its implementation.
Who still needs avalon?
- jnet
- fop
- ... are there others?
Latest version of Avalon I can get is 4.3.1
Maven is having trouble getting version 4.2.0.
Which version of C3 are you running?
Latest snapshots (3.0.0-beta-1-SNAPSHOT) don't suffer from this at all:
find ~/.m2/ -name '*avalon*' -exec rm -rf {} \;
. it.sh
...
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Cocoon 3: Parent ... SUCCESS [5.524s]
[INFO] Apache Cocoon 3: Utilities SUCCESS [2.710s]
[INFO] Apache Cocoon 3: Pipeline . SUCCESS [1.445s]
[INFO] Apache Cocoon 3: SAX .. SUCCESS [6.711s]
[INFO] Apache Cocoon 3: CLI .. SUCCESS [2.794s]
[INFO] Apache Cocoon 3: Sitemap .. SUCCESS [1.863s]
[INFO] Apache Cocoon 3: Controller ... SUCCESS [0.757s]
[INFO] Apache Cocoon 3: Servlet .. SUCCESS [1.137s]
[INFO] Apache Cocoon 3: Optional . SUCCESS [7.556s]
[INFO] Apache cocoon 3: Databases integration components . SUCCESS [1.023s]
[INFO] Apache Cocoon 3: Monitoring ... SUCCESS [3.784s]
[INFO] Apache Cocoon 3: REST support . SUCCESS [2.261s]
[INFO] Apache Cocoon 3: Profiling SUCCESS [1.546s]
[INFO] Apache cocoon 3: Optional REST components . SUCCESS [2.826s]
[INFO] Apache Cocoon 3: String Templates . SUCCESS [1.713s]
[INFO] Apache Cocoon 3: Shiro integration SUCCESS [1.062s]
[INFO] Apache Cocoon 3: StAX . SUCCESS [2.237s]
[INFO] Apache Cocoon 3: Wicket Integration ... SUCCESS [1.076s]
[INFO] Apache Cocoon 3: All dependencies . SUCCESS [1.017s]
[INFO] Apache Cocoon 3: Databases sample integration . SUCCESS [1.428s]
[INFO] Apache Cocoon 3: Sample ... SUCCESS
[21.878s]
[INFO] Apache Cocoon 3: Shiro sample integration . SUCCESS [1.480s]
[INFO] Apache Cocoon 3: Webapplication sample SUCCESS
[34.077s]
[INFO] Apache Cocoon 3: Wicket Integration Webapp Sample . SUCCESS [2.606s]
[INFO] Apache Cocoon 3: Block Archetype .. SUCCESS [2.493s]
[INFO] Apache Cocoon 3: Parent Archetype . SUCCESS [0.508s]
[INFO] Apache Cocoon 3: Sample Archetype . SUCCESS [3.447s]
[INFO] Apache Cocoon 3: Web Application Archetype SUCCESS [0.691s]
[INFO] Apache Cocoon 3: Root . SUCCESS [0.092s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:59.295s
[INFO] Finished at: Mon Oct 22 09:03:05 CEST 2012
[INFO] Final Memory: 83M/500M
[INFO]
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
--
All generous minds have a horror of what are commonly called Facts. They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes
http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: avalon version
All OK!
Maven got confused over fop dependencies. After removing a few frameworks
from the repositories it finds its way back.
All builds well now.
Thanks Francesco,
Jos
On Mon, Oct 22, 2012 at 9:11 AM, Francesco Chicchiriccò ilgro...@apache.org
wrote:
On 22/10/2012 07:50, Jos Snellings wrote:
Dear cocooners,
Since today, it is not possible to package cocoon 3 apps via maven
anymore.
Build is requesting:
org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
as well as its implementation.
Who still needs avalon?
- jnet
- fop
- ... are there others?
Latest version of Avalon I can get is 4.3.1
Maven is having trouble getting version 4.2.0.
Which version of C3 are you running?
Latest snapshots (3.0.0-beta-1-SNAPSHOT) don't suffer from this at all:
find ~/.m2/ -name '*avalon*' -exec rm -rf {} \;
. it.sh
...
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Cocoon 3: Parent ... SUCCESS [5.524s]
[INFO] Apache Cocoon 3: Utilities SUCCESS [2.710s]
[INFO] Apache Cocoon 3: Pipeline . SUCCESS [1.445s]
[INFO] Apache Cocoon 3: SAX .. SUCCESS [6.711s]
[INFO] Apache Cocoon 3: CLI .. SUCCESS [2.794s]
[INFO] Apache Cocoon 3: Sitemap .. SUCCESS [1.863s]
[INFO] Apache Cocoon 3: Controller ... SUCCESS [0.757s]
[INFO] Apache Cocoon 3: Servlet .. SUCCESS [1.137s]
[INFO] Apache Cocoon 3: Optional . SUCCESS [7.556s]
[INFO] Apache cocoon 3: Databases integration components . SUCCESS [1.023s]
[INFO] Apache Cocoon 3: Monitoring ... SUCCESS [3.784s]
[INFO] Apache Cocoon 3: REST support . SUCCESS [2.261s]
[INFO] Apache Cocoon 3: Profiling SUCCESS [1.546s]
[INFO] Apache cocoon 3: Optional REST components . SUCCESS [2.826s]
[INFO] Apache Cocoon 3: String Templates . SUCCESS [1.713s]
[INFO] Apache Cocoon 3: Shiro integration SUCCESS [1.062s]
[INFO] Apache Cocoon 3: StAX . SUCCESS [2.237s]
[INFO] Apache Cocoon 3: Wicket Integration ... SUCCESS [1.076s]
[INFO] Apache Cocoon 3: All dependencies . SUCCESS [1.017s]
[INFO] Apache Cocoon 3: Databases sample integration . SUCCESS [1.428s]
[INFO] Apache Cocoon 3: Sample ... SUCCESS
[21.878s]
[INFO] Apache Cocoon 3: Shiro sample integration . SUCCESS [1.480s]
[INFO] Apache Cocoon 3: Webapplication sample SUCCESS
[34.077s]
[INFO] Apache Cocoon 3: Wicket Integration Webapp Sample . SUCCESS [2.606s]
[INFO] Apache Cocoon 3: Block Archetype .. SUCCESS [2.493s]
[INFO] Apache Cocoon 3: Parent Archetype . SUCCESS [0.508s]
[INFO] Apache Cocoon 3: Sample Archetype . SUCCESS [3.447s]
[INFO] Apache Cocoon 3: Web Application Archetype SUCCESS [0.691s]
[INFO] Apache Cocoon 3: Root . SUCCESS [0.092s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:59.295s
[INFO] Finished at: Mon Oct 22 09:03:05 CEST 2012
[INFO] Final Memory: 83M/500M
[INFO]
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
--
All generous minds have a horror of what are commonly called Facts. They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes
http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
avalon version
Dear cocooners, Since today, it is not possible to package cocoon 3 apps via maven anymore. Build is requesting: org.apache.avalon.framework:avalon-framework-api:jar:4.2.0 as well as its implementation. Who still needs avalon? - jnet - fop - ... are there others? Latest version of Avalon I can get is 4.3.1 Maven is having trouble getting version 4.2.0. Kind regards, Jos -- All generous minds have a horror of what are commonly called Facts. They are the brute beasts of the intellectual domain. -- Thomas Hobbes http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: Cocoon Get Together on ACEU 2012 Sinsheim (was Re: Cocoon presentation link and questions about new contributions)
Hi all, I can think of only one real show stopper: the multiple web application deployment issue (block reference/name ambiguity). Are there any others? Kind regards, Jos On Fri, Oct 12, 2012 at 2:14 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 11/10/2012 11:08, Thorsten Scherler wrote: On 10/11/2012 09:22 AM, Francesco Chicchiriccò wrote: On 11/10/2012 00:38, Javier Puerto wrote: ... I hope to see you soon in the ApacheCon, Yep, me too: who's coming??? Chance to have a small Cocoon Get Together (or just a beer) there? Hi all, I was up to write a similar mail asking about a CGT. We from codebusters.es will come in total 4 pers. Andy tries to come as well and Simone and Francesco are there since they are speakers. Meaning we have a pretty strong group and should get together to get some work on cocoon done and directly commit it. ;) Great idea: maybe we'll be able to remove any obstacle for a new C3 release ;-) codebusters.es is right now moving papers to be official sponsor for a CocoonGetTogether on ACEU 2012 so that we could get some drink and food for the hackathon. What is the best day for everyone? I guess Monday 05.11 would be the best day, or? BTW 3 of us will fly in already on 1.11 and the 4th will come on the 4th. We booked a private house in the area and plan to see some sights on the weekend. If somebody is interested in a private house I have some contacts that still may have some space left, further if somebody is interested to get a beer on the weekend before let us talk. ;) -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~**ilgrosso/http://people.apache.org/~ilgrosso/ -- All generous minds have a horror of what are commonly called Facts. They are the brute beasts of the intellectual domain. -- Thomas Hobbes http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html
Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)
Thanks, Thorsten, that makes it a lot clearer.
I will give it a second thought and get back.
Just another question: are there other use cases than:
- within xslt : document() construct
- sitemap
- controller-modelAndView
?
Now that we reanimated the thread, has anyone else ideas? I feel it is an
important issue and I would love to see it solved,
as I have myself two cocoon apps that I would like to deploy to one server.
Kind regards,
Jos
On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler scher...@gmail.comwrote:
On 09/28/2012 07:24 AM, Jos Snellings wrote:
Dear all,
Noticing that is very interesting discussion is getting silent, I'd like
to ask a question.
First of all, pardon me my ignorance. (blonde, can't help it).
So from just a high-level understanding, can I rephrase the problem?
What we seek to accomplish is:
* in a sitemap, being able to load resources from another sitemap,
according to the scheme:
map:generate src=cocoon://{relative-url}/
* within an xslt calling
xsl:variable name=var select='cocoon://{relative-url}' /
* within controller logic: redirect, or send the reference of a
ModelAndView
Well the cocoon:/ is/was never a java.net handler but resolved via
avalon/excalibur. Further the c3 correspond would be more servlet:/
So now, in C3, we want to address resources cross-block to accomplish
modularity, right?
map:generate src={someBlock}://{relative-url}/
well yes and no. blockcontext:/ refers to static (resources) and not
matches in the blockcontext sitemap. If you would want to call the block
sitemap you would request servlet:${blockId}:/...
This should be restricted to the instance of the cocoon servlet itself, so
it can peacefully coexist with another cocoon servlet in the same JVM.
The blockcontext protocol once installed only will work for the first
called servlet. With the change of Fran. we do what you describe but on a
specific point in the app. BUT we never install the protocol which makes it
unusable outside the java route where you can pass a URLHandler to the
context.
So you would like to avoid tweaking URL for the servlet without
interfering with the rest.
- something less invasive than URL.setURLStreamHandlerFactory ?
- mechanism that keeps track of wich cocoon servlet deployed wich blocks?
Is that a correct way of stating it? Not even my 10 cents, just a question.
If we want to keep using blockcontext protocol, the handler needs a
central place where the different paths are resolved. However due to the
nature of the problem we can have the same name for a block in 2 different
servlet but if we resolve the url in the connection we will have the
problem deciding which path to return to the caller, since it can happen
that the underlying request has no servlet context associated meaning it is
impossible to determine which block to use.
Thanks for keeping the thread alive.
salu2
Cheers,
Jos
On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler scher...@gmail.comwrote:
On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:
Francesco Chicchiriccò created COCOON3-107:
--
Summary: With latest cocoon-block-deployment and
cocoon-service-impl SNAPSHOTs, integration tests fail
Key: COCOON3-107
URL: https://issues.apache.org/jira/browse/COCOON3-107
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sample-webapp, cocoon-servlet,
cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Priority: Critical
Fix For: 3.0.0-beta-1
This is happening as a consequence of COCOON3-105.
Basically, since there is no more an installed URLStreamHandlerFactory,
every new URL() should include an instance of
BlockContextURLStreamHandler.
This makes every other URL loading (including XSLT sheets in a separate
block, like happening for cocoon-sample-webapp) unaware of
blockcontext:// URLs.
Meaning we are back to square one.
Andreas Hartman is ATM in our office and we had a small chat about the
underlying problem.
We think that blockcontext cannot work as protocol as it is for now.
The above report shows that we need to use a URLStreamHandlerFactory to
be able to resolve this protocol.
{myblock2=
file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/
}
Now if we look on the above and how we defined it, we have:
in block-servlet-service.xml
servlet:context mount-path=/${blockId}
context-path=blockcontext:/${blockId}//
will then produce the following blockcontext object:
${blockId}=${tomcat.work}/${servlet_which uses the
block}/blocks/${blockId}/
Meaning that blockcontext:/ will be resolved to
${tomcat.work}/${servlet_which uses the block}/blocks/
There are various problematic parts:
As of the looks
Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)
Dear all,
Noticing that is very interesting discussion is getting silent, I'd like to
ask a question.
First of all, pardon me my ignorance. (blonde, can't help it).
So from just a high-level understanding, can I rephrase the problem?
What we seek to accomplish is:
* in a sitemap, being able to load resources from another sitemap,
according to the scheme:
map:generate src=cocoon://{relative-url}/
* within an xslt calling
xsl:variable name=var select='cocoon://{relative-url}' /
* within controller logic: redirect, or send the reference of a
ModelAndView
So now, in C3, we want to address resources cross-block to accomplish
modularity, right?
map:generate src={someBlock}://{relative-url}/
This should be restricted to the instance of the cocoon servlet itself, so
it can peacefully coexist with another cocoon servlet in the same JVM.
So you would like to avoid tweaking URL for the servlet without
interfering with the rest.
- something less invasive than URL.setURLStreamHandlerFactory ?
- mechanism that keeps track of wich cocoon servlet deployed wich blocks?
Is that a correct way of stating it? Not even my 10 cents, just a question.
Cheers,
Jos
On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler scher...@gmail.comwrote:
On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:
Francesco Chicchiriccò created COCOON3-107:
--**
Summary: With latest cocoon-block-deployment and
cocoon-service-impl SNAPSHOTs, integration tests fail
Key: COCOON3-107
URL: https://issues.apache.org/**
jira/browse/COCOON3-107https://issues.apache.org/jira/browse/COCOON3-107
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sample-webapp, cocoon-servlet,
cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Priority: Critical
Fix For: 3.0.0-beta-1
This is happening as a consequence of COCOON3-105.
Basically, since there is no more an installed URLStreamHandlerFactory,
every new URL() should include an instance of
BlockContextURLStreamHandler.
This makes every other URL loading (including XSLT sheets in a separate
block, like happening for cocoon-sample-webapp) unaware of
blockcontext:// URLs.
Meaning we are back to square one.
Andreas Hartman is ATM in our office and we had a small chat about the
underlying problem.
We think that blockcontext cannot work as protocol as it is for now.
The above report shows that we need to use a URLStreamHandlerFactory to be
able to resolve this protocol.
{myblock2=file:/home/thorsten/**src/apache/apache-tomcat-6.0.**
20/work/Catalina/localhost/**mywebapp2-1.0-SNAPSHOT/blocks/**myblock2/}
Now if we look on the above and how we defined it, we have:
in block-servlet-service.xml
servlet:context mount-path=/${blockId} context-path=blockcontext:/${**
blockId}//
will then produce the following blockcontext object:
${blockId}=${tomcat.work}/${**servlet_which uses the
block}/blocks/${blockId}/
Meaning that blockcontext:/ will be resolved to ${tomcat.work}/${servlet_
**which uses the block}/blocks/
There are various problematic parts:
As of the looks of it a block is treated as servlet mounted to a
context. Problematic is that the mount-path in some cases needs to become
= to catch all incoming request, which means root context.
Blocks are treated as servlets meaning you can only mount once a block (in
a specific version of that block). If another block use this blockId it is
not possible to use the same mount point. However that has the ultimate
consequence that you need to manage the name of your block manually or
ideally the ${blockId} is unique and contains the version of the block!
However blocks are more servlets within a servlet, since without a servlet
that has deps on them they would be not reachable.
This leads to to the real mount point ${servlet_which uses the
block}/{@mount-path_as defined in the block} in the servlet context and
the path as above. For example blockcontext:/test could refer to
${tomcat.work}/${servlet1}/**blocks/test or
${tomcat.work}/${servlet2}/**blocks/test, depending from which servlet
the request is issued. Meaning the blockcontext protocol does not resolve
url (Uniform (or universal) resource locator) since the resources it
describes are not universal (due to the fixed connection to the underlying
servlet).
With all the above said the logical consequence is that the pattern of
blockcontext would need the ${servlet_which uses the block} in it
somewhere, but that would render the whole block concept useless if used
within the block. That however would force a url rewritting on the fly
where the ${servlet_which uses the block} prefixed would be injected prior
of resolving.
We tested to push the resolving logic into the handler but that failed
since some calls have no
COCOON3-103
Yesterday, I had a closer look upon COCOON3-103.
Here is a better restatement of the problem:
The ObjectModel keeps hold of the sitemap parameters and other variables.
In SitemapParametersStack, a series of parameters is pushed upon the stack
- whenever a 'pattern match ' occurs (map:match element)
- when a when condition matches
Here is a simple case that does not work:
map:match name=matcherOne pattern=selecttest/{para1}
map:generate src=static/lyrics/le_bistrot.xml/
map:select value={map:para1}
map:when equals=one
map:transform src=xslt/song.xsl
map:parameter name=para1 value={map:para1}/
/map:transform
map:serialize type=html/
/map:when
map:otherwise
map:serialize type=xml/
/map:otherwise
/map:select
/map:match
The trouble is with getParameter of SitemapParametersStack:
- in this case, there is a match for relativeParameterMatcher,
but subsequently the variable level is not correctly computed and only
the last entry is taken to hold the parameter.
I can fix that, so that parameters always get matched if they are on the
stack, but my real question is:
what is meant to happen? Is there a scope foreseen for sitemap
parameters? Is there an 'absolute' and a 'relative' matching,
are notations foreseen that look like:
bla/blu
or
../../../bla
and what with /{justAName} ?
In any case, this mechanism does not work for the moment.
If you folks can explain me what the idea is, I can gladly provide a patch.
I have nothing to do these days.
Cheers,
Jos
Re: COCOON3-103
Hi Javier,
What is the best to do then?
Close the issue and keep in mind that absolute parameter addressing is
not used?
I think we can live with relative paths. It is just a bit awkward that a
when-matcher does
introduce a new 'level' (well, all depends on how you want to see it ;-)
but, OK, if you know it it works.
And, there is another question I had:
what happened to map:mount?
As in:
map:match pattern=**
map:mount src=residuary-treatment.xmap check-reload=no
uri-prefix= /
/map:match
Cheers,
Jos
On Tue, Sep 25, 2012 at 12:27 PM, Javier Puerto jav...@apache.org wrote:
Hi Jos
2012/9/25 Jos Snellings jos.snelli...@upperware.biz
Yesterday, I had a closer look upon COCOON3-103.
Here is a better restatement of the problem:
The ObjectModel keeps hold of the sitemap parameters and other
variables.
In SitemapParametersStack, a series of parameters is pushed upon the
stack
- whenever a 'pattern match ' occurs (map:match element)
- when a when condition matches
Here is a simple case that does not work:
map:match name=matcherOne pattern=selecttest/{para1}
map:generate src=static/lyrics/le_bistrot.xml/
map:select value={map:para1}
map:when equals=one
map:transform src=xslt/song.xsl
map:parameter name=para1 value={map:para1}/
AFAIK, It should be:
map:parameter name=para1 value={map:../para1}/
(in this case, para1 = one) :)
/map:transform
map:serialize type=html/
/map:when
map:otherwise
map:serialize type=xml/
/map:otherwise
/map:select
/map:match
The trouble is with getParameter of SitemapParametersStack:
- in this case, there is a match for relativeParameterMatcher,
but subsequently the variable level is not correctly computed and only
the last entry is taken to hold the parameter.
I can fix that, so that parameters always get matched if they are on the
stack, but my real question is:
what is meant to happen? Is there a scope foreseen for sitemap
parameters? Is there an 'absolute' and a 'relative' matching,
are notations foreseen that look like:
bla/blu
or
../../../bla
I think that this was the only way to get the parameters because you can
have nested another matcher inside with a different parameter. The ../ is
just the notation to climb up the tree.
and what with /{justAName} ?
Also I think that absolute is not used.
In any case, this mechanism does not work for the moment.
If you folks can explain me what the idea is, I can gladly provide a
patch. I have nothing to do these days.
Thanks, that would be great, I've explained how I remember that it works
but maybe someone wants to add something.
Cheers,
Jos
Salu2
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
{../parameter}
Dear,
Just did a test and saw that:
parameters in relative path notation get translated as:
map match=selecttest/{parameter1}
map select ...
map:when equals=one
map ...
map:transform src=testpage.xsl
map:parameter name=parameter1 value={../map:parameter1}/
/map:transform
{../map:parameter1}== they do not translate.
Let me have a closer look...
Meanwhile:
- anyone used this notation/behaviour?
Strange this did not get observed before.
Jos
Re: {../parameter}
Sorry, I want to revoke this message. (my error ;-)
On Tue, Sep 25, 2012 at 1:45 PM, Jos Snellings
jos.snelli...@upperware.bizwrote:
Dear,
Just did a test and saw that:
parameters in relative path notation get translated as:
map match=selecttest/{parameter1}
map select ...
map:when equals=one
map ...
map:transform src=testpage.xsl
map:parameter name=parameter1 value={../map:parameter1}/
/map:transform
{../map:parameter1} == they do not translate.
Let me have a closer look...
Meanwhile:
- anyone used this notation/behaviour?
Strange this did not get observed before.
Jos
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
[jira] [Closed] (COCOON3-103) Cannot pass map:parameter's to components inside of a map:select
[
https://issues.apache.org/jira/browse/COCOON3-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jos Snellings closed COCOON3-103.
-
Resolution: Not A Problem
Within nested blocks, sitemap parameters should be referred to by a relative
path
to the (ancestor) node in which they are declared.
It is just semantically not clear.
It is not a problem, but this should be documented. I had to look in the source
code to discover this.
Cannot pass map:parameter's to components inside of a map:select
-
Key: COCOON3-103
URL: https://issues.apache.org/jira/browse/COCOON3-103
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Jos Snellings
Labels: clarification
Fix For: 3.0.0-beta-1
Following construct is in a sitemap match of:
map:match pattern=/staticstuff/{docid}/{nn}
map:select value={jexl:cocoon.request.method}
map:when equals=POST
map:transform type=tee
map:parameter name=nn value={map:nn}/
map:parameter name=Url value=repo:/{map:docid}/
/map:transform
map:transform type=edit
map:parameter name=nn value={map:nn}/
map:parameter name=element
value={jexl:cocoon.request.parameter.element}/
/map:transform
/map:when
map:otherwise/
/map:select
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
map:mount
Dear all, Considering the upgrade cost of an existing project to cocoon-3, I have the following question: what happened to map:mount? As in: map:match pattern=** map:mount src=residuary-treatment.xmap check-reload=no uri-prefix= / /map It was a handy modularity mechanism to reduce the size of sitemaps. Is it no longer there? Do we need it? Do we want it? Kind regards, Jos
Re: map:mount
Hi Javier, Thank you, this is clear. 1. I agree with the fact that the blocks mechanism (SSF) is more modular than mounting submaps. 2. That been said, I need to bear that in mind to estimate the work. Just need to assess if they translate into each other. By the way, to my knowledge there is a production site with Apache Cocoon 3: http://thesaurus.european-heritage.net That is the one that I created. is there another one? Kind regards, Jos On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto jav...@apache.org wrote: Hi Jos 2012/9/25 Jos Snellings jos.snelli...@upperware.biz Dear all, Considering the upgrade cost of an existing project to cocoon-3, You have to bear in mind that it's still in beta and there's some components that's are not migrated yet but we have one production site working with Apache Cocoon 3. I have the following question: what happened to map:mount? Was deprecated for 2.2.x version. As in: map:match pattern=** map:mount src=residuary-treatment.xmap check-reload=no uri-prefix= / /map It was a handy modularity mechanism to reduce the size of sitemaps. Is it no longer there? Do we need it? Do we want it? For Apache Cocoon 2.2.x and 3.0, the block is the new unit of modularization. You can see some examples here: http://cocoon.apache.org/2.2/1291_1_1.html It's based on Servlet Service Framework subproject. More info here: http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html Kind regards, Jos Salu2. -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
Re: map:mount
Yes, please! On Tue, Sep 25, 2012 at 4:07 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 25/09/2012 16:05, Jos Snellings wrote: Hi Javier, Thank you, this is clear. 1. I agree with the fact that the blocks mechanism (SSF) is more modular than mounting submaps. 2. That been said, I need to bear that in mind to estimate the work. Just need to assess if they translate into each other. By the way, to my knowledge there is a production site with Apache Cocoon 3: http://thesaurus.european-heritage.net That is the one that I created. is there another one? Yep: http://cocoon.apache.org/live_sites_3.0.html Do you want yours to be added? Regards. On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto jav...@apache.org wrote: Hi Jos 2012/9/25 Jos Snellings jos.snelli...@upperware.biz Dear all, Considering the upgrade cost of an existing project to cocoon-3, You have to bear in mind that it's still in beta and there's some components that's are not migrated yet but we have one production site working with Apache Cocoon 3. I have the following question: what happened to map:mount? Was deprecated for 2.2.x version. As in: map:match pattern=** map:mount src=residuary-treatment.xmap check-reload=no uri-prefix= / /map It was a handy modularity mechanism to reduce the size of sitemaps. Is it no longer there? Do we need it? Do we want it? For Apache Cocoon 2.2.x and 3.0, the block is the new unit of modularization. You can see some examples here: http://cocoon.apache.org/2.2/1291_1_1.html It's based on Servlet Service Framework subproject. More info here: http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/ -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
[jira] [Created] (COCOON3-106) Add cocoon site
Jos Snellings created COCOON3-106: - Summary: Add cocoon site Key: COCOON3-106 URL: https://issues.apache.org/jira/browse/COCOON3-106 Project: Cocoon 3 Issue Type: Wish Components: cocoon-sample-webapp Reporter: Jos Snellings Priority: Minor I'd like the site 'thesaurus on line Editor' for the European Heritage Network to the cocoon 3 production sites. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: map:mount
Thanks Francesco, I added the link. Issue COCOON3-106 (wish). Cheers, Jos On Tue, Sep 25, 2012 at 4:14 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 25/09/2012 16:11, Jos Snellings wrote: Yes, please! Easy: just create an issue and attach a patch (an additional li.../li) of https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-main-site/src/site/xdoc/live_sites_3.0.xml Regards. [1] https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-main-site/src/site/xdoc/live_sites_3.0.xml On Tue, Sep 25, 2012 at 4:07 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 25/09/2012 16:05, Jos Snellings wrote: Hi Javier, Thank you, this is clear. 1. I agree with the fact that the blocks mechanism (SSF) is more modular than mounting submaps. 2. That been said, I need to bear that in mind to estimate the work. Just need to assess if they translate into each other. By the way, to my knowledge there is a production site with Apache Cocoon 3: http://thesaurus.european-heritage.net That is the one that I created. is there another one? Yep: http://cocoon.apache.org/live_sites_3.0.html Do you want yours to be added? Regards. On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto jav...@apache.org wrote: Hi Jos 2012/9/25 Jos Snellings jos.snelli...@upperware.biz Dear all, Considering the upgrade cost of an existing project to cocoon-3, You have to bear in mind that it's still in beta and there's some components that's are not migrated yet but we have one production site working with Apache Cocoon 3. I have the following question: what happened to map:mount? Was deprecated for 2.2.x version. As in: map:match pattern=** map:mount src=residuary-treatment.xmap check-reload=no uri-prefix= / /map It was a handy modularity mechanism to reduce the size of sitemaps. Is it no longer there? Do we need it? Do we want it? For Apache Cocoon 2.2.x and 3.0, the block is the new unit of modularization. You can see some examples here: http://cocoon.apache.org/2.2/1291_1_1.html It's based on Servlet Service Framework subproject. More info here: http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/ -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/ -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
[jira] [Updated] (COCOON3-106) Add cocoon site
[ https://issues.apache.org/jira/browse/COCOON3-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-106: -- Attachment: herein.patch just additional li Add cocoon site --- Key: COCOON3-106 URL: https://issues.apache.org/jira/browse/COCOON3-106 Project: Cocoon 3 Issue Type: Wish Components: cocoon-sample-webapp Reporter: Jos Snellings Priority: Minor Attachments: herein.patch I'd like the site 'thesaurus on line Editor' for the European Heritage Network to the cocoon 3 production sites. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-106) Add cocoon site
[ https://issues.apache.org/jira/browse/COCOON3-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-106: -- Attachment: herein.patch I am sorry, this must be a mistake ;-0 On Tue, Sep 25, 2012 at 4:36 PM, Francesco Chicchiriccò (JIRA) -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson Add cocoon site --- Key: COCOON3-106 URL: https://issues.apache.org/jira/browse/COCOON3-106 Project: Cocoon 3 Issue Type: Wish Components: cocoon-sample-webapp Reporter: Jos Snellings Priority: Minor Attachments: herein.patch, herein.patch I'd like the site 'thesaurus on line Editor' for the European Heritage Network to the cocoon 3 production sites. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
Hi Thorsten,
I believe having encountered this problem once.
However, it is not systematic.
Jos
On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA)
j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456689#comment-13456689]
Thorsten Scherler commented on COCOON3-105:
---
The problem lies in in
org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory.createURLStreamHandler
here we create a BlockContextURLStreamHandler extends URLStreamHandler
Regarding URLStreamHandler
/**
* The abstract class codeURLStreamHandler/code is the common
* superclass for all stream protocol handlers. A stream protocol
* handler knows how to make a connection for a particular protocol
* type, such as codehttp/code, codeftp/code, or
* codegopher/code.
* p
* In most cases, an instance of a codeURLStreamHandler/code
* subclass is not created directly by an application. Rather, the
* first time a protocol name is encountered when constructing a
* codeURL/code, the appropriate stream protocol handler is
* automatically loaded.*/
Which is exactly the problem in our case. Once the URLStreamHandler is
setup for the first blockcontext as protocol the second servlet will
directly use the java.net.URLStreamHandler and use that protocol.
Meaning if you start tomcat with both apps deployed the first request of
the first app decides which blockcontext will be associate with the block
context protocol
That happens in BlockContextURLStreamHandlerFactory where
createURLStreamHandler is only called once with the first request the
second then uses the old block context.
webapp fails if on the same servlet container is a c2.2.1 or other c3
webapp running
-
Key: COCOON3-105
URL: https://issues.apache.org/jira/browse/COCOON3-105
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Priority: Blocker
I noticed that you cannot run 2 c3 based war in a tomcat.
To reproduce:
- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype
where webapp depends on block one and webapp2 depends on block2.
My sample was:
[INFO] Reactor Summary:
[INFO]
[INFO] myparent .. SUCCESS
[1.163s]
[INFO] myblock ... SUCCESS
[3.611s]
[INFO] mywebapp .. SUCCESS
[1.924s]
[INFO] myblock2 .. SUCCESS
[1.498s]
[INFO] mywebapp2 . SUCCESS
[1.230s]
[INFO]
Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy
it before you start to webapp or if you have it enable deploy it on a
running instance. You should see the welcome page under something like
http://localhost:8080/mywebapp-1.0-SNAPSHOT/
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Now if you deploy the second webapp on a running instance it will deploy
without problem but requesting
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't
build sitemap from blockcontext:/myblock2/sitemap.xmap
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2'
deployed. The available blocks are
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at
[jira] [Created] (COCOON3-103) Cannot pass map:parameter's to components inside of a map:select
Jos Snellings created COCOON3-103:
-
Summary: Cannot pass map:parameter's to components inside of a
map:select
Key: COCOON3-103
URL: https://issues.apache.org/jira/browse/COCOON3-103
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Jos Snellings
Fix For: 3.0.0-beta-1
Following construct is in a sitemap match of:
map:match pattern=/staticstuff/{docid}/{nn}
map:select value={jexl:cocoon.request.method}
map:when equals=POST
map:transform type=tee
map:parameter name=nn value={map:nn}/
map:parameter name=Url value=repo:/{map:docid}/
/map:transform
map:transform type=edit
map:parameter name=nn value={map:nn}/
map:parameter name=element
value={jexl:cocoon.request.parameter.element}/
/map:transform
/map:when
map:otherwise/
/map:select
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1337109 - /cocoon/cocoon3/trunk/cocoon-shiro-sample/src/main/resources/META-INF/cocoon/spring/block-application-context.xml
I wish that would be real soon. I have a C3 application live. Based on my best judgement, I decided that the beta version was stable enough. Last winter I was bad-mouthed by some colleagues for having done this. Jos On Fri, May 11, 2012 at 9:04 PM, Michael Müller michael.muel...@mueller-bruehl.de wrote: Hi Thorsten (and other cocoon developers), I recognized some activities (svn commits etc.). On the other hand, cocoon 3.0 is in alpha and beta stage for a long time, feeling like ages. Is there a roadmap available? When might it be release? Herzliche Grüße - Best Regards, Michael Müller Am 11.05.2012 13:06, schrieb thors...@apache.org: Author: thorsten Date: Fri May 11 11:06:56 2012 New Revision: 1337109 URL: http://svn.apache.org/viewvc?**rev=1337109view=revhttp://svn.apache.org/viewvc?rev=1337109view=rev Log: white noise - formating changes -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
COCOON3-99: cross-cultural issue
Dear cocooners,
COCOON3-99 is about applying a user configuration to FopFactory in
FopSerializer.
To pass the location of the configuration file in a nice and portable way,
it is addressed in the jar:
configurationUrl = this.getClass().getResource(/COB-INF/ +
userConfigurationPath);
Fine, but I am still not satisfied. I would like to locate the font file as
well in the block.
FOP however, expects font-base, the path relative to the configuration
file to be a real directory.
As we can see from an example fragment from FOURIResolver.java:
baseURI = new URI(base);
String scheme = baseURI.getScheme();
boolean directoryExists = true;
if (file.equals(scheme)) {
dir = FileUtils.toFile(baseURI.toURL());
directoryExists = dir.isDirectory();
}
if (scheme == null || !directoryExists) {
String message = base + base + is not a valid
directory;
if (throwExceptions) {
throw new MalformedURLException(message);
}
(this is just an example, FO is coded to read resources from expanded
archives).
What do we do?
- live in an imperfect world?
- submit patch to FOP, but to be consistent, maintenance in more places is
necessary
- cross-post this mail to FO?
I should deliver a war to a party without me having server access. I can
hear them complain when I tell that there is some maintenance necessary.
Kind regards,
Jos
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
userconfig for FOP in Cocoon3
Dear cocooners,
We use FOP to generate a PDF publication of a thesaurus. Needing cyrillic
greek we have to setup
a user configuration. This is not yet foreseen in the current FOPSerializer.
Yesterday Robby and Ivan were so kind to send me a working Cocoon 2.2
configuration.
This morning, there was room to adapt it to C3.
I suggest that we extend FOPSerializer.java a bit, to include an internal
configuration file resources.:
public FlopSerializer(String outputFormat, String userConfigurationPath) {
if (outputFormat == null) {
throw new IllegalArgumentException(The parameter
'outputFormat' mustn't be null.);
}
URL configurationURL = this.getClass().getResource(/COB-INF/ +
userConfigurationPath);
try {
DefaultConfigurationBuilder cfgBuilder = new
DefaultConfigurationBuilder();
Configuration cfg =
cfgBuilder.build(configurationURL.openStream());
FOP_FACTORY.setUserConfig(cfg);
this.outputFormat = outputFormat;
}
This way, we can package our custom configuration and the font in the block
jar.
Kind regards,
Jos Snellings
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
Re: userconfig for FOP in Cocoon3
I will do that, Francesco!
However, this patch alters the constructor. This could cause other updates.
Better override setup?
I think that every pipeline's component setup method is called. I will try
that and log it in the ticket.
Ciao,
Jos
On Tue, May 8, 2012 at 9:51 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:
On 08/05/2012 09:48, Jos Snellings wrote:
Dear cocooners,
We use FOP to generate a PDF publication of a thesaurus. Needing cyrillic
greek we have to setup
a user configuration. This is not yet foreseen in the current
FOPSerializer.
Yesterday Robby and Ivan were so kind to send me a working Cocoon 2.2
configuration.
This morning, there was room to adapt it to C3.
I suggest that we extend FOPSerializer.java a bit, to include an internal
configuration file resources.:
public FlopSerializer(String outputFormat, String userConfigurationPath)
{
if (outputFormat == null) {
throw new IllegalArgumentException(The parameter
'outputFormat' mustn't be null.);
}
URL configurationURL = this.getClass().getResource(/**COB-INF/
+ userConfigurationPath);
try {
DefaultConfigurationBuilder cfgBuilder = new
DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.build(**
configurationURL.openStream())**;
FOP_FACTORY.setUserConfig(cfg)**;
this.outputFormat = outputFormat;
}
This way, we can package our custom configuration and the font in the
block jar.
Hi Jos,
this looks very nice: could you open an issue on JIRA and provide a proper
patch for this? I would be glad to take it, then. Thanks!
Regards.
--
Francesco Chicchiriccò
Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~**ilgrosso/http://people.apache.org/%7Eilgrosso/
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
[jira] [Created] (COCOON3-99) Provide FopSerializer with an embedded user configuration present in the cocoon block
Jos Snellings created COCOON3-99: Summary: Provide FopSerializer with an embedded user configuration present in the cocoon block Key: COCOON3-99 URL: https://issues.apache.org/jira/browse/COCOON3-99 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-optional Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 The current FopSerializer creates an instance of FopFactory. Only the defaults are used. This is a problem if you want to generate PDFs from Unicode data. The Cyrillic and Greek characters have no glyphs in these fonts, causing those strings to be displayed as # sequences. This patch adds an override for the method setConfiguration to add a user configuration location via a sitemap parameter. In sitemap.xmap of the block, add the parameter userConfigurationPath indicating the location of the user configuration file. Example: map:match pattern=editor/publish/thesaurus.pdf map:generate type=publish/ map:transform src=presentation/xslt/thesaurusfo.xslt/ map:serialize type=flo2pdf map:parameter name=userConfigurationPath value=fopconf/fop.xconf/ /map:serialize /map:match -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-99) Provide FopSerializer with an embedded user configuration present in the cocoon block
[ https://issues.apache.org/jira/browse/COCOON3-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-99: - Attachment: patch-fopserializer.txt A patch for adding the user configuration to the fop serializer via a sitemap construct. Provide FopSerializer with an embedded user configuration present in the cocoon block - Key: COCOON3-99 URL: https://issues.apache.org/jira/browse/COCOON3-99 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-optional Affects Versions: 3.0.0-beta-1 Reporter: Jos Snellings Priority: Minor Fix For: 3.0.0-beta-1 Attachments: patch-fopserializer.txt The current FopSerializer creates an instance of FopFactory. Only the defaults are used. This is a problem if you want to generate PDFs from Unicode data. The Cyrillic and Greek characters have no glyphs in these fonts, causing those strings to be displayed as # sequences. This patch adds an override for the method setConfiguration to add a user configuration location via a sitemap parameter. In sitemap.xmap of the block, add the parameter userConfigurationPath indicating the location of the user configuration file. Example: map:match pattern=editor/publish/thesaurus.pdf map:generate type=publish/ map:transform src=presentation/xslt/thesaurusfo.xslt/ map:serialize type=flo2pdf map:parameter name=userConfigurationPath value=fopconf/fop.xconf/ /map:serialize /map:match -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
patch
Hi Francesco, I opened issue COCOON3-99 and added a patch. (I hope I did it right). Ciao, Jos -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
Re: [c3] XincludeTransformer.java weirdness
Hi Thorsten, They are under generated-sources/javacc/org/apache/cocoon/sax/xpointer/ParseException.java Apparently the java is only generated at build time. Don't know details (pom.xml has javacc-maven-plugin). Jos On 01/19/2012 10:56 AM, Thorsten Scherler wrote: Hi all, in https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XIncludeTransformer.java we do import org.apache.cocoon.sax.xpointer.ParseException; ... import org.apache.cocoon.sax.xpointer.XPointerFrameworkParser; but in https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/xpointer/ There is no such classes. I do not understand since we can build with cli without problems. In eclipse I can fix the project setup by adding the cocoon-sax beta jar to the classpath. However that is the same jar as the project, which does not make sense at all. Somebody has an idea? salu2
Re: Porting to current cocoon version
Dear mr. Eisert, 1. I believe it does. I am using the beta version in a preproduction environment for quite some time and it is stable. 2. It depends on what you mean by configuration. The sitemap will need some slight adaptations. Specifics from cocoon 2.2 will no longer hold. - no flowscripts - xsp is banned There is a nonvanishing upgrade effort. 3. no, it should be written. I never used all of cocoon 2.x, but from my experience: - start project from 'cocoon sample and cocoon sample webapp' - plan need for conversion scripts - adapt sitemap - adjust configuration (which is now essentially spring configuration) it depends a great deal on what you have been using in cocoon 2.x. Jos On 01/16/2012 12:51 PM, Wolfram Eisert wrote: Dear List, we are currently using Cocoon 2.0.4 and plan to update to a newer version during this year. For that I have a few questions: * Does it make sense to wait for Cocoon 3.0? * Is the configuration compatible between Cocoon 2.2 and Cocoon 3.0? * Is there a howto for moving from Cocoon 2.0.4 to a current Version? Thank you for your answers. Wolfram
Re: Porting to current cocoon version
Hello Wolfram, The first. Cocoon 3 is rather a complete rewrite of the framework. The benefit: the dependencies of the framework have been limited to a minimum. A half-advantage: the scripting capabilities have been limited to stringtemplate. This sort of enforces scripts to do 'strictly presentation'. The minus side: old xsp scripts have to be rewritten. It all depends on how many xsp and flow scripts you have out there. Kind regards, Jos On 01/16/2012 02:54 PM, Wolfram Eisert wrote: Hello Jos, does that mean there is no xsp available in Cocoon 3 at all or that it's just not recommended? Wolfram 2012/1/16 Jos Snellings jos.snelli...@pandora.be mailto:jos.snelli...@pandora.be Dear mr. Eisert, 1. I believe it does. I am using the beta version in a preproduction environment for quite some time and it is stable. 2. It depends on what you mean by configuration. The sitemap will need some slight adaptations. Specifics from cocoon 2.2 will no longer hold. - no flowscripts - xsp is banned There is a nonvanishing upgrade effort. 3. no, it should be written. I never used all of cocoon 2.x, but from my experience: - start project from 'cocoon sample and cocoon sample webapp' - plan need for conversion scripts - adapt sitemap - adjust configuration (which is now essentially spring configuration) it depends a great deal on what you have been using in cocoon 2.x. Jos On 01/16/2012 12:51 PM, Wolfram Eisert wrote: Dear List, we are currently using Cocoon 2.0.4 and plan to update to a newer version during this year. For that I have a few questions: * Does it make sense to wait for Cocoon 3.0? * Is the configuration compatible between Cocoon 2.2 and Cocoon 3.0? * Is there a howto for moving from Cocoon 2.0.4 to a current Version? Thank you for your answers. Wolfram -- _ _ Philasearch.com GmbH Lindenweg 1 D-63877 Sailauf Tel. 06093-932933 Geschäftsführer: Franz Fedra, Wolfram Eisert, Walter Christ Steuer-Nr.:204 135 10911 Finanzamt Aschaffenburg Umsatzsteuer- Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE 112156180
Re: Porting to current cocoon version
HI again, Wolfram, It is not a string template script AND a generator. It is rather 'either'. If you make a list with all the data modifying operations that the application offers, how many would that be? - Let us call them commands. They would go into a cocoon controller. (Or two, or three). Some xsp will only be about presenation of data. You may have a choice there. You may be able to group some xsp's together. You will probably want to move application control and navigation apart. It all depends, I guess. But I agree it is quite some work and demands re-verification. However, once you get the hang of it, I guess you will find C3 more convenient to work with that the older versions, especially if you are familiar with spring. I am sorry I have no better news. Jos On Mon, Jan 16, 2012 at 4:39 PM, Wolfram eis...@philasearch.com wrote: It's a 10 year old app with more than 100 XSP's and specialized tag-librarys depending heavily on the XSP-concept. So that mean's I have to create a generator and a StringTemplate for each XSP. Am I right? Wolfram
Re: where is org.apache.cocoon.components?
Thanks, Simo!
We should document these dependencies, I think.
The cocoon side projects are not always easy to find.
Cheers,
Jos
On Fri, Jan 6, 2012 at 11:05 AM, Simone Tripodi simonetrip...@apache.orgwrote:
Hi Jos!
Looks like the class
org/apache/cocoon/components/serializers/util/XMLSerializer is
contained in C2 cocoon-serializers-charsets, you have to add the
following dependency in your pom:
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-serializers-charsets/artifactId
version1.0.0/version
/dependency
I found it in
jar:file:~/.m2/repository/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/cocoon-serializers-charsets-1.0.0.jar!/org/apache/cocoon/components/serializers/util/XMLSerializer.class
HTH, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 8:16 AM, Jos Snellings
jos.snelli...@upperware.biz wrote:
Dear cocooners,
When trying to load cocoon-optional, spring complains loudly about not
being
able to find class:
org/apache/cocoon/components/
serializers/util/XMLSerializer
In effect, this class is not within the cocoon distribution.
To my best knowledge, there is no sub project
cocoon-components
The problematic declaration is:
public class EncodingXMLSerializer extends
org.apache.cocoon.components.serializers.util.XMLSerializer implements
SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {
Can anybody shed some light upon this one?
Thank you !
Jos
where is org.apache.cocoon.components?
Dear cocooners,
When trying to load cocoon-optional, spring complains loudly about not
being able to find class:
org/apache/cocoon/components/
serializers/util/XMLSerializer
In effect, this class is not within the cocoon distribution.
To my best knowledge, there is no sub project
cocoon-components
The problematic declaration is:
public class EncodingXMLSerializer extends
org.apache.cocoon.components.serializers.util.XMLSerializer implements
SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {
Can anybody shed some light upon this one?
Thank you !
Jos
revoke where is org.apache.cocoon.components
Dear Cocooners, Sorry, sent message in title in haste; answering my own question: /org/apache/cocoon/cocoon-serializers-charsets/1.0.0 As side module it does not come with the distribution when getting the source code, that is why I did not see it. Cheers, Jos
dependency
Hi ! Just glancing through recent evolutions in cocoon 3. When building a block, based upon the sample, I notice a dependency: - avalon-framework-api - avalon-framework implementation Just curious: what does it come from?What needs it? I am running an application with minimum dependencies. Never needed it. Cheers, Jos
Re: status c3
True, Simone, I am delighted to find a renewed activity these days! Projects that stem from the archetypes show: 1. dependency from cocoon parent, but path is relative. I would like to avoid that 2. they are configured with the plugin for the 'reloading class loader', fine when developing, but not for production This is what I am going to try: - make a mvn cocoon project based on maven's latest versions - using just the dependencies I need - packaging just the war for the webapp Kind regards, Jos On 11/02/2011 09:21 AM, Simone Tripodi wrote: Hi Jos! As you noticed, the 'alpha' status - which is related to APIs only, not software stability - is finally terminated, we are on the beta way, but the first beta release has not been released yet! If I recall correctly, core APIs you are interested on, have not changed, so your application should continue working with the new artifacts - problem would be they are still SNAPSHOTs... :S There is not an official plan, with roadmaps and deadlines, unfortunately, since no one of Cocoon developers has the chance to work fulltime on it, so it is currently maintained in our spare time - that's why there are times where activity increases, but sometimes is very low :P Just let us know if you need details about C3, we would be more than pleased to help you! All the best, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Nov 2, 2011 at 5:45 AM, Jos Snellingsjos.snelli...@pandora.be wrote: Hi everybody, What is the current status of cocoon-3? - I notice that the archetypes in the trunk are still on alpha-3, whereas, - most of the artifacts have shifted to beta-1? Here is the news: - I have been using what I could call c3 core for quite some time now ( 1y) no complaints (core = servlet, pipeline, sax, sitemap, controller) - I have a possible case for a nice c3 application, but I am afraid that cocoons official status (alpha according to the documentation) will scare the customer What's the plan on short notice? Could live with beta, I guess. Kind regards, Jos
status c3
Hi everybody, What is the current status of cocoon-3? - I notice that the archetypes in the trunk are still on alpha-3, whereas, - most of the artifacts have shifted to beta-1? Here is the news: - I have been using what I could call c3 core for quite some time now ( 1y) no complaints (core = servlet, pipeline, sax, sitemap, controller) - I have a possible case for a nice c3 application, but I am afraid that cocoons official status (alpha according to the documentation) will scare the customer What's the plan on short notice? Could live with beta, I guess. Kind regards, Jos
Re: [C3] Passing parameters from sitemap to generator
Hi,
Maybe the Generator is sufficient?
To pass parameters from the sitemap is not it is not a big deal.
What sort of parameters do you want? Parts of the path?
controlStuff{tat}/{tit}/{tot}
request parameters?
Kind regards,
Jos
On 07/01/2011 10:33 AM, Thomas Markus wrote:
Hi,
JXGenerator is really useful, its a must have for me.
Thomas
Am 01.07.2011 10:25, schrieb Francesco Chicchiriccò:
Hi all,
recently I have been in the situation for which I need to parametrize
an XML file of my application; I thought there was a simpler way but
I ended up by using an additional XSLT transformation step (since the
XSLTTransformer can accep parameters from the pipeline).
With C2.1 I used to put in place the JXGenerator [1] (or
JXTransformer [2] depending on the case): this saved me, in many
cases, from an additional transformation step in the pipeline.
Even though it is true that everything you could do with JXGenerator
can always be done with XMLGenerator + XSLTTransformer, do you think
that such component can be a nice to have in C3?
Cheers.
[1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html
Re: Latest on Cocoon?
Will turn out well, I guess! I have a cocoon 3 application running with happy users. The core is not so like to undergo dramatic changes. What is evolving a bit is 'goodies' and 'integration'. What I like very much is that unnecessary dependencies have been removed. Also the separation between jars is better. For instance, if you do not need StringTemplate you can skip it; same with cocoon-wicket. Cheers, Jos On 12/17/2010 02:13 PM, Robby Pelssers wrote: I really can't understand why you would still like to use XSP while there are far better alternatives out there? I was in the exact same position 6 years ago where we had this large Cocoon application using solely xsp's. We took the decision to rewrite all functionality to flowscript / jxtemplate and we never regretted this decision. And 2 years back I decided to switch to Cocoon 2.2 and yet again no regrets. Sure, you have to do quite a bit of additional work but postponing an upgrade will fire back at you in the long run. Not saying you have to be an early adapter but once those early birds have used it for 1 year in production environments and most bugs are removed... you should definitely consider it. I'm about to start writing my first Cocoon 3 app while it's still in alpha-2 ... See how that turns out ;-) Kind regards, Robby Pelssers -Oorspronkelijk bericht- Van: Johan Cwiklinski [mailto:johan.cwiklin...@ajlsm.com] Verzonden: vr 17-12-2010 9:54 Aan: dev@cocoon.apache.org Onderwerp: Re: Latest on Cocoon? Le 17/12/2010 09:43, Laurent Medioni a écrit : Unfortunately, if you are stuck as we are with XSPs, 2.2 is not an option... We are even decommissioning our pageflow implementation based on Flowscript to switch to a plain Java stateless implementation... So definitely not the 2.2 direction from what I understood... XSP block is not longer maintained under cocoon 2.1. Anyaway, I was able to build and use the 2.1 xsp block with cocoon 2.2 a few months ago, for testing pruposes. That seems to work pretty well (all my tests on existing XSPs were successfull. Although, I did not plan to use that on production environments... Laurent Regards,
Re: [C3] Pipeline DSL
Good point. I would say: everything you need and even more is there! For people who were familiar with 2.2 or who want to port their application: they are going to miss flowscript. For people who lost contact in version 2.1 or so, they will probably be missing xsp as a presentation scripting, and then get used to the rigid separation line imposed by StringTemplate. So my message would be: cocoon3 is 'gewöhnungsbedürftig', but you can safely choose for it. There is a non-vanishing upgrade effort involved. Jos On 12/07/2010 10:54 PM, Robby Pelssers wrote: Hi Simoni, i think it's indeed more fluent and more explicit. So I think it certainly is an improvement. Only a few days back I wrote a mail to my fellow Java team members complaining that Java feels like a big fat bloated beast more and more with lack of expressiveness and higher order functions. Especially after playing with functional languages. And Guava and functionaljava are good examples... Hell, I even am experimenting myself with similar stuff ;-) http://code.google.com/p/functionalprogramming/wiki/Introduction By the way... If I were to jump on the Cocoon 3 wagon... would i be able to do the same stuff already as with 2.2? Or let me rephrase the question... is most stuff already ported to 3.0? Cheers, Robby Pelssers -Oorspronkelijk bericht- Van: Simone Tripodi [mailto:simone.trip...@gmail.com] Verzonden: di 7-12-2010 21:39 Aan: dev@cocoon.apache.org Onderwerp: [C3] Pipeline DSL Hi all guys, I just committed a first working spike of a Pipeline DSL[1] to expose more fluent APIs to final users to help them correctly creating and running pipelines, built on top of pipeline APIs. I also modified a test to show how to use the new APIs. WDYT? Every feedback/suggestion would be much more than appreciated!!! Have a nice day, Simo [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/builder [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/PipelineTest.java#testPipelineWithCompiledXSLT() http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Cocoon 3: the three sisters as OSGi bundles?
Dear all,
Some weeks ago, I was coding a servlet in an OSGi context (apache
felix/sling).
In the process, of course, I wanted to use the triplet cocoon-pipeline,
cocoon-sax, cocoon-xml, which as a result of the
design goals of Cocoon 3, can be used without further dependencies. A
wise thing !
Of course, a first rough attempt is to just embed the jars in the
bundle. This worked.
But now, I would like to take the thing an obvious step further: prepare
OSGi bundles for the three sisters.
When I checked out the trunk again, I was pleasantly surprised to notice
that ... cocoon-xml already is!
That means that I am not the only guy in the world thinking this would
be a good idea.
I prepared bundles for the other two, but ... there is a class loading
issue with cocoon-sax.
Summarising:
1. in spite of adding the xerces bundle to felix, inside the SAX2
classes a class.forName() gives a
ClassNotFoundException.:
org.apache.cocoon.pipeline.ProcessingException: Cannot create and
prepare an XMLReader.
at
org.apache.cocoon.sax.util.XMLUtils.createXMLReader(XMLUtils.java:138)
and this is because:
Caused by: java.lang.ClassNotFoundException:
org.apache.xerces.parsers.SAXParser
at
org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:189)
2. On the other hand, inside 'my' bundle a code like:
snip
XMLReader reader = new SAXParser();
reader = null;
String className = System.getProperty(org.xml.sax.driver);
try {
reader =
(XMLReader)(Class.forName(className).newInstance());
}
catch (Exception e) {
System.err.println(No love...);
e.printStackTrace();
}
URL here = new
URL(http://localhost:8080/some/nice/xml/content;);
URLConnection hc = here.openConnection();
InputStream in = hc.getInputStream();
ContentHandler contentHandler = new MyFavoriteContentHandler();
reader.setContentHandler(contentHandler);
InputSource input = new InputSource(in);
try {
reader.parse(input);
}
catch (Exception e) {
System.err.println(Can't parse your file);
e.printStackTrace();
}
/snip
works.
So, clearly there is a classloader confusion.
But the question is: is this the right way to go inside OSGi? Probably
it would be better to ask the framework what parser
services it has available for us, and then use XMLParserActivator?
We could think about adding such a method to XMLUtils.
Of course I can take the embedded solution, but this is really a
third-class solution. I really think there is an interest
to transform cocoon-sax into a genuine OSGi bundle.
I do not expect problems with cocoon-pipeline, being nicely insulated
from the JAXP-loading issues.
Is there any interest in this group to dig into the matter?
Please let me know. If we can set up a discussion on this matter I am
willing to address the issues in my own time.
Cheers,
Jos
[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842957#action_12842957 ] Jos Snellings commented on COCOON3-53: -- - No, I cannot say your test is wrong. The test clearly shows that the right response is returned from the cache - It must be somehow 'subtle' - Yesterday I looked into CachingPipeline and I found everything sound - Yet my test case on a browser stands. If you want I can describe it in detail == the next candidate to look at is simplecache. It is hard to imagine what can go wrong here, as it is based upon a map. The only thing I can imagine: - could it be that there is a situation where different cache keys map onto the same content? - my pipes have no jmxname. Can that be a problem? I think not. == the thing to do is probably: I try put a finger on the problem at my side and deliver a very specific test case, for I believe the problem is quite specific. I will keep this group posted. Cocoon 3: XMLSerializer caches all -- Key: COCOON3-53 URL: https://issues.apache.org/jira/browse/COCOON3-53 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842967#action_12842967 ] Jos Snellings commented on COCOON3-53: -- Cocoon 3, checked out from SVN on 5 march, and built with eclipse. Detail: three urls, activating a pipe ending with an xml serializer. (Note: all other pipes work correctly as far as I could verify) http://localhost:8080/thesaurus/hierarchies?language=el, result = the greek hierarchies in the thesaurus http://localhost:8080/thesaurus/showterm.xml?id=1004, visualize a term http://localhost:8080/thesaurus/editor/workspace.xml?random=23948783 Here is what happens: SETUP, manufacturing cacheKey: ~ adding SimpleCacheKey(hashCode=3116185) for component ToptermsGenerator(hashCode=21535750) ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for component XMLSerializer(hashCode=10730286) Creating CompoundCacheKey(hashCode=22406408 key=[SimpleCacheKey(hashCode=3116185), org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline CachingPipeline(hashCode=33258683 components=[ToptermsGenerator(hashCode=21535750), XMLSerializer(hashCode=10730286)]) SETTING CACHE: org.apache.cocoon.pipeline.caching.SimpleCache (CachingPipeline.setCache() called) SETUP, manufacturing cacheKey for 2nd: ~ adding SimpleCacheKey(hashCode=4540490) for component TermGenerator(hashCode=16199287) ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for component XMLSerializer(hashCode=23533966) Creating CompoundCacheKey(hashCode=16471030 key=[SimpleCacheKey(hashCode=4540490), org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline CachingPipeline(hashCode=772032 components=[TermGenerator(hashCode=16199287), XMLSerializer(hashCode=23533966)]) The value is FOUND in cache!!!, Here is the xml for: cacheValue.writeTo(System.out): JDB: CachingPipeline Write cache value to output stream: ?xml version=1.0 encoding=UTF-8?pagesearchform/classlistclass name=Ομάδα 1 - Οργανισμοί και Φορείςtop id=9001κυβέρνηση / διοίκηση/toptop id=9029οργανισμοί/toptop id=9056φορείς/top/classclass name=Ομάδα 2 - Κατηγορίες Πολιτιστικής Κληρονομιάςtop id=9085πολιτιστικό αγαθό/toptop id=9115περιοχές/toptop id=9149ενδιαφέρον πολιτιστικής κληρονομιάς/toptop id=9166κληρονομιά/top/classclass name=Ομάδα 3 - Συστήματα Αρχειοθέτησηςtop id=9194καταγραφή και τεκμηρίωση/toptop id=9215αρχεία καταγραφής/toptop id=9222κατάλογος προστατευόμενων αγαθών/top/classclass name=Ομάδα 4 - Νομικά συστήματαtop id=9225νομικά μέσα/toptop id=9250πολεοδομικό σύστημα/toptop id=9273διαχείριση κληρονομιάς/toptop id=9327ιδιοκτησία/toptop id=9355παράνομες ενέργειες/top/classclass name=Ομάδα 5 - Επεμβάσειςtop id=9362τύποι επεμβάσεων/toptop id=9413πολιτική επεμβάσεων/toptop id=9416προγράμματα επεμβάσεων/toptop id=9421εργαλεία επέμβασης/top/classclass name=Ομάδα 6 - Επαγγέλματα, δεξιότητες και αρμοδιότητεςtop id=9430επαγγέλματα/toptop id=9432δεξιότητες/toptop id=9437εκπαίδευση / επιμόρφωση/top/classclass name=Ομάδα 7 - Πρόσβαση και ερμηνείαtop id=9449πρόσβαση και ερμηνεία/top/classclass name=Ομάδα 8 - Χρηματο-οικονομικά συστήματαtop id=9491χρηματο-οικονομικά συστήματα/top/classclass name=Ομάδα 9 - Γενικές έννοιεςtop id=9521γενικές έννοιες/top/class/classlist/pageSETTING CACHE: org.apache.cocoon.pipeline.caching.SimpleCache Surprise! The Greek hierarchies! SETUP, now the call of workspace: ~ adding SimpleCacheKey(hashCode=30181678) for component WorkspaceProvider(hashCode=27011377) ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for component XMLSerializer(hashCode=28014118) Creating CompoundCacheKey(hashCode=31048679 key=[SimpleCacheKey(hashCode=30181678), org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline CachingPipeline(hashCode=22316052 components=[WorkspaceProvider(hashCode=27011377), XMLSerializer(hashCode=28014118)]) JDB: CachingPipeline Write cache value to output stream: ?xml version=1.0 encoding=UTF-8?pagesearchform/classlistclass name=Ομάδα 1 - Οργανισμοί και Φορείςtop id=9001κυβέρνηση / διοίκηση/toptop id=9029οργανισμοί/toptop id=9056φορείς/top/classclass name=Ομάδα 2 - Κατηγορίες Πολιτιστικής Κληρονομιάςtop id=9085πολιτιστικό αγαθό/toptop id=9115περιοχές/toptop id=9149ενδιαφέρον πολιτιστικής κληρονομιάς/toptop id=9166κληρονομιά/top/classclass name=Ομάδα 3 - Συστήματα Αρχειοθέτησηςtop id=9194καταγραφή και τεκμηρίωση/toptop id=9215αρχεία καταγραφής/toptop id=9222κατάλογος προστατευόμενων αγαθών/top/classclass name=Ομάδα 4 - Νομικά συστήματαtop id=9225νομικά μέσα/toptop id=9250πολεοδομικό σύστημα/toptop id=9273διαχείριση κληρονομιάς/toptop id=9327ιδιοκτησία/toptop id=9355παράνομες ενέργειες/top/classclass name=Ομάδα 5 - Επεμβάσειςtop id=9362τύποι επεμβάσεων/toptop id=9413πολιτική επεμβάσεων/toptop id=9416προγράμματα επεμβάσεων/toptop id
[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843037#action_12843037 ] Jos Snellings commented on COCOON3-53: -- ParameterCacheKey, constructed with the request parameters effectively cures the problem. This issue is closed! Suggestion: Developers starting out with cocoon 3 are very much likely to leave the routine constructCacheKey() as they find it. It would be good to provide a lightly annotated example in the samples! I will post one. Cocoon 3: XMLSerializer caches all -- Key: COCOON3-53 URL: https://issues.apache.org/jira/browse/COCOON3-53 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings closed COCOON3-53. Resolution: Fixed The observed problem was due to using a SimpleCacheKey. It remains a strange fact that this is only observed when the end point is an XMLSerializer. Cocoon 3: XMLSerializer caches all -- Key: COCOON3-53 URL: https://issues.apache.org/jira/browse/COCOON3-53 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842997#action_12842997 ] Jos Snellings commented on COCOON3-53: -- Yes, I thought about that, SimpleCacheKey is all too Simple. I kept it mainly because it was in the samples: it is not expected that a generator produces the same result. but why do pipelines with the same Starters (Termgenerator or WorkspaceProvider) are perfectly OK with the cache when they end in html serialization? Anyway, I will use a parameter cache and verify the cache behaviour is correct. If it does, I close this issue. Cocoon 3: XMLSerializer caches all -- Key: COCOON3-53 URL: https://issues.apache.org/jira/browse/COCOON3-53 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all
[ https://issues.apache.org/jira/browse/COCOON3-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842613#action_12842613 ] Jos Snellings commented on COCOON3-53: -- This is only true for CachingPipeline! AsyncCachingPipeline is not affected. Cocoon 3: XMLSerializer caches all -- Key: COCOON3-53 URL: https://issues.apache.org/jira/browse/COCOON3-53 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2287) Cocoon 3: XMLSerializer caches all
Cocoon 3: XMLSerializer caches all -- Key: COCOON-2287 URL: https://issues.apache.org/jira/browse/COCOON-2287 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Reporter: Jos Snellings After startup, any pipeline/matcher ending in an xml-serializer will produce the output of the first request after server startup, regardless of the url, let alone parameters. So the first xml pipe that is activated produces the expected output. All subsequent calls will echo that output, whatever the url or parameters. It takes a server restart to make a pipeline ending in an xml serializer work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Type 'jsp' does not exist for 'map:generate'
Hi, Maybe you mean: generate type=xsp src=intro.xsp/ an xsp page is a special variant of a jsp page. As far as I know, plain jsp does not fit in cocoon. Cheers On Wed, 2010-03-03 at 12:25 +0530, Venura Kahawala wrote: Hi, For cocoon 2.2, with maven, I have this pipeline in my experimental sitemap-file: map:sitemap xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://apache.org/cocoon/sitemap/1.0 http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd; xmlns:map=http://apache.org/cocoon/sitemap/1.0; map:flow language=javascript/ map:pipelines map:match pattern=intro.jsp map:generate type=jsp src=intro.jsp/ map:transform src=demo/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline /map:sitemap When I run the maven command “mvn jetty-run” I get the following error Caused by: org.apache.avalon.framework.configuration.ConfigurationException: Ty e 'jsp' does not exist for 'map:generate' Is there something missing in my sitemap? Or is there something I have to do with maven or do I have to add some other configurations. And if there are other configurations please advise me where I can find those files in my application. Please advise me. Greetings and thanks for helping! Venura.
Re: Type 'jsp' does not exist for 'map:generate'
Hi again, I am sorry. xsp does not exist anymore from 2.2. My mistake. I responded in haste. Jos On Wed, 2010-03-03 at 09:21 +0100, Jos Snellings wrote: Hi, Maybe you mean: generate type=xsp src=intro.xsp/ an xsp page is a special variant of a jsp page. As far as I know, plain jsp does not fit in cocoon. Cheers On Wed, 2010-03-03 at 12:25 +0530, Venura Kahawala wrote: Hi, For cocoon 2.2, with maven, I have this pipeline in my experimental sitemap-file: map:sitemap xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://apache.org/cocoon/sitemap/1.0 http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd; xmlns:map=http://apache.org/cocoon/sitemap/1.0; map:flow language=javascript/ map:pipelines map:match pattern=intro.jsp map:generate type=jsp src=intro.jsp/ map:transform src=demo/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline /map:sitemap When I run the maven command “mvn jetty-run” I get the following error Caused by: org.apache.avalon.framework.configuration.ConfigurationException: Ty e 'jsp' does not exist for 'map:generate' Is there something missing in my sitemap? Or is there something I have to do with maven or do I have to add some other configurations. And if there are other configurations please advise me where I can find those files in my application. Please advise me. Greetings and thanks for helping! Venura.
[jira] Updated: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
[ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jos Snellings updated COCOON3-46: - Attachment: closeQuietly-fix.patch URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null --- Key: COCOON3-46 URL: https://issues.apache.org/jira/browse/COCOON3-46 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Jos Snellings Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-3 Attachments: closeQuietly-fix.patch finally clause in URLResponse method execute() contains call to URLConnectionUtils.closeQuietly. If servletConnection = this.url.openConnection(); fails, servletConnection is null. In that case closeQuietly causes a stacktrace to be output. Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);, guard the call with a test, or even better, take into account in closeQuietly that the input parameter may be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: closeLoudly()
OK, I attached the patch to the issue. I guess that is the right way. Thanks for mentioning. Jos
Re: closeLoudly()
Thank you, Simone. I will do that.
On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
Hi Jos,
nice to meet you :) Usually suggestions of this kind have to be
submitted by the issue tracker:
http://issues.apache.org/jira/browse/COCOON3
Make your own patch through the command line:
svn diff -x -u Main.java arg-fix.patch
giving your patch file meaningful name.
Goof job!
Simo
On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings jos.snelli...@pandora.be
wrote:
URLResponse.java:
Modifying the finally-clause to remain silent:
finally {
if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
}
Jos
[jira] Created: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null --- Key: COCOON3-46 URL: https://issues.apache.org/jira/browse/COCOON3-46 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Jos Snellings Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-3 finally clause in URLResponse method execute() contains call to URLConnectionUtils.closeQuietly. If servletConnection = this.url.openConnection(); fails, servletConnection is null. In that case closeQuietly causes a stacktrace to be output. Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);, guard the call with a test, or even better, take into account in closeQuietly that the input parameter may be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: closeLoudly()
I attached the patch. Is this the proper way to submit?
Thanks, and please excuse me my ignorance. It is the first time.
(first times can be traumatic, so far I am feeling well).
Jos
On Sat, 2009-12-05 at 09:28 +0100, Jos Snellings wrote:
Thank you, Simone. I will do that.
On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
Hi Jos,
nice to meet you :) Usually suggestions of this kind have to be
submitted by the issue tracker:
http://issues.apache.org/jira/browse/COCOON3
Make your own patch through the command line:
svn diff -x -u Main.java arg-fix.patch
giving your patch file meaningful name.
Goof job!
Simo
On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings jos.snelli...@pandora.be
wrote:
URLResponse.java:
Modifying the finally-clause to remain silent:
finally {
if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
}
Jos
Index: cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/util/URLConnectionUtils.java
===
--- cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/util/URLConnectionUtils.java (revision 884744)
+++ cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/util/URLConnectionUtils.java (working copy)
@@ -34,6 +34,8 @@
* @param urlConnection {...@link URLConnection} to be closed.
*/
public static void closeQuietly(URLConnection urlConnection) {
+
+ if (urlConnection == null) return;
if (urlConnection.getDoInput()) {
InputStream inputStream = null;
try {
Re: [jira] Commented: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
That is what I did. On Sat, 2009-12-05 at 09:50 +, Jörg Heinicke (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786368#action_12786368 ] Jörg Heinicke commented on COCOON3-46: -- Isn't it more convenient if closeQuietly(..) just handles null? URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null --- Key: COCOON3-46 URL: https://issues.apache.org/jira/browse/COCOON3-46 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Jos Snellings Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-3 finally clause in URLResponse method execute() contains call to URLConnectionUtils.closeQuietly. If servletConnection = this.url.openConnection(); fails, servletConnection is null. In that case closeQuietly causes a stacktrace to be output. Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);, guard the call with a test, or even better, take into account in closeQuietly that the input parameter may be null.
Re: Cocoon documentation
Currently there is an initialisation problem. Anyway, Reinhard, you had a great table of contents. That is a good way to get started: what nodes are missing? That way, we may fill in the gaps, whilst trying our best to preserve unity of presentation writing style All docbook, I guess? Jos On Fri, 2009-12-04 at 10:15 +0100, Reinhard Pötz wrote: Matt Whipple wrote: Reinhard Pötz wrote: Matt Whipple wrote: Jos Snellings wrote: The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\ I stumbled upon the HTML deliverable of that on http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. I'd think it would be best if the official documentation focused on being primarily a comprehensive reference with a quick bootstrap guide. A community documentation site could then supplement that with all the typical tutorials/how-to's and tips tricks which gets the reader where he wants to be with a straightforward, minimalist approach which then references the official docs and other more enlightening sources. Regular articles/blog entries could then highlight the activity in the community, and the possibilities of various Cocoon components could be showcased. Guides to all of the overlapping processes which can be [easily] extrapolated from existing material can be given a home so that a potential new developer with a specific need is provided with an apparent foot in the door. Basically a site which presents a welcoming, active community rather than seemingly a group of scattered people developing in Cocoons and enabling me to make bad wordplay (such is the price). To that end, an agreed upon forum would be ideal. Agreed. When I started to write the C3 documentation, I had the Spring reference documentation in mind. I think it's one of the best examples because it focuses on describing the technology and the concepts. As a forum for everything beyond reference docs we could either use Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon) My thought would be Daisy (cocoondev.org?) so the site itself can be Cocoon powered and then the wiki can remain legacy docs. The Cocoon project runs its own Daisy instance at http://cocoon.zones.apache.org/daisy/ We could setup a Cocoon 3 wiki site there.
Re: Cocoon documentation
What editor do you use?. (I mostly use XMLMind) On Fri, 2009-12-04 at 12:09 +0100, Reinhard Pötz wrote: Jos Snellings wrote: Currently there is an initialisation problem. Anyway, Reinhard, you had a great table of contents. That is a good way to get started: what nodes are missing? That way, we may fill in the gaps, whilst trying our best to preserve unity of presentation writing style All docbook, I guess? Yes, cocoon-docs is based on docbook and a Maven 2 docbook plugin that creates html and pdf docs: See http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/docbkx/reference/ You can generate the documentation yourself by invoking 'mvn site' from the base directory of the cocoon-docs module.
closeLoudly()
URLResponse.java:
Modifying the finally-clause to remain silent:
finally {
if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
}
Jos
Re: Initialization of variables
Hi Johannes,
I must say, I do not completely understand your point. Talking about
such things as 'transactions': you could setup in the system what needs
to be setup once in a separate class.
Below is an example from the real world where database connections are
set up in a separate spring bean:
On Fri, 2009-12-04 at 02:06 +0100, Johannes Lichtenberger wrote:
Hello,
how do I initialize an object (a transaction), which I then have to
access in a self written pipeline component (generator)?
My concern is, that the session can only be bound once to a path/file,
so subsequent requests throw errors.
regards,
Johannes
package org.herein.thesaurus.cocoon;
import java.util.Map;
import java.util.Set;
import javax.servlet.http.HttpServletRequest;
import org.apache.cocoon.pipeline.caching.CacheKey;
import org.apache.cocoon.pipeline.caching.SimpleCacheKey;
import org.apache.cocoon.pipeline.component.CachingPipelineComponent;
import org.apache.cocoon.sax.AbstractSAXGenerator;
import org.apache.cocoon.xml.sax.AttributesImpl;
import org.apache.cocoon.sax.SAXConsumer;
import org.apache.cocoon.rest.controller.annotation.SitemapParameter;
import org.apache.cocoon.servlet.util.HttpContextHelper;
import org.xml.sax.SAXException;
import org.herein.thesaurus.ThesaurusBrowser;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
public class ToptermsGenerator extends AbstractSAXGenerator implements
CachingPipelineComponent, ApplicationContextAware {
private ApplicationContext applicationContext;
@SitemapParameter
private String language;
@SitemapParameter
private String deep;
private String showClass;
private String id;
private String editing;
// String language = en;
public void setup(MapString, Object parameters) {
HttpServletRequest request =
HttpContextHelper.getRequest(parameters);
language = request.getParameter(language);
deep = request.getParameter(all);
showClass = request.getParameter(class);
id = request.getParameter(nr);
editing = request.getParameter(edit);
}
public void execute() {
SAXConsumer consumer = this.getSAXConsumer();
try {
consumer.startDocument();
consumer.startElement(, page, page, new
AttributesImpl());
if (deep == null) {
AttributesImpl attr = new AttributesImpl();
consumer.startElement(, searchform, searchform,
attr);
consumer.endElement(, searchform, searchform);
}
ThesaurusBrowser T;
if (editing != null) T = (ThesaurusBrowser)
applicationContext.getBean(EditThesaurusBrowser);
else T = (ThesaurusBrowser)
applicationContext.getBean(ThesaurusBrowser);
if ((showClass != null) showClass.equals(1)) {
T.showClass(consumer,id);
}
else if ((deep != null) (deep.equals(1))) {
T.listClassesDeep(consumer, language);
}
else if (language != null) {
T.listClasses(consumer, language);
}
consumer.endElement(,page,page);
consumer.endDocument();
} catch (SAXException e) {
throw new RuntimeException(e);
}
}
public CacheKey constructCacheKey() {
return new SimpleCacheKey();
}
public void setApplicationContext(ApplicationContext applicationContext)
{
this.applicationContext = applicationContext;
}
}
Re: Cocoon documentation
Yes, that would be it... agreed. On Tue, 2009-12-01 at 06:23 -0500, Matt Whipple wrote: Jos Snellings wrote: The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\ I stumbled upon the HTML deliverable of that on http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. I'd think it would be best if the official documentation focused on being primarily a comprehensive reference with a quick bootstrap guide. A community documentation site could then supplement that with all the typical tutorials/how-to's and tips tricks which gets the reader where he wants to be with a straightforward, minimalist approach which then references the official docs and other more enlightening sources. Regular articles/blog entries could then highlight the activity in the community, and the possibilities of various Cocoon components could be showcased. Guides to all of the overlapping processes which can be [easily] extrapolated from existing material can be given a home so that a potential new developer with a specific need is provided with an apparent foot in the door. Basically a site which presents a welcoming, active community rather than seemingly a group of scattered people developing in Cocoons and enabling me to make bad wordplay (such is the price). To that end, an agreed upon forum would be ideal. The cocoon community will be delighted at some good documentation. Talking about community I fear such as an active community is to be reestablished, so I think we'd better provide some sweet stuff. What would Reinhard think of starting with as a table of contents? I will be glad to write some documentation as well. I have some goose feathers available after Christmas, when I will be through the experience of creating a first How about you? Jos On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote: I'm a recent transplant to Cocoon (and Java), in particular because Cocoon 3 appears as though it is/will be closely in line with my own perspective on web application development. I'm interested in contributing to the development of the framework itself, but likely won't be able to produce anything remotely useful for a couple months as I familiarize myself with all of the related technologies. I've just read some of the attacks on the poor documentation of the project and the resulting difficult entry for those unfamiliar. This is, of course, easily confirmed by the combination of woefully out of date references and dead links on the Web site (i.e. to the Daisy site). As I am (obviously) hopeful to see Cocoon succeed, I certainly don't want it to become mired in isolation like so many good projects. As such I'd like to try to contribute some documentation. Is there any idea among the community as to where documentation should end up, or should I just create a new site? Also, I'd lean towards focusing on Cocoon 3, as having documentation in place for a new release would likely have larger impact than attaching possibly overdue docs to an older, in the process of being superseded one. This would be premature if there's no foreseeable beta
Re: Cocoon documentation
The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs The cocoon community will be delighted at some good documentation. Talking about community I fear such as an active community is to be reestablished, so I think we'd better provide some sweet stuff. What would Reinhard think of starting with as a table of contents? I will be glad to write some documentation as well. I have some goose feathers available after Christmas, when I will be through the experience of creating a first app. How about you? Jos On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote: I'm a recent transplant to Cocoon (and Java), in particular because Cocoon 3 appears as though it is/will be closely in line with my own perspective on web application development. I'm interested in contributing to the development of the framework itself, but likely won't be able to produce anything remotely useful for a couple months as I familiarize myself with all of the related technologies. I've just read some of the attacks on the poor documentation of the project and the resulting difficult entry for those unfamiliar. This is, of course, easily confirmed by the combination of woefully out of date references and dead links on the Web site (i.e. to the Daisy site). As I am (obviously) hopeful to see Cocoon succeed, I certainly don't want it to become mired in isolation like so many good projects. As such I'd like to try to contribute some documentation. Is there any idea among the community as to where documentation should end up, or should I just create a new site? Also, I'd lean towards focusing on Cocoon 3, as having documentation in place for a new release would likely have larger impact than attaching possibly overdue docs to an older, in the process of being superseded one. This would be premature if there's no foreseeable beta
Re: REST / Can't find URLResponseBuilder
In the samples, a typical use of StringTemplate is shown: a page is to
be interpreted by the StringTemplate engine, and a number of properties
are passed via the hashtable.
The idea is that you would open a view on the object.
So,
- the query points to a resource
- the controller decodes what the resource is and what you want (view
it, update it?)
- the way to view it could be: pass my resource to a StringTemplate
invocation: new Page('stringtemplateinvocation',resource);
However, I have not tried to elaborate this so far. Shall I post it when
i have a useable example?
Cheers,
Jos
On Sat, 2009-11-28 at 14:14 +0100, Johannes Lichtenberger wrote:
It is now a bit hard to keep everything consistent, as there are
still
changes made in the interfaces.
Hm, it can't find alpha-2 (it really seems to be alpha-2 specific --
http://cocoon.apache.org/3.0/changes-report.html and it isn't
released)
and I'm not sure how to integrate the trunk version with maven. I've
used the mvn commands described uhm somewhere (for mysite, myparent,
mysample und mywebapp)...
Downloading:
http://repo1.maven.org/maven2/org/apache/cocoon/rest/cocoon-rest/3.0.0-alpha-2/cocoon-rest-3.0.0-alpha-2.jar
[INFO] Unable to find resource
StringTemplateGenerator
Dear,
Just a small question, testing:
When I get:
java.lang.NullPointerException
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.constructCacheKey(StringTemplateGenerator.java:75)
I notice that StringTemplateGenerator has two constructors: one with a
'source' argument, and one without.
The one without source argument is called.
Does this make sense? Am I making a mistake in the sitemap?
Here's the code:
map:match pattern=testcases/{name}.st
map:generate src=testcases/{map:name}.st
type=string-template/
map:serialize type=xhtml/
/map:match
Thanks,
Jos
Re: REST / Can't find URLResponseBuilder
org.apache.cocoon.rest.jaxrs.response.URLResponseBuilder.java What version do you have in your project pom? It should be alpha 2 I guess. Or build it from the svn trunk, svn co http://svn.apache.org/repos/asf/cocoon/cocoon3 It is now a bit hard to keep everything consistent, as there are still changes made in the interfaces. Jos On Sat, 2009-11-28 at 05:02 +0100, Johannes Lichtenberger wrote: URLResponseBuilder
Re: REST / own Generator
Hi Johannes,
Supposing your url is :gearth/parameter1?rp=parameter2
Get a sitemap parameter:
match=gearth/{mGearth}
controller:call controller=rest-controller select=myclass
map:parameter name=mGearth value={map:mGearth}/
/controller:call
In your controller code you can declare a variable to be a sitemap
parameter by annotatino:
@SitemapParameter
private String mGearth;
And for a simple request parameter this provides you with the request:
@Inject
private HttpServletRequest request;
upon which things are like the old days:
parameter2_value = request.getParameter(rp);
That should work.
Good luck,
Jos
On Tue, 2009-11-24 at 23:35 +0100, Johannes Lichtenberger wrote:
Hello,
I'm not sure if it's the right mailing list.
I've got a simple sitemap of the form:
!-- controller ~~~ --
map:pipeline
map:match pattern=gearth
controller:call controller=rest-controller
select=com.treetank.cocoon.controller.GoogleEarthController /
/map:match
map:match pattern=controller/screen
map:generate type=gearth /
map:serialize type=xml /
/map:match
/map:pipeline
My GoogleEarthController is very simple and looks like:
...
@Override
public RestResponse doGet() throws Exception {
final MapString, Object data = new HashMapString, Object();
data.put(mGEarth, mGEarth);
data.put(reqparam, reqparam);
return new Page(servlet:/controller/screen, data);
}
...
The only thing it should do is getting the sitemap parameter mGEarth and
the request parameters (which I then will process in the Generator with
a StringTokenizer...). So how do I get access to the data-HashMap in
my Generator?
greetings,
Johannes
Re: XInclude optimization
Hmmm, I guess the XPath expression is known before the parsing begins? I remember I have done a similar thing, where a chunk had to be isolated from a document that came by via a SAX stream, but here the xpath expression was something like: /element1/elemen...@id=somenumber]. Theorem: any XPath expression can be evaluated with a SAX filter. Proof? Do you know some exceptions? Jos
Re: changes to maven archetypes, alpha1 - alpha2
Being able to type pipeline output is certainly a good idea. I have the existing documentation as an eclipse project and there is litte doubt that I will have a couple of interesting articles to write after my first experience of application writing. OK, shall I make a request to apache.org? Cheers, Jos On Fri, 2009-11-20 at 10:10 +0100, Reinhard Pötz wrote: Jos Snellings wrote: With pleasure. By the way, I am starting to write a prototype for an application with the latest version. Yes, I am willing to take due changes in available classes. Here's a question: - will there be an alpha-3 phase? Yes. Although I consider the code as rather stable, we need more community involvement (your mails are very helpful by the way!) before we are ready to move on. The only technical issue is that I want to rework the pipeline API once again in order to support typed results. Currently a pipeline always writes into an OutputStream and if you need something else (e.g. a SAXBuffer, a business object, etc.) you have to work around by producing some side effect. - can you use some help in assembling the last nuts and bolts? Yes, that is very appreciated! It would be great if you had a look into the existing documentation or if you could event help with writing additional one. I am really pleased with the direction cocoon-3 took. It would be nice to have 3.0.0 out early 2009. I plan to create the release artifacts for alpha-2 by the end of the month.
Re: changes to maven archetypes, alpha1 - alpha2
With pleasure. By the way, I am starting to write a prototype for an application with the latest version. Yes, I am willing to take due changes in available classes. Here's a question: - will there be an alpha-3 phase? - can you use some help in assembling the last nuts and bolts? I am really pleased with the direction cocoon-3 took. It would be nice to have 3.0.0 out early 2009. Cheers, Jos On Wed, 2009-11-18 at 16:49 +0100, Reinhard Pötz wrote: Jos Snellings wrote: DemoRESTController: import org.apache.cocoon.rest.controller.response.Page; must be replaced by org.apache.cocoon.rest.controller.response.URLResponse; TimeStampGenerator: import org.apache.cocoon.pipeline.component.sax.AbstractGenerator; import org.apache.cocoon.pipeline.component.sax.XMLConsumer; import org.apache.cocoon.pipeline.util.ImmutableAttributesImpl; the first two classed have been refactored to cocoon-sax, so org.apache.cocoon.sax.AbstractSAXProducer; org.apache.cocoon.sax.SAXConsumer; and the ImmutableAttributesImpl, I could not find anymore, what's wrong with: org.apache.cocoon.sitemap.xml.AttributesImpl; It should be removed. I can't remember why it was put into the sitemap module at all. You can find AttributesImpl in the cocoon-xml subproject (org.apache.cocoon.xml.sax.AttributesImpl). And many thanks for starting with an alpha-1 to alpha-2 summary.
changes to maven archetypes, alpha1 - alpha2
DemoRESTController: import org.apache.cocoon.rest.controller.response.Page; must be replaced by org.apache.cocoon.rest.controller.response.URLResponse; TimeStampGenerator: import org.apache.cocoon.pipeline.component.sax.AbstractGenerator; import org.apache.cocoon.pipeline.component.sax.XMLConsumer; import org.apache.cocoon.pipeline.util.ImmutableAttributesImpl; the first two classed have been refactored to cocoon-sax, so org.apache.cocoon.sax.AbstractSAXProducer; org.apache.cocoon.sax.SAXConsumer; and the ImmutableAttributesImpl, I could not find anymore, what's wrong with: org.apache.cocoon.sitemap.xml.AttributesImpl; Is that OK? Jos
URLStreamHandler
Hi, I am currently looking if a minimal cocoon distribution could be deployed under Google AppEngine. Unfortunately, java.net.URLStreamHandler is not on the whitelist. Any idea how 'hard' it would be to lift this dependency (java.net.URL and URLConnection can be used)? I guess GAE just wants to keep its applications from opening connections on any server with any protocol. Best, Jos
Re: [c3] auth
Hi, I coded the functionality of an 'auth' block with: - an action authenticate, which inserts the valid user in the HttpSession - a custom 'AuthenticationException when login fails A candidate was 'RESTController'. However, it seems that the setup method of a controller is never called. How can one get access to the HttpRequest from within a controller? I mean, in fact to get access to the session? I assume that it poses no problem to mix http and https urls within one sitemap? Can you confirm this? Which url do I need to perform a svn checkout from trunk of the most actual cocoon-3 source? When is the first beta-release for cocoon-3 scheduled? Thanks, Jos
Re: [c3] auth
Hi Reinhard, Is this a design choice? As I try to read the general idea, Cocoon 3 is to be minimal and would have only a dependency on the Spring framework. Somebody considering to build a web application with cocoon that needs authentication would have to code the page redirection mechanism herself? Assuming that a JAAS/LDAP component is plugged in via Sping, the logic of For a realm filtered by url characteristics (say 'secure/*.*') 'is there a HttpSession which has a remote user? yes - OK, through with processing, based upon role/rights no - send to login page, or 'forbidden' page, whereby the login page captures authentication tokes from user and feeds that to the authentication component (which itself is an indepent component. Not that it is very difficult to code such behaviour for an individual application, but to enable this from within the sitemap looks perfecly sound within the cocoon philosophy, thereby avoiding to insert permission checks into the data access layer. What do you think? Kind regards, Jos Snellings On Fri, 2009-08-14 at 18:01 +0200, Reinhard Pötz wrote: Jos Snellings wrote: Dear, In cocoon 3 I do not find back the auth mechanism (org.apache.cocoon.auth), which comes in very handy to secure a range of urls. In addition, I could not find the notion of application. Will the 'old' construct to build a session hold in cocoon-3? Is the mechanism available in spite of my unability to find it at first glance? Hi Jos, unfortunately there is no equivalent of the C2-Auth block in Cocoon 3 available.
auth
Dear, In cocoon 3 I do not find back the auth mechanism (org.apache.cocoon.auth), which comes in very handy to secure a range of urls. In addition, I could not find the notion of application. Will the 'old' construct to build a session hold in cocoon-3? Is the mechanism available in spite of my unability to find it at first glance? Best, Jos Snellings
