babeldoc-devel — Babeldoc developer list

[Babeldoc-devel] babeldoc/readme/userguide chapter4.xml,1.2,1.3 chapter5.xml,1.2,1.3

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/readme/userguide
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/readme/userguide

Modified Files:
	chapter4.xml chapter5.xml 
Log Message:
Minor documentation updates

Index: chapter4.xml
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter4.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** chapter4.xml	7 Apr 2003 03:53:42 -0000	1.2
--- chapter4.xml	30 Mar 2004 19:15:41 -0000	1.3
***************
*** 1,82 ****
  <?xml version="1.0" encoding="ISO-8859-1"?>
! 		<chapter>
! 			<title>Journal</title>
! 			<section>
! 				<title>Introduction</title>
! 				<para>The journal keeps track of documents as they move through the system as well as the status of each operation performed on the document.  The primary purpose of the journal is to provide a safe environment for the processing of documents.  There are a number of mission critical situations where losing data is not acceptable.  It is possible to recreate document processing if an error condition should arise.  Errors can be both external and internal.  Internal problems could be temporary database errors, disk space, etc.  External causes could be erroneous documents, network outages, etc.</para>
! 				<para>Each document is associated with a <userinput>JournalTicket</userinput> which is assigned uniquely just as the document enters the pipeline.  Each operation upon a document for a JournalTicket (hereafter also refered to as a ticket) is performed at a step.   Steps start at zero and increase until the document is finished processing.   Each operation (or pipelinestage) on a document can be uniquely identified by a combination of a ticket and a step.</para>
! 			</section>
  			
! 			<section>
! 				<title>Journal Operations</title>
! 				<para>A journal operation indicates what happened in the journal for the document at that pipelinestage.  This is essential for determining problems with document processing.  There are a number of journal operations available:</para>
! 				<orderedlist>
! 					<listitem><userinput>newTicket</userinput>. This operation is the first operation (step 0) when a document is introduced into a pipeline. This returns a new ticket.</listitem>
! 					<listitem><userinput>forkTicket</userinput>.  This operation occurs when a document is split intoor similar operation. The forked ticket is a new ticket but is associated with its parent ticket in theTicket lineage may thus be traced.</listitem>
! 					<listitem><userinput>updateStatus</userinput>.  This operation will cause the status of this ticket to be updated and the step updated. The ticket is unchanged, the step is incremented.</listitem>
! 					<listitem><userinput>updateDocument</userinput>.  This operation writes the document to the journal data store (implementation dependant).  The ticket is unchanged and step is incremented.</listitem>
! 					<listitem><userinput>replay</userinput>.  The operation causes the document associated with the ticket to be replayed from the step specified. This operation can only succeed if the document was updated (see update document operation).</listitem>
! 				</orderedlist>
! 			</section>
! 
! 			<section>
! 				<title>Journal Implementations</title>
! 				<para>The implementation of the journal depends on your specific circumstances. There are currently three implementations that are available.  Which specific journal to use is defined in the configuration file: <userinput>config/journal/config.properties</userinput>.   The journal to be used is set in the single name/value pair:  <userinput>journal</userinput>.   The options are:  </para>
! 				<orderedlist>
! 					<listitem>simple</listitem>
! 					<listitem>mysql</listitem>
! 					<listitem>oracle</listitem>
! 					<listitem>ejb</listitem>
! 				</orderedlist>
  			
