Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: First, I'm assuming this is the code you spoke of a while ago to move values outside of Cocoon.xconf and the sitemap so that things like database ports, etc can be defined outside the webapp? Yepp. Well, basically I would need to be able to do whatever you are doing while getting the data from a different file. We have an XML file that has some initial logging configuration as well as a section for system property settings. I'd like to add whatever data you are reading to that file so that the server only needs one configuration file outside the webapp. Basically, I would provide the routine to read the data from wherever I want and your routine would process it. Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: Wow. That would actually be a lot of backporting IMO, meaning the 2.1 branch wouldn't be very different from the trunk! This feature alone will make people jump to 2.2 once we release it, even as a beta. So I agree with Upayavira: let's release a 2.2 without OSGi and concentrate on it for 2.3. And BTW, instrumentable is currently broken (I suspect some binary incompatibility between Excalibur libraries). Excalibur has released a new version of most libraries recently. We should upgrade. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Let's move this into a different thread :) Daniel Fagerstrom wrote: I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 When the OSGi stuff are changed to R4 and is usefull enough we can start to include it within 2.2.x releases for early adaptors. And when it is stable enough and we have all infrastructure in terms of block repositories, deploy tools, build system etc in place, we can remove the classic way and release a 3.0. Ok, this sound reasonable. I see currently two major things that have to be done for releasing a version of 2.2: a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if everyone syncs between one and four blocks, we can get over this very quickly. b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. If these things are fixed, +1 for 2.2M1 after the GT. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Carsten Ziegeler wrote: Let's move this into a different thread :) Daniel Fagerstrom wrote: I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 When the OSGi stuff are changed to R4 and is usefull enough we can start to include it within 2.2.x releases for early adaptors. And when it is stable enough and we have all infrastructure in terms of block repositories, deploy tools, build system etc in place, we can remove the classic way and release a 3.0. Ok, this sound reasonable. I see currently two major things that have to be done for releasing a version of 2.2: a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if everyone syncs between one and four blocks, we can get over this very quickly. b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. If these things are fixed, +1 for 2.2M1 after the GT. Carsten And releasing 2.2 would mean that *NO NEW FEATURES GO TO 2.1.x* from this point on :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Pier Fumagalli wrote: On 5 Sep 2005, at 01:53, Antonio Gallardo wrote: Pier Fumagalli wrote: Depending on your platform encoding (yours apparently ISO8859-1, mine UTF-8, my wife's -she's japanese- Shift-JIS) that sequence (B4) of BYTES as in the original source code will be interpreted as a different character. The char encoding Shift-JIS (JIS X 0201:1997 or JIS X 0208:1997) is is exactly the same as using ISO-8859-1. We need to keep the sources in UNICODE and there is also for Japanese: Hiragana, Katakana, et al: http://www.unicode.org/charts/ Err... Ehmmm.. No... The character in question (Latin-1 character B4, Acute Accent) is encoded in ISO8850-1 as the bytes sequence B4, while in Shift-JIS the same character is encoded as byte sequence 81 4C, quite different. Reading the byte sequence B4 in Shift-JS will produce Unicode character FF74 (Halfwidth katakana E), which is quite different from an acute accent as you intended. Trust me, it's 9 years I'm doing this! :-) Yes, I believe you. :-) When I told that using Shift-JIS and ISO-8859-1 is the same. I had in mind that they don't represent the full unicode expectrum. I was just tryin to show this problem in other char-set So in fact we are in the same problem. Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. Changing the binary sequence B4 to \u00B4 instructs the JVM that no matter what encoding your platform is set to, the resulting character will always (always) be UNICODE 00B4, the Acute Accent, part of the Latin-1 (0X0080) table. If we wrote the code in UNICODE you will have the same effect. It is exactly the same as with XML, isn't? Unicode is simply a list of characters. To save them on a disk, you _need_ to use an encoding. Unicode characters are 32bits long (they were 16 bits until Unicode 4 came along, but that ain't important right now), bytes are 8bits long. It's as easy as that. To represent 32 bits in 8, you need to compress them (or as said in I18N, encoding them). Some encodings are complete (such as the family of UTF encodings) meaning that the encoding CAN represent ALL Unicode characters, some are not (such as ISO8859-1 which can represent only Unicode characters from 00 to FF). Yes. Please correct me here if I am wrong: Our SVN uses UTF-8 as the default charset (or encoding) or not? If not, then we need to take care not only of java sources but also of the chars above 7F in the XML files. I have special interest in that, since we wrote mostly spanish messages. I will like to know if this is needed or not. Best Regards, Antonio Gallardo.
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten I think making it pluggable is what I requested in the first place. But I wouldn't want ot assume that an XML file has nothing else in it other than properties. So I would prefer that the plug-in have the responsibility of interpreting whatever datasource it is reading. Ralph
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Carsten Ziegeler wrote: Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten I think making it pluggable is what I requested in the first place. But I wouldn't want ot assume that an XML file has nothing else in it other than properties. So I would prefer that the plug-in have the responsibility of interpreting whatever datasource it is reading. Ok, I understand this of course, the question is, how do you want to get the information? Currently you can get all properties read from Cocoon in your own component/code. If we make the reading pluggable, we also need a way to deliver this information to the components that are interested in it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Carsten Ziegeler wrote: Carsten Ziegeler wrote: Let's move this into a different thread :) Daniel Fagerstrom wrote: I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 When the OSGi stuff are changed to R4 and is usefull enough we can start to include it within 2.2.x releases for early adaptors. And when it is stable enough and we have all infrastructure in terms of block repositories, deploy tools, build system etc in place, we can remove the classic way and release a 3.0. Ok, this sound reasonable. I see currently two major things that have to be done for releasing a version of 2.2: a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if everyone syncs between one and four blocks, we can get over this very quickly. b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. If these things are fixed, +1 for 2.2M1 after the GT. Carsten And releasing 2.2 would mean that *NO NEW FEATURES GO TO 2.1.x* from this point on :) +1 /me need to move to 2.2 quickly! :-) Best Regards, Antonio Gallardo
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Carsten Ziegeler wrote: Let's move this into a different thread :) Daniel Fagerstrom wrote: I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 When the OSGi stuff are changed to R4 and is usefull enough we can start to include it within 2.2.x releases for early adaptors. And when it is stable enough and we have all infrastructure in terms of block repositories, deploy tools, build system etc in place, we can remove the classic way and release a 3.0. Ok, this sound reasonable. I see currently two major things that have to be done for releasing a version of 2.2: a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if everyone syncs between one and four blocks, we can get over this very quickly. b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. If these things are fixed, +1 for 2.2M1 after the GT. Carsten Where does the switch to Maven 2 fit into this picture? Ralph
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ok, I understand this of course, the question is, how do you want to get the information? Currently you can get all properties read from Cocoon in your own component/code. If we make the reading pluggable, we also need a way to deliver this information to the components that are interested in it. Carsten What does your code currently do? I thought it replaced variables in cocoon.xconf. I guess I was assuming that it would continue to do that. Ralph
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Ralph Goers wrote: Carsten Ziegeler wrote: Let's move this into a different thread :) Daniel Fagerstrom wrote: I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 When the OSGi stuff are changed to R4 and is usefull enough we can start to include it within 2.2.x releases for early adaptors. And when it is stable enough and we have all infrastructure in terms of block repositories, deploy tools, build system etc in place, we can remove the classic way and release a 3.0. Ok, this sound reasonable. I see currently two major things that have to be done for releasing a version of 2.2: a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if everyone syncs between one and four blocks, we can get over this very quickly. b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. If these things are fixed, +1 for 2.2M1 after the GT. Carsten Where does the switch to Maven 2 fit into this picture? Probably 2.2M2 or 2.2M3, depending on how quick people are in implementing it! Regards, Upayavira
Re: Blocks in 2.2
Pier Fumagalli wrote: Any special note on how to do blocks in 2.2? Take a look at a couple of blocks in trunk and you will see how it is done. No big changes since 2.1, main changes is about directory structure and names, IIRC. I've created this week two new blocks validation and captcha, and I would love to see them in sync on HEAD (and not only in BRANCH_2_1_x). Please do. With all this OSGI stuff and work, I lost track of HEAD. Anyone care to explain like I was a three-years-old??? You don't need to care about OSGi for adding your block. The OSGi stuff is still experimental and only tried partly at a few blocks. We will also try to make everything including configuration files as back compatible as possible. If you want to join the OSGi work I can try to explain how it works. /Daniel
Google Summer of Code - the last minutes
Dear Cocooners, First of all I would like to thank the community for the great experience here. I really loved being part of the team! :) Now, a few minutes before the extended deadline, I am finally _done_. All samples work, docs are written and tests pass! Its a great feeling ;) Here is a little description of what I did: It is now possible to write separate collections of widget definitions and bindings which can be dynamically included. These are called libraries and can be imported into other libraries or form definitions/bindings. This doesn't mean these are automatically used in the including definitions or bindings, but they are available for reuse. Also, cache validation is checked recursively through all dependencies, so if a library deep in the inclusion tree changes, the complete path to the final definition or binding will be invalidated. This is something I always disliked with xsl:include/, so I fixed it here. There are three features implemented now: - Importing of external libraries into another library or form definition This works by mapping names to uris like so 'fd:import prefix=name uri=some/uri/to/a/library/'. Widgets inside the library can be referenced using name:widgetId. - Instantiating widgets from imported libraries This is done via 'fd:expand id=name:widgetId/' and directly evaluates to the referenced WidgetDefinition. This means that if a definition is expanded in a library, it can be reused in an importing definition/binding as if it was defined in the library itself. - Inheriting from other definitions/bindings An extra attribute extends on any widget definition or binding will cause the referenced entity to be resolved and used in the initialisation of the current definition or binding. This way, it is possible to override things like ids, datatypes, labels, xpaths and such and add things like validators or new child widgets or bindings. Widgets may also extend other widgets in the same container, meaning for example two widgets in the same group may extend each other, or two top-level widgets in a form may do the same. Not though that it is not possible to form cycles as references are resolved right away and cycles will result in silent ignores because of nonexisting widgets. This should change to complaining exceptions, and the code is there, just has to be uncommented. There are a few restrictions though: The complex Tree widget unfortunately does not support inheritance yet, however you can define it in a library and expand it in your form if you use it in many places. Also, single validators can only be added, not replaced or extended, since there is no way to address them right now. Same goes for selection list items, it is only possible to reset the selection list to something else. In case you want to know more, you can read the daisy page documenting the library subsystem [1]. My original proposal is still on the wiki [2]. To testdrive the new forms features, do this: - in your working copy of the trunk, cd to src/blocks/forms/trunk - svn switch https://svn.apache.org/repos/asf/cocoon/gsoc/mpfingsthorn/forms (svn will switch this part of the path to the repository above and update your working copy) - do a build in the root of the working copy - check out the forms samples! Thanks again for your opportunity and I am very much looking forward to contribute some more! Best regards, Max Pfingsthorn [1] Daisy page: http://cocoon.zones.apache.org/daisy/documentation/forms/685.html [2] Original proposal: http://wiki.apache.org/cocoon/CocoonFormsLibraryProject Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
On 5 Sep 2005, at 04:44, David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? I need to get into a meeting right now, but the first part of the pier2doc translation of this thread is here: http://www.betaversion.org/~pier/wiki/display/pier/Unicode+and+Encodings Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. The --encoding argument applies to commit messages. Paths, URLs/URIs has additional encoding requirements. Cheers Niclas
DO NOT REPLY [Bug 35845] - locale attribute in formatDate is not used in JXTemplateGenerator
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=35845. 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=35845 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||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.
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Pier Fumagalli wrote: David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? I need to get into a meeting right now, but the first part of the pier2doc translation of this thread is here: http://www.betaversion.org/~pier/wiki/display/pier/Unicode+and+Encodings Ah, that was easy for us. I knew there would be one lying around somewhere. :-) Thanks. Ever grateful. -David
[EMAIL PROTECTED]: Project cocoon (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 has an issue affecting its community integration. This issue affects 49 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 15 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-05092005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-05092005.jar -Dbuild=build/cocoon-05092005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon (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 has an issue affecting its community integration. This issue affects 49 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-05092005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 15 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-05092005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-05092005.jar -Dbuild=build/cocoon-05092005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Niclas Hedhman wrote: On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. Problem is the interpretation of line ending. On Unix, it's 0x10 which can be part of a multibyte character in a file encoded in UTF-8. In such a case, although the file is a text file, setting the eol-style=native property may well break the file... Or is there a way to specify the encoding to SVN? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
DO NOT REPLY [Bug 24457] - Xalan/XSLT using UTF-8: Incorrect SAXException: Attempt to output character of integral value...
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=24457. 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=24457 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||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.
Re: locatable exceptions in trunk, exceptions in flowscript
Sylvain Wallez wrote: Leszek Gawron wrote: org.apache.cocoon.ProcessingException: Sitemap: error calling continuation at map:call - file:/C:/dev/projects/pmt/server/build/webapp/central/sitemap.xmap:37:52 at map:mount - file:/C:/dev/projects/pmt/server/build/webapp/sitemap.xmap:535:77 The problem is the location in .js file is not given any more. Hmm... I'll have a look at it. What is causing the error? Is is a pure JS exception or an exception coming from a call to some Java code? Have a look at the stack trace. It's NPE from org.apache.cocoon.forms.datatype.FlowJXPathSelectionListBuilder.build(FlowJXPathSelectionListBuilder.java:64): org.apache.cocoon.ProcessingException: Sitemap: error calling continuation at map:call - file:/C:/dev/projects/pmt/server/build/webapp/central/sitemap.xmap:37:52 at map:mount - file:/C:/dev/projects/pmt/server/build/webapp/sitemap.xmap:533:77 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:112) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:101) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:121) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:38) at org.apache.cocoon.components.treeprocessor.CategoryNode.invokeByName(CategoryNode.java:66) at org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallNode.java:83) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:86) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:116) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:348) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:279) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:263) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:116) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:348) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:279) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:263) at org.apache.cocoon.Cocoon.process(Cocoon.java:503) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:390) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) at com.mobilebox.hibernate.PersistenceManager.doFilter(PersistenceManager.java:42) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:556) at org.mortbay.http.HttpContext.handle(HttpContext.java:1563) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:623)
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Carsten Ziegeler wrote: Ralph Goers wrote: How much do we know about the directory structure required by Maven? I know that OSGi R3 requires a directory structure, R4 doesn't. Don't understand the comment (from Upayavira) about directory structure, R3 and R4, care to explain? However, one package per bundle would make implementation much easier. At least for OSGi R3, each block (bundle) must export a unique set of packages. It would be nice if we could move all classes and interfaces so this is the case and deprecate the block classes and interface with non unique packages before we release 2.2.0 final. It is not particulary complicated but requires some work. It is necessary (if it hasn't changed in R4), that we move to block unique package names before we start to release OSGi functionality. So the sooner we can deprecate the non unique package use, the better. But it is not a blocker for 2.2. Unfortunately, my knowledge only extends to Maven 1. Carsten would have to answer this as he has been working on the conversion to Maven 2. It doesn't look like he has had to do much so far, but I'm still worried that circular dependencies between blocks are going to show up. Currently we don't have circular dependencies, so the current structure will work with maven as well. Now m1 and m2 do not differ that much when it comes to the directory structure: one java source directory per project, several resource directories (if you need), on directory for java tests etc. So this works pretty well for our current blocks. If we want to split blocks into api and impl for example, we have to create two maven projects - this of course then will also reduce problems with circular dependencies. I don't know if we need something else for osgi, but I think this approach (api vs impl) should work there as well. It is not necessary to split into api and implementation for introducing OSGi, but it will certainly be easier to use, and scale much better if we do it. Especially when there are several blocks implementing the same api, it will simplify things if we have separate api blocks. Then the api blocks that a block depends on can be downloaded during compilation of the block, and the user can choose between several implementaions of the used apis while deployoing the block. Spliting the code into api and implemetation require however considerable work and thought as not everything is designed with such a split in mind. So I think that is something that we need to work on incrementally. I just want to avoid any we can't release X because we're waiting for feature Y, that is something we've stumbled with all too often. +1 We should get into the habit of releasing what we actually have done rather, than not releasing because we developed something else than what we planned. Yes, I would like to avoid that as well. However, I don't know that we need to be using a formally released Maven 2 to know how to do this. I think time will tell. Switching to maven is currently at a very low rate, not many of us are working on it (which is ok of course), the same happens to the OSGi stuff. We shouldn't delay 2.2 neither because of waiting for m2 nor waiting for OSGi. The current version seems to work and build system works as well. Exactly. --- o0o --- Considering what we need to _change_ to get real blocks: The only thing I know about is some package renaming as discussed above. It will be more about _adding_ things. We will need manifest files with OSGi info in and we will need block.xml that describe dependencies on other blocks and bundles (this need to be integrated with the m2 dependecy information). The block.xml will also contain references to the blocks (sample) sitemap and component configuration(s) as we discussed last weak. This is all things that we can work on in an evolutionary way. From my current knowledge the largest remaining question is about how to configure components that a block exposes. Part of it is clear, the block.xml can refer to the .xconf(s) that is part of the block today and export the components within the configuration so that it is available to other blocks (through OSGi services as discussed earlier). This far everything is as before, but done using OSGi instead of using compile time mechanism. The question is how a user should be able to adapt the configuration of the components of the block while using it. Today one can modify the component configuration snippets by hand, but that is not as easy while using blocks as the configuration will be embeded in a precompiled block that is packaged as a bundle and asumed to be used as is. One possible solution is to decide before hand what should be deploy time configurable and use block attributes for this (BTW block attributes and the setting stuff that Carsten and Ralph are discussing seem to have a lot in
[Job] Cocoon (freelance) developers needed in Germnany
Hi, We are currently looking to expand our network of freelance Cocoon developers We are working on various Cocoon based projects for large German-speaking corporations in cities such as Düsseldorf, Frankfurt, Vienna and of course Paderborn :). You should be fluent in Cocoon (especially Flow and Forms) and have practical experience integrating databases (e.g. Oracle) using frameworks like Hibernate and Spring. At the moment our emphasis is on freelancers and contract work (full-time employment may also be an option). So, if you speak German and would be interested in becoming part of our team then please feel free to send me your CV or email me off-list to discuss this in more detail. Freundliche Grüße / With kind regards Matthew Langham -- SN AG Competence Center Open Source Klingenderstr. 5 D 33100 Paderborn voice +49 5251/1581-30 fax+49 5251/1581-71 eMail [EMAIL PROTECTED] Webhttp://www.s-und-n.de
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Daniel Fagerstrom wrote: At least for OSGi R3, each block (bundle) must export a unique set of packages. It would be nice if we could move all classes and interfaces so this is the case and deprecate the block classes and interface with non unique packages before we release 2.2.0 final. It is not particulary complicated but requires some work. It is necessary (if it hasn't changed in R4), that we move to block unique package names before we start to release OSGi functionality. So the sooner we can deprecate the non unique package use, the better. But it is not a blocker for 2.2. I think someone mentioned that R4 does not require the unique package names anymore. hmm, but I'm not sure. It is not necessary to split into api and implementation for introducing OSGi, but it will certainly be easier to use, and scale much better if we do it. Especially when there are several blocks implementing the same api, it will simplify things if we have separate api blocks. Then the api blocks that a block depends on can be downloaded during compilation of the block, and the user can choose between several implementaions of the used apis while deployoing the block. Yepp. Spliting the code into api and implemetation require however considerable work and thought as not everything is designed with such a split in mind. So I think that is something that we need to work on incrementally. Agreed. --- o0o --- Considering what we need to _change_ to get real blocks: The only thing I know about is some package renaming as discussed above. It will be more about _adding_ things. We will need manifest files with OSGi info in and we will need block.xml that describe dependencies on other blocks and bundles (this need to be integrated with the m2 dependecy information). The block.xml will also contain references to the blocks (sample) sitemap and component configuration(s) as we discussed last weak. This is all things that we can work on in an evolutionary way. From my current knowledge the largest remaining question is about how to configure components that a block exposes. Part of it is clear, the block.xml can refer to the .xconf(s) that is part of the block today and export the components within the configuration so that it is available to other blocks (through OSGi services as discussed earlier). This far everything is as before, but done using OSGi instead of using compile time mechanism. The question is how a user should be able to adapt the configuration of the components of the block while using it. Today one can modify the component configuration snippets by hand, but that is not as easy while using blocks as the configuration will be embeded in a precompiled block that is packaged as a bundle and asumed to be used as is. One possible solution is to decide before hand what should be deploy time configurable and use block attributes for this (BTW block attributes and the setting stuff that Carsten and Ralph are discussing seem to have a lot in common, we should see if the block attributes could be build avbove or integrated with the settings stuff). Another solution is to export the implementation of the components and configure them in the block that uses them instead (don't like this though, as it don't give any isolation). A third solution could maybe be to declare the configuration as a fragment that can be overided. Fragments is an Eclipse concept that have been made part of OSGi R4, I don't know enough about it to say if it is usefull in this context. Other ideas? I think one of the main problems is that you never know what configuration a component uses/requires. So I think we need a formal description for each configurable component, like a schema or something. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Ralph Goers wrote: How much do we know about the directory structure required by Maven? I know that OSGi R3 requires a directory structure, R4 doesn't. Don't understand the comment (from Upayavira) about directory structure, R3 and R4, care to explain? In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as o.a.c.transformation.*Generator. This would be enough for us to avoid having to rename packages. However, it would likely lead to some complex wildcard expressions, so I would propose that we ignore that functionality and use unique package names per block, as per R3. snip/ Upayavira
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? Why do you think this projet was started? :-) -- Stefano.
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Niclas Hedhman wrote: On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. The --encoding argument applies to commit messages. Paths, URLs/URIs has additional encoding requirements. Correct. And is also worth noting that SVN before 1.2 and CVS2SVN create a pretty broken combination when the commit message in CVS used an encoding that was not UTF-8. As an example, try to get svn log of the apache repository and the svn client will fail, because we have three commit messages in latin-1 placed, as binary, by cvs2svn into svn (and prior to 1.2 there was no encoding validation checking in svn) that get moved into the XML file that is passed between the svn server and client, which is using UTF-8 as the encoding. I've asked infra@ to fix this, but being not really high priority (only data archeologist like myself care about those things) it is unlikely to get fixed. Anyhow, I agree with Pier, we should *only* use ASCII and escape unicode characters explicitly the \u way. -- Stefano.
Re: Blocks in 2.2
Le 5 sept. 05, à 02:49, Pier Fumagalli a écrit : ...PS: I noticed that in the 2.1.x branch, most of the XMAPs in the block samples declare elements within the map namespace for patching, but don't declare the namespace itself. I suspect this is because ANT doesn't use a namespace-aware parser (bytes me how), but XMLLINT reports failures for a number of files (see list below). In my blocks I declare the namespace and that doesn't seem to create any problems, should we go ahead and fix the wrong ones?.. Yes, one reason is to be able to use the refdoc block to generate documentation from them, by annotating them - they must be parseable for this to work. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Status of JXTemplate refactoring
Hello, I was asked for a possible refactoring of the JXTemplateGenerator. Somebody wants to provide only a very limited set of functionality to his template writers: only JXPath (no JEXL), only one object model. He started with patching the version of JXTemplateGenerator coming with 2.1.7. Simply extending it does not work because of to much private stuff. But with the refactoring happened to the official JXTemplateGenerator this also seems not to make much sense. Now the questions: The refactoring happened only in the trunk, didn't it? How far is it pluggable, how far are the above mentioned requirements supported? Is there any obvious problem using the template block in Cocoon 2.1? Thanks for your answers. Jörg
Re: Status of JXTemplate refactoring
Joerg Heinicke wrote:
Hello,
I was asked for a possible refactoring of the JXTemplateGenerator.
Somebody wants to provide only a very limited set of functionality to
his template writers: only JXPath (no JEXL), only one object model.
He started with patching the version of JXTemplateGenerator coming with
2.1.7. Simply extending it does not work because of to much private
stuff. But with the refactoring happened to the official
JXTemplateGenerator this also seems not to make much sense.
Redoing the refactoring work that Leszek and I already have done seem
like wasting time.
Now the questions: The refactoring happened only in the trunk, didn't
it?
It only happened in trunk, keeping a synchronized copy in the 2.1.x
branch while refactoring didn't seem that fun. It would probably easy to
port it to 2.1.x if anyone feel like doing it.
How far is it pluggable,
Concerning instructions sets it is completely pluggable, take a look at
the configuration and o.a.c.template.script.InstructionFactory and
DefaultInstructionFactory.
how far are the above mentioned requirements supported?
Much of it is supported, but there is some refactoring work left to do.
Expressions are pluggable, see o.a.c.components.expression.**. There is
only one common object model for all Expression implementations:
ExpressionContext and the standard object model is created by
o.a.c.template.environment.FlowObjectModelHelper and pluged in in the
JXTemplateGenerator class.
But the actual expression parsing used in the template framework is not
plugable yet. Take a look at the class o.a.c.template.script.Parser, it
calls o.a.c.template.expression.JXTExpression for expression parsing.
JTExpression recognice the ${} and #{} syntax and create the right kind
of expression.
To make the expressions completely plugable within the template
framework, we need a expression parser interface and we need to make the
expression parser implementation plugable in the Parser.
Is there any obvious problem using the template
block in Cocoon 2.1?
No.
--- o0o ---
Further links about the template block design and discussions can be
found at http://wiki.apache.org/cocoon/Templates. There was also an
agreement that JXTG should be renamed to CTemplate and get a new name
space. We had some discussion about what CTemplate should contain:
http://marc.theaimsgroup.com/?t=11094230054r=1w=2. Among other
things it was supposed to have more plugable expressions.
/Daniel
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
On 5 Sep 2005, at 17:25, Stefano Mazzocchi wrote: David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? Why do you think this projet was started? :-) Darn, I can see in that 9 years my communication skills have hardly improved! Pier smime.p7s Description: S/MIME cryptographic signature
Fixing block XCONF files (Was: Re: Blocks in 2.2)
On 5 Sep 2005, at 17:41, Bertrand Delacretaz wrote: Le 5 sept. 05, à 02:49, Pier Fumagalli a écrit : ...PS: I noticed that in the 2.1.x branch, most of the XMAPs in the block samples declare elements within the map namespace for patching, but don't declare the namespace itself. I suspect this is because ANT doesn't use a namespace-aware parser (bytes me how), but XMLLINT reports failures for a number of files (see list below). In my blocks I declare the namespace and that doesn't seem to create any problems, should we go ahead and fix the wrong ones?.. Yes, one reason is to be able to use the refdoc block to generate documentation from them, by annotating them - they must be parseable for this to work. Kewl, that's now done, there's only one thing puzzling me. These are the errors I get from XML files in the blocks/conf: ojb/conf/repository_database.xml:74: parser error : Extra content at the end of the document jdbc-connection-descriptor jcd-alias=personnel default- connection=true ^ ojb/conf/repository_internal.xml:62: parser error : Extra content at the end of the document class-descriptor ^ ojb/conf/repository_user.xml:28: parser error : Extra content at the end of the document class-descriptor class=org.apache.cocoon.ojb.samples.bean.Employee table= ^ Those, though, are beyond my understanding in fixing... Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Pier Fumagalli wrote: Stefano Mazzocchi wrote: David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? Why do you think this projet was started? :-) ;-) Darn, I can see in that 9 years my communication skills have hardly improved! Argh, i did not specify the need properly. Pier communicates brilliantly. The reason for pier2doc is to automate the documentation of that. -David
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
On Monday 05 September 2005 23:52, Upayavira wrote: In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as o.a.c.transformation.*Generator. This would be enough for us to avoid having to rename packages. However, it would likely lead to some complex wildcard expressions, so I would propose that we ignore that functionality and use unique package names per block, as per R3. There is also the concern of sealed Jars of the JVM that should be taken into consideration. IMHO, separation is a GoodThing and should be carried out instead of hanging on to bad habits. Cheers Niclas
Re: SQLTransformer
Leszek Gawron wrote: Antonio Gallardo wrote: I will suggest OJB instead - http://db.apache.org/ojb/. On the contrary I strongly recommend Hibernate :) I was working on a hibernate the last weeks and I need to say that I prefer OJB. Here 2 samples: 1-When using a java List for a collection inside a bean, in Hibernate the table need an additional field to manage the order of the table rows! What is that? That is the persistent order of your collection. A list needs to know what is the sequence of it's child beans. How do you do it in OJB? Using orderby attribute - http://db.apache.org/ojb/docu/guides/repository.html#collection-descriptor There is no need of an extra field. 2-I don't want in my database more fields than what I need, so let replace the Java List witth a Java Set -- then I meet a new problem: cforms binding use jxpath and jxpath don't work with Sets. jxpath throws an Unsupported Operation Exception! Boom! strange: fb:context xmlns:fb=http://apache.org/cocoon/forms/1.0#binding; xmlns:fd=http://apache.org/cocoon/forms/1.0#definition; xmlns:ci=http://apache.org/cocoon/include/1.0; path=/ fb:repeater id=questionDefinitions parent-path=. row-path=questionDefinitions direction=load fb:identity fb:value id=id path=id/ /fb:identity fb:on-bind fb:value id=questionName path=name/ fb:value id=questionCategory path=category/name/ /fb:on-bind /fb:repeater /fb:context In this case I have bound SurveyDefinition.questionDefinitions collection and it works. In my case, I met the Unsupported Operation Exception in jxpath using @direction=save not while loading a not with a repeater, but using a cform multivalue field. I wonder how people using hibernate deal with this situations. The 1st shows me a poor database desing and the second a restriction to use cforms at all! I still do not get why this is a poor database design. In hibernate you can use: 1. unordered set 2. a treeset ordered with Comparable contract 3. a List which has a persistent order of your choice. Only the third choice for obvious reasons needs an indexing column. What is the obvious reason? IMO, an additional index field shows a poor database design. Best Regards, Antonio Gallardo.
[RT] Replace excalibur-io with commons-io
Hi: Recently on excalibur dev I found that most (if not all) the code in excalibur-io was moved to commons-io: http://www.mail-archive.com/dev%40excalibur.apache.org/msg01599.html Cocoon 2.1.x has only 3 references to exclaibur-io. They can be easily switched to commons-io. Some other goodies: 1-Some of the methods in o.a.c.utils can be switched to commons-io 2-Lenya distribute commons-io as an additional jar. WDYT? Best Regards, Antonio Gallardo.
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: So, let us stop the branching madness and work towards having only *one* common branch (the trunk), that we do the releases from. +1 Best Regards, Antonio Gallardo
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Currently, all the code that needs access to that file goes through a single component. That component uses a system property to specify where the file is. But in this case, you can dream up pretty much anything that works. I'm presuming that putting them in cocoon.xconf is out since that is what is being modified. Yes. I hate putting them in web.xml but is OK if that is the only way. Another way that works for me is for your factory to have methods that I can invoke from Spring's lifecycle config. My logging implementation causes Spring to initialize when logging is set up. Propose something else if you hate all of these. Hmm, you can put your own properties file into WEB-INF/properties directory. All these properties are available using the Settings object. You can inject the Cocoon core object into one of your Spring components, access the settings object from there and get your properties. Isn't it this, what you need? (If yes, it works today :) ) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Hmm, you can put your own properties file into WEB-INF/properties directory. All these properties are available using the Settings object. You can inject the Cocoon core object into one of your Spring components, access the settings object from there and get your properties. Isn't it this, what you need? (If yes, it works today :) ) I don't think so. I really don't want to have two files with system properties in them. As I said, we have an XML file that contains iniital logging configuration along with system properties. We use this same file (well, the contents might be different) in different applications, many of which are not Cocoon based. So I really don't want to tell folks that in application A, B and C you add logging definitions and properties to the XML file but in applications D and E you put only the logging defintions in the XML file and properties go in a property file. Ralph
Re: Fixing block XCONF files (Was: Re: Blocks in 2.2)
Le 5 sept. 05, à 23:30, Pier Fumagalli a écrit : ...These are the errors I get from XML files in the blocks/conf: ojb/conf/repository_database.xml:74: parser error : Extra content at the end of the document jdbc-connection-descriptor jcd-alias=personnel default-connection=true ...Those, though, are beyond my understanding in fixing... Hmm..OJB uses entities to include XML document fragments into its config, so I don't know if there's an easy fix. -Bertrand smime.p7s Description: S/MIME cryptographic signature
