Re: [RF] Chainsaws and Seeds
I've been wanting to add my 2 pence since stefano's is cocoon
redundant thread. I also admit i'm not a cocoon developer.
Nice charts.. They assume that the same folk that are there at the
start of the start line are the same folk that are end or even perhaps
middle. Despite having a lot of respect for stefano's achievements and
the contribution that cocoon has made, I think the graphs are wrong,
or at least fail to account for iterations of staff turnover.
In the case of a strong SOC approach vs embedding stuff in htmls
(including taglibs), I think whoever that the graphs work as a
concept. As long and no crack addicts wrote the orginal xsl's etc, any
new folk or contractors can fall into line see whats going on and
hence cost of ownership could indeed be reduced.
Seeing that everyone seems to agree that cocoon's strength are the
pipelines, consider the following
c:import var=xmlds uri=mydatasource.xml
c:import var=htmlRenderer uri=/WEB-INF/xsl/html/foo.xsl /
x:transform xsl=${htmlRenderer} xml=${xmlds} /
or even a i18n example
myxmlfmt:message key=mykey //myxml
This is a over simplification and I know that cocoon does a lot more,
but I think that leveraging standard kit (when it works) would make
life so much easier. JSTL wasn't around when cocoon set out to solve
these problems, I even sincerely believe that cocoon's influence
helped the development of techologies like jstl, so my point isn't
about which is better or worse.
Up until now I've been using jsps for the view controllers with
clearly named file..
/controller/fooController.jsp
jsp:useBean id=errors class=java.util.HashMap scope=request /
c:choose
c:when test=${empty param.email}
fmt:message key=message.email.required var=msg /
c:set target=${errors} property=email value=${msg}
/c:when
c:when test=${myvalidations:email(email)}
c:set target.. . etc
/c:when
..
c:choose
c:when test=${!empty errors}
jsp:forward page=mypage.jsp /
/c:when
..
in mypage.jsp iterate over error map or even a specialised java class
like ValidationError, and generate relevant xml.
Of course there's no reason why scripting or even continuations
couldn't be added, view controller logic in jstl wont be everyone's
cup to tea. But good ide and container support make it a reasonable
choice.
Again overly simple and maybe folk don't like jstl controllers, want
continuations etc, so its not like jstl can do everything. It would
need extending to do all that. But if folk want to talk about cost of
ownership, ide support, contractor/staff turnover and such like, while
maintaining SOC.
Lego is good, SOC is good, room to choose ajax or vanilla html output,
all these things are good. And before the standard kit supported it in
a usable manner was cocoon's main advantage. I see these advances in
jstl as some of the fruits of the cocoon project, and ironically not
leveraged by it. Refining jstl into something more aligned with cocoon
would seem to have more advantages than costs, would provide a clear
means of integrating legacy cocoon apps and maintain SOC.
Hope I haven't bored or annoyed anyone, just had a big itch for a long time.
Mark
On 12/11/05, Niclas Hedhman [EMAIL PROTECTED] wrote:
On Saturday 10 December 2005 19:20, Stefano Mazzocchi wrote:
Niclas Hedhman wrote:
The orthogonality of Cocoon has died. Noone talks about views. Noone
highlights the ability to serve same content to many user agents. Noone
is interested in truly useful smaller components. Noone cares about the
developer vs designer vs deployer roles.
Hmmm, interesting, didn't see it this way. I wonder if it's because the
real life forces those role to hybridize over and over, if we didn't
make the right choice in separating them or because really nobody cares.
If nobody really cares, then I wonder what in hell are we still thinking
in terms of SoC!
I think that is purely a matter of who is in the studied group.
When you started Cocoon, you had the vision to look beyond the developer, and
saw that scalability is a problem and went out to create a solution. But,
somehow Cocoon didn't manage to reach out to those where this was important,
instead it became the geek tool, and that part of the vision eroded.
I am predicting that the next round of waves will not be around
delivering HTML or XML to web browsers, AJAX or not. It will center
around dedicated clients. And not _any_ client - but the Mobile clients.
I very strongly disagree. Mobiles are getting richer and richer, and the
HTML browser software is becoming more and more commoditized. It might
be easier for everybody to deliver XHTML with Ajax-retrieved CSS and
content than to do it the other way around.
Ok, we disagree. Time will show what the future holds. You think the client
side will converge over the next 5 years, I say it will diverge a lot, fueled
by the inadequacy of HTML and ever higher demanding users, with new set of
challenges.
But the important point is
How to connect Avalon Component and SessionListener
It's a new day and a new problem arises for me: I want to notify my Avalon component when a session is created or destroyed. I had previously written a simple HttpSessionListener which I declared in web.xml. sessionCreated() and sessionDestroyed() get invoked just as they should. Now what's the best practise to notify my component from there? These are the ideas I had: 1) Make the SessionListener a Serviceable Component itself, so it can use the ServiceManager to lookup my other component and invoke some method there. 2) Make my Avalon component a SessionListener itself (I don't think that's possible, is it? I added it to web.xml as listener class and cocoon.xconf as component, but the session methods were not invoked) 3) Keep both classes as they are and do it the right way ;) ? How would you go about this? Thanx, Stefan
Re: How to connect Avalon Component and SessionListener
Stefan Pietschmann wrote: It's a new day and a new problem arises for me: I want to notify my Avalon component when a session is created or destroyed. I had previously written a simple HttpSessionListener which I declared in web.xml. sessionCreated() and sessionDestroyed() get invoked just as they should. Now what's the best practise to notify my component from there? These are the ideas I had: 1) Make the SessionListener a Serviceable Component itself, so it can use the ServiceManager to lookup my other component and invoke some method there. 2) Make my Avalon component a SessionListener itself (I don't think that's possible, is it? I added it to web.xml as listener class and cocoon.xconf as component, but the session methods were not invoked) 3) Keep both classes as they are and do it the right way ;) ? How would you go about this? I'd do it the way I have told folks before. Don't use HttpSessionListener. Make your component implement HttpSessionBindingListener. Then store your component as a session attribute. When the session is destroyed it will be notified. This doesn't require anything in web.xml. Ralph
Cocoon server not responding
Hello, Aparently there is some problem with your server. http://cocoon.zones.apache.org Best regards, Juan Joan Baz [EMAIL PROTECTED] Adaptiva Sistemas, S.L. http://www.adaptiva.es Ball de Diables, 2 43205 Reus Spain +34 676 702 569
m2 build broken?
I've just done a fresh build of trunk using m2, which failed somehow because of problems with xml-apis, saying something like: This artifact has been relocated to xml-apis:xml-apis:1.0.b2. And I also found references to it trying to get it from a URL at: http://cvs.apache.org/maven-snapshot-repository that didn't exist. Any ideas? Does it work for other people? Regards, Upayavira
[RT] Ditching the environment abstraction
It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? It made sense when Cocoon was mainly a publication framework, for publication the servlet family of interfaces has a lot of functionlity that is irrelevant. But now when Cocoon has developed to a webapp framework, it makes much less sense to have an own abstraction of what already has a standardized abstraction. o.a.c.e.Request has expanded so that it is close to identical to HttpRequest. For o.a.c.e.Response and Context there are larger differences to their servlet counterparts, they are subsets. But what is not implemented either could be implemented or just throw an not implemented exception. Another reason for having an own abstraction was to be able to use Cocoon in none servlet environments. This has not happened to any large extent, in addition to the Http environment, we have CLI, Faces and Portal environment. For the Http, Faces and Portal environment, using the servlet interfaces should be a simpilification and improvement. For CLI, I dont see that it would complicate anything either. The main problem with swithing to the servlet interfaces AFAICS, except for that it takes some work, is back incompability. This could be solved to some extent by letting our abstactions extend the servlet interfaces. Nearly all methods have the same names and types. But IMO it would be better to simplify Cocoon and take the back incompability now and just remove our own abstraction, we could have some adapter utilities in some compability block. So in a first step I would like to switch our environment abstraction to their servlet correspondances. In an next step I think we should use Servlet instead of processor for our controllers: Cocoon, Sitemap, Flow and possibly the Pipeline. This would make it simpler to reuse Cocoon functionality, and also to experiment with new kinds of controllers. As discussed before the Processor interface contains a far to much implementation details that are connected to sitemap engine internals for beeing suitable as a general controller interface within Cocoon. I'm considering to reimplement the two controllers in the blocks architecture: the BlocksManager and the BlockManager, as servlets, and thus get rid of a lot of start up complications. Also it would make it possible to let a block contain any servlet with a set of components, instead of hardwiring it to the sitemap controller. WDYT? /Daniel
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 December 08:02 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-12-11 08:02:15 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Thu Nov 24 11:07:14 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sun Nov 27 03:07:04 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Wed Nov 16 13:07:07 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to
Re: m2 build broken?
Daniel Fagerstrom wrote: I think that the problems is that there was a 2.0.2 release of the xml-apis by mistake, don't know the story behind it, but see http://www.apache.org/dist/java-repository/xml-apis/jars/. It should have been 1.0.b2. Several poms at the official maven repository have dependencies of 2.0.2. This has been solved by leting the 2.0.2 pom redirect to 1.0.b2, in the repository. Now some part of Cocoon core depends on DOM3 (IIRC), that is part of xml-apis 1.3.02 (but not 1.0.b2). Now there are both indirect dependencies to 2.0.2 and a direct dependency on 1.3.02 in the Cocoon core pom. In this situation it seem like the m2 engine chose to compile with the jar with the pom with the highest version number, i.e. 2.0.2. As we saw above this is actually older (1.0.b2 through redirection) than the version we need (1.3.02). Correct. Possible solutions would be either ask the official maven repository to redirect 2.0.2 to 1.3.02 instead or by tracking down all the indirect dependencies in the cocoon core pom and adding exclusion clauses in our poms. Considering the number of projects that depend on xml-apis and the number of poms that we have it will not be fun. Other projects are probably going to get the same problems, so we should fix the problem at its root IMO. The root of the problem lies somewhere in the current m2 poms from excalibur. These have been automatically converted from the m1 project.xml files, so they are not using things like scopeprovided/scope where they should. This problem became very apparent a while ago, when I noticed that for producing a minimal and working war file, the number of libs to exclude was almost bigger than the number of direct dependencies ! So i started converting excalibur to use real m2 poms, this process is about 95% complete overall, and 100% as to what our dependencies are concerned. The converted artifacts use a different groupId structure, and can be found at [1]. Left to be done : - officially release these poms to ibiblio, requires some infra stuff and coordination with the maven and excalibur people. - switch our core pom to use these poms instead (anyone up for this?) so for ourselves can do : - a round of testing and bugfixing ~ ensure correctly scoped dependencies in excalibur ~ fix and rerelease poms if necessary A strange thing that I don't understand, is that it compiled for me on my new computer where everything was installed, checked out etc this thursday. dunno, poms do get worked on in the backgroud so things can break (or get fixed) seemingly random. Jorg [1] http://cvs.apache.org/maven-snapshot-repository/org/apache/
Re: m2 build broken?
Jorg Heymans skrev: Daniel Fagerstrom wrote: ... The root of the problem lies somewhere in the current m2 poms from excalibur. These have been automatically converted from the m1 project.xml files, so they are not using things like scopeprovided/scope where they should. This problem became very apparent a while ago, when I noticed that for producing a minimal and working war file, the number of libs to exclude was almost bigger than the number of direct dependencies ! So i started converting excalibur to use real m2 poms, this process is about 95% complete overall, and 100% as to what our dependencies are concerned. The converted artifacts use a different groupId structure, and can be found at [1]. Left to be done : - officially release these poms to ibiblio, requires some infra stuff and coordination with the maven and excalibur people. - switch our core pom to use these poms instead (anyone up for this?) so for ourselves can do : - a round of testing and bugfixing ~ ensure correctly scoped dependencies in excalibur ~ fix and rerelease poms if necessary I'll talk to Upayavira, and see if we can take care about it. I saw that you had changed the Cocoon group id to org.apache.cocoon from apache-cocoon in the main pom and the core pom but nowhere else. What is your plane for this? Should we just start to change group id to org.apache.cocoon in all poms? /Daniel
Re: [RT] Ditching the environment abstraction
Il giorno 11/dic/05, alle ore 18:56, Daniel Fagerstrom ha scritto: snip/ WDYT? /Daniel Know what? I proposed the same some time ago (I've tried digging out the reference, but couldn't), so a big +1 from me. Ugo
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 December 11:02 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-12-11 11:02:08 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Thu Nov 24 11:07:14 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sun Nov 27 03:07:04 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] [get] last modified = Wed Nov 16 13:07:07 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to
Re: [RF] Chainsaws and Seeds
Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... -- Stefano.
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? It made sense when Cocoon was mainly a publication framework, for publication the servlet family of interfaces has a lot of functionlity that is irrelevant. But now when Cocoon has developed to a webapp framework, it makes much less sense to have an own abstraction of what already has a standardized abstraction. o.a.c.e.Request has expanded so that it is close to identical to HttpRequest. For o.a.c.e.Response and Context there are larger differences to their servlet counterparts, they are subsets. But what is not implemented either could be implemented or just throw an not implemented exception. Another reason for having an own abstraction was to be able to use Cocoon in none servlet environments. This has not happened to any large extent, in addition to the Http environment, we have CLI, Faces and Portal environment. For the Http, Faces and Portal environment, using the servlet interfaces should be a simpilification and improvement. For CLI, I dont see that it would complicate anything either. The main problem with swithing to the servlet interfaces AFAICS, except for that it takes some work, is back incompability. This could be solved to some extent by letting our abstactions extend the servlet interfaces. Nearly all methods have the same names and types. But IMO it would be better to simplify Cocoon and take the back incompability now and just remove our own abstraction, we could have some adapter utilities in some compability block. So in a first step I would like to switch our environment abstraction to their servlet correspondances. In an next step I think we should use Servlet instead of processor for our controllers: Cocoon, Sitemap, Flow and possibly the Pipeline. This would make it simpler to reuse Cocoon functionality, and also to experiment with new kinds of controllers. As discussed before the Processor interface contains a far to much implementation details that are connected to sitemap engine internals for beeing suitable as a general controller interface within Cocoon. I'm considering to reimplement the two controllers in the blocks architecture: the BlocksManager and the BlockManager, as servlets, and thus get rid of a lot of start up complications. Also it would make it possible to let a block contain any servlet with a set of components, instead of hardwiring it to the sitemap controller. WDYT? The real reason why we wanted to keep the environment pluggable was that we envisioned cocoon as a Mailet as well. Needless to say, this never happened. So, yes, I'd be very happy to get rid of yet-another-servlet-API and simplify things. -- Stefano.
Bug report for Cocoon 2 [2005/12/11]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing | | 9916|New|Enh|2002-06-17|Support passing of object parameters into sitemap | |10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu| |10827|New|Enh|2002-07-15|ESQL get-xml/ doesn't support namespaces| |14048|Opn|Enh|2002-10-29|[PATCH] No-cache enhancement for ResourceReader co| |15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu| |15316|New|Nor|2002-12-12|FOP does not resolve relative paths | |16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 | |17594|New|Nor|2003-03-03|WebSphere redirect bug| |19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable | |19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane | |20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer | |20631|New|Enh|2003-06-10|[PATCH] Support for transactions in SQLTransformer| |21177|Ass|Nor|2003-06-30|a crash in the name() function of the xslt, when u| |22732|Opn|Nor|2003-08-26|Cocoon Servlet can't be included | |23002|New|Nor|2003-09-08|[PATCH]: HSSF Serializer does not process gmr:Pri| |23283|Unc|Nor|2003-09-19|WebServiceProxy doesn't re-encode request paramete| |23542|Opn|Maj|2003-10-01|[PATCH] Fix Bug: Better handling of CLOB in esql (| |23585|New|Nor|2003-10-03|Localton of ev_cache.ser file in DefaultEventRegis| |23615|Ass|Nor|2003-10-06|XSLTC doesn't work with nodeset functions | |23901|New|Nor|2003-10-17|[PATCH] adding wd:on-phase and moving load() and| |24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values| |24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction| |24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers| |24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer | |24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows| |24741|New|Nor|2003-11-17|XSP: util:get-sitemap-parameter/ returns nothing| |24871|New|Maj|2003-11-20|jsp block functionality broken, running on resin 3| |24891|New|Nor|2003-11-21|raw-request-param returns null when used with cinc| |25083|Opn|Nor|2003-11-29|JXTemplate evaluates expressions in comments, need| |25099|New|Enh|2003-12-01|[Roadmap] CocoonForms | |25100|New|Nor|2003-12-01|[PATCH] sitemap parameters support for SVGSerializ| |25110|New|Enh|2003-12-01|[Roadmap] CocoonForms - release 1.0 | |25113|New|Enh|2003-12-01|[Roadmap] CocoonForms - FUTURE releases | |25114|New|Enh|2003-12-01|[Roadmap] Support for multi-page forms| |25115|New|Enh|2003-12-01|[Roadmap] General review of all XML elements | |25280|New|Enh|2003-12-08|[Roadmap] Flowscript | |25281|New|Enh|2003-12-08|[Roadmap] Make it possible to use continuations in| |25284|New|Enh|2003-12-08|[Roadmap] Flowscript - FUTURE releases| |25289|New|Enh|2003-12-08|[Roadmap] Multi-sources binding | |25290|New|Enh|2003-12-08|[Roadmap] Change expression language | |25294|Opn|Enh|2003-12-08|[Roadmap] Refactoring current styles for making ex| |25295|New|Enh|2003-12-08|[Roadmap] XUL support | |25298|New|Enh|2003-12-08|[Roadmap] Calculated fields | |25299|New|Enh|2003-12-08|[Roadmap] Default values for fields | |25301|New|Enh|2003-12-08|[Roadmap] Subforms| |25302|New|Enh|2003-12-08|[Roadmap] Utility checking form definition and for| |25303|New|Enh|2003-12-08|[Roadmap] Enhanced validation for selection lists | |25305|New|Enh|2003-12-08|[Roadmap] Form-model - JavaScript model | |25306|New|Enh|2003-12-08|[Roadmap] Binding isolation model | |25307|New|Enh|2003-12-08|[Roadmap] Cache compiled bindings |
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 12 December 02:02 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-12-12 02:02:16 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Thu Nov 24 11:07:14 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sun Nov 27 03:07:04 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Wed Nov 16 13:07:07 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to
Re: [RF] Chainsaws and Seeds
Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave-
Re: [RF] Chainsaws and Seeds
dave- wrote: Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave- Should not be this more a Lepido[1] concern? Best Regards, Antonio Gallardo. [1] http://www.eclipse.org/lepido/
[HELP] Javadocs link broken. Redirecting more than expected.
Hi: While reviewing the javadocs, I found there is a link that is broken. The content is there, but the linkrewriter is non-correrctly redirecting the content. Try: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/xml/xlink/package-frame.html I found the .htaccess file in /www/cocoon.apache.org/2.1 contains the following rule that makes the javadocs to not display correclty: RedirectMatch link/(.*)$ http://cocoon.apache.org/link/$1; I don't wanted to touch the code, because I don't have an idea why we have this redirection. Can someone fix this? Thanks in advance. Best Regards, Antonio Gallardo.
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 12 December 05:02 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-12-12 05:02:10 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Thu Nov 24 11:07:14 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sun Nov 27 03:07:04 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Wed Nov 16 13:07:07 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to
Re: Cocoon server not responding
Le 11 déc. 05, à 16:37, juan a écrit : ...Aparently there is some problem with your server. http://cocoon.zones.apache.org I'm tied today, it would be good if someone could restart the services according to https://svn.apache.org/repos/private/committers/pmc/cocoon/ cocoon.zones.apache.org/admin-notes/howto-restart-zone.txt -Bertrand smime.p7s Description: S/MIME cryptographic signature