! 				<section>
! 					<title>Simple Journal</title>
! 					<para>The simple journal implements its operations as disk files and directories. It is not intended as a robust, enterprise level implementation. It also lacks structured query functions for querying, etc. Its configuration file is <userinput>config/journal/simple/config.properties</userinput>.  This file has a number of configuration options</para>
! 					<orderedlist>
! 						<listitem><userinput>simpleJournalDir</userinput>:  The directory to create the log-detail files.</listitem>
! 						<listitem><userinput>SimpleJournalLog</userinput>:  The path to the journal file.  See later.</listitem>
! 						<listitem><userinput>logMaxSize</userinput>:  This will roll-over the log file once the journal log reaches this size.</listitem>
! 					</orderedlist>
! 					<para>For each operation logged to the journal, it is logged line by line to the journal log file. The lines are comma-separated values <firstterm>CSV</firstterm> separated and can be parsed by third party applications. The columns are:</para>
! 					<orderedlist>
! 						<listitem><userinput>ticket number</userinput>: the ticket number is currently the time in milliseconds at time of creation of the ticket.</listitem>
! 						<listitem><userinput>step</userinput>: the step number - starting from 0</listitem>
! 						<listitem><userinput>operation</userinput>: The particular operation being executed</listitem>
! 						<listitem><userinput>timestamp</userinput>: The time in milliseconds when the operation was logged</listitem>
! 						<listitem><userinput>status information</userinput>: The fail / success for updateStatus.</listitem>
! 						<listitem><userinput>pipeline stage name</userinput> The stage within the pipeline when this step was logged.</listitem>
! 						<listitem><userinput>additional status information</userinput>: The additional status information that indicates further information about this journal log.</listitem>
! 					</orderedlist>
! 					<para>For each ticket, there is a directory created with the value of the ticket (this is long string of numbers - its actually the time in milliseconds of when the ticket was created.   Inside this directory there are step delta files which represents each step in the log for that ticket. The contents of the delta file may be the status string or the document itself (if the operation is a updateDocument).  The document is persisted as a object serialization.</para>
! 				</section>
! 
! 				<section>
! 					<title>Jdbc Journal</title>
! 					<para>It is possible to use a database to store the journal log and the document data. Currently oracle and mysql are supported. The schema creation scripts are in the directory <userinput>readme/sql</userinput>.  The document data is stored as binary data (<firstterm>BLOBs</firstterm>).  Each vendor supports BLOBS slightly differently hence the specific database support.  There are three fundamental tables to store the journal data (the table <userinput>table_key</userinput> is for unique key generation), being:</para>
! 					<orderedlist>
! 						<listitem><userinput>log</userinput>:  Stores tickets and steps for the tickets as well as the operation details for that ticket step. The other_data columns can either store the status message for update status operations or the parent ticket id for fork ticket operations.</listitem>
! 						<listitem><userinput>journal</userinput>:  Stores the document as a blob for the ticket step.  This is associated with update document operations.</listitem>
! 						<listitem><userinput>journal_data</userinput>:  Storage for the enriched variables associated with the document. The primary reason that these variables are stored separately is that they can be used as query parameters for console operations.  Note that long and binary variables are not stored to the database and that strings can get truncated.</listitem>
! 					</orderedlist>
! 					<para>The configuration for both the Mysql and Oracle journals are stored in the configuration file: <userinput>config/journal/sql/config.properties</userinput>.  The only configuration option in this file is <userinput>resourceName</userinput> indicates that name of the resource that will manage the database connection.  Current the journal is implmented in a separate schema (instance, whatever) than the other database storage areas (user, and console).</para>
! 				</section>
  			
! 				<section>
! 					<title>Ejb Journal Implementation</title>
! 					<para>The intent of this journal implementation is to store the operation journal implementation in a J2EE container. Currently <productname>Jboss</productname> is explicitly supported but not to the exclusion of other containers. This implementation is really a shell around either the <userinput>simple</userinput> or <userinput>sql</userinput> journal implementations but running in a remote server.  By this means, it is possible to move the journal operation to a central location.  The main issue that can arise with the EJB The configuration for the ejb implementation is stored in the configuration file: </para>
! 				</section>
! 			</section>
! 
! 			<section>
! 				<title>Journal Tool</title>
! 				<para>The <userinput>journal tool</userinput> allows access to the journal from the command line.  This enables complex queries to be applied against the journal. There are four separate types of queries:</para>
! 				<orderedlist>
! 					<listitem><userinput>LIST</userinput>:  List all the tickets and the steps in the journal.  This can produce lots of output.  This can be limited by the flag -n (no more than this many lines of output).  It is also possible to start from another index other than zero using the -i flag</listitem>
! 					<listitem><userinput>TICKETSTEPS</userinput>:  List all the ticketsteps for the supplied ticket.</listitem>
! 					<listitem><userinput>DISPLAY</userinput>:  Displays the contents of the document stored at the ticket/step to the screen</listitem>
! 					<listitem><userinput>REPROCESS</userinput>:  This will reintroduce the document at the the point it was stored or later.</listitem>
! 				</orderedlist>
! 				<para>There are a number of options which can change the display of the data from the tool - use the -h command line to get all the options for this tool</para>
! 			</section>
! 		</chapter>
  
--- 1,104 ----
  <?xml version="1.0" encoding="ISO-8859-1"?>
! <chapter>
! 	<title>Journal</title>
! 	<section>
! 		<title>Introduction</title>
! 		<para>The journal keeps track of documents as they move through the system as well as the status of each operation performed on the document.  The primary purpose of the journal is to provide a safe environment for the processing of documents.  There are a number of mission critical situations where losing data is not acceptable.  It is possible to recreate document processing if an error condition should arise.  Errors can be both external and internal.  Internal problems could be temporary database errors, disk space, etc.  External causes could be erroneous documents, network outages, etc.</para>
! 		<para>Each document is associated with a <userinput>JournalTicket</userinput> which is assigned uniquely just as the document enters the pipeline.  Each operation upon a document for a JournalTicket (hereafter also refered to as a ticket) is performed at a step.   Steps start at zero and increase until the document is finished processing.   Each operation (or pipelinestage) on a document can be uniquely identified by a combination of a ticket and a step.</para>
! 	</section>
  			
! 	<section>
! 		<title>Journal Operations</title>
! 		<para>A journal operation indicates what happened in the journal for the document at that pipelinestage.  This is essential for determining problems with document processing.  There are a number of journal operations available:</para>
! 		<orderedlist>
! 			<listitem>
! 				<userinput>newTicket</userinput>. This operation is the first operation (step 0) when a document is introduced into a pipeline. This returns a new ticket.</listitem>
! 			<listitem>
! 				<userinput>forkTicket</userinput>.  This operation occurs when a document is split into many documents or  similar operations. The forked ticket is a new ticket but is associated with it's parent ticket in the Ticket lineage and may thus be traced.</listitem>
! 			<listitem>
! 				<userinput>updateStatus</userinput>.  This operation will cause the status of this ticket to be updated and the step updated. The ticket is unchanged, the step is incremented.</listitem>
! 			<listitem>
! 				<userinput>updateDocument</userinput>.  This operation writes the document to the journal data store (implementation dependant).  The ticket is unchanged and step is incremented.</listitem>
! 			<listitem>
! 				<userinput>replay</userinput>.  This operation causes the document associated with the ticket to be replayed from the step specified. This operation can only succeed if the document was updated (see update document operation).</listitem>
! 		</orderedlist>
! 	</section>
  			
! 	<section>
! 		<title>Journal Implementations</title>
! 		<para>The implementation of the journal depends on your specific circumstances. There are currently three implementations that are available.  Which specific journal to use is defined in the configuration file: <userinput>config/journal/config.properties</userinput>.   The journal to be used is set in the single name/value pair:  <userinput>journalType</userinput>.   The options are:  </para>
! 		<orderedlist>
! 			<listitem>simple</listitem>
! 			<listitem>mysql</listitem>
! 			<listitem>oracle</listitem>
! 			<listitem>ejb</listitem>
! 		</orderedlist>
! 				
! 		<section>
! 			<title>Simple Journal</title>
! 			<para>The simple journal implements it's operations as disk files and directories. It is not intended as a robust, enterprise level implementation. It also lacks structured query functions for querying, etc. Its configuration file is <userinput>config/journal/config.properties</userinput>.  This file has a number of configuration options</para>
! 			<orderedlist>
! 				<listitem>
! 					<userinput>simpleJournalDir</userinput>:  The directory to create the log-detail files.</listitem>
! 				<listitem>
! 					<userinput>simpleJournalLog</userinput>:  The path to the journal file.  See later.</listitem>
! 				<listitem>
! 					<userinput>logMaxSize</userinput>:  This will roll-over the log file once the journal log reaches this size.</listitem>
! 			</orderedlist>
! 			<para>For each operation logged to the journal, it is logged line by line to the journal log file. The lines are comma-separated values <firstterm>(CSV)</firstterm> and can be parsed by third party applications. The columns are:</para>
! 			<orderedlist>
! 				<listitem>
! 					<userinput>ticket number</userinput>: the ticket number is currently the time in milliseconds at time of creation of the ticket.</listitem>
! 				<listitem>
! 					<userinput>step</userinput>: the step number - starting from 0</listitem>
! 				<listitem>
! 					<userinput>operation</userinput>: The particular operation being executed</listitem>
! 				<listitem>
! 					<userinput>timestamp</userinput>: The time in milliseconds when the operation was logged</listitem>
! 				<listitem>
! 					<userinput>status information</userinput>: The fail / success for updateStatus.</listitem>
! 				<listitem>
! 					<userinput>pipeline stage name</userinput> The stage within the pipeline when this step was logged.</listitem>
! 				<listitem>
! 					<userinput>additional status information</userinput>: The additional status information that indicates further information about this journal log.</listitem>
! 			</orderedlist>
! 			<para>For each ticket, there is a directory created with the value of the ticket (this is long string of numbers - its actually the time in milliseconds of when the ticket was created.   Inside this directory there are step delta files which represents each step in the log for that ticket. The contents of the delta file may be the status string or the document itself (if the operation is updateDocument).  The document is persisted as an object serialization.</para>
! 		</section>
! 				
! 		<section>
! 			<title>Jdbc Journal</title>
! 			<para>It is possible to use a database to store the journal log and the document data. Currently oracle and mysql are supported. The schema creation scripts are in the directory <userinput>readme/sql</userinput>.  The document data is stored as binary data (<firstterm>BLOBs</firstterm>).  Each vendor supports BLOBS slightly differently, hence the specific database support.  There are three main tables involved in storing the journal data (the table <userinput>table_key</userinput> is for unique key generation), being:</para>
! 			<orderedlist>
! 				<listitem>
! 					<userinput>log</userinput>:  Stores tickets and steps for the tickets as well as the operation details for each ticket step. The log_other_data column can either store the status message for updateStatus operations or the parent ticket id for forkTicket operations.</listitem>
! 				<listitem>
! 					<userinput>journal</userinput>:  Stores the document as a blob for the ticket step.  This is associated with updateDocument operations.</listitem>
! 				<listitem>
! 					<userinput>journal_data</userinput>:  Storage for the enriched variables associated with the document. The primary reason that these variables are stored separately is that they can be used as query parameters for console operations.  Note that long and binary variables are not stored to the database and that strings can get truncated.</listitem>
! 			</orderedlist>
! 			<para>The configuration for both the Mysql and Oracle journals are stored in the configuration file: <userinput>config/journal/sql/config.properties</userinput>.  The only configuration option in this file is <userinput>resourceName</userinput> indicates that name of the resource that will manage the database connection.  Current the journal is implmented in a separate schema (instance, whatever) than the other database storage areas (user, and console).</para>
! 		</section>
! 				
! 		<section>
! 			<title>Ejb Journal Implementation</title>
! 			<para>The intent of this journal implementation is to store the operation journal implementation in a J2EE container. Currently <productname>Jboss</productname> is explicitly supported but not to the exclusion of other containers. This implementation is really a shell around either the <userinput>simple</userinput> or <userinput>sql</userinput> journal implementations but running in a remote server.  By this means, it is possible to move the journal operation to a central location.  The configuration for the ejb implementation is stored in the configuration file: </para>
! 		</section>
! 	</section>
  			
! 	<section>
! 		<title>Journal Tool</title>
! 		<para>The <userinput>journal tool</userinput> allows access to the journal from the command line.  This enables complex queries to be applied against the journal. There are four separate types of queries:</para>
! 		<orderedlist>
! 			<listitem>
! 				<userinput>-L or --list</userinput>:  List all the tickets and the steps in the journal.  This can produce lots of output.  This can be limited by the flag -n (no more than this many lines of output).  It is also possible to start from another index other than zero using the -i flag</listitem>
! 			<listitem>
! 				<userinput>-T ticket-number or --tickets ticket-number</userinput>:  List all the ticketsteps for the supplied ticket.</listitem>
! 			<listitem>
! 				<userinput>-D ticket-number.step or --document ticket-number.step</userinput>:  Displays the contents of the document stored at the ticket/step to the screen</listitem>
! 			<listitem>
! 				<userinput>-R ticket-number.step or --replay ticket-number.step</userinput>:  This will reintroduce the document at the the point it was stored or later.</listitem>
! 		</orderedlist>
! 		<para>There are a number of options which can change the display of the data from the tool - use the -h command line to get all the options for this tool</para>
! 	</section>
! </chapter>
  

Index: chapter5.xml
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter5.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** chapter5.xml	13 Aug 2003 11:48:24 -0000	1.2
--- chapter5.xml	30 Mar 2004 19:15:42 -0000	1.3
***************
*** 1,23 ****
  <?xml version="1.0" encoding="ISO-8859-1"?>
! 	<chapter>
! 		<title>Scanner</title>
! 		<section>
! 			<title>Introduction</title>
! 			<para>The scanner is a tool that scans for messages from a variety of sources and when a message is found, it is fed into the pipeline.  The scanner is an automation tool in that a system can be built up using scanners and pipelines.  This is an alternative to the <userinput>process</userinput> script which feeds a simple document into the pipeline when run.  The scanner is currently capable of scanning a directory in a filesystem, a mailbox on a mail-server and a JMS queue.  The period of scan and the pipeline to feed as well as other specific configuration options are all set in the <userinput>config/scanner/config/</userinput> file.  There may be one or many scanning threads active, each configured differently. For example, one scanner thread could be polling a mailbox once every 60secs while another scanning a directory every 10seconds.  The scanner is also capable of scanning based on a schedule specified in the same way that CRON is on UNIX systems.</para>
! 		</section>
! 		<section>
! 			<title>Starting scanner</title>
! 			<para>Scanner tool is started by <userinput>babeldoc scanner</userinput> command. This command will use configuration from <userinput>scanner/config</userinput>. If you want to use configuration from some different you can use <userinput>-s another_configuration</userinput> switch to specify configuration that should be used instead of default one.
  			</para>
! 		</section>	
! 		<section>
! 			<title>Configuration</title>
! 			<para>There are two kinds of configuration options available:</para>
! 			<orderedlist>
! 				<listitem><userinput>general</userinput>:  these options are global and apply to all types of scanners.</listitem>
! 				<listitem><userinput>specific</userinput>:  Options for a certain kind of scanner.  For example the configuration: 'host' is only pertinent to the email scanner.</listitem>
! 			</orderedlist>
! 			<para>Each of the options are laid out as: Global Options and  Scanner types.</para>
! 		</section>
  
  		&scanners;
--- 1,26 ----
  <?xml version="1.0" encoding="ISO-8859-1"?>
! <chapter>
! 	<title>Scanner</title>
! 	<section>
! 		<title>Introduction</title>
! 		<para>The scanner is a tool that scans for messages from a variety of sources and when a message is found, it is fed into the pipeline.  The scanner is an automation tool, in that a system can be built up using scanners and pipelines.  This is an alternative to the <userinput>process</userinput> script which feeds a single document into the pipeline when run.  The scanner is currently capable of scanning a directory in a filesystem, a mailbox on a mail-server, an FTP servcer, a web server, a database via a SQL query, external application output and a JMS queue.  The period of scan and the pipeline to feed, as well as other specific configuration options are all set in the <userinput>config/scanner/config.properties</userinput>userinput> file.  There may be one or many scanning threads active, each configured differently. For example, one scanner thread could be polling a mailbox once every 60 secs while another is scanning a directory every 10 seconds.  The scanner is also capable of scanning based on a schedule specified in the same way that CRON is on UNIX systems.</para>
! 		<para>General attributes available are <userinput>file_name</userinput>, <userinput>scan_path</userinput> and <userinput>scan_date</userinput>.</para>
! 			</section>
! 			<section>
! 				<title>Starting scanner</title>
! 				<para>The scanner tool is started by running the command <userinput>babeldoc scanner</userinput>. This command will use configuration from <userinput>config/scanner/config.properties</userinput>. If you want to use configuration from a different file you can use <userinput>-s another_configuration</userinput> switch to specify the configuration that should be used instead of default one.
  			</para>
! 			</section>
! 			<section>
! 				<title>Configuration</title>
! 				<para>There are two kinds of configuration options available:</para>
! 				<orderedlist>
! 					<listitem>
! 						<userinput>general</userinput>:  these options are global and apply to all types of scanners.</listitem>
! 					<listitem>
! 						<userinput>specific</userinput>:  Options for a certain kind of scanner.  For example the configuration: 'host' is only pertinent to the email scanner.</listitem>
! 				</orderedlist>
! 				<para>The options for each scanner type are laid out below.</para>
! 			</section>
  
  		&scanners;

[Babeldoc-devel] babeldoc/modules/core/src/com/babeldoc/core/pipeline/stage DomifyPipelineStage.java,1.16,1.17 ExternalApplicationPipelineStage.java,1.5,1.6 SmtpWriterPipelineStage.java,1.12,1.13

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/pipeline/stage
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/core/src/com/babeldoc/core/pipeline/stage

Modified Files:
	DomifyPipelineStage.java ExternalApplicationPipelineStage.java 
	SmtpWriterPipelineStage.java 
Log Message:
Minor documentation updates

Index: DomifyPipelineStage.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/pipeline/stage/DomifyPipelineStage.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** DomifyPipelineStage.java	18 Oct 2003 04:55:25 -0000	1.16
--- DomifyPipelineStage.java	30 Mar 2004 19:15:40 -0000	1.17
***************
*** 182,185 ****
--- 182,188 ----
                IConfigOptionType.FILENAME,
                I18n.get("core.pipeline.stage.domify.schema"));
+           ConfigOption validOption = new ConfigOption(DomifyPipelineStage.VALID_XML,
+               IConfigOptionType.STRING,
+               I18n.get("core.pipeline.stage.domify.valid"));
  
            schemaOption.getDependentOn().add(validateOption);

Index: ExternalApplicationPipelineStage.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/pipeline/stage/ExternalApplicationPipelineStage.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** ExternalApplicationPipelineStage.java	14 Aug 2003 01:33:23 -0000	1.5
--- ExternalApplicationPipelineStage.java	30 Mar 2004 19:15:40 -0000	1.6
***************
*** 127,137 ****
            options.add(new ConfigOption(APPLICATION, IConfigOptionType.FILENAME,
                null, true,
!               "core.pipeline.stage.externalapplication.opt.application"));
            options.add(new ConfigOption(PIPE_OUT_DOCUMENT,
                IConfigOptionType.BOOLEAN, null, false,
!               "core.pipeline.stage.externalapplication.opt.pipeout"));
            options.add(new ConfigOption(PIPE_IN_RESPONSE,
                IConfigOptionType.BOOLEAN, null, false,
!               "core.pipeline.stage.externalapplication.opt.pipein"));
  
            return options;
--- 127,137 ----
            options.add(new ConfigOption(APPLICATION, IConfigOptionType.FILENAME,
                null, true,
!               I18n.get("core.pipeline.stage.externalapplication.opt.application")));
            options.add(new ConfigOption(PIPE_OUT_DOCUMENT,
                IConfigOptionType.BOOLEAN, null, false,
!               I18n.get("core.pipeline.stage.externalapplication.opt.pipeout")));
            options.add(new ConfigOption(PIPE_IN_RESPONSE,
                IConfigOptionType.BOOLEAN, null, false,
!               I18n.get("core.pipeline.stage.externalapplication.opt.pipein")));
  
            return options;

Index: SmtpWriterPipelineStage.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/pipeline/stage/SmtpWriterPipelineStage.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** SmtpWriterPipelineStage.java	16 Sep 2003 05:19:01 -0000	1.12
--- SmtpWriterPipelineStage.java	30 Mar 2004 19:15:40 -0000	1.13
***************
*** 151,155 ****
                new ValueListConfigOptionType(
                  new String[] { HTML_FORMAT, PLAIN_FORMAT }), PLAIN_FORMAT,
!               false, I18n.get("core.SmtpWriterPipelineStage.format.plain")));
  
            return options;
