DO NOT REPLY [Bug 33178] - Mounting a sitemap with pass-through alters resolveURI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33178. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33178 --- Additional Comments From [EMAIL PROTECTED] 2005-01-31 09:51 --- Oops, forgot that one in the deprecated block. Fixed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Cocoon-2.1.X Tests Failure 01/31/05
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20050131.log Last messages from the log file: == Testsuite: org.apache.cocoon.serialization.XMidiSerializerTestCase Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.01 sec Testcase: testMIDISerializer took 2.721 sec cocoon-block-webdav-tests: Created dir: /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Copying 3 files to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Compiling 1 source file to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Running org.apache.cocoon.components.source.impl.WebDAVSourceTestCase Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.237 sec Testsuite: org.apache.cocoon.components.source.impl.WebDAVSourceTestCase Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.237 sec - Standard Error - log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.HttpClient). log4j:WARN Please initialize the log4j system properly. - --- Testcase: testResolve took 1.797 sec Testcase: testTraversal took 0.057 sec Testcase: testModification took 0.036 sec Testcase: testMakeCollection took 0.057 sec junit-tests-report: Created dir: /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/report Transform time: 51607ms Unit report is at build/cocoon-2.1.7-dev/test/report/index.html Last messages from the server console: == [EMAIL PROTECTED]: [Thread[Thread-4,5,main]]: checkRunning(false) entered [EMAIL PROTECTED]: [Thread[Thread-4,5,main]]: checkRunning(false) exited [EMAIL PROTECTED]: Startup sequence initiated from main() method [EMAIL PROTECTED]: Loaded properties from [/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties] [EMAIL PROTECTED]: Initiating startup sequence... [EMAIL PROTECTED]: Server socket opened successfully in 10 ms. [EMAIL PROTECTED]: Database [index=0, id=0, db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb, alias=] opened sucessfully in 1834 ms. [EMAIL PROTECTED]: Startup sequence completed in 1893 ms. [EMAIL PROTECTED]: 2005-01-31 01:30:17.442 HSQLDB server 1.7.3 is online [EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL [EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly - The database 'db' root directory has been set to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db - [main] '/db/system/SysSymbols' Set object system_SysConfig - [main] '/db/system/SysConfig' Set document database.xml - [main] '/db/system/SysSymbols' Set object meta_Metas - [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig - Database 'db' successfully opened - Xindice server successfully started - VM shutting down with the disk store for cocoon-ehcache-1 still active. The disk store is persistent. Calling dispose... - Database 'db' successfully closed - Scheduler Cocoon_$_Mon_Jan_31_01:30:07_PST_2005 paused. - Scheduler Cocoon_$_Mon_Jan_31_01:30:07_PST_2005 shutting down. - Scheduler Cocoon_$_Mon_Jan_31_01:30:07_PST_2005 paused. - Scheduler Cocoon_$_Mon_Jan_31_01:30:07_PST_2005 shutdown complete.
Cocoon crashs!
Hi, I am directing a course at the University of Munich. We use a Transformer to integrate OWL-QL into the Cocoon framework. Each time when we get a request owl-ql loads up some Ontologies, which may have about 100 MB. I changed the heap-size to 512mb through the java option -X. Well when we geht 20 requests in a short time cocoon crashs. I tried to use the clear-cache action, but it doesn't work. Do you have an Idea how I can solve this problem? I am using cocoon 2.1.5 and tomcat 5. Many thanks, Halgurt
Re: Cocoon crashs!
Halgurt Mustafa-Ali wrote: Hi, I am directing a course at the University of Munich. We use a Transformer to integrate OWL-QL into the Cocoon framework. Each time when we get a request owl-ql loads up some Ontologies, which may have about 100 MB. I changed the heap-size to 512mb through the java option -X. Well when we geht 20 requests in a short time cocoon crashs. I tried to use the clear-cache action, but it doesn't work. Do you have an Idea how I can solve this problem? I am using cocoon 2.1.5 and tomcat 5. In order to help we need more details Does the vm die? Do you see any exceptions? What transformer are you using? ...your explanation is a bit vague. cheers -- Torsten signature.asc Description: OpenPGP digital signature
[GUMP@brutus]: Project cocoon-block-template (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-template has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-template : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [template-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://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html Work Name: build_cocoon_cocoon-block-template (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=31012005 -Dblock-name=template gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[GUMP@brutus]: Project cocoon-block-forms (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-forms has an issue affecting its community integration. This issue affects 8 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-apples : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-tour : Java XML Framework - lenya : Content Management System Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [forms-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://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html Work Name: build_cocoon_cocoon-block-forms (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=31012005 -Dblock-name=forms gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
NPE with global input module
Dear Cocooners, today, after having upgraded our Cocoon build to the latest revision from trunk, we started getting NPEs from a project that had worked perfectly until then. Turns out the NPE was caused in a subsitemap while trying to use the global input module to reference the value of a global variable that was defined in the same subsitemap. I started looking for differences between our app and the Cocoon samples, where the global input module seems to work fine, and I concluded that the only difference was the the samples' top sitemap had a map:component-configurations global-variables/ map:component-configurations section, whereas our toplevel sitemap did not. So I added an empty global-variables element to ours too and the NPE went away! So, apparently, you MUST put a global-variables element in the toplevel sitemap in order to declare global variables in a subsitemap. Is this a bug or is this intended behaviour? Ugo -- Ugo Cei - http://agylen.com/blojsom/blog/ smime.p7s Description: S/MIME cryptographic signature
[ANN] I have a new ISP
Hi All This is to announce that I am moving away from my old ISP, Demon.net and have setup a new domain at fiveone.org. media.demon.co.uk will cease to exist in approximately one month. [any user] at fiveone.org will reach me. Why Five One? My birthday is the 5th of January ;) My new homepage is at http://www.fiveone.org, I have not even got around to viewing the site in WinMSIE yet, so goodness knows what it looks like ;) I have also setup my first blog at http://jeremyquinn.blogspot.com. I have also taken the opportunity to re-subscribe to the Cocoon mailing lists as [EMAIL PROTECTED] So if you are wondering, don't worry . it really is me ;) Best regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: [RT] input-modules in the sitemap
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Am I the only one that is bugged by the fact that you have to add the input modules in the cocoon.xconf while the sitemap components go in the sitemap? We had several attempts to change this but there was always someone against it :( You can do it right now. map:components is handled exactly as an xconf file to feed the service manager. And since components don't care about namespaces in their configurations, you can even write: map:input-modules map:input-module name=blah class=com.blah.BlahModule/ /map:input-modules (notice though the use of class instead of src) This behaviour, although unofficial, is effective since day one in the TreeProcessor. IMO, it's time to make it official. No, please not - with 2.2 we have the official include feature and imho this is sufficient for this. Carsten
Re: NPE with global input module
Ugo Cei wrote: Dear Cocooners, today, after having upgraded our Cocoon build to the latest revision from trunk, we started getting NPEs from a project that had worked perfectly until then. Turns out the NPE was caused in a subsitemap while trying to use the global input module to reference the value of a global variable that was defined in the same subsitemap. I started looking for differences between our app and the Cocoon samples, where the global input module seems to work fine, and I concluded that the only difference was the the samples' top sitemap had a map:component-configurations global-variables/ map:component-configurations section, whereas our toplevel sitemap did not. So I added an empty global-variables element to ours too and the NPE went away! So, apparently, you MUST put a global-variables element in the toplevel sitemap in order to declare global variables in a subsitemap. Is this a bug or is this intended behaviour? This is a bug! Carsten
Re: [RT] input-modules in the sitemap
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Am I the only one that is bugged by the fact that you have to add
the input modules in the cocoon.xconf while the sitemap components
go in the sitemap?
We had several attempts to change this but there was always someone
against it :(
You can do it right now. map:components is handled exactly as an
xconf file to feed the service manager. And since components don't
care about namespaces in their configurations, you can even write:
map:input-modules
map:input-module name=blah class=com.blah.BlahModule/
/map:input-modules
(notice though the use of class instead of src)
This behaviour, although unofficial, is effective since day one in
the TreeProcessor. IMO, it's time to make it official.
No, please not - with 2.2 we have the official include feature and
imho this is sufficient for this.
Yeah, but technically speaking, this makes absolutely no difference, as
include does nothing but expanding the contents of an xconf within
map:components
So writing
map:components
include src=blah.xconf/
/map:components
is exactly the same as copy/pasting the contents of blah.xconf in the
sitemap...
Going further, add the possibility to specify a class-path to
map:components to feed a per-sitemap classloader (or autocompiling
classloader) and you have cheap semi-real blocks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] I have a new ISP
Il giorno 31/gen/05, alle 13:13, Jeremy Quinn ha scritto: Why Five One? My birthday is the 5th of January ;) Ah ha, I thought it was your age ;) Ugo -- Ugo Cei - http://agylen.com/blojsom/blog/ smime.p7s Description: S/MIME cryptographic signature
Re: [ANN] I have a new ISP
Jeremy Quinn wrote:
Hi All
This is to announce that I am moving away from my old ISP, Demon.net
and have setup a new domain at fiveone.org.
media.demon.co.uk will cease to exist in approximately one month.
[any user] at fiveone.org will reach me.
Why Five One? My birthday is the 5th of January ;)
My new homepage is at http://www.fiveone.org, I have not even got
around to viewing the site in WinMSIE yet, so goodness knows what it
looks like ;)
Looks way nicer on Safari than on Firefox, which seems to not understand
the text-shadow CSS property.
I have also setup my first blog at http://jeremyquinn.blogspot.com.
It provides only an Atom feed. Is it possible to provide also an RSS feed?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] input-modules in the sitemap
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Am I the only one that is bugged by the fact that you have to add the input modules in the cocoon.xconf while the sitemap components go in the sitemap? You can do it right now. map:components is handled exactly as an xconf file to feed the service manager. And since components don't care about namespaces in their configurations, you can even write: map:input-modules map:input-module name=blah class=com.blah.BlahModule/ /map:input-modules (notice though the use of class instead of src) This behaviour, although unofficial, is effective since day one in the TreeProcessor. IMO, it's time to make it official. Yeah, we could start doing so by moving that section on our own sitemap ;-) -- Stefano.
Re: NPE with global input module
Ugo Cei wrote: Dear Cocooners, today, after having upgraded our Cocoon build to the latest revision from trunk, we started getting NPEs from a project that had worked perfectly until then. Turns out the NPE was caused in a subsitemap while trying to use the global input module to reference the value of a global variable that was defined in the same subsitemap. I started looking for differences between our app and the Cocoon samples, where the global input module seems to work fine, and I concluded that the only difference was the the samples' top sitemap had a map:component-configurations global-variables/ map:component-configurations section, whereas our toplevel sitemap did not. So I added an empty global-variables element to ours too and the NPE went away! So, apparently, you MUST put a global-variables element in the toplevel sitemap in order to declare global variables in a subsitemap. Is this a bug or is this intended behaviour? Looks like a bug to me. -- Stefano.
DO NOT REPLY [Bug 33286] - broken link for the xreporter expression language
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33286. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33286 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-31 15:40 --- Thanks, applied to trunk and branch 2_1_X. The change will not appear on the website until somebody updates it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [ANN] I have a new ISP
On 31 Jan 2005, at 13:13, Ugo Cei wrote: Il giorno 31/gen/05, alle 13:13, Jeremy Quinn ha scritto: Why Five One? My birthday is the 5th of January ;) Ah ha, I thought it was your age ;) Thanks Ugo . I would not want to go through this hassle every year ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: [RT] input-modules in the sitemap
Sylvain Wallez wrote: No, please not - with 2.2 we have the official include feature and imho this is sufficient for this. Yeah, but technically speaking, this makes absolutely no difference, as include does nothing but expanding the contents of an xconf within map:components Yes, I know - so following your road we could just skip the whole cocoon.xconf and put it in the root sitemap :) Components are not used directly in the sitemap (except sitemap components), so we shouldn't start defining them in the sitemap. Of course this is a little bit different with input modules which just has historical reasons that they're in the xconf. I think it's better to move everything out of the sitemap into xconf files that *belong* to the sitemap than the opposite. Carsten
Re: [ANN] I have a new ISP
On 31 Jan 2005, at 14:03, Sylvain Wallez wrote: Jeremy Quinn wrote: Hi All This is to announce that I am moving away from my old ISP, Demon.net and have setup a new domain at fiveone.org. media.demon.co.uk will cease to exist in approximately one month. [any user] at fiveone.org will reach me. Why Five One? My birthday is the 5th of January ;) My new homepage is at http://www.fiveone.org, I have not even got around to viewing the site in WinMSIE yet, so goodness knows what it looks like ;) Looks way nicer on Safari than on Firefox, which seems to not understand the text-shadow CSS property. Yes, I think Safari is the only one that supports that at the moment. I have also setup my first blog at http://jeremyquinn.blogspot.com. It provides only an Atom feed. Is it possible to provide also an RSS feed? I am a bit too much of a neophyte to know the difference :) Atom appears to be the only one blogger.com offer .. unless this is something I can provide via a 3rd party in some way. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: SVN behaviour with Id keyword
On Sun, Jan 30, 2005 at 11:21:30AM +0100, Sylvain Wallez wrote: The nice thing once all this has been fixed, is that SVN doesn't consider as being modified a file where expanded keyword have been replaced by their unexpanded counterpart. You can then use whatever diffmerge tool you want to sync 2.2 and 2.1, since only files having real differences (and not only a different $Id$) will show up in the tool. Are other people interested in this small Id-unexpander script? I am interested in that script. --Tim Larson
Re: NPE with global input module
Should be fixed now. Carsten Ugo Cei wrote: Dear Cocooners, today, after having upgraded our Cocoon build to the latest revision from trunk, we started getting NPEs from a project that had worked perfectly until then. Turns out the NPE was caused in a subsitemap while trying to use the global input module to reference the value of a global variable that was defined in the same subsitemap. I started looking for differences between our app and the Cocoon samples, where the global input module seems to work fine, and I concluded that the only difference was the the samples' top sitemap had a map:component-configurations global-variables/ map:component-configurations section, whereas our toplevel sitemap did not. So I added an empty global-variables element to ours too and the NPE went away! So, apparently, you MUST put a global-variables element in the toplevel sitemap in order to declare global variables in a subsitemap. Is this a bug or is this intended behaviour? Ugo
Re: [RT] input-modules in the sitemap
Le 31 janv. 05, à 07:59, Sylvain Wallez a écrit : You can do it right now. map:components is handled exactly as an xconf file to feed the service manager... ...This behaviour, although unofficial, is effective since day one in the TreeProcessor. IMO, it's time to make it official. +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 33315] New: - cygwin detection in build.sh is not optimal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33315. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33315 Summary: cygwin detection in build.sh is not optimal Product: Cocoon 2 Version: Current SVN 2.1 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: general components AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] in build.sh cygwin detection is incorrect: if [ $TERM = cygwin ] ; then this breaks if I ssh in from a windows box using cygwin to a unix box, where i try to run build.sh. my $TERM is indeed cygwin, but I am ssh'ed into a unix box. the line below should work in all cases: if [ `uname -o | tr [A-Z] [a-z]` = cygwin ] ; then -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [ANN] I have a new ISP
Le 31 janv. 05, à 16:50, Jeremy Quinn a écrit : ...Atom appears to be the only one blogger.com offer .. unless this is something I can provide via a 3rd party in some way... Looks like http://feedburner.com/ might help but I haven't tried it. Me, I've upgraded my netnewswire RSS reader to the 2.0 beta to be able to subscribe to atom feeds like yours. It looks stable enough until now. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: NPE with global input module
Il giorno 31/gen/05, alle 19:30, Carsten Ziegeler ha scritto: Should be fixed now. Carsten Cool, thanks! Ugo -- Ugo Cei - http://agylen.com/blojsom/blog/ smime.p7s Description: S/MIME cryptographic signature
Portal Tools plugin links
I am running Cocoon on my Linux box and am trying to access the portal tools plugins from my Windows box. This does not work because the links are hardcoded to localhost. I tried changing it to a relative path but it failed miserably. This needs to be changed to behave like the rest of the portal. Ralph
Re: SVN behaviour with Id keyword
Tim Larson wrote: Sylvain Wallez wrote: The nice thing once all this has been fixed, is that SVN doesn't consider as being modified a file where expanded keyword have been replaced by their unexpanded counterpart. You can then use whatever diffmerge tool you want to sync 2.2 and 2.1, since only files having real differences (and not only a different $Id$) will show up in the tool. Are other people interested in this small Id-unexpander script? I am interested in that script. Thanks Sylvain, perhaps add it to the ASF committers repository in the tools/. --David
DO NOT REPLY [Bug 33315] - cygwin detection in build.sh is not optimal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33315. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33315 --- Additional Comments From [EMAIL PROTECTED] 2005-01-31 22:59 --- The idea is good. However, there is no option -o to uname on FreeBSD/Mac OS X/Debian. Using straight 'uname' with no options works for those systems. Does that work for you? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33318] New: - CocoonForms Javascript error on Mac IE 5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33318.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33318
Summary: CocoonForms Javascript error on Mac IE 5
Product: Cocoon 2
Version: 2.1.6
Platform: Macintosh
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
form-libs.js for CocoonForms uses the undefined key word.
Apparently Mac IE 5 doesn't recognize this. A work around mention on the web
was to use the typeof operator and compare the result with the string
undefined
so change
if (name == undefined) { ... }
to
if ( typeof(name) == undefined ) {... }
I'll try and attach a patch once this bug is submitted.
The file affected in the trunk is
http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/resources/js/forms-lib.js
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33318] - CocoonForms Javascript error on Mac IE 5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33318 --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 00:11 --- Created an attachment (id=14143) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14143action=view) patch for form-libs.js -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33319] New: - [PATCH] Fix issue with ResourceReader returning non-cacheable content if expires not explicitly provided
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33319.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33319
Summary: [PATCH] Fix issue with ResourceReader returning non-
cacheable content if expires not explicitly provided
Product: Cocoon 2
Version: Current SVN 2.1
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
The way ResourceReader is currently implemented it will set a 'Vary' response
header if the 'expires' parameter is not provided.
IE will not cache responses containing this header, with one exception when
the header value is the 'User-Agent' field, for more detail see:
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html
Looking at the ResourceReader source and the associated bug report, setting
the 'Vary' header was intended to prevent IE from
caching the resource when the 'expires' parameter was provided with a value of
0. The way the code is implemented the header will also be set when the
expires parameter is not provided.
Patch is provided below:
Index: org/apache/cocoon/reading/ResourceReader.java
===
--- org/apache/cocoon/reading/ResourceReader.java (revision 149197)
+++ org/apache/cocoon/reading/ResourceReader.java (working copy)
@@ -302,7 +302,7 @@
try {
if (expires 0) {
response.setDateHeader(Expires, System.currentTimeMillis()
+ expires);
-} else {
+} else if(expires == 0) {
// See Bug #14048
response.addHeader(Vary, Host);
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
[2.2] building individual blocks
Somewhere in the back of my head I remember a proposal/discussion about changing the build system so it's possible to build individual blocks. So either I was just dreaming of that *sigh* Wouldn't that be nice!? ...or it's already implemented and I just missed how to do it... So what is it? cheers -- Torsten signature.asc Description: OpenPGP digital signature
CocoonForms Javascript function displays alert message and can result in Javascript error on IE
In the the file:
http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/resources/js/forms-lib.js
there's the following code:
// Handlers that are to be called in form's onsubmit event
// FIXME: this single var implies only one form per page, and needs to be
// visited if we decide to support several forms per page.
var forms_onsubmitHandlers = new Array();
function forms_onsubmit() {
if (forms_onsubmitHandlers == null) {
alert(onsubmit called twice!);
}
for (var i = 0; i forms_onsubmitHandlers.length; i++) {
forms_onsubmitHandlers[i].forms_onsubmit();
}
// clear it
forms_onsubmitHandlers = null;
}
This code is called when a widget has an on-changed event, a
selection-list for example.
The problem we've observed is if code called, and the on-value-changed
event has any lag time ( in our case executing a query against a
database ) the user can quickly use the selection-list to select another
option before the 1st selection returned.
This displays the onsubmit called twice! alert box.
In Mozilla, that's it, on IE after the alert box there's a javascript
error. IE complains about calling forms_onsubmitHandlers.length since
it was set to null;
1.) would anyone object to removing the alert(onsubmit called twice!)?
- in our case, we'd just prefer to service the second request without
displaying the alert
2.) should the forms_onsubmitHandlers = null; be changed to
forms_onsubmitHandlers = new Array(); ?
- or alternatively, the for loop could be enclosed in the same sort
of null checking used for the current alert message.
If anyone has a preference for these two issues let me know and I'll
submit a patch.
Thanks,
Dan
Re: [2.2] building individual blocks
Torsten Curdt wrote: Somewhere in the back of my head I remember a proposal/discussion about changing the build system so it's possible to build individual blocks. So either I was just dreaming of that *sigh* Wouldn't that be nice!? ...or it's already implemented and I just missed how to do it... So what is it? well, gump builds blocks one by one... if you do ./build.sh -Dblock-name=blah gump-block it will build just the 'blah' block (and obviously, cocoon, as it needs it) -- Stefano.
Re: SVN behaviour with Id keyword
David Crossley wrote:
Tim Larson wrote:
Sylvain Wallez wrote:
The nice thing once all this has been fixed, is that SVN doesn't
consider as being modified a file where expanded keyword have been
replaced by their unexpanded counterpart. You can then use whatever
diffmerge tool you want to sync 2.2 and 2.1, since only files having
real differences (and not only a different $Id$) will show up in the tool.
Are other people interested in this small Id-unexpander script?
I am interested in that script.
Thanks Sylvain, perhaps add it to the ASF committers repository
in the tools/.
Mmmh... not sure it deserves going there considering how quick-hacked it
is :
---
#!/bin/sh
# Unexpands all $Id $ keywords from files having a certain prefix
(i.e. replaces them by $Id$)
# The good thing with Subversion is that it doesn't consider as being
modified a file where the
# keyword has changed
find . \( -name '*.java' -or -name '*.xml' -or -name '*.xmap' -or -name
'*.js' -or -name '*.xsl' \) -print | while read file
do
echo $file
/usr/bin/sed -e 's/\$Id:.*\$/$Id$/' $file ${file}.rmkw-tmp
mv ${file}.rmkw-tmp $file
done
---
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] input-modules in the sitemap
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
No, please not - with 2.2 we have the official include feature and
imho this is sufficient for this.
Yeah, but technically speaking, this makes absolutely no difference,
as include does nothing but expanding the contents of an xconf
within map:components
Yes, I know - so following your road we could just skip the whole
cocoon.xconf and put it in the root sitemap :)
Components are not used directly in the sitemap (except sitemap
components), so we shouldn't start defining them in the sitemap. Of
course this is a little bit different with input modules which just
has historical reasons that they're in the xconf.
If we restrict ourselves to components used directly in the sitemap,
then yes, other component don't fit there.
Now things are different if we consider a sitemap a modularization unit
in a Cocoon application. Why should we define in the global cocoon.xconf
e.g. a JDBC datasource that is used only in a particular subsitemap, or
a business component used in a particular sitemap's flowscript?
A concrete example: imagine an admin tool for a webapp which has write
access to the user database whereas all other parts of the application
have read-only access. Allowing the datasource to be defined in the
admin sitemap cleanly isolates it from the rest of the application. And
if for some reason we decide that admin should not be possible through
the web, then just delete the admin directory and you're done, without
modifying the main xconf.
I think it's better to move everything out of the sitemap into xconf
files that *belong* to the sitemap than the opposite.
I understand your point. Does this mean you would be ok for the
datasource mentioned above to be declared in an xconf file included by
the admin sitemap? From my POV this is just a syntax detail and I'm ok
with moving sitemap-related components (considered as a modularization
unit) to an xconf file beside the sitemap.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] input-modules in the sitemap
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: No, please not - with 2.2 we have the official include feature and imho this is sufficient for this. Yeah, but technically speaking, this makes absolutely no difference, as include does nothing but expanding the contents of an xconf within map:components Yes, I know - so following your road we could just skip the whole cocoon.xconf and put it in the root sitemap :) Components are not used directly in the sitemap (except sitemap components), so we shouldn't start defining them in the sitemap. Of course this is a little bit different with input modules which just has historical reasons that they're in the xconf. If we restrict ourselves to components used directly in the sitemap, then yes, other component don't fit there. Now things are different if we consider a sitemap a modularization unit in a Cocoon application. Why should we define in the global cocoon.xconf e.g. a JDBC datasource that is used only in a particular subsitemap, or a business component used in a particular sitemap's flowscript? A concrete example: imagine an admin tool for a webapp which has write access to the user database whereas all other parts of the application have read-only access. Allowing the datasource to be defined in the admin sitemap cleanly isolates it from the rest of the application. And if for some reason we decide that admin should not be possible through the web, then just delete the admin directory and you're done, without modifying the main xconf. I think it's better to move everything out of the sitemap into xconf files that *belong* to the sitemap than the opposite. I understand your point. Does this mean you would be ok for the datasource mentioned above to be declared in an xconf file included by the admin sitemap? From my POV this is just a syntax detail and I'm ok with moving sitemap-related components (considered as a modularization unit) to an xconf file beside the sitemap. Yes, I think this is a clean solution. I see the need for defining components locally (on a per sitemap base) as well. That's why I wanted the include feature :) So, I'm +1 for including them from the sitemap, but -1 for adding them directly in the sitemap. I know, technically it's the same, but separating them is imho the cleaner solution. Carsten
DO NOT REPLY [Bug 33324] New: - Sessions that use Flowscript are not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33324. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33324 Summary: Sessions that use Flowscript are not serializable Product: Cocoon 2 Version: Current SVN 2.2 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Flowscript AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] The scopes of Flowscripts are not serializable. The same is valid for the continuation objects. This requires a more sophisticated serialization process. See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33324] - Sessions that use Flowscript are not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33324. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33324 [EMAIL PROTECTED] changed: What|Removed |Added CC||dev@cocoon.apache.org AssignedTo|dev@cocoon.apache.org |[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Session serialization
Ralph Goers wrote: Aurélien DEHAY wrote: Hello. I'm trying to serialize my sessions with the persistance manager of tomcat to not loose them between during a restart. I use session-context to store XML in my session and use a flowscript to handle my login logic (maybe it's not the sexyier way, but that's the way I do it). When I shutdown my tomcat (tested with tomcat 5.0.28, 5.0.30 and 5.5.4), I've got the following error: java.io.NotSerializableException: org.apache.cocoon.components.CocoonComponentManager. What is this object? I've tryied to invalidate my continuations objects in the flowscript without any success. Is anyone knows a solution? Regards. Cocoon is not a distributable application, as defined by the Servlet spec. You will find that quite a few non-Serializable objects are stored in the session. CocoonComponentManager is pretty much what it sounds like. It keeps track of all the components that have been configured and are available for use. As you can imagine, Serializing this would make very little sense. I have no idea why it is being stored in the session though. Not directly but the Flowscript scope has access to e.g. the Cocoon service manager and the serialization process serializes the complete object graph. A few weeks ago I had some discussions with Torsten, Chris Oliver, Sylvain and Vadim I think the problem should be solvable. I'm going to keep the list updated about my experiences and I opened an issue at bugzilla (http://issues.apache.org/bugzilla/show_bug.cgi?id=33324) -- Reinhard
