Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
Please cast your votes:
+1, welcome Jörg!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: Hi folks, Jorg Heymans has been around for more than 2 years now, and has contributed with comments on the dev, help on the user list and several patches along the way, [grep -i heymans status.xml] will tell you more), all of good quality. So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) +1 Upayavira
DO NOT REPLY [Bug 35813] - NullPointerException using CLI caused by new env creation
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=35813. 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=35813 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 09:55 --- The changes on the update script works in unix as well. I am not getting a NPE anymore. But i am getting this: Exception in thread main org.apache.avalon.framework.service.ServiceException: Could not access the component for role [org.apache.cocoon.Processor] (Key='org.apache.cocoon.Processor') . Caused by: org.apache.avalon.framework.context.ContextException: Unable to resolve context key: context-root The update script only replace libraries, it does not touch config files. Maybe I am wrong, but I have the feeling that maybe is it an issue within main/java/org/apache/forrest/log/ForrestLogTargetFactory.java WDYT? -- 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: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: Hi folks, Jorg Heymans has been around for more than 2 years now, and has contributed with comments on the dev, help on the user list and several patches along the way, [grep -i heymans status.xml] will tell you more), all of good quality. So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) A warm +1! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Jorg Heymans as new committer
Please cast your votes: +1 -- Torsten PGP.sig Description: This is a digitally signed message part
Re: RefDoc - Neutral XML Document Format Input/Current State
Hi Robert,
Thanks for your analysis - I hope others are going to answer as well,
but here are at least my comments:
I've created several types and other proposed 'well-defined' bits
of
metadata to assist the publishing of these documents into a nice
format and easing the pain of parsing out such information. The types
are:
*method* - this type is for documenting methods or functions
*package* - this type indicates that the comment contains only the
package string for the file and perhaps the leading 'package'
declaration in java or a trailing semicolon
*class-declaration* - this type contains only the class declaration
(and maybe the trailing '{')
*codeblock* - this type is for indicating that the comment contains
code for publishing purposes
ok - my view was a more high-level one than classes and methods, which
are adequately covered by the javadocs. These are certainly useful
though, but see the proposed use-cases below for a more
component-oriented view.
*name* - this type indicates the 'name' of the document of thing being
documented under
the current key (or specified key for this name
*warning* - this type expresses warnings
*example* - this type is used to indicate that the comment contains an
example
*details* - this type must include another piece of metadata
indicating what it is detailing more on this in a minute
ok
*variable* - this type is used to document a variable or parameter
ok, we'll need to be more detailed here I think, differentiating
sitemap parameters, component configuration parameters, etc.
*description* - this type is used to describe what the purpose of the
current thing being documented is as per the current/specified key
ok
*see-also* - this type specifies that it contains a listing of doktor
keys that you might also want to look at/search for
ok, this is a very important one.
A few new pieces of metadata:
...
*filetype* - this is usually supplied with the key for the document
and indicates what kind of document it is which may be used in a
publishing context...
ok, this will be needed for example to republish XML snippets as XML I
assume.
Issue #1:
The need to associate a codeblock with an example comes from
publishing interests. If I have an example with a block of text
explaining things and then a demostration in code then without
separating them but keeping them associated publishing it correctly
becomes a nightmare. I'm afraid though that this may introduce too
much complexity to deal with...
The sorting of snippets to build the final document will be a problem
as soon as there are more than a few snippets. Maybe introducing an
order number metadata attribute would help and not be too hard to
manage? We could then rearrange the snippets be changing their order
numbers, while keeping the overall order based on the snippet types.
Issue #2:
Of course simple having to index so many different metadata keys might
be annoying and they should perhaps all be changed to one 'id' or
'name' field. I feel this should be done.
I'm not sure what you mean here, can you elaborate or give an example?
...Issue #3:
I figured that the layout of the neutral XML would be similar to how a
javadoc document is arranged with the name and packge followed by a
description and then examples/methods/variables followed finally by
details and perhaps codeblocks. This may be too similar to javadoc,
however and I'd like input on formatting decisions...
Starting from a javadoc model is certainly good.
...Finally, any further comments, ideas, or discussion is welcomed...
I'm just going to add a few brief use-cases, or rather a few example
questions that I'd like refdoc-generated documentation to answer:
a) What is the FileGenerator?
scenario: search the refdoc for FileGenerator or navigate the refdoc:
refdoc/components/FileGenerator
b) Which generator can read URLs through a proxy?
scenario: full-text search for a refdoc document from the components
collection, containing both the URL and proxy words.
c) What sitemap parameters can be used for the FileGenerator?
scenario: find the document as in a), the document contains a list of
parameters build from sitemap-parameter metadata elements found in
doktor comments. The parameter descriptions stay up to date as the
@doktor comments are right next to the source code which reads the
parameter, so people remember to keep them up to date.
d) I need an example of how to use the HtmlTransformer in a sitemap
scenario: search the refdoc for a snippet ot type sitemap-example
where property component-name is HtmlGenerator. The snippet points to
its parent document which describes the HtmlGenerator.
It might be good to elaborate on these use-cases and maybe document
them in a text file in the refdoc block, but for now I hope they help
clarifiy the needs and priorities.
Note that these assume a dynamic search of the refdoc index - I think
the full power of the refdoc will
Re: [CForms] Creating an intermediate object in binding
Il giorno 31/lug/05, alle 14:01, Leszek Gawron ha scritto: I have defined a custom type and convertor for that. The convertor is actually managed by Spring and populated with a DAO and the convertor's factory returns the Spring-managed instance instead of creating a new one. The convertor itself is spring manager or just the dao it holds? Both. Do I get it right that you need to implement a separate: - dao - convertor - convertor builder for every domain object in your model? Not really. I do it only for those types that are reused across many forms and therefore warrant defining a datatype and convertor. At the moment, we have developed datatypes for a bunch of geographical objects like Town, Province, Country, that are used in all the forms where you have to input an address. And we have a single GeoDAO class for all entities of this kind. In general, I would do this for every datatype that is implemented as a look-up-table (key = value) in the database and is reused in more than a couple of forms, or across more than one different project. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
When do we ask people for a CLA?
(CCing Jeremias Maerki of FOP as I have discussed this with him recently) This is mostly a question for the PMC, but I see no need to discuss it in private so here we go: Other ASF projects have started to request CLAs [1] much earlier when people contribute to their projects. The reason, IIUC, is to really make sure that contributors understand what they're doing in terms of licensing, copyright etc. We have accepted several sizeable contributions without requiring a CLA in the past, now the question is, do we want to follow the flow and ask for CLAs for all contributions? A rule that seems to emerge (still unofficial AFAIK) is that as soon as the contribution contains at least one entirely new object (class, module, block?) a CLA is required. On the plus side: the CLA clearly defines the terms under which intellectual property has been contributed to the ASF, quoting from http://apache.org/licenses/#clas The minus side: asking for a CLA even for small things (what's small?) might cause people to refrain from contributing, as this would mean some (easy) paperwork. WDYT? [1] http://apache.org/dev/new-committers-guide.html talks about CLAs smime.p7s Description: S/MIME cryptographic signature
Re: When do we ask people for a CLA?
On Monday 01 August 2005 17:32, Bertrand Delacretaz wrote: On the plus side: the CLA clearly defines the terms under which intellectual property has been contributed to the ASF, quoting from http://apache.org/licenses/#clas The minus side: asking for a CLA even for small things (what's small?) might cause people to refrain from contributing, as this would mean some (easy) paperwork. Another BIG part of the minus side is that for USA contributors, the situation seems to be even worse, as the employer owns all output of the employee (if they have any business claims in software, which nowadays are most sizeable companies), no matter when/how that was produced. legal-discuss@ has have had that up a few months ago, and it seems that for USA contributors the employer need to provide ASF with an agreement (CCLA or otherwise) that relinguish the employer's right over the material. Go figure! :o( Or better, everyone move to Europe. :o) Or better yet, move to Asia... :oD Cheers Niclas
Re: When do we ask people for a CLA?
On Mon, 1 Aug 2005, Bertrand Delacretaz wrote: Other ASF projects have started to request CLAs [1] much earlier when people contribute to their projects. The reason, IIUC, is to really make sure that contributors understand what they're doing in terms of licensing, copyright etc. And this educational aspect should not be ignored. in the past, now the question is, do we want to follow the flow and ask for CLAs for all contributions? A rule that seems to emerge (still Note that version 2 of the license gives us a bit more room than previously. In particularly it makes very clear that 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. Where a contribution is defined as Contribution shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as Not a Contribution. So someone clearly patching 'into' a piece of code under the 2.0 license is making a contribiution. The 'into' signalling that the person making the contribution was fully aware of the 2.0 license and had gotten the very thing he or she was working on under that agreement However things are not black and white; when it is the case that: unofficial AFAIK) is that as soon as the contribution contains at least one entirely new object (class, module, block?) one could argue that there is/was no direct releation to the existing code and one could argue that the submitter diid not enter in that agreement*. So then we propably want to agree that a: a CLA is required. And when in doubt - asking for one never hurts. If you cannot get it - it is a clear signal to investigate. And/or discuss with your PMC and if needed the board, what risk you are willing to take when accepting such. Dw *: As the most extreme case; consider a company or a person donating some greenfield code which was developed totally outside the ASF. And yes - then we'd want the incubator process to go through it.
Re: When do we ask people for a CLA?
On Mon, 1 Aug 2005, Niclas Hedhman wrote: situation seems to be even worse, as the employer owns all output of the employee (if they have any business claims in software, which nowadays are Note that in this case the definition of a contribution and clause 5 help you here. If your company started using apache and lets you work on ASF code - then it quite propably has agreed to the 2.0 license terms. But yes - you do want to discuss this with your manager and companies legal dept. And for this very reason a CLA or a corperate CLA has been developed as an effective instrument to frame that discussion. Dw.
Re: RefDoc - Neutral XML Document Format Input/Current State
Bertrand Delacretaz wrote: Thanks for your analysis - I hope others are going to answer as well, I've forwarded Roberts original message to the Forrest list since we will, no doubt, be using the output of this project. I've asked Forrest devs to reply on our own list, but I will provide a summary here in a few days. *see-also* - this type specifies that it contains a listing of doktor keys that you might also want to look at/search for ok, this is a very important one. Can this also have links to documentation other than RefDoc generated docs? In fact, could this go a step further, with narrative documentation, such as How-To's pulling examples directly from the doktor tags and refdoc automtically creating the XRef in the see-also section (this is probably out of scope for the first implementation, but may be owrth considering in the overall design). Ross
[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, and has been outstanding for 4 runs. 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-faces : 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-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-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... - lenya : Content Management System 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-01082005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-01082005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-01082005/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-01082005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-01082005.jar -Dbuild=build/cocoon-01082005 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, and has been outstanding for 4 runs. 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-faces : 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-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-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... - lenya : Content Management System 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-01082005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-01082005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-01082005/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-01082005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-01082005.jar -Dbuild=build/cocoon-01082005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: RefDoc - Neutral XML Document Format Input/Current State
ok - my view was a more high-level one than classes and methods, which are adequately covered by the javadocs. These are certainly useful though, but see the proposed use-cases below for a more component-oriented view. Okay, this was something I wasn't sure about, but I thought it might be the case. Issue #1: The need to associate a codeblock with an example comes from publishing interests. If I have an example with a block of text explaining things and then a demostration in code then without separating them but keeping them associated publishing it correctly becomes a nightmare. I'm afraid though that this may introduce too much complexity to deal with... The sorting of snippets to build the final document will be a problem as soon as there are more than a few snippets. Maybe introducing an order number metadata attribute would help and not be too hard to manage? We could then rearrange the snippets be changing their order numbers, while keeping the overall order based on the snippet types. Perhaps. I think some sort of weight might give the publisher options while also introducing more complexity to the process. Issue #2: Of course simple having to index so many different metadata keys might be annoying and they should perhaps all be changed to one 'id' or 'name' field. I feel this should be done. I'm not sure what you mean here, can you elaborate or give an example? I meant instead of what I proposed up there: @doktor-start type:method, method:methodName @doktor-start type:codeblock, codeblock:blockName we have something like: @doktor-start type:codeblock, name:blockName @doktor-start type:method, name:methodName a) What is the FileGenerator? scenario: search the refdoc for FileGenerator or navigate the refdoc: refdoc/components/FileGenerator b) Which generator can read URLs through a proxy? scenario: full-text search for a refdoc document from the components collection, containing both the URL and proxy words. c) What sitemap parameters can be used for the FileGenerator? scenario: find the document as in a), the document contains a list of parameters build from sitemap-parameter metadata elements found in doktor comments. The parameter descriptions stay up to date as the @doktor comments are right next to the source code which reads the parameter, so people remember to keep them up to date. d) I need an example of how to use the HtmlTransformer in a sitemap scenario: search the refdoc for a snippet ot type sitemap-example where property component-name is HtmlGenerator. The snippet points to its parent document which describes the HtmlGenerator. It might be good to elaborate on these use-cases and maybe document them in a text file in the refdoc block, but for now I hope they help clarifiy the needs and priorities. I think that these make more sense and give me a good place to start thinking from, but I'm not sure that with my limited experience with Cocoon I could develop a comprehensive listing. Elaboration of more cases would be helpful. Note that these assume a dynamic search of the refdoc index - I think the full power of the refdoc will be available only when querying the Lucene index directly, as is done in some of these use-cases, but the document-oriented version (that will probably be published as static HTML pages) will contain the same information, only with less precise searches. The Lucene index will be available to people who start Cocoon on their own machines anyway, so I think having to use the Lucene index for precise queries is not a big problem. I always have believed that a dynamic use was if not the end goal for this project it was at least the target for RefDoc in the future. We still have a month to complete whatever it is you'd like and perhaps I could better achieve it if I knew what you had in mind? Although, I'd like to finish even if it isn't before September. Robert
Cocoon stack traces
Hi all, I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. For example, we can track nested JXTG macro calls, flowscript function calls, pipeline locations, mounted sitemaps, etc. More locations will be added in the future. This refactoring is based on a few new features: Location management --- The new org.apache.cocoon.util.location package defines the Location class (a URI, line and column numbers) and a Locatable interface for objects that have a Location. The LocatorAsAttributesPipe is a SAX filter that registers parser location information as attributes on elements. This used by CForms to parse form definitions and bindings, thus removing the dependency on some Xerces internal APIs. The LocatedException and LocatedRuntimeException classes are exceptions that implement Locatable and therefore hold a Location. ProcessingException now extends LocatedException so that we're able to attach a location to a processing error. The class org.apache.cocoon.util.ExceptionUtils allows to get the location of LocatedException and some other well-known exception classes that hold a location (e.g. SAXParseException). Exception management A Cocoon stacktrace is defined by all exceptions in an exception chain that have a location. To add a particular statement to a Cocoon stacktrace, it is therefore necessary to provide this location information. This requires that we identify those places that we want to see in stacktraces, and make sure to catch exceptions and rethrow them wrapped in a LocatedException. I did this already for a few strategic places: flowscript calls, serialize statemements (that trigger execution of a pipeline) and mounts. The JTXG was already doing this wrapping using SAXParseException in macro calls. Exception display and log - The NotifyingGenerator and the associated stuff is... ahem... very complicated for something simple, and modifying it to handle a set of locations rather than a single one didn't seem obvious. I therefore wrote a new ExceptionGenerator that directly dumps as XML the Throwable catched by map:handle-errors, including all the needed location and stacktrace information. You can see it in action when an error occurs: a new Cocoon stacktrace section is now displayed along with the not-so-friendly Java stacktraces. And since these error pages should not be used in production, I also made sure that a LocatedException correctly prints the location in printStackTrace() so that we have the same information in the log files. Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
[EMAIL PROTECTED] wrote: Author: ugo Date: Sat Jul 30 04:01:10 2005 New Revision: 226493 URL: http://svn.apache.org/viewcvs?rev=226493view=rev Log: Don't output div if there are no errors and give it a class attribute Ugo, Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: RefDoc - Neutral XML Document Format Input/Current State
Robert Graham wrote: Note that these assume a dynamic search of the refdoc index - I think the full power of the refdoc will be available only when querying the Lucene index directly, as is done in some of these use-cases, but the document-oriented version (that will probably be published as static HTML pages) will contain the same information, only with less precise searches. The Lucene index will be available to people who start Cocoon on their own machines anyway, so I think having to use the Lucene index for precise queries is not a big problem. I always have believed that a dynamic use was if not the end goal for this project it was at least the target for RefDoc in the future. We still have a month to complete whatever it is you'd like and perhaps I could better achieve it if I knew what you had in mind? Although, I'd like to finish even if it isn't before September. The dynamic searching capability can be got for free by integrating your work into Forrest (a cocoon based publishing framework that is used by Cocoon and many other projects to publish their websites [1]). We (the Forrest devs) are watching with interest. If you can make it work in a static environment then it is a simple step to create a plugin in Forrest which already includes Lucene for searching. Of course, Bertrand may have something else in mind as well. Ross [1] http://forrest.apache.org
Re: RefDoc - Neutral XML Document Format Input/Current State
Le 1 août 05, à 15:29, Ross Gardler a écrit : ...The dynamic searching capability can be got for free by integrating your work into Forrest ... ...Of course, Bertrand may have something else in mind as well. I was thinking about searching on any metadata field provided by refodc snippets. But it's not terribly important at this stage. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto: Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Also, if this is the case, the div element should be output regardless of whether there are validation errors or not, right? Not that putting it back is a problem, I am just trying to understand. The only real issue I had was with the div not having a class attribute, but while I was at it, I tried to optimize away a useless element and an empty attribute. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: RefDoc - Neutral XML Document Format Input/Current State
Hi Robert, ...Maybe introducing an order number metadata attribute would help and not be too hard to manage? We could then rearrange the snippets be changing their order numbers, while keeping the overall order based on the snippet types. Perhaps. I think some sort of weight might give the publisher options while also introducing more complexity to the process... Weight sounds good as a concept for this, and if sensible defaults are used to order snippets when no weights are set, the normal case will be easy to handle. Issue #2: Of course simple having to index so many different metadata keys might be annoying and they should perhaps all be changed to one 'id' or 'name' field. I feel this should be done. I'm not sure what you mean here, can you elaborate or give an example? I meant instead of what I proposed up there: @doktor-start type:method, method:methodName @doktor-start type:codeblock, codeblock:blockName we have something like: @doktor-start type:codeblock, name:blockName @doktor-start type:method, name:methodName Ok, then I agree with you that the second way is better. a) What is the FileGenerator? ... b) Which generator can read URLs through a proxy? ... c) What sitemap parameters can be used for the FileGenerator? ... d) I need an example of how to use the HtmlTransformer .. ... I think that these make more sense and give me a good place to start thinking from, but I'm not sure that with my limited experience with Cocoon I could develop a comprehensive listing. Elaboration of more cases would be helpful. Ok - I think these are a good start, if I think of more I'll post them here! ...I always have believed that a dynamic use was if not the end goal for this project it was at least the target for RefDoc in the future... You're right, static documents (which will themselves be searchable) is the main goal. The Lucene index will be here anyway when we want to go further. .. We still have a month to complete whatever it is you'd like and perhaps I could better achieve it if I knew what you had in mind? Although, I'd like to finish even if it isn't before September... The initial spec stays as the main goal, I agree that you should stay focused on the document generation. Fancier searches will come later. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto: Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? Also, if this is the case, the div element should be output regardless of whether there are validation errors or not, right? Yes. Have a look at the template for fi:placeholder, which is what is produced by hidden fields in order to mark their place in the page if an event-listener changes their state. Not that putting it back is a problem, I am just trying to understand. The only real issue I had was with the div not having a class attribute, but while I was at it, I tried to optimize away a useless element and an empty attribute. I understand. But actually, they _are_ useful (in the general cases, as I don't know where validation-errors come from). Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto: If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? I'm not sure where I lost you ;-). Weren't we talking about the template in forms-field-styling.xsl that I modified: xsl:template match=fi:validation-errors ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Otherwise, it's me who's lost. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto: If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? I'm not sure where I lost you ;-). Weren't we talking about the template in forms-field-styling.xsl that I modified: xsl:template match=fi:validation-errors ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. Or maybe I need new glasses... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 16:38, Sylvain Wallez ha scritto: Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. It's not produced. You have to put it yourself in your form template, if you want to display all your validation errors in a single block. At least according to http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors. And it works as expected, too, in the ajax=false case. Now, what you're telling me is that for it to be correctly show up in the ajax=true case, the resulting HTML element must have an id attribute. Then, since the original template did something like: xsl:template match=fi_validation-errors div id=[EMAIL PROTECTED] ... you need to put something like fi:validation-errors id=whatever/ in the form template. Is that right? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) +1 here.. welcome!! Tony
Re: Cocoon stack traces
Sylvain Wallez wrote: big-snip/ Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! Wow. This is neat. For the curious, fire this up and go to: http://localhost:/samples/errorhandling/ Below is what I saw when I went there. Now isn't this better than extremely long java stack traces? Thanks Sylvain! Regards, Upayavira An error has occured org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. context://samples/errorhandling/sitemap.xmap - 18:2 Cocoon stacktrace[hide] The markup in the document preceding the root element must be well-formed. context://samples/errorhandling/sitemap.xmap - 18:2 Sitemap: error when calling sub-sitemap context://samples/sitemap.xmap - 183:65 Sitemap: error when calling sub-sitemap context://sitemap.xmap - 852:66 Java stacktrace[show] Java full stacktrace[show] The Apache Cocoon Project
Re: Cocoon stack traces
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto: I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. I think it's time to take that hero plate out of the closet and polish it again ;-) Ugo attachment: hero.jpg -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[Portal] Skinning questions
Hello devs, I had a quick look on the Cocoon Portal. I have a question about http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create +a+new+skin+for+your+portal The current layout is table based which I need to change. I was looking in the style producing matches and stylesheet. http://cocoon.apache.org/2.1/developing/portal/portal-block.html#The +skin%27s+stylesheets I just could find some transformation in the sitemap.xmap that were refering to http://cocoon.apache.org/2.1/developing/portal/portal-block.html#The +portal-page.xsl How are the other xsl-stylesheets processed like e.g. tab.xsl. I saw that it is defined in the protal.samplesxconf which refers to the AbractRenderer.java. Can you point me where in the pipeline it got matched and how the processing is working. To be honest I did not really understand http://cocoon.apache.org/2.1/developing/portal/portal-block.html#The +Rendering+Process Another question is the portal view. http://cocoon.apache.org/2.1/developing/portal/profiles.html#The+Portal +View Does that mean we can have a) user based portal b) role based portal c) global based portal views? Would it be possible to extend this? a) user based portal b) role based portal c) request based portal d) directory (relative to the request) based portal e) doctype based portal f) global based portal views? Last but not least, is it possible to have coplet specific rendering (better coplet specific layout)? How can this be done? My background is the recent prototype of the forrest new skinning concept which has the codename forrest:views. I would like to try to incooperate this into the portal. WDYT? TIA for any hints. salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: Hi folks, Jorg Heymans has been around for more than 2 years now, and has contributed with comments on the dev, help on the user list and several patches along the way, [grep -i heymans status.xml] will tell you more), all of good quality. So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) Wow... this community keeps amazing me ! I feel extremely honoured to be given this chance and would be happy to accept committer responsibility should the vote be successful. I promise i will do everything I can to act as a worthy committer :-) Cheers, Jorg
Re: Cocoon stack traces
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto: I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. I think it's time to take that hero plate out of the closet and polish it again ;-) ROTFL !!! I'm currently working on the next Big Thing in error handling: getting real exceptions out of Xalan instead of a stupid RuntimeException. Maybe I should wait a bit to have my plate polished again later :-P Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
TraxTransformer now reports the real exception!
Hi all, Another important achievement in better error handlinn! When an exception occurs in a pipeline after a TraxTransformer (i.e. xslt), it now reports the *real* exception that was raised rather than a useless RuntimeException (see [1] and search for 'new RuntimeException'). Also, the reported exception shows *where* the error occured, i.e. in which XSL stylesheet it happened. Enjoy! Sylvain [1] http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/transformer/TransformerImpl.java?rev=1.167view=markup -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: TraxTransformer now reports the real exception!
Sylvain, you're the best. Working with portal block we were *always* behind TraxTransformer, which was hiding all exceptions. Now, we can manage to work more efficiently. A big thank you! -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: Cocoon stack traces
Sylvain Wallez wrote: Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! big +1! -- Stefano.
Re: [VOTE] Jorg Heymans as new committer
Tony Collen wrote: Antonio Gallardo wrote: So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) +1 here.. welcome!! +1 -- Stefano.
Re: TraxTransformer now reports the real exception!
Jean-Baptiste Quenot wrote: Sylvain, you're the best. Working with portal block we were *always* behind TraxTransformer, which was hiding all exceptions. Now, we can manage to work more efficiently. A big thank you! Ditto from the Forrest community. Ross
Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: So, I'm pleased to propose Jorg Heymans, as a committer. +1 Vadim
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
On Mon, 2005-08-01 at 16:38 +0200, Sylvain Wallez wrote: ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. You are correct, it is not produced by anything besides the template author. It's simply a styling hint, much like fi:group, which is handled entirely by the XSLT. Unfortunately this means that it is never included in the AJAX browser- update XML since there's nothing to ensure it's wrapped in a bu:update element. (Hmm, would manually wrapping it in a bu:update in the template do the trick? I wonder. It would definitely need an id attribute though.) I think there's a definite usefulness in having it AJAX-enabled, so perhaps it needs to be handled further upstream, e.g. in FormsTemplateTransformer. Should it become an ft-namespaced element instead like ft:validation-errors id=someId /? Thoughts? I'm willing to take a whack at putting together a patch, with guidance. --Jason
Re: [VOTE] Jorg Heymans as new committer
On 7/31/05, Antonio Gallardo [EMAIL PROTECTED] wrote: So, I'm pleased to propose Jorg Heymans, as a committer. +1, and welcome aboard! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: When do we ask people for a CLA?
On 01.08.2005 11:32, Bertrand Delacretaz wrote: We have accepted several sizeable contributions without requiring a CLA in the past, now the question is, do we want to follow the flow and ask for CLAs for all contributions? From my non-legal, but practical view: What are the ways we receive contributions? Isn't it nearly just Bugzilla? Whenever somebody contributed a patch over the lists we pointed him to Bugzilla - for practical reasons: the patch should not get lost. Let's just add a legal reason: We only accept patches over Bugzilla in general where the Apache 2.0 must be accepted explicitely. I like this much more than the paper work. Is it possible to customize Bugzilla for Apache in that way? Joerg
Re: When do we ask people for a CLA?
Joerg Heinicke wrote: On 01.08.2005 11:32, Bertrand Delacretaz wrote: We have accepted several sizeable contributions without requiring a CLA in the past, now the question is, do we want to follow the flow and ask for CLAs for all contributions? From my non-legal, but practical view: What are the ways we receive contributions? Isn't it nearly just Bugzilla? Whenever somebody contributed a patch over the lists we pointed him to Bugzilla - for practical reasons: the patch should not get lost. Let's just add a legal reason: We only accept patches over Bugzilla in general where the Apache 2.0 must be accepted explicitely. I like this much more than the paper work. Is it possible to customize Bugzilla for Apache in that way? That has been suggested recently. Jira already does it. The SpamAssassin bugzilla (a different installation) does it. Regards, Upayavira
[cforms] fi:validation-errors in AJAX mode (was: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl)
On Mon, 2005-08-01 at 13:19 -0600, Jason Johnston wrote: You are correct, it is not produced by anything besides the template author. It's simply a styling hint, much like fi:group, which is handled entirely by the XSLT. Unfortunately this means that it is never included in the AJAX browser- update XML since there's nothing to ensure it's wrapped in a bu:update element. (Hmm, would manually wrapping it in a bu:update in the template do the trick? I wonder. It would definitely need an id attribute though.) I think there's a definite usefulness in having it AJAX-enabled, so perhaps it needs to be handled further upstream, e.g. in FormsTemplateTransformer. Should it become an ft-namespaced element instead like ft:validation-errors id=someId /? Thoughts? I'm willing to take a whack at putting together a patch, with guidance. Some more thoughts on a possible approach: We create a new template element, ft:validation-errors /. When this element is encountered by FormsTemplateTransformer (or the jx macros), the widget tree is walked and each widget is checked for a validation error. If one is present it is added to the transformer output, for example: fi:validation-errors id=forms-validation-errors-0 fi:validation-error widget-id=streetValidation error for street widget/fi:validation-error fi:validation-error widget-id=companyInfo.companyNameValidation error for company name widget/fi:validation-error !-- etc. for each validation error in the form -- /fi:validation-errors The @id in that output is autogenerated, and the number on the end is an index so that we can allow the template element to appear multiple times in the document and avoid duplicate ids (if necessary, just a thought.) In terms of XSLT styling, if there are no errors present then it would be presented like fi:placeholder (create an element with the matching @id so the AJAX code knows where to insert its replacement). If there are errors present then it would be presented much like the current fi:validation-errors. Things to figure out/think about: * How, if at all, would be retain compatibility with the old fi:validation-errors styling element? One approach might be to check for the presence of the @id attribute in the XSLT and if it isn't there use the old xsl:template. * Since this approach builds the list of validation errors from the widget tree rather than the template, the order of the errors may not be the same as the order the fields appear on the page. Would there be a way to control this ordering in the template transformer so the ordering would match? * A possible enhancement might be to make ft:validation-errors sensitive to the widget context in which it is invoked, for instance an ft:validation-errors within an ft:group would only aggregate the validation errors for widgets within that fd:group. We might want a way to override this though, and/or add an attribute (@context-path or something) to allow authors to specify the context widget. Thoughts? --Jason
Re: [VOTE] Jorg Heymans as new committer
Antonio Gallardo wrote: Hi folks, Jorg Heymans has been around for more than 2 years now, and has contributed with comments on the dev, help on the user list and several patches along the way, [grep -i heymans status.xml] will tell you more), all of good quality. So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) Best Regards, Antonio Gallardo Sorry, I was away for the weekend. +1 ! .
Re: svn commit: r226838 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/transformation/TraxTransformer.java status.xml
Will you commit to trunk as well?
salu2
On Mon, 2005-08-01 at 16:52 +, [EMAIL PROTECTED] wrote:
Author: sylvain
Date: Mon Aug 1 09:52:50 2005
New Revision: 226838
URL: http://svn.apache.org/viewcvs?rev=226838view=rev
Log:
Yeah! Real exceptions with Xalan rather than a useless RuntimeException!
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java
cocoon/branches/BRANCH_2_1_X/status.xml
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java?rev=226838r1=226837r2=226838view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java
Mon Aug 1 09:52:50 2005
@@ -26,6 +26,8 @@
import java.util.Set;
import java.util.Map.Entry;
+import javax.xml.transform.ErrorListener;
+import javax.xml.transform.TransformerException;
import javax.xml.transform.sax.SAXResult;
import javax.xml.transform.sax.TransformerHandler;
@@ -47,6 +49,10 @@
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.Session;
import org.apache.cocoon.environment.SourceResolver;
+import org.apache.cocoon.util.ExceptionUtils;
+import org.apache.cocoon.util.TraxErrorHandler;
+import org.apache.cocoon.util.location.LocatedRuntimeException;
+import org.apache.cocoon.util.location.Location;
import org.apache.cocoon.xml.XMLConsumer;
import org.apache.commons.lang.BooleanUtils;
@@ -201,6 +207,32 @@
/** Exception that might occur during setConsumer */
private SAXException exceptionDuringSetConsumer;
+
+private TransformerException transformerException;
+
+private ErrorListener errorListener = new ErrorListener() {
+
+public void warning(TransformerException ex) throws
TransformerException {
+if (getLogger().isWarnEnabled()) {
+Location loc = ExceptionUtils.getLocation(ex);
+getLogger().warn(Warning at + loc == null ?
inputSource.getURI() : loc.toString(), ex);
+}
+}
+
+public void error(TransformerException ex) throws
TransformerException {
+if (getLogger().isWarnEnabled()) {
+Location loc = ExceptionUtils.getLocation(ex);
+getLogger().error(Error at + loc == null ?
inputSource.getURI() : loc.toString(), ex);
+}
+}
+
+public void fatalError(TransformerException ex) throws
TransformerException {
+// Keep it for later use
+transformerException = ex;
+// and rethrow it
+throw ex;
+}
+};
/**
* Configure this transformer.
@@ -413,6 +445,8 @@
final SAXResult result = new SAXResult(consumer);
result.setLexicalHandler(consumer);
this.transformerHandler.setResult(result);
+
+
this.transformerHandler.getTransformer().setErrorListener(this.errorListener);
}
/**
@@ -567,6 +601,7 @@
this.transformerHandler = null;
this.transformerValidity = null;
this.exceptionDuringSetConsumer = null;
+this.transformerException = null;
super.recycle();
}
@@ -575,7 +610,30 @@
*/
public void endDocument()
throws SAXException {
-super.endDocument();
+try {
+super.endDocument();
+} catch(SAXException se) {
+// Rethrow
+throw se;
+} catch(Exception e) {
+if (transformerException != null) {
+// Ignore the fake RuntimeException sent by Xalan
+Location loc =
ExceptionUtils.getLocation(transformerException);
+if (loc == null) {
+// No location: if it's just a wrapper, consider only
the wrapped exception.
+Throwable realEx = transformerException.getCause();
+if (realEx == null) realEx = transformerException;
+
+// Now throw an exception locating the current stylesheet
+throw new LocatedRuntimeException(Error during
transformation, realEx, new Location(this.inputSource.getURI()));
+} else {
+throw new SAXException(transformerException);
+}
+} else {
+// It's not a fake exception
+throw new SAXException(e);
+}
+}
this.finishedDocument = true;
}
Modified: cocoon/branches/BRANCH_2_1_X/status.xml