--- 151,155 ----
                new ValueListConfigOptionType(
                  new String[] { HTML_FORMAT, PLAIN_FORMAT }), PLAIN_FORMAT,
!               false, I18n.get("100151")));
  
            return options;

[Babeldoc-devel] babeldoc/modules/sql/config/i18n messages.properties,1.8,1.9

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/sql/config/i18n
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/sql/config/i18n

Modified Files:
	messages.properties 
Log Message:
Minor documentation updates

Index: messages.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/config/i18n/messages.properties,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** messages.properties	15 Aug 2003 00:25:30 -0000	1.8
--- messages.properties	30 Mar 2004 19:15:41 -0000	1.9
***************
*** 35,36 ****
--- 35,39 ----
  sql.201=Option resourceName is not optional!
  sql.202=Either sqlScript or attributeSql must be defined!
+ 
+ sql.900=Creates an XML file from a SQL query
+ sql.901=Name of the resource that contains Database Connection

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner ScannerWorkerInfo.java,1.12,1.13

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/scanner/src/com/babeldoc/scanner

Modified Files:
	ScannerWorkerInfo.java 
Log Message:
Minor documentation updates

Index: ScannerWorkerInfo.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/ScannerWorkerInfo.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** ScannerWorkerInfo.java	12 Sep 2003 01:09:16 -0000	1.12
--- ScannerWorkerInfo.java	30 Mar 2004 19:15:41 -0000	1.13
***************
*** 123,127 ****
      //adding general scanner options
      ConfigOption typeOption = new ConfigOption(SCANNER_TYPE,
!         new ServiceTypeConfigOptionType(SCANNER), null, true, "Type of scanner");
      typeOption.setMutable(false);  //cannot change type
      general.add(typeOption);
--- 123,127 ----
      //adding general scanner options
      ConfigOption typeOption = new ConfigOption(SCANNER_TYPE,
!         new ServiceTypeConfigOptionType(SCANNER), null, true, "General: Type of scanner (" + this.getName() +")");
      typeOption.setMutable(false);  //cannot change type
      general.add(typeOption);
