Menu
▾
▴
babeldoc-devel — Babeldoc developer list
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. <de...@us...> - 2004-05-07 09:31:15
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/pipeline In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16627/pipeline Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/pipeline added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:31:15
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/scanner In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16627/scanner Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/scanner added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:31:15
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/data In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16627/data Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb2/data added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:45
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/xslt In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/xslt Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/xslt added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:44
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/scanner In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/scanner Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/scanner added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:44
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/out In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/out Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/out added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:44
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/in In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/in Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/in added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:44
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/pipeline In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/pipeline Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/pipeline added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:27:42
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/data In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029/data Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1/data added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:26:51
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb1 In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15832/xmldb1 Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb1 added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:26:50
|
Update of /cvsroot/babeldoc/modules/xmldb/examples/xmldb2 In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15832/xmldb2 Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples/xmldb2 added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:25:37
|
Update of /cvsroot/babeldoc/modules/xmldb/config/i18n In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15675/i18n Log Message: Directory /cvsroot/babeldoc/modules/xmldb/config/i18n added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:45
|
Update of /cvsroot/babeldoc/modules/xmldb/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15449/src Log Message: Directory /cvsroot/babeldoc/modules/xmldb/src added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:44
|
Update of /cvsroot/babeldoc/modules/xmldb/services In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15449/services Log Message: Directory /cvsroot/babeldoc/modules/xmldb/services added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:44
|
Update of /cvsroot/babeldoc/modules/xmldb/lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15449/lib Log Message: Directory /cvsroot/babeldoc/modules/xmldb/lib added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:44
|
Update of /cvsroot/babeldoc/modules/xmldb/examples In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15449/examples Log Message: Directory /cvsroot/babeldoc/modules/xmldb/examples added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:42
|
Update of /cvsroot/babeldoc/modules/xmldb/config In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15449/config Log Message: Directory /cvsroot/babeldoc/modules/xmldb/config added to the repository |
|
From: Dejan K. <de...@us...> - 2004-05-07 09:24:06
|
Update of /cvsroot/babeldoc/modules/xmldb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15311/xmldb Log Message: Directory /cvsroot/babeldoc/modules/xmldb added to the repository |
|
From: Michael A. <ze...@ze...> - 2004-04-16 14:49:39
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, On Friday 16 April 2004 12:26, Dejan Krsmanovic wrote: > There are few thing that we could do: > - Change execute() method of Scanner class. The trick is not to call > start method if we are in the managed enviroment (probably by using some > property). This is probably the fastest solution. Unless this is an issue in production, I'm going to leave this for now. If= it=20 is an issue in production, please contact me, and I'll make the change, so= =20 that it can be included in the next maintenance release. > - Change the whole Scanner class by introducing new class that would > contain logic for starting scanner workers and other stuff. Scanner > class is subclass of BabeldocCommand, and I think it should be only used > for command line startup. So that new class would be used by JMX and by > Scanner class. That way we won't have problems with execute method and > constructors since Scanner class would just delegate calls to that new > class. I think this is the best solution since but it would require the > most time to implement. I like this idea. I think I'm going to create a copy of the Scanner class,= =20 but not inherited from BabeldocCommand, called maybe ManagedScanner. Then = I=20 can do all the managed scanner stuff without breaking existing code. > - Change Scanner constructor and disable calling execute method. I don't > like this solution because we will need to maintain the sam logic twice > (BabeldocCommand's constructor and Scanner's constructor). Don't like this. To much effort, perhaps, and breaks the design model. > By the way, Mike, have you tought about extending ScannerService and > including some other operations. See, in early Babeldoc days, I wrote > ScannerMonitor GUI application that was able to query scanner tool and > get information about each worker. You could change worker config in > runtime as well as stop or restart them. However, there were many > changes in scanner module and since it wasn't my priority I haven't > upgraded monitor tool to work with 1.2 release. Anyway, that application > used RMI for comunication with Scanner but I was alway tought that it > should be changed to use JMX so that you can use other JMX tools, not > just that application. I have. However, I don't have a JMX container that has a decent console. = =20 JBoss' console is pretty primitive; either that, or I'm not understanding i= t=20 properly. However, right now I'm actually using the babeldoc-console, with= =20 all its velocity templates and extending that to accomodate adding new=20 scanners, and eventually, I'll probably get around to pipelines and other=20 stuff. However, once it's done, I suspect it'll make adding the JMX=20 equivalents a lot easier. I guess it's just the experience. I'm finding t= he=20 velocity stuff quite easy, though. > In fact, one of my plans (for which I can never find time to implement!) > was to use JMX for every part of Babeldoc which is configurable. Since > all components (almost all) now use the same classes and interfaces for > configuration I think it should not be too difficult to create dynamic > MBean which could expose configuration details by using those classes. > We have Info classes for pipeline stages and scanner workes that contain > configuration metadata and config option values that could be exposed > via JMX. I think this is a good idea. Once I have a fully updatable set of factorie= s=20 and stuff, then I'll have a look at this. If the underlying code is right,= =20 then the JMX wrappers should be easy to write. Cheers... Mike > > Michael Ansley wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Hi, all, > > > >I'm transferring this over from the user list because there are some > > issues here that need discussing amongst the developers. > > > >The issue here is that Scanner is an extension of BabeldocCommand, which > > calls execute() in its constructor. Changing this would require a lot = of > > changes right through the system. All code that instantiates a > > derivative of BabeldocCommand would have to take responsibility for > > calling execute(). Having it called automatically when using Babeldoc on > > the command line probably makes sense, but certainly in a managed > > environment, such as a J2EE server, this causes problems. > > > >Personally, I think that separating the execute() call from the > > constructor is the Right Thing to do. But it's going to involve a fair > > amount of coding, debugging, and testing. > > > >So, first of all, can anyone think of a better way of doing it? Secondl= y, > >what are the implications for the rest of the system? As far as I can > > tell, the execute() call is the last thing to happen in the constructor, > > so it's possible, I guess, to turn it off, based on a system property.= =20 > > Is this a good idea? > > > >Thoughts, please, everyone... > > > > > >Mike > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.2.3 (GNU/Linux) > > > >iD8DBQFAf7n0Sm2Jqh63mOsRAqSIAJ4uiArqIDmxrNVVDXd9ROVh/YoOtwCdGtKW > >AsK+BfLER70waIEQKzkEvNY=3D > >=3DVWtU > >-----END PGP SIGNATURE----- > > > > > >------------------------------------------------------- > >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=1470&alloc_id638&op=CCk > >_______________________________________________ > >Babeldoc-devel mailing list > >Bab...@li... > >https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > ------------------------------------------------------- > 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=1470&alloc_id638&op=3DClick > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAf/LfSm2Jqh63mOsRAvSlAJ47rrlu54GLiTH4VCLllNmhl01jTQCeKROs UviId/IBNC/fXb7xF6loEzs=3D =3DzcwC =2D----END PGP SIGNATURE----- |
|
From: Dejan K. <dej...@nb...> - 2004-04-16 11:27:10
|
There are few thing that we could do: - Change execute() method of Scanner class. The trick is not to call=20 start method if we are in the managed enviroment (probably by using some=20 property). This is probably the fastest solution. - Change the whole Scanner class by introducing new class that would=20 contain logic for starting scanner workers and other stuff. Scanner=20 class is subclass of BabeldocCommand, and I think it should be only used=20 for command line startup. So that new class would be used by JMX and by=20 Scanner class. That way we won't have problems with execute method and=20 constructors since Scanner class would just delegate calls to that new=20 class. I think this is the best solution since but it would require the=20 most time to implement. - Change Scanner constructor and disable calling execute method. I don't=20 like this solution because we will need to maintain the sam logic twice=20 (BabeldocCommand's constructor and Scanner's constructor). By the way, Mike, have you tought about extending ScannerService and=20 including some other operations. See, in early Babeldoc days, I wrote=20 ScannerMonitor GUI application that was able to query scanner tool and=20 get information about each worker. You could change worker config in=20 runtime as well as stop or restart them. However, there were many=20 changes in scanner module and since it wasn't my priority I haven't=20 upgraded monitor tool to work with 1.2 release. Anyway, that application=20 used RMI for comunication with Scanner but I was alway tought that it=20 should be changed to use JMX so that you can use other JMX tools, not=20 just that application. In fact, one of my plans (for which I can never find time to implement!)=20 was to use JMX for every part of Babeldoc which is configurable. Since=20 all components (almost all) now use the same classes and interfaces for=20 configuration I think it should not be too difficult to create dynamic=20 MBean which could expose configuration details by using those classes.=20 We have Info classes for pipeline stages and scanner workes that contain=20 configuration metadata and config option values that could be exposed=20 via JMX. Michael Ansley wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, all, > >I'm transferring this over from the user list because there are some iss= ues=20 >here that need discussing amongst the developers. > >The issue here is that Scanner is an extension of BabeldocCommand, which= calls=20 >execute() in its constructor. Changing this would require a lot of chan= ges=20 >right through the system. All code that instantiates a derivative of=20 >BabeldocCommand would have to take responsibility for calling execute().= =20 >Having it called automatically when using Babeldoc on the command line=20 >probably makes sense, but certainly in a managed environment, such as a = J2EE=20 >server, this causes problems. > >Personally, I think that separating the execute() call from the construc= tor is=20 >the Right Thing to do. But it's going to involve a fair amount of codin= g,=20 >debugging, and testing. > >So, first of all, can anyone think of a better way of doing it? Secondl= y,=20 >what are the implications for the rest of the system? As far as I can t= ell,=20 >the execute() call is the last thing to happen in the constructor, so it= 's=20 >possible, I guess, to turn it off, based on a system property. Is this = a=20 >good idea? > >Thoughts, please, everyone... > > >Mike >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.3 (GNU/Linux) > >iD8DBQFAf7n0Sm2Jqh63mOsRAqSIAJ4uiArqIDmxrNVVDXd9ROVh/YoOtwCdGtKW >AsK+BfLER70waIEQKzkEvNY=3D >=3DVWtU >-----END PGP SIGNATURE----- > > >------------------------------------------------------- >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=1470&alloc_id638&op=CCk >_______________________________________________ >Babeldoc-devel mailing list >Bab...@li... >https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > =20 > |
|
From: Michael A. <ze...@ze...> - 2004-04-16 11:11:07
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Perhaps it would be possible for BabeldocCommand to only call execute() if= =20 there are actually command line parameters, otherwise to just leave the=20 command in a stopped state. Mike On Friday 16 April 2004 11:48, Michael Ansley wrote: > Hi, all, > > I'm transferring this over from the user list because there are some issu= es > here that need discussing amongst the developers. > > The issue here is that Scanner is an extension of BabeldocCommand, which > calls execute() in its constructor. Changing this would require a lot of > changes right through the system. All code that instantiates a derivative > of BabeldocCommand would have to take responsibility for calling execute(= ). > Having it called automatically when using Babeldoc on the command line > probably makes sense, but certainly in a managed environment, such as a > J2EE server, this causes problems. > > Personally, I think that separating the execute() call from the construct= or > is the Right Thing to do. But it's going to involve a fair amount of > coding, debugging, and testing. > > So, first of all, can anyone think of a better way of doing it? Secondly, > what are the implications for the rest of the system? As far as I can > tell, the execute() call is the last thing to happen in the constructor, = so > it's possible, I guess, to turn it off, based on a system property. Is > this a good idea? > > Thoughts, please, everyone... > > > Mike > > > ------------------------------------------------------- > 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=1470&alloc_id638&op=3DClick > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAf7+rSm2Jqh63mOsRAi96AJ4/+5T8MyZ5TBCKXVKaYCC5bRo8sACeLw4J +5NmjcDAKcb9YNR4Vwj0wH0=3D =3DROvX =2D----END PGP SIGNATURE----- |
|
From: Michael A. <ze...@ze...> - 2004-04-16 10:46:44
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I'm transferring this over from the user list because there are some issues= =20 here that need discussing amongst the developers. The issue here is that Scanner is an extension of BabeldocCommand, which ca= lls=20 execute() in its constructor. Changing this would require a lot of changes= =20 right through the system. All code that instantiates a derivative of=20 BabeldocCommand would have to take responsibility for calling execute(). =20 Having it called automatically when using Babeldoc on the command line=20 probably makes sense, but certainly in a managed environment, such as a J2E= E=20 server, this causes problems. Personally, I think that separating the execute() call from the constructor= is=20 the Right Thing to do. But it's going to involve a fair amount of coding,= =20 debugging, and testing. So, first of all, can anyone think of a better way of doing it? Secondly,= =20 what are the implications for the rest of the system? As far as I can tell= ,=20 the execute() call is the last thing to happen in the constructor, so it's= =20 possible, I guess, to turn it off, based on a system property. Is this a=20 good idea? Thoughts, please, everyone... Mike =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAf7n0Sm2Jqh63mOsRAqSIAJ4uiArqIDmxrNVVDXd9ROVh/YoOtwCdGtKW AsK+BfLER70waIEQKzkEvNY=3D =3DVWtU =2D----END PGP SIGNATURE----- |
|
From: Martin L. <mar...@us...> - 2004-04-14 20:13:50
|
Update of /cvsroot/babeldoc/babeldoc/readme/userguide In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24412/readme/userguide Modified Files: chapter1.xml chapter2.xml chapter3.xml chapter4.xml Added Files: chapter7.xml Log Message: Minor documentation updates - Added HOWTO chapter 7 Index: chapter4.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter4.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** chapter4.xml 30 Mar 2004 19:15:41 -0000 1.3 --- chapter4.xml 14 Apr 2004 20:13:41 -0000 1.4 *************** *** 5,9 **** <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> --- 5,9 ---- <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 referred 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> *************** *** 19,23 **** <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> --- 19,23 ---- <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 dependent). 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> *************** *** 77,81 **** <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> --- 77,81 ---- <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 implemented in a separate schema (instance, whatever) than the other database storage areas (user, and console).</para> </section> Index: chapter2.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter2.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** chapter2.xml 25 Mar 2004 01:12:34 -0000 1.6 --- chapter2.xml 14 Apr 2004 20:13:41 -0000 1.7 *************** *** 6,10 **** <title>Introduction</title> <para>A pipeline is a program whose purpose is to transform a document into one or more resultant documents. An example pipeline could transform a received XML purchase order into a set of SQL statements intended to update a database, produce a printable PDF file for record keeping and a confirmation email sent to the originating party.</para> ! <para>All of the pipelines in <productname>Babeldoc</productname> must have a unique name like <userinput>test</userinput> or <userinput>document</userinput>. A pipeline is a set of processing steps arranged in a linear fashion. Each processing step is called a "pipeline stage" and each pipeline stage in a pipeline must have a unique name. Two pipelines may have a pipeline stage of the same name. There is a special pipeline stage in a pipeline, the <firstname>entryStage</firstname> which indicates which pipeline stage should initially recieve the document from the feeder mechanisms. It is also possible to introduce a document into the "middle" of a pipeline. In order to designate a particular stage in a pipeline, the name is given as: <userinput>pipeline-name.pipeline stage-name</userinput>.</para> <para>The pipelines in the <userinput>babeldoc</userinput> system are managed by the <firstterm>Pipeline factory</firstterm> which determines how and when a pipeline runs. Each pipeline stage in a pipeline has a <firstterm>type</firstterm> and a set of configuration options. An example of the a pipeline stage is the <userinput>test.transform</userinput> pipeline stage whose type is <userinput>XslTranform</userinput>. This type of pipeline stage requires either the configuration option <userinput>tranformationFile</userinput> which supplies the filename (or URL) of the XSLt file to perform the transformation or <userinput>transformationScript</userinput> which is the inline XSL.t document. There is an additional non-mandatory configuration option, <userinput>bufferSize</userinput> which can help with larger transformations.</para> </section> --- 6,10 ---- <title>Introduction</title> <para>A pipeline is a program whose purpose is to transform a document into one or more resultant documents. An example pipeline could transform a received XML purchase order into a set of SQL statements intended to update a database, produce a printable PDF file for record keeping and a confirmation email sent to the originating party.</para> ! <para>All of the pipelines in <productname>Babeldoc</productname> must have a unique name like <userinput>test</userinput> or <userinput>document</userinput>. A pipeline is a set of processing steps arranged in a linear fashion. Each processing step is called a "pipeline stage" and each pipeline stage in a pipeline must have a unique name. Two pipelines may have a pipeline stage of the same name. There is a special pipeline stage in a pipeline, the <firstname>entryStage</firstname> which indicates which pipeline stage should initially receive the document from the feeder mechanisms. It is also possible to introduce a document into the "middle" of a pipeline. In order to designate a particular stage in a pipeline, the name is given as: <userinput>pipeline-name.pipeline stage-name</userinput>.</para> <para>The pipelines in the <userinput>babeldoc</userinput> system are managed by the <firstterm>Pipeline factory</firstterm> which determines how and when a pipeline runs. Each pipeline stage in a pipeline has a <firstterm>type</firstterm> and a set of configuration options. An example of the a pipeline stage is the <userinput>test.transform</userinput> pipeline stage whose type is <userinput>XslTranform</userinput>. This type of pipeline stage requires either the configuration option <userinput>tranformationFile</userinput> which supplies the filename (or URL) of the XSLt file to perform the transformation or <userinput>transformationScript</userinput> which is the inline XSL.t document. There is an additional non-mandatory configuration option, <userinput>bufferSize</userinput> which can help with larger transformations.</para> </section> *************** *** 47,51 **** </example> <para> ! <productname>Babeldoc</productname> has a rather complex data abstraction mechanism. It is just as easy to read a file from your hard-disk as it is to load it from a file in a your classpath, or even from a website (http://...) or a ftp site (ftp://....). This means that your simple pipeline which works on local files, will also work in a networked evironment.</para> </section> </section> --- 47,51 ---- </example> <para> ! <productname>Babeldoc</productname> has a rather complex data abstraction mechanism. It is just as easy to read a file from your hard-disk as it is to load it from a file in a your classpath, or even from a website (http://...) or a ftp site (ftp://....). This means that your simple pipeline which works on local files, will also work in a networked environment.</para> </section> </section> *************** *** 422,426 **** &processors; ! <para>The standard processor is the <userinput>sync</userinput> processor. This can be overriidden if necessary. The processor for each pipeline is given in the <userinput>pipeline/config.properties</userinput> file. This is specified by: pipeline-name.processor.type=processor-type. </para> <example> <title>Using another pipeline stage processor</title> --- 422,426 ---- &processors; ! <para>The standard processor is the <userinput>sync</userinput> processor. This can be overridden if necessary. The processor for each pipeline is given in the <userinput>pipeline/config.properties</userinput> file. This is specified by: pipeline-name.processor.type=processor-type. </para> <example> <title>Using another pipeline stage processor</title> *************** *** 474,478 **** <userinput>sync</userinput> - this feeder synchronously feeds each document to the pipeline. The feeder waits until the processing has completed before feeding the next document</listitem> <listitem> ! <userinput>async</userinput> - this feeder asynchronously feeds each document to the pipeline. The feeder immediately submits all documents and then returns. The documemts are then submitted in parallel to the pipelines. The pipelines are run in parallel</listitem> <listitem> <userinput>async-disk</userinput> - this feeder is like the async feeder except that the documents are spooled to a directory on the disk so that if the processing is terminated, the feeding may be restarted without any documents being lost</listitem> --- 474,478 ---- <userinput>sync</userinput> - this feeder synchronously feeds each document to the pipeline. The feeder waits until the processing has completed before feeding the next document</listitem> <listitem> ! <userinput>async</userinput> - this feeder asynchronously feeds each document to the pipeline. The feeder immediately submits all documents and then returns. The documents are then submitted in parallel to the pipelines. The pipelines are run in parallel</listitem> <listitem> <userinput>async-disk</userinput> - this feeder is like the async feeder except that the documents are spooled to a directory on the disk so that if the processing is terminated, the feeding may be restarted without any documents being lost</listitem> *************** *** 500,504 **** <section> <title>Pipeline stage types</title> ! <para>There are a limited number of types of pipeline stages. Each of the stages peforms a single function. The options available through the configurations change the operation of the stage. In order for your custom pipeline to do any useful work, you have to configure the pipeline stages. You can also create your own custom pipeline stage for specialized processing. See the documentation for each stage type.</para> </section> --- 500,504 ---- <section> <title>Pipeline stage types</title> ! <para>There are a limited number of types of pipeline stages. Each of the stages performs a single function. The options available through the configurations change the operation of the stage. In order for your custom pipeline to do any useful work, you have to configure the pipeline stages. You can also create your own custom pipeline stage for specialized processing. See the documentation for each stage type.</para> </section> Index: chapter1.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter1.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -d -r1.5 -r1.6 *** chapter1.xml 25 Mar 2004 01:12:34 -0000 1.5 --- chapter1.xml 14 Apr 2004 20:13:41 -0000 1.6 *************** *** 91,95 **** <member>Usage: babeldoc <command></member> <member>where command must be one of:</member> ! <member>xls2xml, scanmon, addstagewiz, setupwiz, lightconfig, sqlload, pipeline, setentr ywiz, journal, process, journalbrowser, flat2xml, scanner, guiprocess, pipelineb uilder, babelfish, module.</member> <member>Babeldoc 1.2.1 Copyright (C) 2002 Bruce McDonald, Dejan Krsmanovic, et al.</member> <member>Babeldoc comes with ABSOLUTELY NO WARRANTY;</member> --- 91,95 ---- <member>Usage: babeldoc <command></member> <member>where command must be one of:</member> ! <member>xls2xml, scanmon, addstagewiz, setupwiz, lightconfig, sqlload, pipeline, setentrywiz, journal, process, journalbrowser, flat2xml, scanner, guiprocess, pipelineb uilder, babelfish, module.</member> <member>Babeldoc 1.2.1 Copyright (C) 2002 Bruce McDonald, Dejan Krsmanovic, et al.</member> <member>Babeldoc comes with ABSOLUTELY NO WARRANTY;</member> *************** *** 181,185 **** <itemizedlist> <listitem>(UNIX) <userinput>/tmp/in</userinput> and <userinput>/tmp/done</userinput></listitem> ! <listitem>(WINDOWS) <userinput>\tmp\in</userinput> and <userinput>\tmp\done</userinput> on the same partition as your <productname>Babeldoc</productname> installlation</listitem> </itemizedlist> <para>Start the scanner as follows:</para> --- 181,185 ---- <itemizedlist> <listitem>(UNIX) <userinput>/tmp/in</userinput> and <userinput>/tmp/done</userinput></listitem> ! <listitem>(WINDOWS) <userinput>\tmp\in</userinput> and <userinput>\tmp\done</userinput> on the same partition as your <productname>Babeldoc</productname> installation</listitem> </itemizedlist> <para>Start the scanner as follows:</para> *************** *** 273,277 **** </simplelist> </computeroutput> ! <para>This output indicates that the configuration key is defined once in the babeldoc_core.jar file and is not subsequently overriden.</para> </example> </section> --- 273,277 ---- </simplelist> </computeroutput> ! <para>This output indicates that the configuration key is defined once in the babeldoc_core.jar file and is not subsequently overridden.</para> </example> </section> --- NEW FILE: chapter7.xml --- <?xml version="1.0" encoding="ISO-8859-1"?> <chapter> <title>HOW TOs</title> <section> <title>Introduction</title> <para>This chapter is intended to collect together some of the collected knowledge of those using <productname>babeldoc</productname>. The intention is to save you time if you are trying to perform some of these tasks or similar.</para> </section> <section><title>HOWTO Set up Eclipse with Babeldoc</title> <para>Pre-requisites: Eclipse 3.0 build M4 or later. Anything earlier will not work.</para> <orderedlist> <listitem>Open eclipse</listitem> <listitem>Make sure that you can see the CVS Repositories View. If you can't, click Window | Show View | Other ... and select CVS Repositories.</listitem> <listitem>The Repositories View will (probably) come up empty. Right click on the white space, and click New | Repository Location ... Enter all the repository details (extssh for anybody with a developer account, otherwise pserver), and click OK.</listitem> <listitem>A new entry for the repository will appear. It's the root node in a tree. Open the tree. Below you should see entries HEAD, Branches and Versions. If you want to develop on the HEAD, as most core developers would probably want, open the HEAD node.</listitem> <listitem>Right-click on the babeldoc node that appears under the HEAD, and select Check Out As... A dialog will appear. You can use "Check out as a project configured using the New Project Wizard". or try the "Check out as a project in the workspace".</listitem> <listitem>Complete the New Project Wizard details. </listitem> <listitem>Once the New Project Wizard has finished processing, you should have a project open in the Java perspective. If not, click on the Add Perspective button, and add a Java Perspective.</listitem> <listitem>Right-click on the project node, and select Properties. Select the Java Build Path option, and select the Source tab.</listitem> <listitem>You should see your project appear with a single (empty) exclusion filter. Edit the filter, and set it to **, i.e.: exclude all files (trust me, I'm a programmer), and click OK.</listitem> <listitem>Select Add Folder... and add each of the src/ folders. You can multiselect on the folder selection dialog. For example, you should open the root node, and then open modules/, and then open babelfish/, and then select the src/ directory. Then open the conversion/ directory, and select src/ (with the Ctrl button down, this time), and so on. In the j2ee/ folder, don't forget to add both src/ and gensrc/. All src/ directories inside modules/ should be added.</listitem> <listitem>Now in the Properties dialog, still in the Java Build Path option, select the Libraries tab. Click Add JARs... and select all the jar files in build/lib, except for any library beginning with "babeldoc_". Also add support/ant/lib/ant.jar and support/ant/lib/junit.jar.</listitem> <listitem>Now click OK in the Properties dialog. Eclipse will probably spend a few seconds rebuilding its project information.</listitem> </orderedlist> <para> You should now have a happy eclipse system showing all the source modules, and the libraries. Eclipse should not show any errors detected by the background compiler. However, there will be a stack of warnings. They can, for the moment, be ignored.</para> <para> Now to get ant working.</para> <orderedlist> <listitem>In the Java perspective, right-click on build.xml, and select Run Ant...</listitem> <listitem>The Ant dialog will now appear. Click on the Main tab, and ensure that the Base Directory is set to the project root. It will probably look something like this: ${workspace_loc:/Babeldoc}</listitem> <listitem> Click on the Classpath tab. Uncheck the "Use global classpath as specified in the Ant runtime preferences". Click Add JARs... and add support/ant/lib/babeldoc_bootstrap.jar, support/ant/lib/xercesImpl.jar, and support/jalopy/lib/jalopy-ant-0.6.1.jar, or whatever the current version is.</listitem> <listitem>Click on the JRE tab. Click Alternate JRE, and select one of your JREs. You should probably set it to something fairly recent. Now, this is critical. You have to set the Working directory. Uncheck the "Use default working directory", and select "Workspace". Click Browse... and select the root node of the project. Click OK. If you don't have a "Working directory" section on the JRE tab, running ant is not going to work. If you do not have the working directory section, you need to upgrade your eclipse to at least version 3.0 build M4. </listitem> <listitem>Click Apply.</listitem> <listitem>Click on the Targets tab. Select the "build" target, and click Run.</listitem> </orderedlist> <para> You should now get a Console View appear, and the ant output will be spooled into the Console View.</para> </section> <section><title>HOWTO Read an attribute from external XML file</title><para>As there is no equivalent to SQLEnrich for XML it is not obvious how to get an attribute from an external file and then revert to the original document. One way to do this is to store the current document as an attribute, process the second file and then revert the document to value of the attribute</para> <para> <simplelist> <member>doc2attrib.stageType=Scripting</member> <member>doc2attrib.nextStage={Stages that load other document etc.}</member> <member>doc2attrib.script=document.put("originalContent", document.getBytes());</member> <member> </member> <member>attrib2doc.stageType=Scripting</member> <member>attrib2doc.nextSyage={Continue with processing}</member> <member>attrib2doc.script=document.setBytes(document.get("originalContent"));</member> </simplelist></para></section> <section><title>HOWTO Access the attributes of a pipeline document inside an XSLT</title> <para>Essentially you can use document.get("myprop")</para> <simplelist><member><xsl:param name="doc" select="$document"/></member> <member><xsl:param name="myprop" select="java:get($doc, 'myprop')"/> </member></simplelist> <para>For the syntax, see: http://xml.apache.org/xalan-j/extensions.html See the java section. </para> <para>Additionally you can get the pipeline stage object from the XSL and then you can manipulate the java code directly.</para> <para> The snippet below is an example of how to get the current time and format it nicely:</para> <simplelist> <member> <xsl:variable name="date" select="java:java.util.Date.new()"/></member> <member> <xsl:variable name="seconds" select="java:getTime($date)"/></member> <member> <xsl:variable name="velocity"</member> <member>select="java:com.babeldoc.core.VelocityUtilityContext.new()"/></member> <member> <xsl:variable name="datestr" select="java:getFormattedDate($velocity, 'd MMM yyyy</member> <member>HH:mm:ss', $seconds)"/></member> </simplelist> </section> </chapter> Index: chapter3.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide/chapter3.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** chapter3.xml 7 Apr 2004 17:16:42 -0000 1.4 --- chapter3.xml 14 Apr 2004 20:13:41 -0000 1.5 *************** *** 21,25 **** <orderedlist> <listitem> ! <userinput>dbName</userinput> name of user to log into the database. </listitem> <listitem> --- 21,25 ---- <orderedlist> <listitem> ! <userinput>dbUser</userinput> name of user to log into the database. </listitem> <listitem> *************** *** 33,37 **** </listitem> </orderedlist> ! <para>For this to work correctly the jdbc jar file for the specific database you need to access needs to be in the classpath. Currently only the mysql jar is built into <productname>Babeldoc</productname>. Access to other kinds of databases like Oracle, DB2 and Sybase will require that the JDBC driver libraries be placed in the CLASSPATH. The name of the dbDriver parameter and the form of the dbUrl will be highly dependant on the particulars of the vendor database. There are a number of limitations to the simple jdbc resource, the primary limitation being that the resource does not pool connections. Each time a connection is requested, a new connection is created and this can be VERY time consuming.</para> </section> --- 33,37 ---- </listitem> </orderedlist> ! <para>For this to work correctly the jdbc jar file for the specific database you need to access needs to be in the classpath. Currently only the mysql jar is built into <productname>Babeldoc</productname>. Access to other kinds of databases like Oracle, DB2 and Sybase will require that the JDBC driver libraries be placed in the CLASSPATH. The name of the dbDriver parameter and the form of the dbUrl will be highly dependent on the particulars of the vendor database. There are a number of limitations to the simple jdbc resource, the primary limitation being that the resource does not pool connections. Each time a connection is requested, a new connection is created and this can be VERY time consuming.</para> </section> |
|
From: Martin L. <mar...@us...> - 2004-04-14 20:13:49
|
Update of /cvsroot/babeldoc/babeldoc/readme In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24412/readme Modified Files: userguide.xml Log Message: Minor documentation updates - Added HOWTO chapter 7 Index: userguide.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/userguide.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -d -r1.5 -r1.6 *** userguide.xml 17 Sep 2003 22:13:21 -0000 1.5 --- userguide.xml 14 Apr 2004 20:13:41 -0000 1.6 *************** *** 8,11 **** --- 8,12 ---- <!ENTITY chapter5 SYSTEM "${system.get('babeldoc.home')}/readme/userguide/chapter5.xml"> <!ENTITY chapter6 SYSTEM "${system.get('babeldoc.home')}/readme/userguide/chapter6.xml"> + <!ENTITY chapter7 SYSTEM "${system.get('babeldoc.home')}/readme/userguide/chapter7.xml"> <!ENTITY appendix1 SYSTEM "${system.get('babeldoc.home')}/readme/userguide/appendix1.xml"> <!ENTITY pipelinestages SYSTEM "${system.get('babeldoc.home')}/readme/userguide/pipelinestages.xml"> *************** *** 40,43 **** --- 41,45 ---- &chapter5; &chapter6; + &chapter7; &appendix1; |
|
From: Martin L. <mar...@us...> - 2004-04-14 20:13:49
|
Update of /cvsroot/babeldoc/babeldoc/readme/devguide In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24412/readme/devguide Modified Files: chapter1.xml chapter2.xml Log Message: Minor documentation updates - Added HOWTO chapter 7 Index: chapter2.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/devguide/chapter2.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -d -r1.5 -r1.6 *** chapter2.xml 29 Aug 2003 02:02:58 -0000 1.5 --- chapter2.xml 14 Apr 2004 20:13:41 -0000 1.6 *************** *** 63,67 **** <para> Modules are the basic unit of extension in Babeldoc. A module has a unique name ! and a list of modules that it is dependant on. The module must have a regular directory structure and a Jakarta Ant build XML file. When building Babeldoc, the build searches through a path list for modules. It is possible to build Babeldoc --- 63,67 ---- <para> Modules are the basic unit of extension in Babeldoc. A module has a unique name ! and a list of modules that it is dependent on. The module must have a regular directory structure and a Jakarta Ant build XML file. When building Babeldoc, the build searches through a path list for modules. It is possible to build Babeldoc *************** *** 103,107 **** <para> During the build of Babeldoc, once all the modules have been determined by ! searching the module search path, and the dependancy order has been determined by reading the build.properties files, the build.xml gets called by the main build.xml. There has to be five targets: --- 103,107 ---- <para> During the build of Babeldoc, once all the modules have been determined by ! searching the module search path, and the dependency order has been determined by reading the build.properties files, the build.xml gets called by the main build.xml. There has to be five targets: *************** *** 183,194 **** file MUST extend the class <userinput>com.babeldoc.core.module.BabeldocModule</userinput>. Most importantly it must provide the formal name of the module and the list of modules that this ! module is dependant on. </para> <para> For those jar files in the classpath that have the Module and Depends attributes in the ! manifest, it builds a list of modules from least dependant (always core) to most dependant. ! It then places each of the jar files into the resource search path from least dependant to most dependant. ! This has the effect that a property in the most dependant module file will always override the ! same property in a less dependant module file. </para> </section> --- 183,194 ---- file MUST extend the class <userinput>com.babeldoc.core.module.BabeldocModule</userinput>. Most importantly it must provide the formal name of the module and the list of modules that this ! module is dependent on. </para> <para> For those jar files in the classpath that have the Module and Depends attributes in the ! manifest, it builds a list of modules from least dependent (always core) to most dependent. ! It then places each of the jar files into the resource search path from least dependent to most dependent. ! This has the effect that a property in the most dependent module file will always override the ! same property in a less dependent module file. </para> </section> Index: chapter1.xml =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/readme/devguide/chapter1.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** chapter1.xml 17 Mar 2003 02:31:43 -0000 1.2 --- chapter1.xml 14 Apr 2004 20:13:40 -0000 1.3 *************** *** 17,22 **** <section> <title>Contact Us</title> ! <para>If you are working with <productname>Babeldoc</productname>, please contact us t ! hrough the SourceForge pages. We want to drive the development of babeldoc and welcome input from everyone. </para> --- 17,21 ---- <section> <title>Contact Us</title> ! <para>If you are working with <productname>Babeldoc</productname>, please contact us through the SourceForge pages. We want to drive the development of babeldoc and welcome input from everyone. </para> |
2 messages has been excluded from this view by a project administrator.
