Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Thorsten Scherler wrote: > El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió: >> Thorsten Scherler wrote: >>> El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: David Crossley wrote: > Upayavira wrote: >> Sylvain Wallez wrote: >>> Carsten Ziegeler wrote: Sylvain Wallez wrote: > Hmm... the current CLI uses Cocoon's links view to crawl the website. > So > although the new crawler can be based on servlets, it will assume > these > servlets to answer to a ?cocoon-view=links :-) > Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. >>> In the case of Forrest, you're probably right. Now the links view also >>> allows to follow links in pipelines producing something that's not HTML, >>> such as PDF, SVG, WML, etc. >>> >>> We have to decide if we want to loose this feature. > I am not sure if we use this in Forrest. If not > then we probably should be. > >> In my view, the whole idea of crawling (i.e. gathering links from pages) >> is suboptimal anyway. For example, some sites don't directly link to all >> pages (e.g. they are accessed via javascript, or whatever) so you get >> pages missed. >> >> Were I to code a new CLI, whilst I would support crawling I would mainly >> configure the CLI to get the list of pages to visit by calling one or >> more URLs. Those URLs would specify the pages to generate. >> >> Thus, Forrest would transform its site.xml file into this list of pages, >> and drive the CLI via that. > This is what we do do. We have a property > "start-uri=linkmap.html" > http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html > (we actually use corresponding xml of course). > > We define a few extra URIs in the Cocoon cli.xconf > > There are issues of course. Sometimes we want to > include directories of files that are not referenced > in site.xml navigation. For my sites i just use a > DirectoryGenerator to build an index page which feeds > the crawler. Sometime that technique is not sufficent. > > We also gather links from text files (e.g. CSS) > using Chaperon. This works nicely but introduces > some overhead. This more or less confirms my suggested approach - allow crawling at the 'end-point' HTML, but more importantly, use a page/URL to identify the pages to be crawled. The interesting thing from what you say is that this page could itself be nothing more than HTML. >>> Well, yes and not really, since e.g. Chaperon is text based and no >>> markup. You need a lex-writer to generate links for the crawler. >> Yes. You misunderstand me I think. > > Yes, sorry I did misunderstood you. > >> Even if you use Chaperon etc to parse >> markup, there'd be no difficulty expressing the links that you found as >> an HTML page - one intended to be consumed by the CLI, not to be >> publically viewed. > > Well in the case of css you want them as well publically viewed but I > got your point. ;) > >> In fact, if it were written to disc, forrest would >> probably delete it afterwards. >> >>> Forrest actually is *not* aimed for html only support and one can think >>> of the situation that you want your site to be only txt (kind of a >>> book). Here you need to crawler the lex-rewriter outcome and follow the >>> links. >> Hopefully I've shown that I had understood that already :-) > > yeah ;) > >>> The current limitation of forrest regarding the crawler are IMO not >>> caused by the crawler design but rather by our (as in forrest) usage of >>> it. >> Yep, fair enough. But if the CLI is going to survive the shift that is >> happening in Cocoon trunk, something big needs to be done by someone. It >> cannot survive in its current form as the code it uses is changing >> almost beyond recognition. >> >> Heh, perhaps the Cocoon CLI should just be a Maven plugin. > > ...or forrest plugin. ;) This would makes it possible that cocoon, lenya > and forrest committer can help. > > Kind of http://svn.apache.org/viewcvs.cgi/lenya/sandbox/doco/ ;) Well, in the end, it is he who implements that decides. Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió: > Thorsten Scherler wrote: > > El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: > >> David Crossley wrote: > >>> Upayavira wrote: > Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > >> Sylvain Wallez wrote: > >>> Hmm... the current CLI uses Cocoon's links view to crawl the website. > >>> So > >>> although the new crawler can be based on servlets, it will assume > >>> these > >>> servlets to answer to a ?cocoon-view=links :-) > >>> > >> Hmm, I think we don't need the links view in this case anymore. A > >> simple > >> HTML crawler should be enough as it will follow all links on the page. > >> The view would only make sense in the case where you don't output html > >> where the usual crawler tools would not work. > >> > > In the case of Forrest, you're probably right. Now the links view also > > allows to follow links in pipelines producing something that's not HTML, > > such as PDF, SVG, WML, etc. > > > > We have to decide if we want to loose this feature. > >>> I am not sure if we use this in Forrest. If not > >>> then we probably should be. > >>> > In my view, the whole idea of crawling (i.e. gathering links from pages) > is suboptimal anyway. For example, some sites don't directly link to all > pages (e.g. they are accessed via javascript, or whatever) so you get > pages missed. > > Were I to code a new CLI, whilst I would support crawling I would mainly > configure the CLI to get the list of pages to visit by calling one or > more URLs. Those URLs would specify the pages to generate. > > Thus, Forrest would transform its site.xml file into this list of pages, > and drive the CLI via that. > >>> This is what we do do. We have a property > >>> "start-uri=linkmap.html" > >>> http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html > >>> (we actually use corresponding xml of course). > >>> > >>> We define a few extra URIs in the Cocoon cli.xconf > >>> > >>> There are issues of course. Sometimes we want to > >>> include directories of files that are not referenced > >>> in site.xml navigation. For my sites i just use a > >>> DirectoryGenerator to build an index page which feeds > >>> the crawler. Sometime that technique is not sufficent. > >>> > >>> We also gather links from text files (e.g. CSS) > >>> using Chaperon. This works nicely but introduces > >>> some overhead. > >> This more or less confirms my suggested approach - allow crawling at the > >> 'end-point' HTML, but more importantly, use a page/URL to identify the > >> pages to be crawled. The interesting thing from what you say is that > >> this page could itself be nothing more than HTML. > > > > Well, yes and not really, since e.g. Chaperon is text based and no > > markup. You need a lex-writer to generate links for the crawler. > > Yes. You misunderstand me I think. Yes, sorry I did misunderstood you. > Even if you use Chaperon etc to parse > markup, there'd be no difficulty expressing the links that you found as > an HTML page - one intended to be consumed by the CLI, not to be > publically viewed. Well in the case of css you want them as well publically viewed but I got your point. ;) > In fact, if it were written to disc, forrest would > probably delete it afterwards. > > > Forrest actually is *not* aimed for html only support and one can think > > of the situation that you want your site to be only txt (kind of a > > book). Here you need to crawler the lex-rewriter outcome and follow the > > links. > > Hopefully I've shown that I had understood that already :-) yeah ;) > > > The current limitation of forrest regarding the crawler are IMO not > > caused by the crawler design but rather by our (as in forrest) usage of > > it. > > Yep, fair enough. But if the CLI is going to survive the shift that is > happening in Cocoon trunk, something big needs to be done by someone. It > cannot survive in its current form as the code it uses is changing > almost beyond recognition. > > Heh, perhaps the Cocoon CLI should just be a Maven plugin. ...or forrest plugin. ;) This would makes it possible that cocoon, lenya and forrest committer can help. Kind of http://svn.apache.org/viewcvs.cgi/lenya/sandbox/doco/ ;) salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Thorsten Scherler wrote: > El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: >> David Crossley wrote: >>> Upayavira wrote: Sylvain Wallez wrote: > Carsten Ziegeler wrote: >> Sylvain Wallez wrote: >>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So >>> although the new crawler can be based on servlets, it will assume these >>> servlets to answer to a ?cocoon-view=links :-) >>> >> Hmm, I think we don't need the links view in this case anymore. A simple >> HTML crawler should be enough as it will follow all links on the page. >> The view would only make sense in the case where you don't output html >> where the usual crawler tools would not work. >> > In the case of Forrest, you're probably right. Now the links view also > allows to follow links in pipelines producing something that's not HTML, > such as PDF, SVG, WML, etc. > > We have to decide if we want to loose this feature. >>> I am not sure if we use this in Forrest. If not >>> then we probably should be. >>> In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. >>> This is what we do do. We have a property >>> "start-uri=linkmap.html" >>> http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html >>> (we actually use corresponding xml of course). >>> >>> We define a few extra URIs in the Cocoon cli.xconf >>> >>> There are issues of course. Sometimes we want to >>> include directories of files that are not referenced >>> in site.xml navigation. For my sites i just use a >>> DirectoryGenerator to build an index page which feeds >>> the crawler. Sometime that technique is not sufficent. >>> >>> We also gather links from text files (e.g. CSS) >>> using Chaperon. This works nicely but introduces >>> some overhead. >> This more or less confirms my suggested approach - allow crawling at the >> 'end-point' HTML, but more importantly, use a page/URL to identify the >> pages to be crawled. The interesting thing from what you say is that >> this page could itself be nothing more than HTML. > > Well, yes and not really, since e.g. Chaperon is text based and no > markup. You need a lex-writer to generate links for the crawler. Yes. You misunderstand me I think. Even if you use Chaperon etc to parse markup, there'd be no difficulty expressing the links that you found as an HTML page - one intended to be consumed by the CLI, not to be publically viewed. In fact, if it were written to disc, forrest would probably delete it afterwards. > Forrest actually is *not* aimed for html only support and one can think > of the situation that you want your site to be only txt (kind of a > book). Here you need to crawler the lex-rewriter outcome and follow the > links. Hopefully I've shown that I had understood that already :-) > The current limitation of forrest regarding the crawler are IMO not > caused by the crawler design but rather by our (as in forrest) usage of > it. Yep, fair enough. But if the CLI is going to survive the shift that is happening in Cocoon trunk, something big needs to be done by someone. It cannot survive in its current form as the code it uses is changing almost beyond recognition. Heh, perhaps the Cocoon CLI should just be a Maven plugin. Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: > David Crossley wrote: > > Upayavira wrote: > >> Sylvain Wallez wrote: > >>> Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > Hmm... the current CLI uses Cocoon's links view to crawl the website. So > > although the new crawler can be based on servlets, it will assume these > > servlets to answer to a ?cocoon-view=links :-) > > > Hmm, I think we don't need the links view in this case anymore. A simple > HTML crawler should be enough as it will follow all links on the page. > The view would only make sense in the case where you don't output html > where the usual crawler tools would not work. > > >>> In the case of Forrest, you're probably right. Now the links view also > >>> allows to follow links in pipelines producing something that's not HTML, > >>> such as PDF, SVG, WML, etc. > >>> > >>> We have to decide if we want to loose this feature. > > > > I am not sure if we use this in Forrest. If not > > then we probably should be. > > > >> In my view, the whole idea of crawling (i.e. gathering links from pages) > >> is suboptimal anyway. For example, some sites don't directly link to all > >> pages (e.g. they are accessed via javascript, or whatever) so you get > >> pages missed. > >> > >> Were I to code a new CLI, whilst I would support crawling I would mainly > >> configure the CLI to get the list of pages to visit by calling one or > >> more URLs. Those URLs would specify the pages to generate. > >> > >> Thus, Forrest would transform its site.xml file into this list of pages, > >> and drive the CLI via that. > > > > This is what we do do. We have a property > > "start-uri=linkmap.html" > > http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html > > (we actually use corresponding xml of course). > > > > We define a few extra URIs in the Cocoon cli.xconf > > > > There are issues of course. Sometimes we want to > > include directories of files that are not referenced > > in site.xml navigation. For my sites i just use a > > DirectoryGenerator to build an index page which feeds > > the crawler. Sometime that technique is not sufficent. > > > > We also gather links from text files (e.g. CSS) > > using Chaperon. This works nicely but introduces > > some overhead. > > This more or less confirms my suggested approach - allow crawling at the > 'end-point' HTML, but more importantly, use a page/URL to identify the > pages to be crawled. The interesting thing from what you say is that > this page could itself be nothing more than HTML. Well, yes and not really, since e.g. Chaperon is text based and no markup. You need a lex-writer to generate links for the crawler. Forrest actually is *not* aimed for html only support and one can think of the situation that you want your site to be only txt (kind of a book). Here you need to crawler the lex-rewriter outcome and follow the links. The current limitation of forrest regarding the crawler are IMO not caused by the crawler design but rather by our (as in forrest) usage of it. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
David Crossley wrote: > Upayavira wrote: >> Sylvain Wallez wrote: >>> Carsten Ziegeler wrote: Sylvain Wallez wrote: > Hmm... the current CLI uses Cocoon's links view to crawl the website. So > although the new crawler can be based on servlets, it will assume these > servlets to answer to a ?cocoon-view=links :-) > Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. >>> In the case of Forrest, you're probably right. Now the links view also >>> allows to follow links in pipelines producing something that's not HTML, >>> such as PDF, SVG, WML, etc. >>> >>> We have to decide if we want to loose this feature. > > I am not sure if we use this in Forrest. If not > then we probably should be. > >> In my view, the whole idea of crawling (i.e. gathering links from pages) >> is suboptimal anyway. For example, some sites don't directly link to all >> pages (e.g. they are accessed via javascript, or whatever) so you get >> pages missed. >> >> Were I to code a new CLI, whilst I would support crawling I would mainly >> configure the CLI to get the list of pages to visit by calling one or >> more URLs. Those URLs would specify the pages to generate. >> >> Thus, Forrest would transform its site.xml file into this list of pages, >> and drive the CLI via that. > > This is what we do do. We have a property > "start-uri=linkmap.html" > http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html > (we actually use corresponding xml of course). > > We define a few extra URIs in the Cocoon cli.xconf > > There are issues of course. Sometimes we want to > include directories of files that are not referenced > in site.xml navigation. For my sites i just use a > DirectoryGenerator to build an index page which feeds > the crawler. Sometime that technique is not sufficent. > > We also gather links from text files (e.g. CSS) > using Chaperon. This works nicely but introduces > some overhead. This more or less confirms my suggested approach - allow crawling at the 'end-point' HTML, but more importantly, use a page/URL to identify the pages to be crawled. The interesting thing from what you say is that this page could itself be nothing more than HTML. Regards, Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Upayavira wrote: > Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > >> Sylvain Wallez wrote: > > > >>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So > >>> although the new crawler can be based on servlets, it will assume these > >>> servlets to answer to a ?cocoon-view=links :-) > >>> > >> Hmm, I think we don't need the links view in this case anymore. A simple > >> HTML crawler should be enough as it will follow all links on the page. > >> The view would only make sense in the case where you don't output html > >> where the usual crawler tools would not work. > >> > > > > In the case of Forrest, you're probably right. Now the links view also > > allows to follow links in pipelines producing something that's not HTML, > > such as PDF, SVG, WML, etc. > > > > We have to decide if we want to loose this feature. I am not sure if we use this in Forrest. If not then we probably should be. > In my view, the whole idea of crawling (i.e. gathering links from pages) > is suboptimal anyway. For example, some sites don't directly link to all > pages (e.g. they are accessed via javascript, or whatever) so you get > pages missed. > > Were I to code a new CLI, whilst I would support crawling I would mainly > configure the CLI to get the list of pages to visit by calling one or > more URLs. Those URLs would specify the pages to generate. > > Thus, Forrest would transform its site.xml file into this list of pages, > and drive the CLI via that. This is what we do do. We have a property "start-uri=linkmap.html" http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html (we actually use corresponding xml of course). We define a few extra URIs in the Cocoon cli.xconf There are issues of course. Sometimes we want to include directories of files that are not referenced in site.xml navigation. For my sites i just use a DirectoryGenerator to build an index page which feeds the crawler. Sometime that technique is not sufficent. We also gather links from text files (e.g. CSS) using Chaperon. This works nicely but introduces some overhead. -David > Whilst gathering links from within pipelines is clever, it always struck > me as awkward at the same time. > > Regards, Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Sylvain Wallez wrote: > Carsten Ziegeler wrote: >> Sylvain Wallez wrote: >> > >>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So >>> although the new crawler can be based on servlets, it will assume these >>> servlets to answer to a ?cocoon-view=links :-) >>> >> Hmm, I think we don't need the links view in this case anymore. A simple >> HTML crawler should be enough as it will follow all links on the page. >> The view would only make sense in the case where you don't output html >> where the usual crawler tools would not work. >> > > In the case of Forrest, you're probably right. Now the links view also > allows to follow links in pipelines producing something that's not HTML, > such as PDF, SVG, WML, etc. > > We have to decide if we want to loose this feature. In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. Whilst gathering links from within pipelines is clever, it always struck me as awkward at the same time. Regards, Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Sylvain Wallez wrote: > Carsten Ziegeler wrote: > In the case of Forrest, you're probably right. Now the links view also > allows to follow links in pipelines producing something that's not HTML, > such as PDF, SVG, WML, etc. Yepp. > > We have to decide if we want to loose this feature. Right. So the question is, if someone is using this feature :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Carsten Ziegeler wrote: > Sylvain Wallez wrote: > >> Hmm... the current CLI uses Cocoon's links view to crawl the website. So >> although the new crawler can be based on servlets, it will assume these >> servlets to answer to a ?cocoon-view=links :-) >> > Hmm, I think we don't need the links view in this case anymore. A simple > HTML crawler should be enough as it will follow all links on the page. > The view would only make sense in the case where you don't output html > where the usual crawler tools would not work. > In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Sylvain Wallez wrote: > Upayavira wrote: > >> Ah, I wasn't getting that subtle. I was simply saying that I can agree >> with using the servlet API for _all_ environments. The CLI becomes >> nothing more than a custom servlet container that uses a servlet to >> generate its pages. >> >> In fact, having said that, it becomes yet another tool that is actually >> independent of Cocoon - it could be used to crawl pages generated by >> _any_ servlet, not just the Cocoon one. >> > > Hmm... the current CLI uses Cocoon's links view to crawl the website. So > although the new crawler can be based on servlets, it will assume these > servlets to answer to a ?cocoon-view=links :-) > Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Upayavira wrote: > Ah, I wasn't getting that subtle. I was simply saying that I can agree > with using the servlet API for _all_ environments. The CLI becomes > nothing more than a custom servlet container that uses a servlet to > generate its pages. > > In fact, having said that, it becomes yet another tool that is actually > independent of Cocoon - it could be used to crawl pages generated by > _any_ servlet, not just the Cocoon one. > Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
A new CLI (was Re: [RT] The environment abstraction, part II)
Carsten Ziegeler wrote: > Upayavira wrote: >> David Crossley wrote: >>> Carsten Ziegeler wrote: I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? >>> Thanks to you all for the followup. I don't have a >>> ready answer yet. Will make sure that the other >>> Forrest people are aware. >> In the end, it doesn't really matter that much, and will be up to >> whoever volunteers to implement the new CLI. > > It depends a little bit on how we see things. My opinion :) is to remove > the environment > abstraction completly and simply use the servlet environment while > others might think that we should only base our environment abstraction > on the servlet api but allow to run Cocoon in a different environment > which provides *some* features of the servlet environment but not all. > The difference might be subtle, but its not the same. Ah, I wasn't getting that subtle. I was simply saying that I can agree with using the servlet API for _all_ environments. The CLI becomes nothing more than a custom servlet container that uses a servlet to generate its pages. In fact, having said that, it becomes yet another tool that is actually independent of Cocoon - it could be used to crawl pages generated by _any_ servlet, not just the Cocoon one. Regards, Upayavira
Re: [RT] The environment abstraction, part II
Upayavira wrote: > David Crossley wrote: >> Carsten Ziegeler wrote: >>> I can't speak for Daniel, but my idea/suggestion was to forget about the >>> different environments and let Cocoon always run in a servlet container. >>> The CLI would then be kind of a http client which starts up jetty and >>> then generates the site using http requests. This would simplify some >>> things in Cocoon, the question is if this would make the life of Forrest >>> too hard? >> Thanks to you all for the followup. I don't have a >> ready answer yet. Will make sure that the other >> Forrest people are aware. > > In the end, it doesn't really matter that much, and will be up to > whoever volunteers to implement the new CLI. It depends a little bit on how we see things. My opinion :) is to remove the environment abstraction completly and simply use the servlet environment while others might think that we should only base our environment abstraction on the servlet api but allow to run Cocoon in a different environment which provides *some* features of the servlet environment but not all. The difference might be subtle, but its not the same. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
David Crossley wrote: > Carsten Ziegeler wrote: >> I can't speak for Daniel, but my idea/suggestion was to forget about the >> different environments and let Cocoon always run in a servlet container. >> The CLI would then be kind of a http client which starts up jetty and >> then generates the site using http requests. This would simplify some >> things in Cocoon, the question is if this would make the life of Forrest >> too hard? > > Thanks to you all for the followup. I don't have a > ready answer yet. Will make sure that the other > Forrest people are aware. In the end, it doesn't really matter that much, and will be up to whoever volunteers to implement the new CLI. Having said that, I think it makes sense for the CLI to have its own, minimal servlet container. It could just use Jetty, but it would be better/faster if the container didn't serve over http, i.e. require an http client too. Regards, Upayavira
Re: [RT] The environment abstraction, part II
El vie, 31-03-2006 a las 14:32 +1100, David Crossley escribió: > Carsten Ziegeler wrote: > > > > I can't speak for Daniel, but my idea/suggestion was to forget about the > > different environments and let Cocoon always run in a servlet container. > > The CLI would then be kind of a http client which starts up jetty and > > then generates the site using http requests. This would simplify some > > things in Cocoon, the question is if this would make the life of Forrest > > too hard? > > Thanks to you all for the followup. I don't have a > ready answer yet. Will make sure that the other > Forrest people are aware. > El mié, 29-03-2006 a las 22:54 +0200, Daniel Fagerstrom escribió: > > So the current CLI is a minimal command line Processor container, we > could have a minimal command line Servlet container instead. I do not see a problem. I guess noone has to even notice the differents. There is http://jakarta.apache.org/commons/httpclient/ I do not see a problem for forrest. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: [RT] The environment abstraction, part II
David Crossley wrote: Carsten Ziegeler wrote: I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? Thanks to you all for the followup. I don't have a ready answer yet. Will make sure that the other Forrest people are aware. Which David has done, with a post to the Forrest list - you may see a few of us post now. I've reviewed this thread, in my opinion and *only* from a Forrest perspective I feel it is unimportant how we generate the static site from Forrest. To be honest, I don't really care if we end up bundling a building/bundling a small crawler along the lines of wget in order to do the static generation (although it is great we won't need to). It looks to me like the proposals here will make life inside Cocoon much easier. This will, undoubtedly, have a knock on effect for projects like Forrest. I'm sure we will have to go through a period of pain before reaping the rewards - but I believe it will be worth it. --- Speaking in a from a wider perspective. I would ask one important question "how many other users, besides Forrest, make heavy use of the CLI and would they be damaged by this proposal?" I would *guess* this is a low number since Cocoon is a *web* framework. Ross
Re: [RT] The environment abstraction, part II
Carsten Ziegeler wrote: > > I can't speak for Daniel, but my idea/suggestion was to forget about the > different environments and let Cocoon always run in a servlet container. > The CLI would then be kind of a http client which starts up jetty and > then generates the site using http requests. This would simplify some > things in Cocoon, the question is if this would make the life of Forrest > too hard? Thanks to you all for the followup. I don't have a ready answer yet. Will make sure that the other Forrest people are aware. -David
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > Carsten Ziegeler skrev: >> David Crossley wrote: >> >> >>> Hi Daniel, sorry i cannot understand that last sentence. >>> Would you please re-phrase it. >>> >>> We currently have the three ways: >>> >>> 'forrest run' >>> Starts its packaged Jetty and uses Forrest/Cocoon as a webapp. >>> >>> 'forrest war' >>> Builds a projectName.war ready for deployment in a full Jetty >>> or Tomcat. >>> >>> 'forrest site' >>> Calls the Cocoon CLI to generate a static set of docs. >>> >>> >> I can't speak for Daniel, but my idea/suggestion was to forget about the >> different environments and let Cocoon always run in a servlet container. >> The CLI would then be kind of a http client which starts up jetty and >> then generates the site using http requests. This would simplify some >> things in Cocoon, the question is if this would make the life of Forrest >> too hard? >> > In Cocoon today, the Cocoon object that implements the Processor > interface is in some way the top level interface against "Cocoon > functionality". Then the CocoonServlet and the CLI booth sets up and use > the Cocoon object. When creating the blocks fw, Processor didn't work as > abstraction as it contains lots of tree processor specifics. So I > decided to use the Servlet and javax.servlet.http set of interfaces > instead (as discussed on the list a couple of times). This means that > the CLI in it current state (working against the Processor interface) > doesn't work with the blocks fw. So the CLI needs to be refactored so > that it works with a Servlet rather than a Processor. > > To some extent this is actually an advantage as the CocoonServlet and > the CLI has a lot of overlap and the servlet part has been maintained > and developed while the CLI part hasn't. By using Servlet as the "top > level" interface of Cocoon the CLI will be much smaller and reuse more > of the Servlet work. > > Back to your question, my incomprehensible sentence was an answer to > something like what Carsten propose above. In many cases I agree with > Carsten that it makes most sense to run Cocoon in a full servlet > container but in some cases, e.g. testing and for a minimal OSGi setup, > it makes IMO sense to have a really light weight and minimal servlet > container instead. I have built a such one for creating the servlet > environment needed for running a servlet within a block and make it > possible for it to communicate with other blocks. It is also used for > the block protocol (the block correspondence to the Cocoon protocol). We > could reuse part of this for the CLI. > > So the current CLI is a minimal command line Processor container, we > could have a minimal command line Servlet container instead. This makes complete sense to me and is exactly how I would have proposed implementing it. Upayavira
Re: [RT] The environment abstraction, part II
Carsten Ziegeler skrev: David Crossley wrote: Hi Daniel, sorry i cannot understand that last sentence. Would you please re-phrase it. We currently have the three ways: 'forrest run' Starts its packaged Jetty and uses Forrest/Cocoon as a webapp. 'forrest war' Builds a projectName.war ready for deployment in a full Jetty or Tomcat. 'forrest site' Calls the Cocoon CLI to generate a static set of docs. I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? In Cocoon today, the Cocoon object that implements the Processor interface is in some way the top level interface against "Cocoon functionality". Then the CocoonServlet and the CLI booth sets up and use the Cocoon object. When creating the blocks fw, Processor didn't work as abstraction as it contains lots of tree processor specifics. So I decided to use the Servlet and javax.servlet.http set of interfaces instead (as discussed on the list a couple of times). This means that the CLI in it current state (working against the Processor interface) doesn't work with the blocks fw. So the CLI needs to be refactored so that it works with a Servlet rather than a Processor. To some extent this is actually an advantage as the CocoonServlet and the CLI has a lot of overlap and the servlet part has been maintained and developed while the CLI part hasn't. By using Servlet as the "top level" interface of Cocoon the CLI will be much smaller and reuse more of the Servlet work. Back to your question, my incomprehensible sentence was an answer to something like what Carsten propose above. In many cases I agree with Carsten that it makes most sense to run Cocoon in a full servlet container but in some cases, e.g. testing and for a minimal OSGi setup, it makes IMO sense to have a really light weight and minimal servlet container instead. I have built a such one for creating the servlet environment needed for running a servlet within a block and make it possible for it to communicate with other blocks. It is also used for the block protocol (the block correspondence to the Cocoon protocol). We could reuse part of this for the CLI. So the current CLI is a minimal command line Processor container, we could have a minimal command line Servlet container instead. WDYT? /Daniel
Re: [RT] The environment abstraction, part II
David Crossley wrote: > Hi Daniel, sorry i cannot understand that last sentence. > Would you please re-phrase it. > > We currently have the three ways: > > 'forrest run' > Starts its packaged Jetty and uses Forrest/Cocoon as a webapp. > > 'forrest war' > Builds a projectName.war ready for deployment in a full Jetty > or Tomcat. > > 'forrest site' > Calls the Cocoon CLI to generate a static set of docs. > I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
On Thu, Feb 02, 2006 Daniel Fagerstrom wrote: > Carsten Ziegeler skrev: > >Daniel Fagerstrom wrote: > >>AFAIK you can't call filters and listeners from within servlets, so they > >>are at the servlet container level, and I don't see how a block would > >>need them. A block could certainly need something that a listener put in > >>a context attribute or that a filter did to the request, but that is > >>another question. > >> > >There was recently a discussion here about adding a servlet listener for > >some functionality in the xsp block - I don't know what, but the > >important message is that this will happen and already happens: some > >blocks need more than just the servlet: like listeners or filters or > >whatever the servlet spec requires. > > As I said, servlet listeners are for putting something in a context > attribute so that it is available to the servlet. With blocks we have a > sophisticated component layer that is available for all blocks, so I > fail to see why anyone would need to use a servlet listener at the block > level. You need to go into the details of the above usecase to convince me. > > Filters might be usable within blocks, but it is a rather crude > mechanism compared to pipelines, so I need usecases to become convinced > that it would be worthwhile to support. > > >And as soon as a block uses these > >features you need a full servlet environment and not just a http > >request, response and context. > > Question is still why a block would need them. > > >In addition, I could imagine that Cocoon provides filters which might be > >used by other web frameworks running in the same web app as Cocoon. > >I might be wrong, but I think another issue is if you are using spring. > >Spring is initialized through a servlet listener and is assuming a > >servlet context to work properly. So as soon as you don't have the > >listener, you can use Spring in that way. > > IIUC, the idea is that you start a Spring container complete with > component configurations and everything in a servlet listener, then it > makes it service manager available from within the servlets through a > context attribute. > > I'm rather certain that we would prefer a less primitive Spring > integration in the blocks architecture. One where the Spring container > is started within the blocks architecture and where a block can contain > Spring managed components with its own component configuration. > > >Of course there are other ways > >of using Spring which would also work in a CLI but they do not leverage > >the special web functionality. So you either don't use that or you have > >two versions, one for the Cli and one for the web. > > As described above "the special web functionality" is a hack around the > fact that servlets are more isolated from each other than one would > prefer from a system building design POV, blocks was created to address > this issues with the servlet architecture. > > >I can imagine more scenarios for these kind of things and we could avoid > >all of them. The only drawback - if you want to call it drawback - is > >that the CLI is firing up internally a servlet engine. But I could > >imagine that this "clarification of environments" would also make the > >work for Forrest easier in the end. > > I think it would be enough if we provide a lightweight CLI that just set > up context, request and response. If someone want to use Forrest in a > full servlet container I wonder if there really is any usecases for > needing to do that from the CLI, why not just use a web server in that case. Hi Daniel, sorry i cannot understand that last sentence. Would you please re-phrase it. We currently have the three ways: 'forrest run' Starts its packaged Jetty and uses Forrest/Cocoon as a webapp. 'forrest war' Builds a projectName.war ready for deployment in a full Jetty or Tomcat. 'forrest site' Calls the Cocoon CLI to generate a static set of docs. -David
Re: [RT] The environment abstraction, part II
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: AFAIK you can't call filters and listeners from within servlets, so they are at the servlet container level, and I don't see how a block would need them. A block could certainly need something that a listener put in a context attribute or that a filter did to the request, but that is another question. There was recently a discussion here about adding a servlet listener for some functionality in the xsp block - I don't know what, but the important message is that this will happen and already happens: some blocks need more than just the servlet: like listeners or filters or whatever the servlet spec requires. As I said, servlet listeners are for putting something in a context attribute so that it is available to the servlet. With blocks we have a sophisticated component layer that is available for all blocks, so I fail to see why anyone would need to use a servlet listener at the block level. You need to go into the details of the above usecase to convince me. Filters might be usable within blocks, but it is a rather crude mechanism compared to pipelines, so I need usecases to become convinced that it would be worthwhile to support. And as soon as a block uses these features you need a full servlet environment and not just a http request, response and context. Question is still why a block would need them. In addition, I could imagine that Cocoon provides filters which might be used by other web frameworks running in the same web app as Cocoon. I might be wrong, but I think another issue is if you are using spring. Spring is initialized through a servlet listener and is assuming a servlet context to work properly. So as soon as you don't have the listener, you can use Spring in that way. IIUC, the idea is that you start a Spring container complete with component configurations and everything in a servlet listener, then it makes it service manager available from within the servlets through a context attribute. I'm rather certain that we would prefer a less primitive Spring integration in the blocks architecture. One where the Spring container is started within the blocks architecture and where a block can contain Spring managed components with its own component configuration. Of course there are other ways of using Spring which would also work in a CLI but they do not leverage the special web functionality. So you either don't use that or you have two versions, one for the Cli and one for the web. As described above "the special web functionality" is a hack around the fact that servlets are more isolated from each other than one would prefer from a system building design POV, blocks was created to address this issues with the servlet architecture. I can imagine more scenarios for these kind of things and we could avoid all of them. The only drawback - if you want to call it drawback - is that the CLI is firing up internally a servlet engine. But I could imagine that this "clarification of environments" would also make the work for Forrest easier in the end. I think it would be enough if we provide a lightweight CLI that just set up context, request and response. If someone want to use Forrest in a full servlet container I wonder if there really is any usecases for needing to do that from the CLI, why not just use a web server in that case. /Daniel
Re: [RT] The environment abstraction, part II
Reinhard Poetz skrev: Daniel Fagerstrom wrote: Upayavira skrev: Daniel Fagerstrom wrote: Upayavira wrote: ... We can also release with non OSGi blocks. The blocks are ongoing work, the most important thing that lacks is "two level configuration". As discussed before the component configuration is part of the block and constant, so they need to be parametrized in some way for making them user configurable. We have not had much discussion about how to do this yet. My understanding is that a user can parameterize a block at deployment (which is supported by the block deployer) if he wants. Otherwise the default values are taken. Yes, but that says nothing about the details about parametrization of components (which isn't implemented yet), does it? Also the APIs and concepts for blocks need to actually be used for some real life examples before we can be convinced that we got it right. Of course. I'm working on getting trunk as far as making it very simple to use it for custom projects. Then I will start to rework at least one of my projects to use blocks and learn more about their real life usage. We should make it easy that at least we developers (and some brave users) can start to experiment. Hope to be able to use it in my projects as well. Gradual steps, release often is good. Agree, but as it will be the first release from trunk the threshold is higher. IMO we should consolidate the current status and make trunk useable for projects again which should result in agreeing on our external contracts. Yes Making life harder for future exciting developments by releasing too early isn't good. Exactly, one point i that trunk contains nice mechanisms for parameterizing components and sitemaps at a global level and also for having foreign component managers within sitemaps. While very usefull for the current development style in Cocoon they are not very relevant for blocks. For blocks we should avoid global configurations as it is in the way for splitting Cocoon in small reusable parts. And also component configurations in sitemaps is rather unnecessary when we have component configurations on the block level. So what should we do about introducing things that we know that we will want to remove in a later release? As long as we have milestone releases, I have no problem with sitemap classloaders and sitemap application containers. If both features become block functionality, people have to migrate. (IIRC also Eclipse had some incompatible changes in their 3.0 milestone series.) I have not that much problem with the sitemap stuff, it shouldn't be that hard to migrate them. I'm more concerned about the Core and Settings objects, that is part of the trunk contract and that doesn't fit well into a splited up non-monolithic architecture. If this is the case, then it would seem timely to improve these interfaces now, as 2.2 given the greater flexibility could become _the_ future Cocoon, and we may miss the boat if we don't make this change now. Yes, I feel some urgency. With enough focus and dedication on refactoring Cocoon and finish the blocks Cocoon can be the Rich Server Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And regain its momentum. Focusing on 2.2 seem more like losing valuable time for me. Well, define 2.2 :-) I presume you mean releasing a Maven based Cocoon without a ready blocks system would loose valuable momentum. Yes. Do you have a roadmap on what's open? * Component handling - design issues * Logging - I put it in the BlocksManager but didn't give it much thought, here is a new chance for all logging enthusiasts to discuss ;) * Multi part MIME handling - not part of the blocks architecture to simplify things, would make most sense to put in a ServletFilter IMO * Error handling - there is sophisticated creation of error messages in the CocoonServlet, where is the right place for it in the blocks architecture? * JARed blocks - the BlocksManager assumes that the wiring location points to unpacked blocks, implement support for packed blocks. I think these are the main issues. /Daniel
Re: [RT] The environment abstraction, part II
Sylvain Wallez wrote: > Sorry, but I still fail to see how this changes anything. It makes it > easier to develop with Cocoon as using the standard servlet API rather > than with a "proprietary clone" eases the learning process and > facilitates the integration with 3rd-party libraries. But does it change > something for the internal code? I fail to see how. > We get rid off the whole o.a.c.environment package - and this is the another step to make the core cleaner. I can imagine a lot of changes based on this one making the internal handling of requests easier to understand and implement. > I never said it doesn't make sense, rather the contrary. But there's a > difference IMO between "let's use the standard servlet API" and "let's > fire up a servlet engine to process a simple XML pipeline". > Sure, but see my latest response to Daniel showing some use cases where you need the whole servlet engine. And I of course web apps have their servlet engine running, so there is only the cli left. But starting jetty inside is really a small thing and totally transparent from a user pov. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: >> For me these things make more sense for a higher >> version than 2.2. I would love to get 2.2 out today with the main >> changes being ECM++ and the Maven build. > > I'm not so certain about this anymore as you can see in my answer to > Upayavira. But go ahead and write a release plan, so that we can discuss > what it will mean. > Sorry, but I don't have time for these kind of things atm - so someone else has to do come up with a release plan if we want to have a release soon. But on the other hand, the maven build is not finished yet, and this is the first thing which has to work - currently you can't run 2.2 at all. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > > AFAIK you can't call filters and listeners from within servlets, so they > are at the servlet container level, and I don't see how a block would > need them. A block could certainly need something that a listener put in > a context attribute or that a filter did to the request, but that is > another question. > There was recently a discussion here about adding a servlet listener for some functionality in the xsp block - I don't know what, but the important message is that this will happen and already happens: some blocks need more than just the servlet: like listeners or filters or whatever the servlet spec requires. And as soon as a block uses these features you need a full servlet environment and not just a http request, response and context. In addition, I could imagine that Cocoon provides filters which might be used by other web frameworks running in the same web app as Cocoon. I might be wrong, but I think another issue is if you are using spring. Spring is initialized through a servlet listener and is assuming a servlet context to work properly. So as soon as you don't have the listener, you can use Spring in that way. Of course there are other ways of using Spring which would also work in a CLI but they do not leverage the special web functionality. So you either don't use that or you have two versions, one for the Cli and one for the web. I can imagine more scenarios for these kind of things and we could avoid all of them. The only drawback - if you want to call it drawback - is that the CLI is firing up internally a servlet engine. But I could imagine that this "clarification of environments" would also make the work for Forrest easier in the end. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
Question is is there an interim "thing" that we can release before whole
OSGi is implemented? We were talking about an RC when Maven build was
done, but we seem to be moving away from that.
Sure there are a number possible interim things.
We can release more or less as is, what is lacking is a Maven
correspondence of the block.properties file and a plugin that collect
and install the configuration snippets in the blocks to the webapp.
I'm working on that and the design of the block deployer already supports
property replacement. Only the implementation is missing but will come soon.
We can also release with non OSGi blocks. The blocks are ongoing work,
the most important thing that lacks is "two level configuration". As
discussed before the component configuration is part of the block and
constant, so they need to be parametrized in some way for making them
user configurable. We have not had much discussion about how to do this
yet.
My understanding is that a user can parameterize a block at deployment (which is
supported by the block deployer) if he wants. Otherwise the default values are
taken.
Also the APIs and concepts for blocks need to actually be used for some
real life examples before we can be convinced that we got it right.
Of course. I'm working on getting trunk as far as making it very simple to use
it for custom projects. Then I will start to rework at least one of my projects
to use blocks and learn more about their real life usage. We should make it easy
that at least we developers (and some brave users) can start to experiment.
Gradual steps, release often is good.
Agree, but as it will be the first release from trunk the threshold is
higher.
IMO we should consolidate the current status and make trunk useable for projects
again which should result in agreeing on our external contracts.
Making life harder for future
exciting developments by releasing too early isn't good.
Exactly, one point i that trunk contains nice mechanisms for
parameterizing components and sitemaps at a global level and also for
having foreign component managers within sitemaps. While very usefull
for the current development style in Cocoon they are not very relevant
for blocks. For blocks we should avoid global configurations as it is in
the way for splitting Cocoon in small reusable parts. And also component
configurations in sitemaps is rather unnecessary when we have component
configurations on the block level.
So what should we do about introducing things that we know that we will
want to remove in a later release?
As long as we have milestone releases, I have no problem with sitemap
classloaders and sitemap application containers. If both features become block
functionality, people have to migrate. (IIRC also Eclipse had some incompatible
changes in their 3.0 milestone series.)
If this is the case, then it would seem timely to improve these
interfaces now, as 2.2 given the greater flexibility could become _the_
future Cocoon, and we may miss the boat if we don't make this change
now.
Yes, I feel some urgency. With enough focus and dedication on
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
regain its momentum. Focusing on 2.2 seem more like losing valuable time
for me.
Well, define 2.2 :-)
I presume you mean releasing a Maven based Cocoon without a ready blocks
system would loose valuable momentum.
Yes.
Do you have a roadmap on what's open?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] The environment abstraction, part II
Sylvain Wallez skrev: Daniel Fagerstrom wrote: Sylvain Wallez skrev: ... Now Cocoon is much more than a web framework, as we discussed in the "necessary mutation" thread: - a servlet - a component container - a controller - a pipeline engine - many blocks built on top of one of the above. The CocoonBean used by the CLI is actually parallel to the servlet and uses the lower-level layers. Right now it is but as I implemented the blocks as servlets rather than Processors, the CLI need to call the blocks at the servlet level ratherv than the processor level. So it will not be parallel anymore. And that will save us a lot of parallel setup code. Hmm... this looks really close to a servlet engine, where the request dispatcher gives access to other servlets. Yes. Aren't we reinventing the wheel here? We are. If there is some servlet engine that separates the servlet container part from the http protocol and communication parts, we can reuse the container part. Given that the servlet container part has a good enough API and is lightweight enough. /Daniel
Re: [RT] The environment abstraction, part II
Carsten Ziegeler skrev: Sylvain Wallez wrote: Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based implementation of the servlet API, but having the Cocoon CLI launching an internal Jetty for this really seems wrong to me. Forrest is already a large beast, now if you say that generating a site requires to start a servlet engine, many people with run away for something probably less powerful but much more light. Then let them run. No, seriously, we can be all to everyone. This is the flexibility syndrom in action. From a user pov, where is the difference in starting the current cli and starting a cli which internally fires up jetty and uses http? It's transparent - but it makes the implementation of Cocoon much easier. Setting up a HttpServletRequest object and a ServletConfiguration object is all that is needed for calling a servlet. It requires not that much code. ... Now, if I'm the only one thinking that removing the whole env abstraction makes sense, I'll shut up for now. You are not, but as you also state that you don't want it now it makes your position less easy to agree with. My plan is: * Let our environment abstraction extend the http servlet set of interfaces now, (back compatible and solves the problem at hand). * Push down the creation of the Environment object one step at a time through the call chain (refactorings, will remain back compatible as long as we have our interfaces in the object model, when we remove that it will create incompatibility). /Daniel
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: Sylvain Wallez skrev: ... Now Cocoon is much more than a web framework, as we discussed in the "necessary mutation" thread: - a servlet - a component container - a controller - a pipeline engine - many blocks built on top of one of the above. The CocoonBean used by the CLI is actually parallel to the servlet and uses the lower-level layers. Right now it is but as I implemented the blocks as servlets rather than Processors, the CLI need to call the blocks at the servlet level ratherv than the processor level. So it will not be parallel anymore. And that will save us a lot of parallel setup code. Hmm... this looks really close to a servlet engine, where the request dispatcher gives access to other servlets. Aren't we reinventing the wheel here? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] The environment abstraction, part II
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say that generating a site requires to start a
servlet engine, many people with run away for something probably less
powerful but much more light.
Then let them run. No, seriously, we can be all to everyone. This is the
flexibility syndrom in action. From a user pov, where is the difference
in starting the current cli and starting a cli which internally fires up
jetty and uses http? It's transparent - but it makes the implementation
of Cocoon much easier.
Sorry, but I still fail to see how this changes anything. It makes it
easier to develop with Cocoon as using the standard servlet API rather
than with a "proprietary clone" eases the learning process and
facilitates the integration with 3rd-party libraries. But does it change
something for the internal code? I fail to see how.
Now Cocoon is much more than a web framework, as we discussed in the
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
So, if someone asks you what Cocoon is, you say the above? Lock at the
first sentence at cocoon.apache.org: "Apache Cocoon is a web development
framework built around the concepts of separation of concerns and
component-based web development."
Then the next question is "how is it different from
Struts/Spring/Webwork?", and the answer is the list above.
Now, you could argue that the docs are out-dated, but I think the point
is that Cocoon has always been marketed as a web framework - and that is
the area we should focus on. Everything else, being it cli or portlet
env or whatever can be built somehow "on top" of the web framework.
This uses the servlet API, as calling Cocoon from Struts is done using
the request dispatcher:
request.getRequestDispatcher("/path/to/cocoon").forward(request, response)
Yupp.
Now, if I'm the only one thinking that removing the whole env
abstraction makes sense, I'll shut up for now.
I never said it doesn't make sense, rather the contrary. But there's a
difference IMO between "let's use the standard servlet API" and "let's
fire up a servlet engine to process a simple XML pipeline".
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The environment abstraction, part II
Sylvain Wallez skrev: ... Now Cocoon is much more than a web framework, as we discussed in the "necessary mutation" thread: - a servlet - a component container - a controller - a pipeline engine - many blocks built on top of one of the above. The CocoonBean used by the CLI is actually parallel to the servlet and uses the lower-level layers. Right now it is but as I implemented the blocks as servlets rather than Processors, the CLI need to call the blocks at the servlet level ratherv than the processor level. So it will not be parallel anymore. And that will save us a lot of parallel setup code. /Daniel
Re: [RT] The environment abstraction, part II
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Agree, but as people (you included) had valid reasons for not going that far in 2.2, I suggest something less radical this time, as I want to get rid of the problem of calling servlets from within Cocoon already in 2.2. Yes, true, I had reasons against doing radical changes in 2.2 and I still have them. I know, that is the reason for my "extension proposal", I need that change now. A radical change later is nothing that I can use right now. And the extension proposal should AFAICS keep back compability as we only will add methods to the interfaces (we have already added other methods to these interfaces in trunk). For me these things make more sense for a higher version than 2.2. I would love to get 2.2 out today with the main changes being ECM++ and the Maven build. I'm not so certain about this anymore as you can see in my answer to Upayavira. But go ahead and write a release plan, so that we can discuss what it will mean. Yes, by letting our Request etc interfaces extend their http servlet counterparts we can always assume that Cocoon is executed in a servlet environment, (given that the actual environment provide rich enough implementations of course). No, inheriting is imho not enough. What about servlet listener or filters that might be need by some blocks? Those things only work in a real servlet environment. And there might be other things. AFAIK you can't call filters and listeners from within servlets, so they are at the servlet container level, and I don't see how a block would need them. A block could certainly need something that a listener put in a context attribute or that a filter did to the request, but that is another question. /Daniel
Re: [RT] The environment abstraction, part II
Upayavira skrev: Daniel Fagerstrom wrote: Upayavira wrote: ... It starts to look like a 3.0 rather than a 2.2 and my personal goal is to implement the whole blocks design including OSGi. OTH I try to not hinder the possibility for a 2.2 release, given that someone is prepared to spearhead it. Question is is there an interim "thing" that we can release before whole OSGi is implemented? We were talking about an RC when Maven build was done, but we seem to be moving away from that. Sure there are a number possible interim things. We can release more or less as is, what is lacking is a Maven correspondence of the block.properties file and a plugin that collect and install the configuration snippets in the blocks to the webapp. We can also release with non OSGi blocks. The blocks are ongoing work, the most important thing that lacks is "two level configuration". As discussed before the component configuration is part of the block and constant, so they need to be parametrized in some way for making them user configurable. We have not had much discussion about how to do this yet. Also the APIs and concepts for blocks need to actually be used for some real life examples before we can be convinced that we got it right. Gradual steps, release often is good. Agree, but as it will be the first release from trunk the threshold is higher. Making life harder for future exciting developments by releasing too early isn't good. Exactly, one point i that trunk contains nice mechanisms for parameterizing components and sitemaps at a global level and also for having foreign component managers within sitemaps. While very usefull for the current development style in Cocoon they are not very relevant for blocks. For blocks we should avoid global configurations as it is in the way for splitting Cocoon in small reusable parts. And also component configurations in sitemaps is rather unnecessary when we have component configurations on the block level. So what should we do about introducing things that we know that we will want to remove in a later release? ... If this is the case, then it would seem timely to improve these interfaces now, as 2.2 given the greater flexibility could become _the_ future Cocoon, and we may miss the boat if we don't make this change now. Yes, I feel some urgency. With enough focus and dedication on refactoring Cocoon and finish the blocks Cocoon can be the Rich Server Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And regain its momentum. Focusing on 2.2 seem more like losing valuable time for me. Well, define 2.2 :-) I presume you mean releasing a Maven based Cocoon without a ready blocks system would loose valuable momentum. Yes. But that is IMHO, if enough people are prepared to make a 2.2 happen, I will of course join in that work. Again - define what 2.2 is. At the moment, these are just numbers. We should be taking about whether we are going to release feature sets, not numbers. You are right, I was referring to the first alternative above, i.e. more or less as is. So the main question is if enough people are motivated to work for making that happen. I'm not particularly motivated in working for keeping life in the monolithic beast for another minor version series. I rather work without releasing for a while and release something that I will feel proud to be part of. Again, if there is a momentum for an "as is" release I will of course respect that. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. Yes. For CLI an alternative is to have a minimal servlet container as part of the CLI. Maybe its possible to use Jetty in that way without needing to go over a socket? Why a servlet container? Or do you mean simple implementation of the servlet interfaces? That would be what we would need. Something to set up request and response and call the servlet's service() method. I mean a simple implementation of the servlet interfaces as you suggest. I haven't studied the CLI implementation in any detail, what is your opinion about letting it work on the servlet interfaces rather than at the Processor level. What consequences will it have? Wouldn't be too hard. It builds its own Request, Response and Environment, and a Cocoon object to use. Moving it across shouldn't be too hard (although the CLI could do with a _serious_ rewriting, but that's for other reasons). It seemed that it hasn't been refactored for a while. Much of the setup work will not be needed anymore if it call the rest of Cocoon at the servlet level rather than the processor level. /Daniel
Re: [RT] The environment abstraction, part II
On 1/30/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Now, if I'm the only one thinking that removing the whole env > abstraction makes sense, I'll shut up for now. Nope. Makes perfect sense to me, please continue on this crusade. -- Peter Hunsberger
Re: [RT] The environment abstraction, part II
Sylvain Wallez wrote:
>
> Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
> implementation of the servlet API, but having the Cocoon CLI launching
> an internal Jetty for this really seems wrong to me. Forrest is already
> a large beast, now if you say that generating a site requires to start a
> servlet engine, many people with run away for something probably less
> powerful but much more light.
>
Then let them run. No, seriously, we can be all to everyone. This is the
flexibility syndrom in action. From a user pov, where is the difference
in starting the current cli and starting a cli which internally fires up
jetty and uses http? It's transparent - but it makes the implementation
of Cocoon much easier.
> Now Cocoon is much more than a web framework, as we discussed in the
> "necessary mutation" thread:
> - a servlet
> - a component container
> - a controller
> - a pipeline engine
> - many blocks built on top of one of the above.
>
So, if someone asks you what Cocoon is, you say the above? Lock at the
first sentence at cocoon.apache.org: "Apache Cocoon is a web development
framework built around the concepts of separation of concerns and
component-based web development."
Now, you could argue that the docs are out-dated, but I think the point
is that Cocoon has always been marketed as a web framework - and that is
the area we should focus on. Everything else, being it cli or portlet
env or whatever can be built somehow "on top" of the web framework.
>
> This uses the servlet API, as calling Cocoon from Struts is done using
> the request dispatcher:
> request.getRequestDispatcher("/path/to/cocoon").forward(request, response)
>
Yupp.
Now, if I'm the only one thinking that removing the whole env
abstraction makes sense, I'll shut up for now.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Sorry, what do you mean by "web framework"? Isn't it already one? Or do
you mean "servlet"?
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web framework or a web server or something like that.
Now, because of this, we have the environment abstraction. And I think
we can remove that completly making Cocoon just a web framework which
always has a servlet environment including listeners and filters etc.
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say that generating a site requires to start a
servlet engine, many people with run away for something probably less
powerful but much more light.
Now Cocoon is much more than a web framework, as we discussed in the
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
The CocoonBean used by the CLI is actually parallel to the servlet and
uses the lower-level layers.
Now, we have currently two other environments: cli and portlets.
There's also BackgroundEnvironment for background jobs.
True, but as that one is running "inside" Cocoon it shouldn't cause
problems either.
Right. But that also means we need to have request/response/context
implementations that are totally decorrelated from a servlet
environment. This is the same for the CLI also.
Hmm... Struts and Cocoon are on the same level, as they handle the
request. Spring (its container part) is more to be compared with our
ECM. So although setting up ECM as a context listener would make sense,
Cocoon itself must remain a servlet to be able to handle requests.
Yes, it can remain a servlet (although it might not need to be, but
that's another topic). Why not, for example, calling pdf generation from
let's say Struts?
This uses the servlet API, as calling Cocoon from Struts is done using
the request dispatcher:
request.getRequestDispatcher("/path/to/cocoon").forward(request, response)
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > Agree, but as people (you included) had valid reasons for not going that > far in 2.2, I suggest something less radical this time, as I want to get > rid of the problem of calling servlets from within Cocoon already in 2.2. Yes, true, I had reasons against doing radical changes in 2.2 and I still have them. For me these things make more sense for a higher version than 2.2. I would love to get 2.2 out today with the main changes being ECM++ and the Maven build. > Yes, by letting our Request etc interfaces extend their http servlet > counterparts we can always assume that Cocoon is executed in a servlet > environment, (given that the actual environment provide rich enough > implementations of course). No, inheriting is imho not enough. What about servlet listener or filters that might be need by some blocks? Those things only work in a real servlet environment. And there might be other things. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Sylvain Wallez wrote: > > Sorry, what do you mean by "web framework"? Isn't it already one? Or do > you mean "servlet"? > Cocoon is currently a mixture. It's mostly used as a web framework through a servlet, but for example if you're using the cli you don't have a web framework or a web server or something like that. Now, because of this, we have the environment abstraction. And I think we can remove that completly making Cocoon just a web framework which always has a servlet environment including listeners and filters etc. >> Now, we have currently two other environments: cli and portlets. > > There's also BackgroundEnvironment for background jobs. True, but as that one is running "inside" Cocoon it shouldn't cause problems either. > Hmm... Struts and Cocoon are on the same level, as they handle the > request. Spring (its container part) is more to be compared with our > ECM. So although setting up ECM as a context listener would make sense, > Cocoon itself must remain a servlet to be able to handle requests. Yes, it can remain a servlet (although it might not need to be, but that's another topic). Why not, for example, calling pdf generation from let's say Struts? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > Upayavira wrote: > >> Daniel Fagerstrom wrote: >> >> >>> Carsten Ziegeler skrev: >>> > > ... > First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. >>> >>> Agree, but as people (you included) had valid reasons for not going that >>> far in 2.2, I suggest something less radical this time, as I want to get >>> rid of the problem of calling servlets from within Cocoon already in >>> 2.2. >>> >> >> >> I am starting to change my mind about this in regard to 2.2. 2.2 is >> changing as a concept. It was previously just a small step up from 2.1, >> in which case a significant change in interface would not have been >> appropriate. However, particularly the maven build, but also a lot of >> the other stuff that is going on, is leading to some quite substantial >> improvements. > > It starts to look like a 3.0 rather than a 2.2 and my personal goal is > to implement the whole blocks design including OSGi. OTH I try to not > hinder the possibility for a 2.2 release, given that someone is prepared > to spearhead it. Question is is there an interim "thing" that we can release before whole OSGi is implemented? We were talking about an RC when Maven build was done, but we seem to be moving away from that. Gradual steps, release often is good. Making life harder for future exciting developments by releasing too early isn't good. >> More particularly Daniel's proposals to do with using >> servlet interfaces for block controllers would make it possible to >> implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this >> framework. > > That is the goal :) Yup, and I like it. >> If this is the case, then it would seem timely to improve these >> interfaces now, as 2.2 given the greater flexibility could become _the_ >> future Cocoon, and we may miss the boat if we don't make this change now. > > Yes, I feel some urgency. With enough focus and dedication on > refactoring Cocoon and finish the blocks Cocoon can be the Rich Server > Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And > regain its momentum. Focusing on 2.2 seem more like losing valuable time > for me. Well, define 2.2 :-) I presume you mean releasing a Maven based Cocoon without a ready blocks system would loose valuable momentum. > But that is IMHO, if enough people are prepared to make a 2.2 happen, I > will of course join in that work. Again - define what 2.2 is. At the moment, these are just numbers. We should be taking about whether we are going to release feature sets, not numbers. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. >>> >>> Yes. For CLI an alternative is to have a minimal servlet container as >>> part of the CLI. Maybe its possible to use Jetty in that way without >>> needing to go over a socket? >> >> Why a servlet container? Or do you mean simple implementation of the >> servlet interfaces? That would be what we would need. Something to set >> up request and response and call the servlet's service() method. > > I mean a simple implementation of the servlet interfaces as you suggest. > > I haven't studied the CLI implementation in any detail, what is your > opinion about letting it work on the servlet interfaces rather than at > the Processor level. What consequences will it have? Wouldn't be too hard. It builds its own Request, Response and Environment, and a Cocoon object to use. Moving it across shouldn't be too hard (although the CLI could do with a _serious_ rewriting, but that's for other reasons). Regards, Upayavira
Re: [RT] The environment abstraction, part II
Upayavira wrote: Daniel Fagerstrom wrote: Carsten Ziegeler skrev: ... First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. Agree, but as people (you included) had valid reasons for not going that far in 2.2, I suggest something less radical this time, as I want to get rid of the problem of calling servlets from within Cocoon already in 2.2. I am starting to change my mind about this in regard to 2.2. 2.2 is changing as a concept. It was previously just a small step up from 2.1, in which case a significant change in interface would not have been appropriate. However, particularly the maven build, but also a lot of the other stuff that is going on, is leading to some quite substantial improvements. It starts to look like a 3.0 rather than a 2.2 and my personal goal is to implement the whole blocks design including OSGi. OTH I try to not hinder the possibility for a 2.2 release, given that someone is prepared to spearhead it. More particularly Daniel's proposals to do with using servlet interfaces for block controllers would make it possible to implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this framework. That is the goal :) If this is the case, then it would seem timely to improve these interfaces now, as 2.2 given the greater flexibility could become _the_ future Cocoon, and we may miss the boat if we don't make this change now. Yes, I feel some urgency. With enough focus and dedication on refactoring Cocoon and finish the blocks Cocoon can be the Rich Server Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And regain its momentum. Focusing on 2.2 seem more like losing valuable time for me. But that is IMHO, if enough people are prepared to make a 2.2 happen, I will of course join in that work. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. Yes. For CLI an alternative is to have a minimal servlet container as part of the CLI. Maybe its possible to use Jetty in that way without needing to go over a socket? Why a servlet container? Or do you mean simple implementation of the servlet interfaces? That would be what we would need. Something to set up request and response and call the servlet's service() method. I mean a simple implementation of the servlet interfaces as you suggest. I haven't studied the CLI implementation in any detail, what is your opinion about letting it work on the servlet interfaces rather than at the Processor level. What consequences will it have? /Daniel
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > Carsten Ziegeler skrev: > >> Daniel Fagerstrom wrote: >> >>> I suggested that we should ditch our environment abstraction and >>> replace it with the javax.servlet.http set of interfaces, as one step >>> in simplifying Cocoon in >>> http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2. >>> >>> The result of the discussion was that there are some "extras" in our >>> interfaces compared to the http servlet interfaces that are needed in >>> the sitemap, so we would get back incompatibility and maybe other >>> problems and it might be much work to accomplish. >>> >>> Now I would instead suggest that our environment interfaces just >>> extends the corresponding Servlet 2.3 (or 2.4) interfaces, Request >>> extends HttpServletRequest etc. This should not create any problems >>> with the current code base at all AFAICS, and would make it easier to >>> make Cocoon cooperate with other systems. >>> >>> Calling Cocoon from a Servlet environment is currently not a problem >>> as we have wrappers, but it gets inconvenient to call servlets from >>> within Cocoon. And the block architecture is Servlet based for making >>> integration and development of new controllers easier and the result >>> more reusable. As the block protocol requires the sitemap to call >>> back the block architecture it would be an advantage if we used the >>> servlet set of interfaces. >>> >>> Also for being able to use the CLI with blocks it need to be able to >>> call the block architecture, and here it would also be an advantage >>> if our environment interfaces extended the servlet ones. >>> >>> I'd like to implement the above change ASAP, WDYT? >>> >> First, I'm still not sure if this should go into the current 2.2 code >> base, but apart from that I now think we should even be more radical in >> this area and remove the whole environment abstraction completly and >> make Cocoon a web framework. Period. > > > Agree, but as people (you included) had valid reasons for not going that > far in 2.2, I suggest something less radical this time, as I want to get > rid of the problem of calling servlets from within Cocoon already in 2.2. I am starting to change my mind about this in regard to 2.2. 2.2 is changing as a concept. It was previously just a small step up from 2.1, in which case a significant change in interface would not have been appropriate. However, particularly the maven build, but also a lot of the other stuff that is going on, is leading to some quite substantial improvements. More particularly Daniel's proposals to do with using servlet interfaces for block controllers would make it possible to implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this framework. If this is the case, then it would seem timely to improve these interfaces now, as 2.2 given the greater flexibility could become _the_ future Cocoon, and we may miss the boat if we don't make this change now. >> Now, we have currently two other environments: cli and portlets. A >> portlet is a web application, so there won't be any problem. And for >> the CLI we can come up with some kind of HttpClient that internally >> starts Jetty etc. > > Yes. For CLI an alternative is to have a minimal servlet container as > part of the CLI. Maybe its possible to use Jetty in that way without > needing to go over a socket? Why a servlet container? Or do you mean simple implementation of the servlet interfaces? That would be what we would need. Something to set up request and response and call the servlet's service() method. >> This would simplify Cocoon even more - and has some other advantages as >> well. For example if you're using third party frameworks like spring or >> hivemind, they are using servlet context listeners. These are only >> available/working in a web environment. So as soon as you are using >> something like that, other environmnents would not work. There are other >> similar examples to this. For example the portal has extra code that >> checks if the portal is used in a servlet environment or not to avoid >> startup problems. > > Yes, by letting our Request etc interfaces extend their http servlet > counterparts we can always assume that Cocoon is executed in a servlet > environment, (given that the actual environment provide rich enough > implementations of course). > >> And we could use a context listener for setting up Cocoon as well. Which >> would make Cocoon easy usable within other frameworks - it's the least >> intrusive way. So imagine a struts web app, which is calling Cocoon (and >> Cocoon has been set up by the context listener and is available through >> the context - similar to what Spring et.all. do). > > We should definitively make Cocoon more friendly towards other frameworks. Yup. >> So, let's simplify Cocoon and remove this extra abstraction completly. > > Would be nice. We will see what others think. For me it is most > important that we let our environment api extend the http servlet api
Re: [RT] The environment abstraction, part II
Sylvain Wallez skrev: ... AFAIU, what Daniel is proposing is to add an "extends" statement to our environment interfaces, which are very close to the standard javax.servlet ones. Just like we did with Cocoon's SourceResolver extending Excalibur's SourceResolver. Exactly /Daniel
Re: [RT] The environment abstraction, part II
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: I suggested that we should ditch our environment abstraction and replace it with the javax.servlet.http set of interfaces, as one step in simplifying Cocoon in http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2. The result of the discussion was that there are some "extras" in our interfaces compared to the http servlet interfaces that are needed in the sitemap, so we would get back incompatibility and maybe other problems and it might be much work to accomplish. Now I would instead suggest that our environment interfaces just extends the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends HttpServletRequest etc. This should not create any problems with the current code base at all AFAICS, and would make it easier to make Cocoon cooperate with other systems. Calling Cocoon from a Servlet environment is currently not a problem as we have wrappers, but it gets inconvenient to call servlets from within Cocoon. And the block architecture is Servlet based for making integration and development of new controllers easier and the result more reusable. As the block protocol requires the sitemap to call back the block architecture it would be an advantage if we used the servlet set of interfaces. Also for being able to use the CLI with blocks it need to be able to call the block architecture, and here it would also be an advantage if our environment interfaces extended the servlet ones. I'd like to implement the above change ASAP, WDYT? First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. Agree, but as people (you included) had valid reasons for not going that far in 2.2, I suggest something less radical this time, as I want to get rid of the problem of calling servlets from within Cocoon already in 2.2. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. Yes. For CLI an alternative is to have a minimal servlet container as part of the CLI. Maybe its possible to use Jetty in that way without needing to go over a socket? This would simplify Cocoon even more - and has some other advantages as well. For example if you're using third party frameworks like spring or hivemind, they are using servlet context listeners. These are only available/working in a web environment. So as soon as you are using something like that, other environmnents would not work. There are other similar examples to this. For example the portal has extra code that checks if the portal is used in a servlet environment or not to avoid startup problems. Yes, by letting our Request etc interfaces extend their http servlet counterparts we can always assume that Cocoon is executed in a servlet environment, (given that the actual environment provide rich enough implementations of course). And we could use a context listener for setting up Cocoon as well. Which would make Cocoon easy usable within other frameworks - it's the least intrusive way. So imagine a struts web app, which is calling Cocoon (and Cocoon has been set up by the context listener and is available through the context - similar to what Spring et.all. do). We should definitively make Cocoon more friendly towards other frameworks. So, let's simplify Cocoon and remove this extra abstraction completly. Would be nice. We will see what others think. For me it is most important that we let our environment api extend the http servlet api now, (which should be back compatible). /Daniel
Re: [RT] The environment abstraction, part II
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: I suggested that we should ditch our environment abstraction and replace it with the javax.servlet.http set of interfaces, as one step in simplifying Cocoon in http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2. The result of the discussion was that there are some "extras" in our interfaces compared to the http servlet interfaces that are needed in the sitemap, so we would get back incompatibility and maybe other problems and it might be much work to accomplish. Now I would instead suggest that our environment interfaces just extends the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends HttpServletRequest etc. This should not create any problems with the current code base at all AFAICS, and would make it easier to make Cocoon cooperate with other systems. Calling Cocoon from a Servlet environment is currently not a problem as we have wrappers, but it gets inconvenient to call servlets from within Cocoon. And the block architecture is Servlet based for making integration and development of new controllers easier and the result more reusable. As the block protocol requires the sitemap to call back the block architecture it would be an advantage if we used the servlet set of interfaces. Also for being able to use the CLI with blocks it need to be able to call the block architecture, and here it would also be an advantage if our environment interfaces extended the servlet ones. I'd like to implement the above change ASAP, WDYT? First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. Sorry, what do you mean by "web framework"? Isn't it already one? Or do you mean "servlet"? Now, we have currently two other environments: cli and portlets. There's also BackgroundEnvironment for background jobs. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. HttpServletRequest is an interface. So we just have to write a CliHttpServletRequest that implements that interface, just as we do today with our own interfaces. AFAIU, what Daniel is proposing is to add an "extends" statement to our environment interfaces, which are very close to the standard javax.servlet ones. Just like we did with Cocoon's SourceResolver extending Excalibur's SourceResolver. This would simplify Cocoon even more - and has some other advantages as well. For example if you're using third party frameworks like spring or hivemind, they are using servlet context listeners. These are only available/working in a web environment. So as soon as you are using something like that, other environmnents would not work. There are other similar examples to this. For example the portal has extra code that checks if the portal is used in a servlet environment or not to avoid startup problems. And we could use a context listener for setting up Cocoon as well. Which would make Cocoon easy usable within other frameworks - it's the least intrusive way. So imagine a struts web app, which is calling Cocoon (and Cocoon has been set up by the context listener and is available through the context - similar to what Spring et.all. do). Hmm... Struts and Cocoon are on the same level, as they handle the request. Spring (its container part) is more to be compared with our ECM. So although setting up ECM as a context listener would make sense, Cocoon itself must remain a servlet to be able to handle requests. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: > I suggested that we should ditch our environment abstraction and replace > it with the javax.servlet.http set of interfaces, as one step in > simplifying Cocoon in > http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2. > > The result of the discussion was that there are some "extras" in our > interfaces compared to the http servlet interfaces that are needed in > the sitemap, so we would get back incompatibility and maybe other > problems and it might be much work to accomplish. > > Now I would instead suggest that our environment interfaces just extends > the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends > HttpServletRequest etc. This should not create any problems with the > current code base at all AFAICS, and would make it easier to make Cocoon > cooperate with other systems. > > Calling Cocoon from a Servlet environment is currently not a problem as > we have wrappers, but it gets inconvenient to call servlets from within > Cocoon. And the block architecture is Servlet based for making > integration and development of new controllers easier and the result > more reusable. As the block protocol requires the sitemap to call back > the block architecture it would be an advantage if we used the servlet > set of interfaces. > > Also for being able to use the CLI with blocks it need to be able to > call the block architecture, and here it would also be an advantage if > our environment interfaces extended the servlet ones. > > I'd like to implement the above change ASAP, WDYT? > First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. This would simplify Cocoon even more - and has some other advantages as well. For example if you're using third party frameworks like spring or hivemind, they are using servlet context listeners. These are only available/working in a web environment. So as soon as you are using something like that, other environmnents would not work. There are other similar examples to this. For example the portal has extra code that checks if the portal is used in a servlet environment or not to avoid startup problems. And we could use a context listener for setting up Cocoon as well. Which would make Cocoon easy usable within other frameworks - it's the least intrusive way. So imagine a struts web app, which is calling Cocoon (and Cocoon has been set up by the context listener and is available through the context - similar to what Spring et.all. do). So, let's simplify Cocoon and remove this extra abstraction completly. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