***************
*** 129,137 ****
      ConfigOption periodOption = new ConfigOption(SCANNER_PERIOD,
          IConfigOptionType.INTEGER, null, false,
!         "Interval between two scanning operation in milliseconds");
  
      ConfigOption scheduleOption = new ConfigOption(SCANNER_CRON_SCHEDULE,
          IConfigOptionType.STRING, null, false,
!         "Cron-like entry for speciying scanner schedule");
  
      //these two options are exclusive
--- 129,137 ----
      ConfigOption periodOption = new ConfigOption(SCANNER_PERIOD,
          IConfigOptionType.INTEGER, null, false,
!         "General: Interval between two scanning operation in milliseconds (Only one of cronSchedule or period can be used)");
  
      ConfigOption scheduleOption = new ConfigOption(SCANNER_CRON_SCHEDULE,
          IConfigOptionType.STRING, null, false,
!         "General: Cron-like entry for speciying scanner schedule (Only one of cronSchedule or period can be used)");
  
      //these two options are exclusive
***************
*** 143,160 ****
      general.add(new ConfigOption(SCANNER_PIPELINE,
          IConfigOptionType.STRING, null, true,
!         "Name of pipeline where scanned document will be processed"));
      general.add(new ConfigOption(IGNORED,
          IConfigOptionType.BOOLEAN, "false", false,
!         "true if scanner should not scan false otherwise. Default is false"));
      general.add(new ConfigOption(JOURNAL,
          IConfigOptionType.BOOLEAN, "true", false,
!         "Should the scanner use the journal. Default is true"));
      general.add(new ConfigOption(COUNTDOWN,
          IConfigOptionType.INTEGER, "-1", false,
!         "The number of times this countdown must run."));
  
      general.add(new ConfigOption(BINARY,
          IConfigOptionType.BOOLEAN, "false", false,
!         "The documents from this stage must be submitted as binary pipeline documents"));
  
      return general;
--- 143,163 ----
      general.add(new ConfigOption(SCANNER_PIPELINE,
          IConfigOptionType.STRING, null, true,
!         "General: Name of pipeline where scanned document will be processed"));
!     general.add(new ConfigOption(CONTENT_TYPE,
!         IConfigOptionType.STRING, null, false,
!         "General: Content type of document to be scanned"));
      general.add(new ConfigOption(IGNORED,
          IConfigOptionType.BOOLEAN, "false", false,
!         "General: true if scanner should not scan false otherwise. Default is false"));
      general.add(new ConfigOption(JOURNAL,
          IConfigOptionType.BOOLEAN, "true", false,
!         "General: Should the scanner use the journal. Default is true"));
      general.add(new ConfigOption(COUNTDOWN,
          IConfigOptionType.INTEGER, "-1", false,
!         "General: The number of times this countdown must run."));
  
      general.add(new ConfigOption(BINARY,
          IConfigOptionType.BOOLEAN, "false", false,
!         "General: The documents from this stage must be submitted as binary pipeline documents"));
  
      return general;

[Babeldoc-devel] babeldoc/modules/scanner/config/i18n messages.properties,1.19,1.20

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/config/i18n
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/scanner/config/i18n

Modified Files:
	messages.properties 
Log Message:
Minor documentation updates

Index: messages.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/config/i18n/messages.properties,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** messages.properties	25 Dec 2003 14:15:50 -0000	1.19
--- messages.properties	30 Mar 2004 19:15:41 -0000	1.20
***************
*** 85,92 ****
  scanner.MailboxScanner.error.gettingMessage=Error getting message from mail
  
! scanner.MailboxScannerInfo.description=The MailboxScanner is used for scanning mail servers for e-mail messages. Document can be scanned from e-mail body or from attachments.  This is very useful for integration with email enabled clients.  An example would be purchase orders emailed to a mailbox scanned by Babeldoc. The From, To and Subject filters are regular expression filters. Enter regular expressions which, if matched, cause the matching email to be processed. For example, if you wanted to match a recipient address of fir...@se..., you would enter "first\\.last@server\\.com" in the toFilter.  The expressions are effectively OR'd together, because if any one of the filters gets a match, the e-mail message will be processed.  The toFilter is tested against all addresses in the TO field.  It is <emphasis>NOT</emphasis> tested against the CC or BCC fields.
  scanner.MailboxScannerInfo.option.host=Mail server host name or address
! scanner.MailboxScannerInfo.option.protocol=Protocol which is used for connecting to mail server (pop3, imap...)
! scanner.MailboxScannerInfo.option.folder=Name of folder on mail server. (for example INBOX)
  scanner.MailboxScannerInfo.option.username=Username for logging to mail server
  scanner.MailboxScannerInfo.option.password=Password for logging to mail server
--- 85,92 ----
  scanner.MailboxScanner.error.gettingMessage=Error getting message from mail
  
! scanner.MailboxScannerInfo.description=The MailboxScanner is used for scanning mail servers for e-mail messages. Document can be scanned from e-mail body or from attachments.  This is very useful for integration with email enabled clients.  An example would be purchase orders emailed to a mailbox scanned by Babeldoc. The From, To and Subject filters are regular expression filters. Enter regular expressions which, if matched, cause the matching email to be processed. For example, if you wanted to match a recipient address of fir...@se..., you would enter "first\\.last@server\\.com" in the toFilter.  The expressions are effectively OR'd together, because if any one of the filters gets a match, the e-mail message will be processed.  The toFilter is tested against all addresses in the TO field.  It is <emphasis>NOT</emphasis> tested against the CC or BCC fields. Accessible attributes are subject, from and replyTo.
  scanner.MailboxScannerInfo.option.host=Mail server host name or address
! scanner.MailboxScannerInfo.option.protocol=Protocol which is used for connecting to mail server (pop3, imap...). Default is pop3
! scanner.MailboxScannerInfo.option.folder=Name of folder on mail server. Default is INBOX
  scanner.MailboxScannerInfo.option.username=Username for logging to mail server
  scanner.MailboxScannerInfo.option.password=Password for logging to mail server
***************
*** 108,112 ****
  scanner.nullScanner.desc=Null Scanner feeds null documents everytime the scanner runs.  This is useful for scheduling.
  
! scanner.SqlScanner.option.updateStatement=Sql Statement that is executed after selecting rows and creating documents. It is used for marging rows as processes so they don't need to be processed later.
  
  
--- 108,112 ----
  scanner.nullScanner.desc=Null Scanner feeds null documents everytime the scanner runs.  This is useful for scheduling.
  
! scanner.SqlScanner.option.updateStatement=SQL Statement that is executed after selecting rows and creating documents. It is used for marking rows as processed so they don't need to be processed later.
  
  
***************
*** 171,179 ****
  scanner.062=Name of the connection resource
  scanner.063=SQL statement that is executed to get documents
! scanner.064=Type of document that is returned
! scanner.065=Character that is used for separating fields in CSV file
! scanner.066=Character that is used for separating row sin CSV files
! scanner.067=Tag that is used in XML document for heading
! scanner.068=Tag that is used in XML document for each row
  scanner.069=No scanner threads provided
  scanner.070=Stopping threads: 
--- 171,179 ----
  scanner.062=Name of the connection resource
  scanner.063=SQL statement that is executed to get documents
! scanner.064=Type of document that is returned. Choices are simple, xml or csv
! scanner.065=Character that is used for separating fields in CSV file. Default is  comma
! scanner.066=Character that is used for separating rows in CSV files. Default is \\n
! scanner.067=Tag that is used in XML document for heading. Default is document
! scanner.068=Tag that is used in XML document for each row. Default is row.
  scanner.069=No scanner threads provided
  scanner.070=Stopping threads: 

[Babeldoc-devel] babeldoc/modules/core/config/i18n messages.properties,1.24,1.25 messages_de.properties,1.1.1.1,1.2 messages_es.properties,1.1.1.1,1.2 messages_fr.properties,1.1.1.1,1.2 messages_it.properties,1.1.1.1,1.2 messages_sr.properties,1.1.1.1,1.2

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/core/config/i18n
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/core/config/i18n

Modified Files:
	messages.properties messages_de.properties 
	messages_es.properties messages_fr.properties 
	messages_it.properties messages_sr.properties 
Log Message:
Minor documentation updates

Index: messages.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages.properties,v
retrieving revision 1.24
retrieving revision 1.25
diff -C2 -d -r1.24 -r1.25
*** messages.properties	29 Aug 2003 21:25:03 -0000	1.24
--- messages.properties	30 Mar 2004 19:15:40 -0000	1.25
***************
*** 317,320 ****
--- 317,321 ----
  100149=Cannot change document!
  100150=Error setting attachments
+ 100151=The mail format - text/plain or text/html - Deafult is text/plain
  100170=Send this document to a tcp/ip socket
  100171=The name of the host
***************
*** 334,338 ****
  100251=The name of the XSL to convert the document
  100260=Compress the document
