You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(14) |
Mar
(107) |
Apr
(211) |
May
(93) |
Jun
(158) |
Jul
(159) |
Aug
(368) |
Sep
(188) |
Oct
(151) |
Nov
(115) |
Dec
(98) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(25) |
Feb
|
Mar
(33) |
Apr
(28) |
May
(116) |
Jun
(2) |
Jul
(117) |
Aug
(19) |
Sep
(9) |
Oct
(2) |
Nov
|
Dec
(4) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(9) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(22) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(267) |
Sep
|
Oct
|
Nov
(6) |
Dec
(512) |
| 2008 |
Jan
(187) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dejan K. <dej...@ya...> - 2003-04-25 09:08:32
|
Hi Erik, getOptions methods are used for getting values of configuration options. By default Velocity templatization is performed on option values. If you need to get option value without templatization use methods getOptions(optionName, false). If you have option with multiple suboptions use getOptionList method (look in Enrich, XpathExtract and some other stage's source). There are some other methods fot getting options but they are used rarely if used at all. (I think we need some refactorings here. For example, I think that it would be more natural if method getOptions is called getOption since it gets only one option. There are unused methods here too...) AdditionalInfo was workaround for solving some problems specific to my project that was not implemented in Babeldoc. Basicly, you can use it in pipeline stages to store some information in Journal like exception message or anything else. I am not very satisfied with this solution and I am open to some other solutions here. get() method in PipelineDocument is used for getting attribute values from document. There are some other get methods here which gets some specific attribute so they are just shortcuts (getName, getMimeType). PipelineStageResult object represents result of operation. It is used for specifying where document should go after processing in one stage. In most cases you don't need to deal with PipelineStageResult. There are helpers methods that are used for creating PipelineStageResult objects. Since most stages just performs some operation on a document you can call processHelper method that will just create PipelineStageResult object with current document, current ticket and nextStage and will return it in array. There are also situations where you perform some operations that changes document. XslTransform, XslFoTransform and few other stages are exampe of this. In this case you will create a new document and call processHelper(PipelineDocument) method. Some stages performs operations that results in more that one document (XPathSplitter) or routes same document on different stages (Router). In this case you shoud create PipelineStageResult[] array by yourself. Dejan --- ek...@ba... wrote: > Also, when/where would I want to use "Options" from > the PipelineStage? > > I guess I need to know the usage, source, and > differences between: > -- PipelineStage Options > -- PipelineStage AdditionalInfo > -- PipelineDocument get( ) methods > -- PipelineStageResult array from > PipelineStage.process( ) method > > as well as how to get at the information from the > input to babeldoc (my > XML and specific tags within it, for example) > > Thanks. Good night. > > ---------------------- Forwarded by Erik > Klein/NY/DOMESTIC/BNY on 04/24/2003 05:50 PM > --------------------------- > To: bab...@li... > cc: > Subject: Simple Question > > This might sound simple to you, but I am trying to > do something basic and > want to verify. > > My input to babeldoc is an XML string. I want to be > able to reference > tags from the XML String from within the stages of > the pipeline. One of > my PipelineStages is the Script stage (I am using > Jython). I want to > reference some of the XML tags from within the > script but have had no luck > using document.get(<tagName>). > > A few questions: > 1. Should I be using the XPath Pipeline Stage to > extract the wanted tags > and use document.put(<tagName>,<tagValue>) so that > my later Script stage > can use document.get(<tagName)? > 2. If so, where would I find some decent > documentation/examples for coding > XPath? > 3. Should I use the Enrich Pipeline Stage instead? > 4. Is there a better way to do this than my above > approach? > > Thanks in advance. > > > > ________________________________________________________________________ > The information in this e-mail, and any attachment > therein, is confidential and for use by the > addressee only. If you are not the intended > recipient, please return the e-mail to the sender > and delete it from your computer. Although The Bank > of New York attempts to sweep e-mail and attachments > for viruses, it does not guarantee that either are > virus-free and accepts no liability for any damage > sustained as a result of viruses. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: <br...@mc...> - 2003-04-25 07:05:04
|
Buildfile: build.xml
declare:
depends:
[echo] Build order: core gui sql web soap scanner crypto babelfish conversion
build:
[echo] Building Babeldoc in: /home/bruce/work/cvs-babeldoc/babeldoc_v1
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/examples
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/readme
build:
[echo] Building core
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[javac] Compiling 146 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[copy] Copying 26 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build/env
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_core.jar
[copy] Copying 81 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building core
build:
[echo] Building gui
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/gui/build
[javac] Compiling 3 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/gui/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_gui.jar
build:
[echo] Building gui
build:
[echo] Building sql
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[javac] Compiling 21 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[copy] Copying 11 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_sql.jar
[copy] Copying 7 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building sql
build:
[echo] Building web
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[javac] Compiling 5 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_web.jar
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console
[copy] Copying 23 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-console.war
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-httpfeed.war
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/bin
build:
[echo] Building web
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_web.jar
build:
[echo] Building soap
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[javac] Compiling 4 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_soap.jar
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_soapfeed.war
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building soap
build:
[echo] Building scanner
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[javac] Compiling 28 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[rmic] RMI Compiling 1 class to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-scanner.jar
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building scanner
build:
[echo] Building crypto
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[javac] Compiling 4 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_crypto.jar
build:
[echo] Building crypto
build:
[echo] Building babelfish
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[javac] Compiling 2 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_babelfish.jar
build:
[echo] Building babelfish
build:
[echo] Building conversion
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[javac] Compiling 14 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_conversion.jar
[copy] Copying 11 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building conversion
BUILD SUCCESSFUL
Total time: 32 seconds
|
|
From: Bruce M. <br...@mc...> - 2003-04-25 00:44:06
|
On Thursday 24 April 2003 05:44 pm, ek...@ba... wrote: > This might sound simple to you, but I am trying to do something basic and > want to verify. > > My input to babeldoc is an XML string. I want to be able to reference > tags from the XML String from within the stages of the pipeline. One of > my PipelineStages is the Script stage (I am using Jython). I want to Jython - ewwww. Kidding. > reference some of the XML tags from within the script but have had no luck > using document.get(<tagName>). > > A few questions: > 1. Should I be using the XPath Pipeline Stage to extract the wanted tags > and use document.put(<tagName>,<tagValue>) so that my later Script stage > can use document.get(<tagName)? Correct. 2. If so, where would I find some decent documentation/examples for coding > XPath? Take a look at the higgs bros or the other big example. > 3. Should I use the Enrich Pipeline Stage instead? Enrich is possible too - but enrich does not use XPath to get data out of the xml document. Its more for adding ancilliary enrichments - date, userdirectory, scripts, etc, etc. > 4. Is there a better way to do this than my above approach? No. > > Thanks in advance. > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-24 21:55:42
|
Also, when/where would I want to use "Options" from the PipelineStage? I guess I need to know the usage, source, and differences between: -- PipelineStage Options -- PipelineStage AdditionalInfo -- PipelineDocument get( ) methods -- PipelineStageResult array from PipelineStage.process( ) method as well as how to get at the information from the input to babeldoc (my XML and specific tags within it, for example) Thanks. Good night. ---------------------- Forwarded by Erik Klein/NY/DOMESTIC/BNY on 04/24/2003 05:50 PM --------------------------- To: bab...@li... cc: Subject: Simple Question This might sound simple to you, but I am trying to do something basic and want to verify. My input to babeldoc is an XML string. I want to be able to reference tags from the XML String from within the stages of the pipeline. One of my PipelineStages is the Script stage (I am using Jython). I want to reference some of the XML tags from within the script but have had no luck using document.get(<tagName>). A few questions: 1. Should I be using the XPath Pipeline Stage to extract the wanted tags and use document.put(<tagName>,<tagValue>) so that my later Script stage can use document.get(<tagName)? 2. If so, where would I find some decent documentation/examples for coding XPath? 3. Should I use the Enrich Pipeline Stage instead? 4. Is there a better way to do this than my above approach? Thanks in advance. ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-24 21:45:09
|
This might sound simple to you, but I am trying to do something basic and want to verify. My input to babeldoc is an XML string. I want to be able to reference tags from the XML String from within the stages of the pipeline. One of my PipelineStages is the Script stage (I am using Jython). I want to reference some of the XML tags from within the script but have had no luck using document.get(<tagName>). A few questions: 1. Should I be using the XPath Pipeline Stage to extract the wanted tags and use document.put(<tagName>,<tagValue>) so that my later Script stage can use document.get(<tagName)? 2. If so, where would I find some decent documentation/examples for coding XPath? 3. Should I use the Enrich Pipeline Stage instead? 4. Is there a better way to do this than my above approach? Thanks in advance. ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-24 07:19:43
|
First of all I don't think you need scanners at all. Scanners are used just for feeding pipelines and no other module depends on them. So you can exclude this module without loosing anything important for your project. I have implemented filtering in scanners using regular expressions few week ago. Since I haven't used any of third-party regex packages (Jakarta Oro and Jakarta Regexp) I did implement them using jdk 1.4 java.util.regex package. So, if you want to use scanners with jdk 1.3 you should try to port methods that use java.util.regex to some of third-party libraries. Since there are only two methods I don't think this will be a problem for someone who did use Jakarta Oro/Regexp Dejan ----- Original Message ----- From: ek...@ba... To: bab...@li... Sent: Wednesday, April 23, 2003 5:14 PM Subject: [Babeldoc-devel] Catching up ... I am just today integrating my development environment with the same directory that I synchronize with CVS. Today I discovered that com.babeldoc.scanner.ScannerWorker implemented the JDK 1.4 Regex package about 3 1/2 weeks ago. Is there any desire to use a 3rd party package for this so that JDK 1.3 compatibility can be restored? If not, is this a class I could just exclude from my build? Or do all Scanners depend on it? Since it is abstract, it would seem to be subclassed and I see Javadocs indicating that Directory, FTP, Mailbox, and SQL Scanners all subclass it. Any thoughts? Erik ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: <br...@mc...> - 2003-04-24 07:04:50
|
Buildfile: build.xml
declare:
depends:
[echo] Build order: core gui sql web soap scanner crypto babelfish conversion
build:
[echo] Building Babeldoc in: /home/bruce/work/cvs-babeldoc/babeldoc_v1
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/examples
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/readme
build:
[echo] Building core
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[javac] Compiling 146 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[copy] Copying 26 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build/env
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_core.jar
[copy] Copying 81 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building core
build:
[echo] Building gui
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/gui/build
[javac] Compiling 3 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/gui/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_gui.jar
build:
[echo] Building gui
build:
[echo] Building sql
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[javac] Compiling 21 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[copy] Copying 11 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/sql/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_sql.jar
[copy] Copying 7 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building sql
build:
[echo] Building web
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[javac] Compiling 5 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_web.jar
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console
[copy] Copying 23 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/console/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-console.war
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/web/build/httpfeed/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-httpfeed.war
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/bin
build:
[echo] Building web
build:
[echo] Building soap
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[javac] Compiling 4 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_soap.jar
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed
[copy] Copying 1 file to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/soap/build/soapfeed/WEB-INF
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_soapfeed.war
[copy] Copying 5 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building soap
build:
[echo] Building scanner
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[javac] Compiling 28 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[rmic] RMI Compiling 1 class to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/scanner/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc-scanner.jar
[copy] Copying 3 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building scanner
build:
[echo] Building crypto
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[javac] Compiling 4 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/crypto/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_crypto.jar
build:
[echo] Building crypto
build:
[echo] Building babelfish
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[javac] Compiling 2 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/babelfish/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_babelfish.jar
build:
[echo] Building babelfish
build:
[echo] Building conversion
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[javac] Compiling 14 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[copy] Copying 2 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/conversion/build
[jar] Building jar: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib/babeldoc_conversion.jar
[copy] Copying 11 files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
build:
[echo] Building conversion
BUILD SUCCESSFUL
Total time: 32 seconds
|
|
From: Bruce M. <br...@mc...> - 2003-04-23 23:31:26
|
Dejan? On Wednesday 23 April 2003 11:14 am, ek...@ba... wrote: > I am just today integrating my development environment with the same > directory that I synchronize with CVS. Today I discovered that > com.babeldoc.scanner.ScannerWorker implemented the JDK 1.4 Regex package > about 3 1/2 weeks ago. > > Is there any desire to use a 3rd party package for this so that JDK 1.3 > compatibility can be restored? If not, is this a class I could just > exclude from my build? Or do all Scanners depend on it? Since it is > abstract, it would seem to be subclassed and I see Javadocs indicating > that Directory, FTP, Mailbox, and SQL Scanners all subclass it. > > Any thoughts? > > Erik > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-23 15:14:40
|
I am just today integrating my development environment with the same directory that I synchronize with CVS. Today I discovered that com.babeldoc.scanner.ScannerWorker implemented the JDK 1.4 Regex package about 3 1/2 weeks ago. Is there any desire to use a 3rd party package for this so that JDK 1.3 compatibility can be restored? If not, is this a class I could just exclude from my build? Or do all Scanners depend on it? Since it is abstract, it would seem to be subclassed and I see Javadocs indicating that Directory, FTP, Mailbox, and SQL Scanners all subclass it. Any thoughts? Erik ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-23 10:15:37
|
Just to let you know - the bug that causes errors when using remote scanning option in scanner program has been fixed so Scanner Monitor application can be used now. This has been updated in main branch of CVS so it will ba avaliable in 1.0 release (I am also working on different cvs branch these days refactoring scanner code). Dejan |
|
From: <br...@mc...> - 2003-04-23 07:05:07
|
Buildfile: build.xml
declare:
depends:
[echo] Build order: core gui sql web soap scanner crypto babelfish conversion
build:
[echo] Building Babeldoc in: /home/bruce/work/cvs-babeldoc/babeldoc_v1
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/lib
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/examples
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/build/readme
build:
[echo] Building core
[mkdir] Created dir: /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
[javac] Compiling 146 source files to /home/bruce/work/cvs-babeldoc/babeldoc_v1/modules/core/build
|
|
From: Dejan K. <dej...@nb...> - 2003-04-23 06:20:55
|
Erik, we don't have some kind of deadline for release so one or two weeks delaying will not cause problems. More important is improving Babeldoc's quality for that release. Anyway, your "incredibly tight deadline" means that we don't have to wait more than 4 weeks ;-) We know that you have no time to work anything that is not part of your project and I am OK with that. But, I do think that code inspections, suggestions and some bug fixes is helpful and important for us (at least for me!). I have few projects working on Babeldoc and we are plan few more serious projects and I am very interested to improve quality of this software. Be sure this software will not be "custom built for your needs" but anything we found iteresting to include or change in Babeldoc we will do if it doesn't break code compatibility. In other words, don't worry - nobody will do your job or something that will be applicable only to your project! So if we can delay our release (and Bruce said he is OK with that) I suggest choosing option 2. you have proposed since it is the best for Babeldoc. You should be aware that this option might be worst for you, because you will depend on other people and will have requirement to keep most code backward compatibile. Dejan ----- Original Message ----- From: ek...@ba... To: bab...@li... Sent: Tuesday, April 22, 2003 9:45 PM Subject: Re: [Babeldoc-devel] PipelineStageFactory Gentlemen, the last thing I want to do is be the cause of the delay of the initial release. I "walked onto" this project very late in your development cycle and have been quite a drain on your resources in order to get the assistance I need in implementing this for my purposes. I never expected the software to be "custom built" for my needs. The product will never be "all things to all people". The issue of Exceptions may be a touchy one ... I certainly don't want to go around changing the method signatures of the majority of methods in the system if the current functionality meets most people's needs right now. Whether I discovered a rare instance of an exception not being handled well or if this "issue" is propogated all throughout the system, I have no idea. I get the impression that what I've proposed today may be a bigger modification than is desired at this point. As you are aware, I have incredibly tight deadlines for production implementation (less than 4 weeks at this point) and hence may not be able to provide the type of "community support" that most other participants in an open-source project can provide. And I don't want other people spending their time and effort making modifications solely for my consumption. I am equally open to the following options: 1. Me implementing my own Logging extension that throws a RuntimeException whenever an Error Log request is made, thereby affecting no one else 2. Us investigating which discarded exceptions are legitimate and which need to be addressed and dividing the work to do it ... this can take a tremendous amount of analysis for someone not familiar with the codebase 3. Me diverging from the codebase at this point, implementing my own exception handling, and perhaps merging back after 1.0 is released. I'm open to any of the above. Bruce, I look to you for guidance on this. Thanks. Erik Sent by: bab...@li... To: bab...@li... cc: Subject: Re: [Babeldoc-devel] PipelineStageFactory If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Bruce M. <br...@mc...> - 2003-04-22 19:50:59
|
Erik, all, I am quite open to delaying the release of 1.0 until we have gotten this sorted out. I would prefer that we follow your efforts so that we may immediately reap the benefits of your work. Basically I agree with Dejan here - we need not rush to 1.0 after moving patiently for this long year. regards, Bruce. On Tuesday 22 April 2003 03:45 pm, ek...@ba... wrote: > Gentlemen, the last thing I want to do is be the cause of the delay of the > initial release. I "walked onto" this project very late in your > development cycle and have been quite a drain on your resources in order > to get the assistance I need in implementing this for my purposes. I > never expected the software to be "custom built" for my needs. The > product will never be "all things to all people". > > The issue of Exceptions may be a touchy one ... I certainly don't want to > go around changing the method signatures of the majority of methods in the > system if the current functionality meets most people's needs right now. > Whether I discovered a rare instance of an exception not being handled > well or if this "issue" is propogated all throughout the system, I have no > idea. I get the impression that what I've proposed today may be a bigger > modification than is desired at this point. > > As you are aware, I have incredibly tight deadlines for production > implementation (less than 4 weeks at this point) and hence may not be able > to provide the type of "community support" that most other participants in > an open-source project can provide. And I don't want other people > spending their time and effort making modifications solely for my > consumption. > > I am equally open to the following options: > 1. Me implementing my own Logging extension that throws a RuntimeException > whenever an Error Log request is made, thereby affecting no one else > 2. Us investigating which discarded exceptions are legitimate and which > need to be addressed and dividing the work to do it ... this can take a > tremendous amount of analysis for someone not familiar with the codebase > 3. Me diverging from the codebase at this point, implementing my own > exception handling, and perhaps merging back after 1.0 is released. > > I'm open to any of the above. Bruce, I look to you for guidance on this. > Thanks. > > Erik > > > > Sent by: bab...@li... > To: bab...@li... > cc: > Subject: Re: [Babeldoc-devel] PipelineStageFactory > > > If you asking me I would not hurry with this realase. > > We do plan some changes in core module that could > impact on all other modules. I guess there will be > more changes like this since requirements that Erik > has are pretty different than those that you had when > you have started to write Babeldoc and those that I > had in my projects. This will require a lot of > testing. Some aspects that was not important for us > will be important for Erik's project so he will > probably do more changes (which is good thing because > it will improve Babeldoc and make it applicable to > problems that was not initialy planned). > > > > Also, note that I will be on vacation between April > 25th and May 5th. > > Dejan > > --- Bruce McDonald <br...@mc...> wrote: > > Dejan, > > > > The release, all things being equal will go out on > > May 2 2003 > > > > regards, > > Bruce. > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-22 19:45:36
|
Gentlemen, the last thing I want to do is be the cause of the delay of the initial release. I "walked onto" this project very late in your development cycle and have been quite a drain on your resources in order to get the assistance I need in implementing this for my purposes. I never expected the software to be "custom built" for my needs. The product will never be "all things to all people". The issue of Exceptions may be a touchy one ... I certainly don't want to go around changing the method signatures of the majority of methods in the system if the current functionality meets most people's needs right now. Whether I discovered a rare instance of an exception not being handled well or if this "issue" is propogated all throughout the system, I have no idea. I get the impression that what I've proposed today may be a bigger modification than is desired at this point. As you are aware, I have incredibly tight deadlines for production implementation (less than 4 weeks at this point) and hence may not be able to provide the type of "community support" that most other participants in an open-source project can provide. And I don't want other people spending their time and effort making modifications solely for my consumption. I am equally open to the following options: 1. Me implementing my own Logging extension that throws a RuntimeException whenever an Error Log request is made, thereby affecting no one else 2. Us investigating which discarded exceptions are legitimate and which need to be addressed and dividing the work to do it ... this can take a tremendous amount of analysis for someone not familiar with the codebase 3. Me diverging from the codebase at this point, implementing my own exception handling, and perhaps merging back after 1.0 is released. I'm open to any of the above. Bruce, I look to you for guidance on this. Thanks. Erik Sent by: bab...@li... To: bab...@li... cc: Subject: Re: [Babeldoc-devel] PipelineStageFactory If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@ya...> - 2003-04-22 19:30:17
|
If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Bruce M. <br...@mc...> - 2003-04-22 16:48:20
|
Dejan, The release, all things being equal will go out on May 2 2003 regards, Bruce. On Tuesday 22 April 2003 10:56 am, Dejan Krsmanovic wrote: > This is not good idea. There are places where exceptions should be logged > without rethrowing them. If I understood you, using your aproach would > break processing whenever exception is logged. There are situations (like > project that I am working on) where pipeline stage order depends on error > that occured. In case of error, I need to send e-mail or something else, > but breaking processing would not be good for me. Anyway, there are really > no many places where exceptions should be rethrown. getPipelineStage and > trackDocument are good examples of methods that should rethrow exception... > I think it would not be to hard to identify all or most of these methods. > Also, I don't think it is too important if 1.0 release would be delayed few > weeks... Bruce when did you planned it, anyway? > > Dejan > > > ----- Original Message ----- > From: ek...@ba... > To: bab...@li... > Sent: Tuesday, April 22, 2003 4:47 PM > Subject: Re: [Babeldoc-devel] PipelineStageFactory > > > > << > No, dont fork the codebase, let the exceptions move up the stack - just > make sure that they get caught "somewhere". The "somewhere" in the case of > PipelineFeeder.process is ultimately called from PipelineFeeder.execute. > In this case all the possible exceptions are caught so all is well. > > > My suggestion was either for me to modify the codebase or for ME to break > away from the codebase and develop independently. I had no intention of > forking the codebase within CVS (if that is what you meant). > > As to catching the exception "somewhere", I personally feel that the > system should expose certain "high-level / client-consumable" exceptions > through its entry points. Otherwise, clients of this software (even > command-line processes) will not be aware of the errors occurring within > Babeldoc and can code to handle them. I am certainly no expert at the > exceptions being used in the software, but it seems to me that exceptions > such as PipelineException and JournalException seem "client consumable". > > My approach would be the following: > 1. Search out areas where exceptions are being discarded or just logged > 2. Choose an "appropriate" exception class to represent the exception and > include this in the "throws" clause of the method signature. 3. Allow the > compiler to identify all the calling methods which either need to also > "throw" these exceptions or take specific action to "trap and handle" the > exception > > I just finished a quick analysis that identified every "catch" statement > in the entire codebase. Following are some statistics: -- 289 catch > statements > -- 157 of these either log the error or do printStackTrace ... > discarded -- 33 of these do nothing ... discarded > -- 99 of these rethrow the exception "appropriately" ... handled > > Not included in the numbers above are situations that obviously require > no exception handling (inability to close a database prepared statement / > connection, code that specifically documents that nothing should be done). > It should be noted that most of the Scanner, PipelineStage, and Journal > classes do a very good job of exception handling. > > Please provide your thoughts on the following suggestion: > Since there are many places that simply log the error (using the > commons-logger), one "quick and dirty" approach would be to have the > underlying logging system throw a type of RuntimeException after the > logging has occurred when a logError request is made. This would mean that > no method signatures would need to be modified and exceptions would flow > straight to the top of the call stack. It would require very little effort > and would allow us to be one step closer to v1.0, but would not be "as > professional". Maybe this is a good stop-gap solution until 1.0 is > released. > > What are your thoughts? > > Erik > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is > confidential and for use by the addressee only. If you are not the intended > recipient, please return the e-mail to the sender and delete it from your > computer. Although The Bank of New York attempts to sweep e-mail and > attachments for viruses, it does not guarantee that either are virus-free > and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 14:59:33
|
This is not good idea. There are places where exceptions should be =
logged without rethrowing them. If I understood you, using your aproach =
would break processing whenever exception is logged. There are =
situations (like project that I am working on) where pipeline stage =
order depends on error that occured. In case of error, I need to send =
e-mail or something else, but breaking processing would not be good for =
me.
Anyway, there are really no many places where exceptions should be =
rethrown. getPipelineStage and trackDocument are good examples of =
methods that should rethrow exception... I think it would not be to hard =
to identify all or most of these methods.=20
Also, I don't think it is too important if 1.0 release would be delayed =
few weeks... Bruce when did you planned it, anyway?
Dejan
----- Original Message -----=20
From: ek...@ba...=20
To: bab...@li...=20
Sent: Tuesday, April 22, 2003 4:47 PM
Subject: Re: [Babeldoc-devel] PipelineStageFactory
<<=20
No, dont fork the codebase, let the exceptions move up the stack - =
just make
sure that they get caught "somewhere". The "somewhere" in the case of
PipelineFeeder.process is ultimately called from =
PipelineFeeder.execute. In
this case all the possible exceptions are caught so all is well.
>>=20
My suggestion was either for me to modify the codebase or for ME to =
break away from the codebase and develop independently. I had no =
intention of forking the codebase within CVS (if that is what you =
meant).=20
As to catching the exception "somewhere", I personally feel that the =
system should expose certain "high-level / client-consumable" exceptions =
through its entry points. Otherwise, clients of this software (even =
command-line processes) will not be aware of the errors occurring within =
Babeldoc and can code to handle them. I am certainly no expert at the =
exceptions being used in the software, but it seems to me that =
exceptions such as PipelineException and JournalException seem "client =
consumable".=20
My approach would be the following:=20
1. Search out areas where exceptions are being discarded or just =
logged=20
2. Choose an "appropriate" exception class to represent the exception =
and include this in the "throws" clause of the method signature.=20
3. Allow the compiler to identify all the calling methods which either =
need to also "throw" these exceptions or take specific action to "trap =
and handle" the exception=20
I just finished a quick analysis that identified every "catch" =
statement in the entire codebase. Following are some statistics:=20
-- 289 catch statements=20
-- 157 of these either log the error or do printStackTrace ... =
discarded=20
-- 33 of these do nothing ... discarded=20
-- 99 of these rethrow the exception "appropriately" ... =
handled=20
Not included in the numbers above are situations that obviously =
require no exception handling (inability to close a database prepared =
statement / connection, code that specifically documents that nothing =
should be done). It should be noted that most of the Scanner, =
PipelineStage, and Journal classes do a very good job of exception =
handling.=20
Please provide your thoughts on the following suggestion:=20
Since there are many places that simply log the error (using the =
commons-logger), one "quick and dirty" approach would be to have the =
underlying logging system throw a type of RuntimeException after the =
logging has occurred when a logError request is made. This would mean =
that no method signatures would need to be modified and exceptions would =
flow straight to the top of the call stack. It would require very =
little effort and would allow us to be one step closer to v1.0, but =
would not be "as professional". Maybe this is a good stop-gap solution =
until 1.0 is released.=20
What are your thoughts?=20
Erik=20
=
________________________________________________________________________
The information in this e-mail, and any attachment therein, is =
confidential and for use by the addressee only. If you are not the =
intended recipient, please return the e-mail to the sender and delete it =
from your computer. Although The Bank of New York attempts to sweep =
e-mail and attachments for viruses, it does not guarantee that either =
are virus-free and accepts no liability for any damage sustained as a =
result of viruses.
|
|
From: <ek...@ba...> - 2003-04-22 14:47:28
|
<<
No, dont fork the codebase, let the exceptions move up the stack - just
make
sure that they get caught "somewhere". The "somewhere" in the case of
PipelineFeeder.process is ultimately called from PipelineFeeder.execute.
In
this case all the possible exceptions are caught so all is well.
>>
My suggestion was either for me to modify the codebase or for ME to break
away from the codebase and develop independently. I had no intention of
forking the codebase within CVS (if that is what you meant).
As to catching the exception "somewhere", I personally feel that the
system should expose certain "high-level / client-consumable" exceptions
through its entry points. Otherwise, clients of this software (even
command-line processes) will not be aware of the errors occurring within
Babeldoc and can code to handle them. I am certainly no expert at the
exceptions being used in the software, but it seems to me that exceptions
such as PipelineException and JournalException seem "client consumable".
My approach would be the following:
1. Search out areas where exceptions are being discarded or just logged
2. Choose an "appropriate" exception class to represent the exception and
include this in the "throws" clause of the method signature.
3. Allow the compiler to identify all the calling methods which either
need to also "throw" these exceptions or take specific action to "trap and
handle" the exception
I just finished a quick analysis that identified every "catch" statement
in the entire codebase. Following are some statistics:
-- 289 catch statements
-- 157 of these either log the error or do printStackTrace ...
discarded
-- 33 of these do nothing ... discarded
-- 99 of these rethrow the exception "appropriately" ... handled
Not included in the numbers above are situations that obviously require no
exception handling (inability to close a database prepared statement /
connection, code that specifically documents that nothing should be done).
It should be noted that most of the Scanner, PipelineStage, and Journal
classes do a very good job of exception handling.
Please provide your thoughts on the following suggestion:
Since there are many places that simply log the error (using the
commons-logger), one "quick and dirty" approach would be to have the
underlying logging system throw a type of RuntimeException after the
logging has occurred when a logError request is made. This would mean
that no method signatures would need to be modified and exceptions would
flow straight to the top of the call stack. It would require very little
effort and would allow us to be one step closer to v1.0, but would not be
"as professional". Maybe this is a good stop-gap solution until 1.0 is
released.
What are your thoughts?
Erik
________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 14:37:29
|
I will handle scanner part, since I am working on it these days anyway Dejan > No, dont fork the codebase, let the exceptions move up the stack - just make > sure that they get caught "somewhere". The "somewhere" in the case of > PipelineFeeder.process is ultimately called from PipelineFeeder.execute. In > this case all the possible exceptions are caught so all is well. > |
|
From: Bruce M. <br...@mc...> - 2003-04-22 14:04:36
|
Erik, all, Comments inline. On Tuesday 22 April 2003 09:56 am, ek...@ba... wrote: > << > It can be explained by not having your set of requirements at the time of > writing. You will probably need to implement the changes you need > yourself. > > > Understood. Not a problem. > > So, shall I implement these changes in the codebase or do I need to > diverge from the codebase at this point in time? No, dont fork the codebase, let the exceptions move up the stack - just make sure that they get caught "somewhere". The "somewhere" in the case of PipelineFeeder.process is ultimately called from PipelineFeeder.execute. In this case all the possible exceptions are caught so all is well. > Note: I suspect we may find things that "break" once the exceptions start > flowing through the call stack. This is probably a good thing - we will need to fix theses places. > Additionally, I'm sure there are a few truly legitimate places where the > exceptions are not important and processing handles this. If there is any > insight into examples of these, please advise. Lets deal with that when we find them. Sorry to be not specific. > Erik > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 13:58:08
|
I agree with you that these two methods should throw exceptions. These =
are serious problems and exception should not be discarded. If you =
asking me, feel free to implement this.=20
Dejan
----- Original Message -----=20
From: ek...@ba...=20
To: bab...@li...=20
Sent: Tuesday, April 22, 2003 3:48 PM
Subject: Re: [Babeldoc-devel] PipelineStageFactory
<<=20
Then probably process method of PipelineStageFactory should throw =
exception, right? I guess it is not enough if you use another =
PipelineStageErrorHandler since it is used only for handling errors that =
occurs in PipelineStage.process().
>>=20
Here is the call stack as I can trace it:=20
PipelineFeeder.process( ) throws PipelineException, JournalException=20
PipelineFactoryFactory.process( ) throws PipelineException=20
PipelineFactory.process( ) throws PipelineException=20
PipelineStageFactory.process( ) **which throws =
nothing**=20
PipelineStageFactory.process( ) calls the following methods, which =
discard the exceptions they catch:=20
-- getPipelineStage=20
-- trackDocument=20
As I looked at the programs above, I found more examples of exceptions =
being caught and then either being discarded or having Error Log =
messages generated.=20
I guess the question I have is: "If something is important enough to =
cause an exception to be thrown, why is it so frequently sufficient to =
discard the exception or replace it with a logged error message??"=20
I am going to search for more examples of this ... the production =
system I implement cannot afford to have low-level exceptions discarded =
and I will not be writing log-scanning software to search for errors in =
logs when it could just as easily be identified by a thrown exception. =
Can anyone explain this?=20
Erik=20
=
________________________________________________________________________
The information in this e-mail, and any attachment therein, is =
confidential and for use by the addressee only. If you are not the =
intended recipient, please return the e-mail to the sender and delete it =
from your computer. Although The Bank of New York attempts to sweep =
e-mail and attachments for viruses, it does not guarantee that either =
are virus-free and accepts no liability for any damage sustained as a =
result of viruses.
|
|
From: <ek...@ba...> - 2003-04-22 13:57:07
|
<< It can be explained by not having your set of requirements at the time of writing. You will probably need to implement the changes you need yourself. >> Understood. Not a problem. So, shall I implement these changes in the codebase or do I need to diverge from the codebase at this point in time? Note: I suspect we may find things that "break" once the exceptions start flowing through the call stack. Additionally, I'm sure there are a few truly legitimate places where the exceptions are not important and processing handles this. If there is any insight into examples of these, please advise. Erik ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Bruce M. <br...@mc...> - 2003-04-22 13:52:21
|
It can be explained by not having your set of requirements at the time of writing. You will probably need to implement the changes you need yourself. On Tuesday 22 April 2003 09:48 am, ek...@ba... wrote: > << > Then probably process method of PipelineStageFactory should throw > exception, right? I guess it is not enough if you use another > PipelineStageErrorHandler since it is used only for handling errors that > occurs in PipelineStage.process(). > > > Here is the call stack as I can trace it: > > PipelineFeeder.process( ) throws PipelineException, JournalException > PipelineFactoryFactory.process( ) throws PipelineException > PipelineFactory.process( ) throws PipelineException > PipelineStageFactory.process( ) **which throws > nothing** > > PipelineStageFactory.process( ) calls the following methods, which discard > the exceptions they catch: > -- getPipelineStage > -- trackDocument > > As I looked at the programs above, I found more examples of exceptions > being caught and then either being discarded or having Error Log messages > generated. > > I guess the question I have is: "If something is important enough to cause > an exception to be thrown, why is it so frequently sufficient to discard > the exception or replace it with a logged error message??" > > I am going to search for more examples of this ... the production system I > implement cannot afford to have low-level exceptions discarded and I will > not be writing log-scanning software to search for errors in logs when it > could just as easily be identified by a thrown exception. Can anyone > explain this? > > Erik > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-22 13:49:06
|
<<
Then probably process method of PipelineStageFactory should throw
exception, right? I guess it is not enough if you use another
PipelineStageErrorHandler since it is used only for handling errors that
occurs in PipelineStage.process().
>>
Here is the call stack as I can trace it:
PipelineFeeder.process( ) throws PipelineException, JournalException
PipelineFactoryFactory.process( ) throws PipelineException
PipelineFactory.process( ) throws PipelineException
PipelineStageFactory.process( ) **which throws
nothing**
PipelineStageFactory.process( ) calls the following methods, which discard
the exceptions they catch:
-- getPipelineStage
-- trackDocument
As I looked at the programs above, I found more examples of exceptions
being caught and then either being discarded or having Error Log messages
generated.
I guess the question I have is: "If something is important enough to cause
an exception to be thrown, why is it so frequently sufficient to discard
the exception or replace it with a logged error message??"
I am going to search for more examples of this ... the production system I
implement cannot afford to have low-level exceptions discarded and I will
not be writing log-scanning software to search for errors in logs when it
could just as easily be identified by a thrown exception. Can anyone
explain this?
Erik
________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 13:44:31
|
I have done some refactorings in PipelineStage and PipelineStageFactory classes. Few methods that are related to PipelineStage are moved to from PipelineStageFactory to PipelineStage. Also, I have written DefaultPipelineStageErrorHandler class and moved handleError method in it. I will commit code to cvs in next few minutes... Dejan |