Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Wednesday 07 December 2005 23:56, Sylvain Wallez wrote: > > * No IDE support for JavaScript > > There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4] > that does autocompletion of function and argument names, plus tooltips > and all that stuff. Really?? How can it do code completion since the type is not known until runtime? In IDEA the completion only handles the DOM binding and some rare cases when the type can be derived. As for JS being easier for non-Java peeps, my take is; 1. To make JS useful the developers exposes useful object bindings. 2. There is no "development environment" to contend with. Align those and the "JS vs Java" argumentation becomes a different experience altogether. Adding to that is, the times when I have seen "non-Java" peeps making anything useful on "JS-serverside" is when they already know JS well from client development. So, the take is a lot about profiling the target before making hard-core decisions that JS is better for flow than Java. I, for one, can't stand JS, due to "runtime hell". I very much agree with everything Berin have said in this thread. Cheers Niclas
Re: ForrestBot build for cocoon-site FAILED
We are getting similar sporadic failures at Forrest so i have turned off the cronjobs for all Cocoon-site building. The daisy-to-docs does not use the PDF plugin. -David
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: Hi Ralph On 9 Dec 2005, at 15:06, Ralph Goers wrote: Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? I don't know :) Is there anything in the portal samples I can try this on? I don't know. Carsten has been working on Ajax support. http://svn.apache.org/viewcvs?rev=331752&view=rev http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113152940422930&w=2 http://mail-archives.apache.org/mod_mbox/cocoon-users/200511.mbox/[EMAIL PROTECTED]
Re: RFC: Ajax Roadmap
Hi Antonio, On 9 Dec 2005, at 17:17, Antonio Gallardo wrote: Jeremy Quinn wrote: Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"? Any ajax-specific code from the files above and from cocoon- ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. cocoon.ajax.cforms --> cocoon.ajax.forms 3 levels are ok if we will have others "cocoon.ajax." namespaces, if not the case, then "cocoon.ajax" should be enough. Shorter names --> faster typing --> faster development. ;-) Sorry, I cannot help you there :) The namespace works like this : [framework].[block].[file] [] The namespaces are converted into URLs, we need to distinguish between Cocoon and Dojo and between Ajax and Forms Blocks. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is true, then we should not store it under "cocoon.ajax"? Yes, thanks for pointing that out. Here is something interesting, JS allow us to create more complex widgets. The FormsMultiValueEditor is only one of this "complex" widgets. I believe in the future we can have more sofisticated widgets as a widget looking up data from a database and others. If this is really going to happens, then we can create a namespace for them: cocoon.ajax.widget cocoon.forms.widget Hence we can store the FormsMultiValueEditor under: cocoon.forms.widget.FormsMultiValueEditor WDYT? Fine by me. DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. +1 for cocoon.ajax.DOMUtils Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1! Thanks Jeremy for taking care of this. :-) Thank /you/ for you useful feedback ;) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Hi Ralph
On 9 Dec 2005, at 15:06, Ralph Goers wrote:
Jeremy Quinn wrote:
The first thing I have done is to use the dojo.require mechanism
to dynamically load all JS in the browser, so for instance, if
your form does not use htmlarea, the javascripts are not loaded :)
If there are multiple forms on a page (i.e. in the portal) will
multiple copies be loaded?
I don't know :)
Is there anything in the portal samples I can try this on?
With my changes, forms processed through the built-in cforms xslt now
only load 2 files via script tags :
The first one gets dojo bootstrapped, the second plugs in Cocoon's
namespace to the script loader, so we keep our code separate.
Then the other libs are 'required' as appropriate. eg. these are
always used (these samples are using the 'old' names) :
dojo.require("cocoon.forms.forms-lib");
dojo.require("cocoon.forms.cforms");
or
. . .
dojo.require("cocoon.ajax.cocoon-ajax");
cocoon.forms.ajax = true;
. . .
If the same dojo.require is called several times, only the first one
results in a file actually loading.
HTH
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"? Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. cocoon.ajax.cforms --> cocoon.ajax.forms 3 levels are ok if we will have others "cocoon.ajax." namespaces, if not the case, then "cocoon.ajax" should be enough. Shorter names --> faster typing --> faster development. ;-) FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is true, then we should not store it under "cocoon.ajax"? Here is something interesting, JS allow us to create more complex widgets. The FormsMultiValueEditor is only one of this "complex" widgets. I believe in the future we can have more sofisticated widgets as a widget looking up data from a database and others. If this is really going to happens, then we can create a namespace for them: cocoon.ajax.widget cocoon.forms.widget Hence we can store the FormsMultiValueEditor under: cocoon.forms.widget.FormsMultiValueEditor WDYT? DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. +1 for cocoon.ajax.DOMUtils Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1! Thanks Jeremy for taking care of this. :-) Best Regards, Antonio Gallardo.
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 09 December 03:59 PM Using Forrest 0.8-dev Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-12-09 03:59:30 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site 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-release/conf/work/cocoon-site/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-release/conf/work/cocoon-site/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/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-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: [echo] Oops, something broke
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? Ralph
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 09 December 02:59 PM Using Forrest 0.8-dev Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-12-09 02:59:07 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site 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-release/conf/work/cocoon-site/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-release/conf/work/cocoon-site/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/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-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: [echo] Oops, something broke
Re: RFC: Ajax Roadmap
On 9 Dec 2005, at 12:46, hepabolu wrote: Jeremy Quinn wrote: I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] GREAT! :) The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. +1, will this be available in the 2.1 branch as well or will it be reserved for 2.2? I understood that the Forms Block was shared between the two branches. I am working in 2.1. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) Great, this has been on my wish list for quite some time. I just hope the Safari problems can be overcome, plus this is not tested at all on Windows yet ;) forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. +1 Any ajax-specific code from the files above and from cocoon- ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. +1 Are they mutually exclusive? There is a bunch of code to support the background updating of widgets (without page refresh) like adding to or rearranging items in a repeater widget, that is not needed if Ajax is not turned on for the form. There was a thread lately by Antonio about resetting the form/ widget handlers to null, thereby removing the ability for widgets to use AJAX after the first (AJAX) submit. For non-ajax forms that was the correct behaviour IIUC. Yes I read that. I am not completely up to speed on the issues, but would expect to re- visit that when dealing with the events stuff (below). FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. +1 DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. what would be the reason to make it separate? I don't have any strong arguments either way ATM. Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] I cannot figure out the implications for this, but given the goal of minimizing our own ajax code: +1 Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. This could include stuff like tabs, help popups, visual effects, trees, date picker, rich text editor etc. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. I am not sure there is a dojo equivalent to our multivalue fields, we may prefer the functionality of our current date picker, rich text editor etc. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. There are widgets for time picking, colour picking, etc. This I don't understand (due to lack of dojo knowledge). Could you give one example of each? I also probably do not have enough knowledge yet about available dojo widgets either, yet :) But see above. IIUC Dojo is all client-side behaviour of widgets. There is nothing that could replace the server-side, model and binding of CForms. If all this is true, I don't understand the above 3 actions. Some of the behaviours we have in Ajax CForms are purely client-side code, others a mixture of client and server-side. Dojo helps with the client-side in terms of its widget framework but also with stuff like the interaction between client and server, it's powerful event api etc. CForms would continue to work in the same way, i.e. transparently provide the behaviours you turn on in your form. Hopefully the range of behaviours can get richer, while the amount of code for us to maintain gets smaller :) Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1 HTH. Thanks for your response. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] GREAT! The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. +1, will this be available in the 2.1 branch as well or will it be reserved for 2.2? The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) Great, this has been on my wish list for quite some time. forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. +1 Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. +1 Are they mutually exclusive? There was a thread lately by Antonio about resetting the form/widget handlers to null, thereby removing the ability for widgets to use AJAX after the first (AJAX) submit. For non-ajax forms that was the correct behaviour IIUC. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. +1 DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. what would be the reason to make it separate? Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] I cannot figure out the implications for this, but given the goal of minimizing our own ajax code: +1 Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. This I don't understand (due to lack of dojo knowledge). Could you give one example of each? IIUC Dojo is all client-side behaviour of widgets. There is nothing that could replace the server-side, model and binding of CForms. If all this is true, I don't understand the above 3 actions. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1 HTH. Bye, Helma
RFC: Ajax Roadmap
Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). WDYT ? regards Jeremy [1] http://dojotoolkit.org [2] http://dojotoolkit.org/trac/ticket/236 [3] http://dojotoolkit.org/docs/intro_to_dojo_io.html [4] http://dojotoolkit.org/docs/dojo_event_system.html smime.p7s Description: S/MIME cryptographic signature
[EMAIL PROTECTED]: Project cocoon-block-portal (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-portal has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-faces : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-scratchpad : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [portal-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/gump_work/build_cocoon_cocoon-block-portal.html Work Name: build_cocoon_cocoon-block-portal (Type: Build) Work ended in a state of : Failed Elapsed: 32 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-08122005 -Dblock-name=portal gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-08122005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-08122005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-08122005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-08122005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-08122005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-08122005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-08122005.jar:/usr/local/gu
[EMAIL PROTECTED]: Project cocoon-block-portal (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-portal has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-faces : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-scratchpad : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [portal-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/gump_work/build_cocoon_cocoon-block-portal.html Work Name: build_cocoon_cocoon-block-portal (Type: Build) Work ended in a state of : Failed Elapsed: 32 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-08122005 -Dblock-name=portal gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-08122005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-08122005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-08122005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-08122005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-08122005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-08122005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-08122005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-08122005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-08122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-08122005.jar:/usr/local/gu
Custom Pipeline questions
Hey guys, my problem of today: I'm writing a custom pipeline implementation. When it is set up, I lookup a special component, which sole purpose is to manipulate pipeline processing. I'm, however, not sure how all this works, once more than one user sends a request. If a pipeline is processing, another request must not interfere. Does that mean, that a new pipeline object is created (and thus a new object of my component) when two requests occur simultaneously? I see that the AbstractProcessingPipeline is Recyclable, so it looks like this? Is there a pool of pipelines? My second question: Well, if there are different pipeline objects for different requests I don't really need this. The point is, that my component manipulates pipeline processing depending on the user that sends the request, so if there are different components per request I don't need to make a distinction via the sessionID. If they are sharing a pipeline and my object, I need to find out, which request starts the pipeline processing. Can I somehow find that out? (read: get the Request object or something similar to distinguish user requests from each other) Man it's a pain to explain this.. ;) Stefan