! 100261=Compression type
  100262=Error during compression
  100263=Invalid compression type: {0}
--- 335,339 ----
  100251=The name of the XSL to convert the document
  100260=Compress the document
! 100261=Compression type (zip or gzip)
  100262=Error during compression
  100263=Invalid compression type: {0}
***************
*** 340,344 ****
  100271=Error during decompression
  100289=Execute a user supplied script.  This pipeline stage enables pipeline developers to create and manipulate documents in novel and unforeseen ways.
! 100290=Scripting language
  100291=Script to be executed
  100292=Script processing failed
--- 341,345 ----
  100271=Error during decompression
  100289=Execute a user supplied script.  This pipeline stage enables pipeline developers to create and manipulate documents in novel and unforeseen ways.
! 100290=Scripting language - supported as per Apache BSF - Default is javascript
  100291=Script to be executed
  100292=Script processing failed
***************
*** 368,373 ****
  
  core.pipeline.stage.domify.desc=Domify the document and save as an attribute
! core.pipeline.stage.domify.validate=Validate the XML
  core.pipeline.stage.domify.schema=The schema file to validate against
  
  core.pipeline.stage.callstage.desc=Allows a pipeline to call another pipelinestage.  This pipeline stage is very useful in that it allows for modular pipeline configurations.  The result of the called pipeline is either used instead of the current pipeline document or is discarded depending on the setting of the discardResults configuration
--- 369,375 ----
  
  core.pipeline.stage.domify.desc=Domify the document and save as an attribute
! core.pipeline.stage.domify.validate=Validate the XML. Default is false.
  core.pipeline.stage.domify.schema=The schema file to validate against
+ core.pipeline.stage.domify.valid=The parameter to store result of validation (true/false)
  
  core.pipeline.stage.callstage.desc=Allows a pipeline to call another pipelinestage.  This pipeline stage is very useful in that it allows for modular pipeline configurations.  The result of the called pipeline is either used instead of the current pipeline document or is discarded depending on the setting of the discardResults configuration
***************
*** 385,390 ****
  core.pipeline.stage.externalapplication.description=This pipeline stage allows for external applications to be run.  Optionally the pipeline document is piped to the application.
  core.pipeline.stage.externalapplication.opt.application=Full path to the application to run
! core.pipeline.stage.externalapplication.opt.pipeout=Pipe the current document to the script - the script must fully accept the stardard input otherwise an exception is thrown.
! core.pipeline.stage.externalapplication.opt.pipein=Pipe the response into the document in the attribute ExternalApplicationResponse
  
  core.pipeline.stage.journalupdate.description=This pipeline stage writes a message into the journal that can be viewed with the journal tool (babeldoc journal).  Please note that journal entries should be one line long and contain no quotes, commas, or newlines.  If these characters are detected, they will be translated into their HTML equivalents to prevent 'bad things' from happening to the journal tool.  However, the output from the journal tool will most likely not be what you are expecting.
--- 387,392 ----
  core.pipeline.stage.externalapplication.description=This pipeline stage allows for external applications to be run.  Optionally the pipeline document is piped to the application.
  core.pipeline.stage.externalapplication.opt.application=Full path to the application to run
! core.pipeline.stage.externalapplication.opt.pipeout=Pipe the current document to the script - the script must fully accept the stardard input otherwise an exception is thrown. Boolean default is false.
! core.pipeline.stage.externalapplication.opt.pipein=Pipe the response into the document in the attribute ExternalApplicationResponse. Boolean default is false.
  
  core.pipeline.stage.journalupdate.description=This pipeline stage writes a message into the journal that can be viewed with the journal tool (babeldoc journal).  Please note that journal entries should be one line long and contain no quotes, commas, or newlines.  If these characters are detected, they will be translated into their HTML equivalents to prevent 'bad things' from happening to the journal tool.  However, the output from the journal tool will most likely not be what you are expecting.
***************
*** 417,423 ****
  
  core.pipeline.processor.async.desc=Asynchronously process the pipeline documents
! core.pipeline.processor.async.option.maxThreads=The maximum number of threads that this processor can spawn.  The pipeline stage may override this but can never exceed this value.
  
  core.pipeline.processor.threadpool.desc=Asynchronously process the pipeline documents using a threadpool.  This is probably the most useful in a multithreaded environment.
! core.pipeline.processor.threadpool.option.poolSize=The number of threads in the thread pool.  This sets the maximum number of documents to process at one time.
! core.pipeline.processor.threadpool.option.keepAlive=The number of milliseconds that an idle thread in the threadpool will remain alive before being reclaimed.
\ No newline at end of file
--- 419,425 ----
  
  core.pipeline.processor.async.desc=Asynchronously process the pipeline documents
! core.pipeline.processor.async.option.maxThreads=The maximum number of threads that this processor can spawn.  The pipeline stage may override this but can never exceed this value. Default is 5.
  
  core.pipeline.processor.threadpool.desc=Asynchronously process the pipeline documents using a threadpool.  This is probably the most useful in a multithreaded environment.
! core.pipeline.processor.threadpool.option.poolSize=The number of threads in the thread pool.  This sets the maximum number of documents to process at one time. Default is 5.
! core.pipeline.processor.threadpool.option.keepAlive=The number of milliseconds that an idle thread in the threadpool will remain alive before being reclaimed. Default is 15000.

Index: messages_fr.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages_fr.properties,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** messages_fr.properties	24 Feb 2003 22:42:14 -0000	1.1.1.1
--- messages_fr.properties	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 221,225 ****
  100263=Type inadmissible de compression
  100262=Erreur pendant la compression
! 100261=Type de compression
  100260=Comprimez le document
  007003=Outil de Commandline pour charger des donn\u00C3\u00A9es de configuration dans les tables de SQL
--- 221,225 ----
  100263=Type inadmissible de compression
  100262=Erreur pendant la compression
! 100261=Type de compression (zip/gzip)
  100260=Comprimez le document
  007003=Outil de Commandline pour charger des donn\u00C3\u00A9es de configuration dans les tables de SQL

Index: messages_it.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages_it.properties,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** messages_it.properties	24 Feb 2003 22:42:14 -0000	1.1.1.1
--- messages_it.properties	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 221,225 ****
  100263=Tipo non valido di compressione
  100262=Errore durante la compressione
! 100261=Tipo di compressione
  100260=Comprima il documento
  007003=Attrezzo di Commandline per caricare i dati di configurazione nelle tabelle di sql
--- 221,225 ----
  100263=Tipo non valido di compressione
  100262=Errore durante la compressione
! 100261=Tipo di compressione (zip/gzip)
  100260=Comprima il documento
  007003=Attrezzo di Commandline per caricare i dati di configurazione nelle tabelle di sql

Index: messages_de.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages_de.properties,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** messages_de.properties	24 Feb 2003 22:42:13 -0000	1.1.1.1
--- messages_de.properties	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 221,225 ****
  100263=Unzul\u00C3\u00A4ssige Kompression Art
  100262=St\u00C3\u00B6rung w\u00C3\u00A4hrend der Kompression
! 100261=Kompression Art
  100260=Dr\u00C3\u00BCcken Sie das Dokument zusammen
  007003=Commandline Werkzeug, zum von von Konfiguration Daten in die sql Tabellen zu laden
--- 221,225 ----
  100263=Unzul\u00C3\u00A4ssige Kompression Art
  100262=St\u00C3\u00B6rung w\u00C3\u00A4hrend der Kompression
! 100261=Kompression Art (zip/gzip)
  100260=Dr\u00C3\u00BCcken Sie das Dokument zusammen
  007003=Commandline Werkzeug, zum von von Konfiguration Daten in die sql Tabellen zu laden

Index: messages_es.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages_es.properties,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** messages_es.properties	24 Feb 2003 22:42:13 -0000	1.1.1.1
--- messages_es.properties	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 221,225 ****
  100263=Tipo inv\u00C3\u00A1lido de la compresi\u00C3\u00B3n
  100262=Error durante la compresi\u00C3\u00B3n
! 100261=Tipo de la compresi\u00C3\u00B3n
  100260=Comprima el documento
  007003=Herramienta de Commandline para cargar datos de la configuraci\u00C3\u00B3n en las tablas del sql
--- 221,225 ----
  100263=Tipo inv\u00C3\u00A1lido de la compresi\u00C3\u00B3n
  100262=Error durante la compresi\u00C3\u00B3n
! 100261=Tipo de la compresi\u00C3\u00B3n (zip/gzip)
  100260=Comprima el documento
  007003=Herramienta de Commandline para cargar datos de la configuraci\u00C3\u00B3n en las tablas del sql

Index: messages_sr.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/i18n/messages_sr.properties,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** messages_sr.properties	24 Feb 2003 22:42:15 -0000	1.1.1.1
--- messages_sr.properties	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 480,484 ****
  100251=The name of the XSL to convert the document
  100260=Compress the document
! 100261=Compression type
  100262=Error during compression
  100263=Invalid compression type
--- 480,484 ----
  100251=The name of the XSL to convert the document
  100260=Compress the document
! 100261=Compression type (zip/gzip)
  100262=Error during compression
  100263=Invalid compression type

[Babeldoc-devel] babeldoc/modules/core/config/pipeline/documentation stage2docbook.xsl,1.1,1.2

[Martin L. <mar...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/core/config/pipeline/documentation
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4646/modules/core/config/pipeline/documentation

Modified Files:
	stage2docbook.xsl 
Log Message:
Minor documentation updates

Index: stage2docbook.xsl
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/config/pipeline/documentation/stage2docbook.xsl,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** stage2docbook.xsl	6 Aug 2003 00:18:07 -0000	1.1
--- stage2docbook.xsl	30 Mar 2004 19:15:40 -0000	1.2
***************
*** 4,8 ****
  	<xsl:template match="/stage-defns">
  		<section>
! 			<xsl:apply-templates/>
  		</section>
  	</xsl:template>
--- 4,8 ----
  	<xsl:template match="/stage-defns">
  		<section>
! 			<xsl:apply-templates><xsl:sort select="stage-type"/></xsl:apply-templates>
  		</section>
  	</xsl:template>

Re: [Babeldoc-devel] Rationalising LightConfig and SqlConfig

[Dejan K. <dej...@nb...>]

Mike,
I see no reason for not doing this, so go for it!
Dejan

----- Original Message ----- 
From: "Michael Ansley" <mic...@ze...>
To: <bab...@li...>
Sent: Monday, March 29, 2004 4:18 AM
Subject: [Babeldoc-devel] Rationalising LightConfig and SqlConfig

[Babeldoc-devel] Re: Rationalising LightConfig and SqlConfig

[Sherman W. <sg...@ix...>]

Mike,

Your proposal makes perfect sense to me.


Sherman

[Babeldoc-devel] Commits

[Michael A. <mic...@ze...>]

Hi, all,

Sorry about the excess commits here.  My CVS behaved oddly, I think
caused by using different repositories for read and write (eclipse
allows this, but there are clearly issues with it).  Anyway, the commits
seem to have gone through OK.

Cheers...


MikeA

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner ScannerWorker.java,1.33,1.34

[Michael A. <mic...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22040/modules/scanner/src/com/babeldoc/scanner

Modified Files:
	ScannerWorker.java 
Log Message:
Corrected some status code which was inconsistent, picked up while trying to make the JMX scanner work.

Index: ScannerWorker.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/ScannerWorker.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -C2 -d -r1.33 -r1.34
*** ScannerWorker.java	29 Mar 2004 20:49:13 -0000	1.33
--- ScannerWorker.java	29 Mar 2004 21:10:16 -0000	1.34
***************
*** 125,130 ****
    protected ScannerWorker(ScannerWorkerInfo info) {
      this.info = info;
-     setValueObject(new ScannerWorkerVO());
      setStatus(ScannerWorkerStatus.STOPPED);
    }
  
--- 125,131 ----
    protected ScannerWorker(ScannerWorkerInfo info) {
      this.info = info;
      setStatus(ScannerWorkerStatus.STOPPED);
+     setValueObject(new ScannerWorkerVO());
+     getValueObject().setDateStarted(System.currentTimeMillis());
    }
  
***************
*** 495,499 ****
      this.setLastStatusChangeTime(System.currentTimeMillis());
      this.status = newStatus;
-     this.valueObject.setStatus(newStatus);
    }
  
--- 496,499 ----
***************
*** 569,573 ****
    protected void setTimeStarted(long timeStarted) {
      this.timeStarted = timeStarted;
-     this.valueObject.setDateStarted(timeStarted);
    }
  
--- 569,572 ----

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner Scanner.java,1.32,1.33

[Michael A. <mic...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21904/modules/scanner/src/com/babeldoc/scanner

Modified Files:
	Scanner.java 
Log Message:
Corrected some status code which was inconsistent, picked up while trying to make the JMX scanner work.

Index: Scanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/Scanner.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -C2 -d -r1.32 -r1.33
*** Scanner.java	29 Mar 2004 20:49:13 -0000	1.32
--- Scanner.java	29 Mar 2004 21:09:48 -0000	1.33
***************
*** 343,353 ****
  	}
  	
! 	public void refreshConfig() throws ScannerException {
  		log.logInfo("Refreshing configuration");
  		log.logInfo("Status: " + I18n.get(stateDescriptions[status]));
  		if (status == Scanner.STATE_STOPPED) {
  			factory.flushConfig();
- 		} else {
- 			throw new com.babeldoc.scanner.ScannerException("Invalid state: " + I18n.get(stateDescriptions[status]));
  		}
  	}
--- 343,351 ----
  	}
  	
! 	public void refreshConfig() {
  		log.logInfo("Refreshing configuration");
  		log.logInfo("Status: " + I18n.get(stateDescriptions[status]));
  		if (status == Scanner.STATE_STOPPED) {
  			factory.flushConfig();
  		}
  	}

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner/jmx ScannerServiceMBean.java,1.4,1.5 ScannerService.java,1.6,1.7

[Michael A. <mic...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/jmx
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16790/modules/scanner/src/com/babeldoc/scanner/jmx

Modified Files:
	ScannerServiceMBean.java ScannerService.java 
Log Message:
General improvements in the JMX ScannerService, as well as including pipelines in the refresh.

Index: ScannerService.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/jmx/ScannerService.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** ScannerService.java	4 Dec 2003 00:44:42 -0000	1.6
--- ScannerService.java	29 Mar 2004 20:49:14 -0000	1.7
***************
*** 67,71 ****
--- 67,74 ----
  
  import com.babeldoc.core.LogService;
+ import com.babeldoc.core.pipeline.IPipelineFactory;
+ import com.babeldoc.core.pipeline.PipelineFactoryFactory;
  import com.babeldoc.scanner.Scanner;
+ import com.babeldoc.scanner.ScannerWorkerVO;
  
  import java.net.URL;
***************
*** 85,92 ****
  				LogService.getInstance(ScannerService.class.getName());
  	public static final int STATE_STOPPED = 0;
! 	public static final int STATE_STARTED = 1; 
  	public static final String stateDescriptions[] = new String[] {"scanner.002", "scanner.001"};
  	int state = 0;
  	Scanner scanner = null;
  
  	// Property
--- 88,96 ----
  				LogService.getInstance(ScannerService.class.getName());
  	public static final int STATE_STOPPED = 0;
! 	public static final int STATE_STARTED = 1;
  	public static final String stateDescriptions[] = new String[] {"scanner.002", "scanner.001"};
  	int state = 0;
  	Scanner scanner = null;
+ 	boolean passedFirstStart = false;
  
  	// Property
***************
*** 137,141 ****
     */
    public String getBabeldocHome() throws Exception {
! 		String home = System.getProperty("babeldoc.home"); 
  		getLog().logDebug("getBabeldocHome: " + home);
  		return (home);
--- 141,145 ----
     */
    public String getBabeldocHome() throws Exception {
! 		String home = System.getProperty("babeldoc.home");
  		getLog().logDebug("getBabeldocHome: " + home);
  		return (home);
***************
*** 147,153 ****
  		getLog().logDebug("setBabeldocUserHome: " + home);
    }
!   
    public String getBabeldocUserHome() throws Exception {
! 		String home = System.getProperty("babeldoc.user"); 
  		getLog().logDebug("getBabeldocUserHome: " + home);
  		return (home);
--- 151,157 ----
  		getLog().logDebug("setBabeldocUserHome: " + home);
    }
! 
    public String getBabeldocUserHome() throws Exception {
! 		String home = System.getProperty("babeldoc.user");
  		getLog().logDebug("getBabeldocUserHome: " + home);
  		return (home);
***************
*** 163,168 ****
     */
    public String getStateString() throws Exception {
! 		getLog().logDebug("getStateString: " + com.babeldoc.core.I18n.get(stateDescriptions[state]));
! 		return (com.babeldoc.core.I18n.get(stateDescriptions[state]));
    }
    
--- 167,177 ----
     */
    public String getStateString() throws Exception {
!       if (passedFirstStart) {
! 				getLog().logDebug("getStateString: " + com.babeldoc.core.I18n.get(stateDescriptions[state]));
! 				return (com.babeldoc.core.I18n.get(stateDescriptions[state]));
!       } else {
! 				getLog().logDebug("getStateString: " + stateDescriptions[state]);
!       	return (stateDescriptions[state]);
!   		}
    }
    
***************
*** 173,177 ****
  	 */
  	public void start() throws Exception {
!         
  		/* This section determines what the usual babeldoc.home will be for a standard
  		 *  JBoss system.  This will be ignored by other J2EE application containers,
--- 182,188 ----
  	 */
  	public void start() throws Exception {
! 	    
! 	    passedFirstStart = true;
! 
  		/* This section determines what the usual babeldoc.home will be for a standard
  		 *  JBoss system.  This will be ignored by other J2EE application containers,
***************
*** 182,192 ****
  			// This assumes that jboss.server.conf.url will always be a file://
  			// Not sure if babeldoc can handle a non-file home directory, e.g. ftp://
  			URL urlHome = new URL(babeldocHome);
  			setBabeldocHome(urlHome.getFile());
  			setBabeldocUserHome(urlHome.getFile());
  		}
! 		
  		scanner = new Scanner(new String[] {  });
! 		
  		//TODO: Double check this since it maybe won't work... Did anyone used this anyway???
  		// MCA: I checked, it works.
--- 193,204 ----
  			// This assumes that jboss.server.conf.url will always be a file://
  			// Not sure if babeldoc can handle a non-file home directory, e.g. ftp://
+ 			// But then, I'm not sure if JBoss can handle a non-file conf directory
  			URL urlHome = new URL(babeldocHome);
  			setBabeldocHome(urlHome.getFile());
  			setBabeldocUserHome(urlHome.getFile());
  		}
! 
  		scanner = new Scanner(new String[] {  });
! 
  		//TODO: Double check this since it maybe won't work... Did anyone used this anyway???
  		// MCA: I checked, it works.
***************
*** 207,212 ****
  		}
  		if (state != ScannerService.STATE_STOPPED) {
! 				scanner.stop();
! 				scanner.finishUp();
  		}
  	state = ScannerService.STATE_STOPPED;
--- 219,224 ----
  		}
  		if (state != ScannerService.STATE_STOPPED) {
! 			scanner.stop();
! 			scanner.finishUp();
  		}
  	state = ScannerService.STATE_STOPPED;
***************
*** 222,232 ****
    }
    
!   public void refreshConfig() throws Exception {
!   	if (state == ScannerService.STATE_STOPPED) {
!   		getLog().logDebug("Refreshing scanner configuration");
!   		scanner.refreshConfig();
!   	} else {
!   		throw new Exception("Invalid state for operation");
!   	}
    }
! }
\ No newline at end of file
--- 234,261 ----
    }
    
!   public void refreshConfig() throws com.babeldoc.scanner.ScannerException {
!       if (passedFirstStart) {
! 				if (state == ScannerService.STATE_STOPPED) {
! 					getLog().logDebug("Refreshing scanner configuration");
! 					scanner.refreshConfig();
! 					IPipelineFactory pf = PipelineFactoryFactory.getPipelineFactory();
! 					pf.clearCache();
! 				} else {
! 					throw new com.babeldoc.scanner.ScannerException("Invalid state for operation");
! 				}
!       }
    }
!   
!   public String scannerStatus() {
!       String result = "";
!       if ((passedFirstStart) && (scanner != null)) {
!           for (int i=0; i < scanner.listWorkers().length; i++) {
!               ScannerWorkerVO s = scanner.listWorkers()[i];
!               String currentScannerStatus = "Name: " + s.getName();
!               currentScannerStatus += ", Status: " + s.getStatus();
!               result += currentScannerStatus;
!           }
!       }
!       return result;
!   }
! }

Index: ScannerServiceMBean.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/jmx/ScannerServiceMBean.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** ScannerServiceMBean.java	4 Dec 2003 00:44:42 -0000	1.4
--- ScannerServiceMBean.java	29 Mar 2004 20:49:14 -0000	1.5
***************
*** 122,124 ****
--- 122,132 ----
     */
    public void refreshConfig() throws Exception;
+   
+   /**
+    * TODO: DOCUMENT ME!
+    *
+    * @throws Exception DOCUMENT ME!
+    */
+   public String scannerStatus() throws Exception;
+ 
  }

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner Scanner.java,1.31,1.32 ScannerWorker.java,1.32,1.33

[Michael A. <mic...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16790/modules/scanner/src/com/babeldoc/scanner

Modified Files:
	Scanner.java ScannerWorker.java 
Log Message:
General improvements in the JMX ScannerService, as well as including pipelines in the refresh.

Index: Scanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/Scanner.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -C2 -d -r1.31 -r1.32
*** Scanner.java	4 Dec 2003 00:44:42 -0000	1.31
--- Scanner.java	29 Mar 2004 20:49:13 -0000	1.32
***************
*** 343,351 ****
  	}
  	
! 	public void refreshConfig() {
  		log.logInfo("Refreshing configuration");
  		log.logInfo("Status: " + I18n.get(stateDescriptions[status]));
  		if (status == Scanner.STATE_STOPPED) {
  			factory.flushConfig();
  		}
  	}
--- 343,353 ----
  	}
  	
! 	public void refreshConfig() throws ScannerException {
  		log.logInfo("Refreshing configuration");
  		log.logInfo("Status: " + I18n.get(stateDescriptions[status]));
  		if (status == Scanner.STATE_STOPPED) {
  			factory.flushConfig();
+ 		} else {
+ 			throw new com.babeldoc.scanner.ScannerException("Invalid state: " + I18n.get(stateDescriptions[status]));
  		}
  	}

Index: ScannerWorker.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/ScannerWorker.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -C2 -d -r1.32 -r1.33
*** ScannerWorker.java	14 Jan 2004 10:12:29 -0000	1.32
--- ScannerWorker.java	29 Mar 2004 20:49:13 -0000	1.33
***************
*** 125,131 ****
    protected ScannerWorker(ScannerWorkerInfo info) {
      this.info = info;
-     setStatus(ScannerWorkerStatus.STOPPED);
      setValueObject(new ScannerWorkerVO());
!     getValueObject().setDateStarted(System.currentTimeMillis());
    }
  
--- 125,130 ----
    protected ScannerWorker(ScannerWorkerInfo info) {
      this.info = info;
      setValueObject(new ScannerWorkerVO());
!     setStatus(ScannerWorkerStatus.STOPPED);
    }
  
***************
*** 496,499 ****
--- 495,499 ----
      this.setLastStatusChangeTime(System.currentTimeMillis());
      this.status = newStatus;
+     this.valueObject.setStatus(newStatus);
    }
  
***************
*** 569,572 ****
--- 569,573 ----
    protected void setTimeStarted(long timeStarted) {
      this.timeStarted = timeStarted;
+     this.valueObject.setDateStarted(timeStarted);
    }
  

[Babeldoc-devel] Rationalising LightConfig and SqlConfig

[Michael A. <mic...@ze...>]

Hi, all,

It seems to me that LightConfig and SqlConfig could be rationalised into
a single Config class.  This would mean adding two methods to the
IConfigService interface: setConfig(String key, String value) and
setConfig(String name, String value, Locale locale).  What this means is
that the IConfigService interface implies updatability.  In the case of
LightConfigService, this could simply throw a NotImplemented exception.

I think the implementations of both LightConfig and SqlConfig are very
generic, and I think the linkage between each of them and their services
(LightConfigService and SqlConfigService) would be clarified by this
change.  Also, it codifies the principle that the service is changeable,
while the config structure isn't, i.e.: no matter which config service
you use, the actual config structures stay the same.

The rationalised Config class could be extended if necessary to take new
functionality into account, but at least would provide a reasonable
default implementation, which could probably be used for any new service
types that might be written.

Thoughts, ideas, pros, cons?

MikeA

Re: [Babeldoc-devel] SQL Config issue

[Michael A. <mic...@ze...>]

OK, problem sorted.  I was forgetting that SqlConfigService gets it's
configuration from System.Properties, for exactly this reason,
presumably.

MikeA

On Sat, 2004-03-27 at 02:50, Michael Ansley wrote:
> Hmmm, I just tried using the SqlConfigService, and I got it started, and
> then ran into a stack overflow, because: the SqlConfigService needs a
> data source name (I'm using Jndi to store the DataSource object), but
> it's trying to use itself to obtain the values to create the data
> source.
>=20
> Anybody out there actually using this kind of setup?  And any idea how I
> might force the SqlConfigService to use config files rather than falling
> over itself?
>=20
> Cheers...
>=20
>=20
> MikeA
>=20

[Babeldoc-devel] SQL Config issue

[Michael A. <mic...@ze...>]

Hmmm, I just tried using the SqlConfigService, and I got it started, and
then ran into a stack overflow, because: the SqlConfigService needs a
data source name (I'm using Jndi to store the DataSource object), but
it's trying to use itself to obtain the values to create the data
source.

Anybody out there actually using this kind of setup?  And any idea how I
might force the SqlConfigService to use config files rather than falling
over itself?

Cheers...


MikeA

Re: [Babeldoc-devel] Possible changes to SQL Config immediate write

[Michael A. <mic...@ze...>]

Hi,

Excellent, this is exactly the kind of information I was looking for.  I
never thought about the case of clustered servers.  I'll work out how to
build that into the design, and see what I come up with.

Cheers...


MikeA


On Sun, 2004-03-21 at 11:16, Dejan Krsmanovic wrote:
> Hi Mike,=20
> First of all, I must say that I have never used that
> code so I am probably not aware of all issues
> regarding to SQlConfig. I know that Erik has some
> problems with initial SqlConfig implementation since
> his system was required to run in clustered enviroment
> where all nodes should be aware of changes made in one
> node (without restarting). So, (if I remember well) he
> dropped all cache usage in SqlConfig and every change
> made in configuration is immediatelly written to
> database.=20
>=20
> Now, I am not sure if this could be done better.
> Perhaps, you could introduce some new config option
> that would enable cache usage in SqlConfig.
>=20
> I am not sure if this is all true, but you could
> search mailing list. Also, I guess that old
> SqlConfig(Service) implementation is still in CVS so
> you can look at the CVS history for these files.=20
>=20
> regards,
> Dejan
>=20
> --- Michael Ansley <mic...@ze...> wrote:
> > Hi,
> >=20
> > When a setString() is called on a SQLConfig object,
> > it immediately
> > passes the values to it's server (a
> > SQLConfigService, funnily enough),
> > which writes it to the database.  In addition, the
> > saveConfig method on
> > the SQLConfigService class doesn't do anything.
> >=20
> > I was thinking, it makes more sense to me if the
> > setString() call does
> > *not* pass the call to the service object and save
> > immediately to the
> > database, but simply changes it's own cache value.=20
> > Then, when some or
> > other client code calls to saveConfig() on the
> > SQLConfigService, that's
> > when the service retrieves the cached updates and
> > the data gets written
> > back to the database.  That way it can all be done
> > in a single
> > transaction, as well.
> >=20
> > Thoughts, please, anybody who cares, one way or the
> > other...
> >=20
> > Cheers...
> >=20
> >=20
> > MikeA
> >=20
> >=20
> >=20
>=20
> > ATTACHMENT part 2 application/pgp-signature
> name=3Dsignature.asc
>=20
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> http://taxes.yahoo.com/filing.html
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Possible changes to SQL Config immediate write

[Dejan K. <dej...@ya...>]

Hi Mike, 
First of all, I must say that I have never used that
code so I am probably not aware of all issues
regarding to SQlConfig. I know that Erik has some
problems with initial SqlConfig implementation since
his system was required to run in clustered enviroment
where all nodes should be aware of changes made in one
node (without restarting). So, (if I remember well) he
dropped all cache usage in SqlConfig and every change
made in configuration is immediatelly written to
database. 

Now, I am not sure if this could be done better.
Perhaps, you could introduce some new config option
that would enable cache usage in SqlConfig.

I am not sure if this is all true, but you could
search mailing list. Also, I guess that old
SqlConfig(Service) implementation is still in CVS so
you can look at the CVS history for these files. 

regards,
Dejan

--- Michael Ansley <mic...@ze...> wrote:
> Hi,
> 
> When a setString() is called on a SQLConfig object,
> it immediately
> passes the values to it's server (a
> SQLConfigService, funnily enough),
> which writes it to the database.  In addition, the
> saveConfig method on
> the SQLConfigService class doesn't do anything.
> 
> I was thinking, it makes more sense to me if the
> setString() call does
> *not* pass the call to the service object and save
> immediately to the
> database, but simply changes it's own cache value. 
> Then, when some or
> other client code calls to saveConfig() on the
> SQLConfigService, that's
> when the service retrieves the cached updates and
> the data gets written
> back to the database.  That way it can all be done
> in a single
> transaction, as well.
> 
> Thoughts, please, anybody who cares, one way or the
> other...
> 
> Cheers...
> 
> 
> MikeA
> 
> 
> 

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc



__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Babeldoc-devel] Possible changes to SQL Config immediate write

[Michael A. <mic...@ze...>]

Hi,

When a setString() is called on a SQLConfig object, it immediately
passes the values to it's server (a SQLConfigService, funnily enough),
which writes it to the database.  In addition, the saveConfig method on
the SQLConfigService class doesn't do anything.

I was thinking, it makes more sense to me if the setString() call does
*not* pass the call to the service object and save immediately to the
database, but simply changes it's own cache value.  Then, when some or
other client code calls to saveConfig() on the SQLConfigService, that's
when the service retrieves the cached updates and the data gets written
back to the database.  That way it can all be done in a single
transaction, as well.

Thoughts, please, anybody who cares, one way or the other...

Cheers...


MikeA

Re: [Babeldoc-devel] Sample SQL Config data

[Michael A. <mic...@ze...>]

Hi, Dejan,

Yes, you understood right.  Thanks for the info.  I managed to finally
get the SQLConfigurationLoader working, and got the example config data
into a Postgres database.  Things are looking up.  I'm pleased to hear
that the sql configuration code is in production.

Cheers...


MikeA


On Mon, 2004-03-15 at 10:01, Dejan Krsmanovic wrote:
> Mike,
>=20
> if I understood  you are asking about storing configuration data into
> database (instead of properties files) , right?
>=20
> I haven't used Babeldoc this way, but it is possible to configure it to u=
se
> database. In fact, one of our developers, Erik Klein have done it in one
> production system so it should work well. Try to search mail archive ( I
> think it was last year) or contact him or Leong M. Dong (he works in the
> company where Erik has implemented that system) for further information.
>=20
> Dejan
>=20
> >Thanks Sherman. Though, what I was actually looking for was some sample
>=20
> >data for using the sql configuration, not the sql journal, i.e.: some
>=20
> >sample pipeline configuration data that actually goes into a database,
>=20
> >along with the file configuration data to make it work.
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Sample SQL Config data

[Dejan K. <dej...@nb...>]

Mike,

if I understood  you are asking about storing configuration data into
database (instead of properties files) , right?

I haven't used Babeldoc this way, but it is possible to configure it to use
database. In fact, one of our developers, Erik Klein have done it in one
production system so it should work well. Try to search mail archive ( I
think it was last year) or contact him or Leong M. Dong (he works in the
company where Erik has implemented that system) for further information.

Dejan

>Thanks Sherman. Though, what I was actually looking for was some sample

>data for using the sql configuration, not the sql journal, i.e.: some

>sample pipeline configuration data that actually goes into a database,

>along with the file configuration data to make it work.

[Babeldoc-devel] Re: Sample SQL Config data

[Sherman W. <sw...@ga...>]

Ignoring the journal part, I think what I showed is essentially right.

Did you find:

http://www.babeldoc.com/development/readme/userguide.xml.html#N1186D
If you set up the datasource myDbDS and then create:

resource/myDb.properties
------------------------------------------------------------------
# Type is required.
type=jndi
datasourceName=java:myDbDS


You can do:

<stage-inst>

    <stage-name>writer</stage-name>

    <stage-desc>this writes stuff</stage-desc>

    <stage-type>SqlWriter</stage-type>

     <option>

        <option-name>resourceName</option-name>

        <option-value>myDb</option-value>

    </option>

    <option>

        <option-name>sql</option-name>

        <option-value>insert into document (blah, blah, blah) values
($document.get("document_id"), blah, blah)</option-value>

    </option>

</stage-inst>



Sherman

Re: [Babeldoc-devel] Sample SQL Config data

[Michael A. <mic...@ze...>]

Hi,

Thanks Sherman.  Though, what I was actually looking for was some sample
data for using the sql configuration, not the sql journal, i.e.: some
sample pipeline configuration data that actually goes into a database,
along with the file configuration data to make it work.

Cheers...


MikeA



On Fri, 2004-03-12 at 17:07, Sherman Wood wrote:
> >Does anybody have a sample of configuration data for a database
> configuration?
>=20
> =20
>=20
> Is this what you meant?
>=20
> =20
>=20
> sql/config.properties
>=20
> ---------------------
>=20
> journalType=3Dpostgresql
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> journal/sql/config.properties
>=20
> -----------------------------
>=20
> resourceName=3Dbabel-journal
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> resource/babel-journal.properties
>=20
> ------------------------------------------------------------------
>=20
> # Type is required.
>=20
> type=3Djndi
>=20
> datasourceName=3Djava:galenworksDS
>=20
> =20
>=20
> =20
>=20
> Sherman Wood
>=20
> GalenWorks LLC
>=20
> 415 516-4894
>=20
> =20
>=20
>=20

Re: [Babeldoc-devel] Sample SQL Config data

[Sherman W. <sw...@ga...>]

>Does anybody have a sample of configuration data for a database
configuration?

 

Is this what you meant?

 

sql/config.properties

---------------------

journalType=postgresql

 

 

 

journal/sql/config.properties

-----------------------------

resourceName=babel-journal

 

 

 

resource/babel-journal.properties

------------------------------------------------------------------

# Type is required.

type=jndi

datasourceName=java:galenworksDS

 

 

Sherman Wood

GalenWorks LLC

415 516-4894