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. <dej...@nb...> - 2003-09-24 14:36:47
|
Hi David, I have applied your patch (I hope it works correctly!). Regarding to your question about using threadpool pipeline processor I have to say that this is still new ferature in development phase so there could be such errors. Anyway, stack trace you sent looks like error in particular stage (extract_fid) so it maybe some configuration issue... I guess Bruce could help you more on this. Anyway, if you find some Babeldoc's bug please send us a patch. Or we could grant you CVS access permissions if you are interested! Dejan |
|
From: <de...@us...> - 2003-09-24 14:26:50
|
Update of /cvsroot/babeldoc/babeldoc/modules/scanner/config/i18n In directory sc8-pr-cvs1:/tmp/cvs-serv30176/modules/scanner/config/i18n Modified Files: messages.properties Log Message: Applying David's patch with lastModified config option Index: messages.properties =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/config/i18n/messages.properties,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -d -r1.14 -r1.15 *** messages.properties 12 Sep 2003 01:09:16 -0000 1.14 --- messages.properties 24 Sep 2003 14:26:46 -0000 1.15 *************** *** 49,52 **** --- 49,53 ---- scanner.DirectoryScannerInfo.option.includeFilter=File extension of the files that should be included. Files that do not match, will be excluded scanner.DirectoryScannerInfo.option.filter=Regular expression filter. Only files that do match will be included. If not specified all files will be included + scanner.DirectoryScannerInfo.option.minimumFileAge=Minimum age of file in ms (attempts to guard against incomplete reads) #FtpScanner scanner.FtpScanner.error.init=Error during scanner initialization |
|
From: <de...@us...> - 2003-09-24 14:26:33
|
Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker
In directory sc8-pr-cvs1:/tmp/cvs-serv30128/modules/scanner/src/com/babeldoc/scanner/worker
Modified Files:
DirectoryScanner.java
Log Message:
Applying David's patch with lastModified config option
Index: DirectoryScanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/DirectoryScanner.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -C2 -d -r1.21 -r1.22
*** DirectoryScanner.java 24 Sep 2003 09:00:20 -0000 1.21
--- DirectoryScanner.java 24 Sep 2003 14:26:29 -0000 1.22
***************
*** 99,102 ****
--- 99,103 ----
public static final String INCLUDE_SUB_DIRS = "includeSubfolders";
public static final String FILTER_FILENAME = "filter";
+ public static final String MINIMUM_FILE_AGE = "minimumFileAge";
public DirectoryScanner() {
***************
*** 113,116 ****
--- 114,123 ----
private boolean includeSubDirs = false;
+ /** Minimum time in ms since file was last modified.
+ * Attempts to guard against incomplete reads when
+ * the writer of the file is "slow".
+ */
+ private int minimumFileAge = 0;
+
/**
* This method will scan for new documents. It will queue documents by
***************
*** 166,169 ****
--- 173,183 ----
}
+ setMinimumFileAge(this.getInfo().getIntValue(MINIMUM_FILE_AGE));
+
+ if(getMinimumFileAge() > 0) {
+ LogService.getInstance().logInfo("Minimum file age: "
+ + getMinimumFileAge() + " ms");
+ }
+
//Add filename filter if exist
addFilter(FILTER_FILENAME);
***************
*** 233,237 ****
return isIncludeSubDirs();
} else {
! return acceptEntry(FILTER_FILENAME, current.getName());
}
}
--- 247,252 ----
return isIncludeSubDirs();
} else {
! //if file fulfils configured criteria
! return acceptFile(current);
}
}
***************
*** 297,300 ****
--- 312,349 ----
}
+ /**
+ * Consult configuration if this file should be processed
+ * or not. Current configurable constraints include the age
+ * of the file and a filename filter.
+ *
+ * @param file The file to be checked against configuration
+ * @return true If the file should be processed at this time
+ */
+ private boolean acceptFile(File file) {
+ // Check name filter first, and then age.
+ if(acceptEntry(FILTER_FILENAME, file.getName())) {
+ if(getMinimumFileAge() <= getFileAge(file)) {
+ return true;
+ } else {
+ LogService.getInstance().logDebug(
+ "Ignoring " + file.getName()
+ + " (age " + getFileAge(file) + " < " + getMinimumFileAge() + ")");
+ }
+ // Potentially add additional checks here.
+ }
+ return false;
+ }
+
+ /**
+ * Get age of file in ms.
+ *
+ * @param file The file to get the age of.
+ * @return long The age of the file in ms.
+ */
+ private long getFileAge(File file) {
+ return System.currentTimeMillis() - new Date(file.lastModified()).getTime();
+ }
+
+
public File getInDirectory() {
return inDirectory;
***************
*** 320,323 ****
--- 369,381 ----
this.includeSubDirs = includeSubDirs;
}
+
+ public int getMinimumFileAge() {
+ return minimumFileAge;
+ }
+
+ public void setMinimumFileAge(int minimumFileAge) {
+ if(minimumFileAge < 0) minimumFileAge = 0;
+ this.minimumFileAge = minimumFileAge;
+ }
}
***************
*** 383,386 ****
--- 441,452 ----
false,
I18n.get("scanner.DirectoryScannerInfo.option.filter")));
+
+ options.add(
+ new ConfigOption(
+ DirectoryScanner.MINIMUM_FILE_AGE,
+ IConfigOptionType.INTEGER,
+ null,
+ false,
+ I18n.get("scanner.DirectoryScannerInfo.option.minimumFileAge")));
return options;
|
|
From: David K. <dav...@al...> - 2003-09-24 13:40:55
|
Dejan Krsmanovic wrote: > Hi David, Hi again, Dejan, and list, [snipped Dejan's suggestions regarding the DirectoryScanner] I have read source, coded and tested a bit, and come up with a new version of the patch to the DirectoryScanner. This one: - Integrates the file-age criteria into the filter mechanism already present in the DirectoryScanner - Creates a new private method boolean acceptFile(File file) that gets called instead of the original acceptEntry, but calls acceptEntry itself, in addition to the age check, allowing for easily extending acceptFile to do more things - Changes the name from minLastModified to minimumFileAge, both in the code as well as for the configuration parameter - Makes the parameter optional with default value of 0 (zero), i.e it behaves exactly as before and is backwards compatible - Externalizes the description of the configuration parameter into the messages.properties for the scanner module - Does not sleep any more, since it merely ignores the file if it is too young, until next scanner phase, when it gets a new chance to be considered for processing again - Gracefully handles the removal of files between scannings, since it has no memory of what files were there last time - Totally fails to handle the case where the sender deliberately (or not) uploads an invalid file... ;-) Patch, against both messages.properties and DirectoryScanner.java is attached. Please review and comment. Regards, David |
|
From: <de...@us...> - 2003-09-24 13:12:47
|
Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker In directory sc8-pr-cvs1:/tmp/cvs-serv13872/modules/scanner/src/com/babeldoc/scanner/worker Modified Files: SqlScanner.java Log Message: Fixing bug 809462 (http://sourceforge.net/tracker/index.php?func=detail&aid=809462&group_id=56976&atid=482496) NPE when table contains null column Index: SqlScanner.java =================================================================== RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/SqlScanner.java,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -d -r1.13 -r1.14 *** SqlScanner.java 17 Sep 2003 21:11:58 -0000 1.13 --- SqlScanner.java 24 Sep 2003 13:12:41 -0000 1.14 *************** *** 180,184 **** for (int i = 1; i <= columnCount; i++) { sb.append("\t\t<" + rs.getMetaData().getColumnLabel(i) + ">"); ! sb.append("<![CDATA[" + rs.getObject(i).toString() + "]]>"); sb.append("</" + rs.getMetaData().getColumnLabel(i) + ">\n"); } --- 180,188 ---- for (int i = 1; i <= columnCount; i++) { sb.append("\t\t<" + rs.getMetaData().getColumnLabel(i) + ">"); ! String data = ""; ! if (rs.getObject(i)!=null) { ! data = rs.getObject(i).toString(); ! } ! sb.append("<![CDATA[" + data + "]]>"); sb.append("</" + rs.getMetaData().getColumnLabel(i) + ">\n"); } |
|
From: David K. <dav...@al...> - 2003-09-24 09:46:47
|
Dejan Krsmanovic wrote:
> Hi David,
Hi Dejan,
> I like your idea. In fact I had problems like you but we have solved it by
> ignoring corrupt files ;). Since we have used XML files, we would know if
> file is incomplete. These files would be ignored in pipeline processing. But
> that is not good solution and I think your solution is better and more
> general. Altough it is not perfect, I believe it could be usefull in most
> situations.
Yes, it definitely helps in our situation. But as you say, it is most
certainly not perfect.
> However, I think this option should not be mandatory and configuration shoud
> work without specifying it. (false should be specified in
> DirectoryScannerInfo.getTypeSpecificOptions() for this option. Some other
> options should not be mandatory so I have changed this).
Whoops. That wasn't intentional. Of course it should be optional.
> Also, I don't like the fact that worker will sleep as long as the file is
> being modified ignoring other files that may arrive in the meantime. What do
> you think about ignoring fresh files and continuing processing other files.
Yeah, that sounds like a better idea.
> So new files may not be process in first or second doScan() method call.
Yup. I will take a second look at the code and see if I can come
up with something passable for this.
> Also, what's happening if upload is aborted? Will file remain on file
> system? What if user decide to delete file while worker is sleeping? Have
> you tested with these (maybe rare but still real) situations?
Hm...in our specific case:
- Aborted upload -> file remains, uploader tries again later.
-> Will lead to failed parsing attempt in our case... :-/
- Delete file during sleep
-> In my current patch this will (probably) fail.
-> When your suggested change is in there, I guess that the
scanner won't see the file any longer, and it will therefore
not be processed. Which is better, I think. (At least logical.)
- I have, as you can see, not tested with these situations yet.
I'll try to recode my change according to your idea, and run a
few tests, including the specific cases above, and see how it
goes. If it looks ok I'll get back to the list with an updated
patch.
I have another question, regarding the multithreading support:
- When trying to use the threadpool pipeline processor I get
into massive problems down the pipeline, where stages fail
spectacularly that when using the sync pipeline works fine.
- Is there any known failure/problem modes when using the
threadpool pipeline processor?
Extract from log-entries in my console attached. Background:
- Two DirectoryScanner's feeding one pipeline each.
- The two pipelines use the threadpool processor with a thread
count of 2, each.
- The two pipelines call a third pipeline for final common
processing as their last stage. The third pipeline also uses
the threadpool processor, with a thread count of 4.
- The failure as shown in the attached log fragment occurs in
one of the first pipelines, in the third stage "extract_fid",
which is an XpathExtract stage.
Any idea(s) about cause/solution/further research in this case?
> Dejan
David
|
|
From: Dejan K. <dej...@nb...> - 2003-09-24 09:00:59
|
Hi David,
I like your idea. In fact I had problems like you but we have solved it by
ignoring corrupt files ;). Since we have used XML files, we would know if
file is incomplete. These files would be ignored in pipeline processing. But
that is not good solution and I think your solution is better and more
general. Altough it is not perfect, I believe it could be usefull in most
situations.
However, I think this option should not be mandatory and configuration shoud
work without specifying it. (false should be specified in
DirectoryScannerInfo.getTypeSpecificOptions() for this option. Some other
options should not be mandatory so I have changed this).
Also, I don't like the fact that worker will sleep as long as the file is
being modified ignoring other files that may arrive in the meantime. What do
you think about ignoring fresh files and continuing processing other files.
So new files may not be process in first or second doScan() method call.
Also, what's happening if upload is aborted? Will file remain on file
system? What if user decide to delete file while worker is sleeping? Have
you tested with these (maybe rare but still real) situations?
Dejan
---- Original Message -----
From: "David Kinnvall" <dav...@al...>
To: "McDonald, Bruce" <Bru...@ba...>;
<bab...@li...>
Sent: Tuesday, September 23, 2003 6:37 PM
Subject: Re: [Babeldoc-devel] Avoiding incomplete reads in DirectoryScanner
> Hi, Bruce,
>
> McDonald, Bruce wrote:
> > This issue is really problematic generally! We did build in a .done
file solution into the directory scanner which looks for the existance of
the .done flag file. This file indicates that the transfer has completed.
Why dont you look into this?
>
> Hm...there is no .done file solution in the DirectoryScanner.
>
> There is one in the FileWriterPipelineStage, though, but that
> is of no real help in the (our) DirectoryScanner case, since:
>
> - Someone else is doing the writing, and can be slow at
> it, to make things worse...perhaps even via modem. :-)
> - I can't make the writer (a different organization)
> change their system to provide an additional done file
> to indicate completion in this case, unfortunately.
> - The scanner submits the read document, in whatever state
> it is, to the pipeline queue, for processing, and then
> lets go of it, hence I cannot go back to the scanner if
> I detect in the PipelineStage that something is wrong,
> at least not in any clean way that I can see.
>
> Have I missed anything?
>
> The configurable delay approach in the DirectoryScanner seems
> to work so far, at least for me, and I can't really see any
> obviously cleaner solution when there is no possibility of
> modifying the sender's behavior.
>
> A bit more research indicates that there is really no clean
> way (even at the OS level) in Linux to detect when a file has
> been completely written and closed. So it seems to me at this
> time that the delay might be a viable trick.
>
> I have modified the patch every so slightly so that it checks
> the modification timestamp after each delay, to cover the case
> with a really slow writer appending a number of bytes each and
> every second, for some time. Manually tested using "touch". :-)
>
> Adjusted patch attached, FWIW.
>
> /David
>
----------------------------------------------------------------------------
----
> Index: DirectoryScanner.java
> ===================================================================
> RCS file:
/cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/D
irectoryScanner.java,v
> retrieving revision 1.20
> diff -u -r1.20 DirectoryScanner.java
> --- DirectoryScanner.java 12 Sep 2003 01:09:16 -0000 1.20
> +++ DirectoryScanner.java 23 Sep 2003 16:30:44 -0000
> @@ -98,6 +98,7 @@
> public static final String BUFFER_LEN = "bufferLen";
> public static final String INCLUDE_SUB_DIRS = "includeSubfolders";
> public static final String FILTER_FILENAME = "filter";
> + public static final String MIN_LAST_MODIFIED = "minLastModified";
>
> public DirectoryScanner() {
> super(new DirectoryScannerInfo());
> @@ -112,6 +113,12 @@
> /** flag to include sub directories */
> private boolean includeSubDirs = false;
>
> + /** Minimum time in ms since file was last modified.
> + * Attempts to guard against incomplete reads when
> + * the writer of the file is "slow".
> + */
> + private int minLastModified = 0;
> +
> /**
> * This method will scan for new documents. It will queue documents by
> * itself, so it will return null no matter how many documents found!
> @@ -165,6 +172,12 @@
> // Dont catch or do anything here - this means that the default is
accepted.
> }
>
> +
setMinLastModified(this.getInfo().getIntValue(MIN_LAST_MODIFIED));
> +
> + LogService.getInstance().logInfo(
> + "Minimum time since last modification of files will be " +
getMinLastModified() + " ms"
> + );
> +
> //Add filename filter if exist
> addFilter(FILTER_FILENAME);
> }
> @@ -273,6 +286,21 @@
> //getting message from file
> byte[] data = new byte[1024];
> long modified = new Date(file.lastModified()).getTime();
> +
> + // avoid (if configured) incomplete reads due to slow
writer(s)
> + long now = System.currentTimeMillis();
> + while(getMinLastModified() > (now - modified)) {
> + try {
> + long interval = getMinLastModified() - (now -
modified);
> + LogService.getInstance().logInfo("Sleeping " +
interval + " ms, since file was too fresh...");
> + Thread.currentThread().sleep(interval);
> + } catch (java.lang.InterruptedException ie) {
> + // Ignore.
> + }
> + now = System.currentTimeMillis();
> + modified = new Date(file.lastModified()).getTime();
> + }
> +
> fis = new FileInputStream(file);
> baos = new ByteArrayOutputStream((int) file.length());
>
> @@ -319,6 +347,15 @@
> public void setIncludeSubDirs(boolean includeSubDirs) {
> this.includeSubDirs = includeSubDirs;
> }
> +
> + public int getMinLastModified() {
> + return minLastModified;
> + }
> +
> + public void setMinLastModified(int minLastModified) {
> + if(minLastModified < 0) minLastModified = 0;
> + this.minLastModified = minLastModified;
> + }
> }
>
> /**
> @@ -382,6 +419,14 @@
> null,
> true,
> I18n.get("scanner.DirectoryScannerInfo.option.filter")));
> +
> + options.add(
> + new ConfigOption(
> + DirectoryScanner.MIN_LAST_MODIFIED,
> + IConfigOptionType.INTEGER,
> + null,
> + true,
> + "Minimum time in ms since file was last modified
(attempts to guard against incomplete reads)"));
>
> return options;
> }
>
|
|
From: <de...@us...> - 2003-09-24 09:00:30
|
Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker
In directory sc8-pr-cvs1:/tmp/cvs-serv2204/modules/scanner/src/com/babeldoc/scanner/worker
Modified Files:
DirectoryScanner.java
Log Message:
Changing metadata of few config options
Index: DirectoryScanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/DirectoryScanner.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** DirectoryScanner.java 12 Sep 2003 01:09:16 -0000 1.20
--- DirectoryScanner.java 24 Sep 2003 09:00:20 -0000 1.21
***************
*** 372,376 ****
IConfigOptionType.BOOLEAN,
"false",
! true,
I18n.get(
"scanner.DirectoryScannerInfo.option.includeSubdirs")));
--- 372,376 ----
IConfigOptionType.BOOLEAN,
"false",
! false,
I18n.get(
"scanner.DirectoryScannerInfo.option.includeSubdirs")));
***************
*** 381,385 ****
IConfigOptionType.STRING,
null,
! true,
I18n.get("scanner.DirectoryScannerInfo.option.filter")));
--- 381,385 ----
IConfigOptionType.STRING,
null,
! false,
I18n.get("scanner.DirectoryScannerInfo.option.filter")));
|
|
From: David K. <dav...@al...> - 2003-09-23 16:37:55
|
Hi, Bruce, McDonald, Bruce wrote: > This issue is really problematic generally! We did build in a .done file solution into the directory scanner which looks for the existance of the .done flag file. This file indicates that the transfer has completed. Why dont you look into this? Hm...there is no .done file solution in the DirectoryScanner. There is one in the FileWriterPipelineStage, though, but that is of no real help in the (our) DirectoryScanner case, since: - Someone else is doing the writing, and can be slow at it, to make things worse...perhaps even via modem. :-) - I can't make the writer (a different organization) change their system to provide an additional done file to indicate completion in this case, unfortunately. - The scanner submits the read document, in whatever state it is, to the pipeline queue, for processing, and then lets go of it, hence I cannot go back to the scanner if I detect in the PipelineStage that something is wrong, at least not in any clean way that I can see. Have I missed anything? The configurable delay approach in the DirectoryScanner seems to work so far, at least for me, and I can't really see any obviously cleaner solution when there is no possibility of modifying the sender's behavior. A bit more research indicates that there is really no clean way (even at the OS level) in Linux to detect when a file has been completely written and closed. So it seems to me at this time that the delay might be a viable trick. I have modified the patch every so slightly so that it checks the modification timestamp after each delay, to cover the case with a really slow writer appending a number of bytes each and every second, for some time. Manually tested using "touch". :-) Adjusted patch attached, FWIW. /David |
|
From: McDonald, B. <Bru...@ba...> - 2003-09-23 15:56:31
|
This issue is really problematic generally! We did build in a .done file solution into the directory scanner which looks for the existance of the .done flag file. This file indicates that the transfer has completed. Why dont you look into this? -----Original Message----- From: David Kinnvall [mailto:dav...@al...] Sent: Tuesday, September 23, 2003 10:52 AM To: bab...@li... Subject: [Babeldoc-devel] Avoiding incomplete reads in DirectoryScanner Hi people! I am getting bitten by the fact that a slow writer using FTP to upload files to our server for processing using Babeldoc via the DirectoryScanner sometimes, due to timing obviously, causes the read file to be incomplete, thereby causing parsing/transformation errors and so forth. (Long sentence, yeah I know... ;-p ) To fix this, I have looked at various alternatives, including potential ftp daemon settings (nope), kernel module (not very nice), the fam thing (from SGI, old Perl module, didn't work) to avoid the read from taking place until the file was written completely. After failing enough at the above trials...I turned to our beloved Babeldoc instead, for a dirty(?) little hack: I extended the DirectoryScanner to take another config parameter 'minLastModified', default 0, specififying the least number of milliseconds that must have passed since the file's last modification timestamp, as reported by the File instance. I am working under the assumption that the modification timestamp is indeed correctly updated during the ftp upload, and it seems to be the case, at least on my Red Hat 7.2 installation where I am testing this. Using <scanner_name>.minLastModified = 5000 I have yet to see any failed reads so far. But then again, I have only tested it for about an hour or so... :-) I'll know better tomorrow what the actual effect will be. Diff (unified) against DirectoryScanner.java (per current CVS) attached. Note: I haven't made any changes to the I18N stuff, and I do use a logInfo() here and there, for debugging, so please treat the patch as a proof-of-concept needing some (hopefully little) cleanup. Any hope of getting something like this into Babeldoc proper? (Oh, yeah, I haven't had the time to properly follow up on the last mail I sent about the SqlPreparedWriter and FileTransfer stages. Sorry about that. Still pondering if it makes sense to merge the Sql thing into the standard SqlWriter, since my prepared version has no support for multiple statements nor comments in it...I'll get back to the list on that in the (hopefully) near future.) Regards, David Kinnvall |
|
From: David K. <dav...@al...> - 2003-09-23 14:52:55
|
Hi people! I am getting bitten by the fact that a slow writer using FTP to upload files to our server for processing using Babeldoc via the DirectoryScanner sometimes, due to timing obviously, causes the read file to be incomplete, thereby causing parsing/transformation errors and so forth. (Long sentence, yeah I know... ;-p ) To fix this, I have looked at various alternatives, including potential ftp daemon settings (nope), kernel module (not very nice), the fam thing (from SGI, old Perl module, didn't work) to avoid the read from taking place until the file was written completely. After failing enough at the above trials...I turned to our beloved Babeldoc instead, for a dirty(?) little hack: I extended the DirectoryScanner to take another config parameter 'minLastModified', default 0, specififying the least number of milliseconds that must have passed since the file's last modification timestamp, as reported by the File instance. I am working under the assumption that the modification timestamp is indeed correctly updated during the ftp upload, and it seems to be the case, at least on my Red Hat 7.2 installation where I am testing this. Using <scanner_name>.minLastModified = 5000 I have yet to see any failed reads so far. But then again, I have only tested it for about an hour or so... :-) I'll know better tomorrow what the actual effect will be. Diff (unified) against DirectoryScanner.java (per current CVS) attached. Note: I haven't made any changes to the I18N stuff, and I do use a logInfo() here and there, for debugging, so please treat the patch as a proof-of-concept needing some (hopefully little) cleanup. Any hope of getting something like this into Babeldoc proper? (Oh, yeah, I haven't had the time to properly follow up on the last mail I sent about the SqlPreparedWriter and FileTransfer stages. Sorry about that. Still pondering if it makes sense to merge the Sql thing into the standard SqlWriter, since my prepared version has no support for multiple statements nor comments in it...I'll get back to the list on that in the (hopefully) near future.) Regards, David Kinnvall |
|
From: McDonald, B. <Bru...@ba...> - 2003-09-22 14:57:38
|
Multithreaded access to the pipeline is my big concern. -----Original Message----- From: Leech, Jonathan [mailto:jl...@vi...] Sent: Monday, September 22, 2003 10:51 AM To: 'Stefan Krieger'; Bruce McDonald; David Glick; SourceForge.net Cc: Bab...@li... Subject: RE: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc processe s The SQL journal works great multithreaded. I don't know about multiple = JVMs though. -Jonathan -----Original Message----- From: Stefan Krieger [mailto:ste...@co...] Sent: Sunday, September 21, 2003 12:16 PM To: Bruce McDonald; David Glick; SourceForge.net Cc: Bab...@li... Subject: AW: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc processes Yes, the SQL Journal solves the problem with my latest patch. The "SELECT MAX(...) and UPDATE" commands must be exceuted in a "synchronized" block. Stean > -----Urspr=FCngliche Nachricht----- > Von: bab...@li... > [mailto:bab...@li...]Im Auftrag von = Bruce > McDonald > Gesendet: Sonntag, 21. September 2003 15:44 > An: David Glick; SourceForge.net > Cc: Bab...@li... > Betreff: Re: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc > processes > > > I dont know. > > On Sunday 21 September 2003 09:19 am, David Glick wrote: > > Hi Bruce, > > > > Does the SQL journal solve this problem? > > > > David > > > > On Sunday 21 September 2003 5:43 am, Bruce McDonald wrote: > > > David / Davor: > > > > > > If your are running two instances of babeldoc (two jvms) then > all is good > > > - the simple journals steps do not get mixed up. The problem > arises when > > > you are threading, in the same pipeline for the same journal > ticket, then > > > the ticket steps get mixed. > > > > > > The issue is that the simple journal uses the strict consecutive > > > provision of ticket steps to know about ordering, etc. This > is a problem > > > if you have multiple threads - everything is out of order... > > > > > > regards, > > > Bruce. > > > > > > On Sunday 21 September 2003 12:40 am, David Glick wrote: > > > > Hi Davor, > > > > > > > > If you are executing multiple invocations of Babeldoc from > the command > > > > line, each invocation is running is a separate JVM and therefore = you > > > > shouldn't have any problems executing the same pipeline > simultaneously > > > > (with the possible exception of the Journal update... Bruce, how = is > > > > contention handled in the case of multiple JVM copies of = Babeldoc > > > > trying to simultaneously update the Journal?). > > > > > > > > If you are executing multiple invocations in the same JVM, I = believe > > > > that this situation is handled via the multi-threading > model Babeldoc > > > > supports. The section on Multithreaded Operation in the > Users Guide is > > > > an excellent source of info for this situation. > > > > > > > > > > > > Hope this helps, > > > > > > > > David > > > > > > > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > > > > Read and respond to this message at: > > > > > https://sourceforge.net/forum/message.php?msg_id=3D2201154 > > > > > By: dchocky > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a = simple > > > > > Document Workflow System (or at least that's what we call > it), as a > > > > > part of my college theses. I've built a custom = (RMI)feeder-wrapper > > > > > for Babeldoc. > > > > > > > > > > The application could work ok with this feeder, but I'd like = to > > > > > provide an alternative way of feeding documents into the = pipeline. > > > > > Here's the question: > > > > > > > > > > Is it possible to start in one process my (or any other) > feeder for > > > > > Babeldoc, and in another process to start a scanner (a mailbox > > > > > scanner) and should I expect any problems or do these > processes work > > > > > independently (concurrent access to journal?,velocity log...)? > > > > > Does it become a problem if both processes are operating > on the same > > > > > pipeline? ...on different pipelines? > > > > > I've tried this and it seems to work fine, but... > > > > > > > > > > > > > > > > > > > > Davor Cokrlic > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > >_ You are receiving this email because you elected to monitor = this > > > > > forum. To stop monitoring this forum, login to SourceForge.net = and > > > > > visit: = https://sourceforge.net/forum/unmonitor.php?forum_id=3D190909 > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Welcome to geek heaven. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > Babeldoc-devel mailing list > > > > > Bab...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: Leech, J. <jl...@vi...> - 2003-09-22 14:53:51
|
The SQL journal works great multithreaded. I don't know about multiple = JVMs though. -Jonathan -----Original Message----- From: Stefan Krieger [mailto:ste...@co...] Sent: Sunday, September 21, 2003 12:16 PM To: Bruce McDonald; David Glick; SourceForge.net Cc: Bab...@li... Subject: AW: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc processes Yes, the SQL Journal solves the problem with my latest patch. The "SELECT MAX(...) and UPDATE" commands must be exceuted in a "synchronized" block. Stean > -----Urspr=FCngliche Nachricht----- > Von: bab...@li... > [mailto:bab...@li...]Im Auftrag von = Bruce > McDonald > Gesendet: Sonntag, 21. September 2003 15:44 > An: David Glick; SourceForge.net > Cc: Bab...@li... > Betreff: Re: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc > processes > > > I dont know. > > On Sunday 21 September 2003 09:19 am, David Glick wrote: > > Hi Bruce, > > > > Does the SQL journal solve this problem? > > > > David > > > > On Sunday 21 September 2003 5:43 am, Bruce McDonald wrote: > > > David / Davor: > > > > > > If your are running two instances of babeldoc (two jvms) then > all is good > > > - the simple journals steps do not get mixed up. The problem > arises when > > > you are threading, in the same pipeline for the same journal > ticket, then > > > the ticket steps get mixed. > > > > > > The issue is that the simple journal uses the strict consecutive > > > provision of ticket steps to know about ordering, etc. This > is a problem > > > if you have multiple threads - everything is out of order... > > > > > > regards, > > > Bruce. > > > > > > On Sunday 21 September 2003 12:40 am, David Glick wrote: > > > > Hi Davor, > > > > > > > > If you are executing multiple invocations of Babeldoc from > the command > > > > line, each invocation is running is a separate JVM and = therefore you > > > > shouldn't have any problems executing the same pipeline > simultaneously > > > > (with the possible exception of the Journal update... Bruce, = how is > > > > contention handled in the case of multiple JVM copies of = Babeldoc > > > > trying to simultaneously update the Journal?). > > > > > > > > If you are executing multiple invocations in the same JVM, I = believe > > > > that this situation is handled via the multi-threading > model Babeldoc > > > > supports. The section on Multithreaded Operation in the > Users Guide is > > > > an excellent source of info for this situation. > > > > > > > > > > > > Hope this helps, > > > > > > > > David > > > > > > > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > > > > Read and respond to this message at: > > > > > https://sourceforge.net/forum/message.php?msg_id=3D2201154 > > > > > By: dchocky > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a = simple > > > > > Document Workflow System (or at least that's what we call > it), as a > > > > > part of my college theses. I've built a custom = (RMI)feeder-wrapper > > > > > for Babeldoc. > > > > > > > > > > The application could work ok with this feeder, but I'd like = to > > > > > provide an alternative way of feeding documents into the = pipeline. > > > > > Here's the question: > > > > > > > > > > Is it possible to start in one process my (or any other) > feeder for > > > > > Babeldoc, and in another process to start a scanner (a = mailbox > > > > > scanner) and should I expect any problems or do these > processes work > > > > > independently (concurrent access to journal?,velocity = log...)? > > > > > Does it become a problem if both processes are operating > on the same > > > > > pipeline? ...on different pipelines? > > > > > I've tried this and it seems to work fine, but... > > > > > > > > > > > > > > > > > > > > Davor Cokrlic > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > >_ You are receiving this email because you elected to monitor = this > > > > > forum. To stop monitoring this forum, login to = SourceForge.net and > > > > > visit: = https://sourceforge.net/forum/unmonitor.php?forum_id=3D190909 > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Welcome to geek heaven. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > Babeldoc-devel mailing list > > > > > Bab...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: Stefan K. <ste...@co...> - 2003-09-21 18:16:28
|
Yes, the SQL Journal solves the problem with my latest patch. The "SELECT MAX(...) and UPDATE" commands must be exceuted in a "synchronized" block. Stean > -----Ursprüngliche Nachricht----- > Von: bab...@li... > [mailto:bab...@li...]Im Auftrag von Bruce > McDonald > Gesendet: Sonntag, 21. September 2003 15:44 > An: David Glick; SourceForge.net > Cc: Bab...@li... > Betreff: Re: [Babeldoc-devel] [babeldoc - Help] multiple Babeldoc > processes > > > I dont know. > > On Sunday 21 September 2003 09:19 am, David Glick wrote: > > Hi Bruce, > > > > Does the SQL journal solve this problem? > > > > David > > > > On Sunday 21 September 2003 5:43 am, Bruce McDonald wrote: > > > David / Davor: > > > > > > If your are running two instances of babeldoc (two jvms) then > all is good > > > - the simple journals steps do not get mixed up. The problem > arises when > > > you are threading, in the same pipeline for the same journal > ticket, then > > > the ticket steps get mixed. > > > > > > The issue is that the simple journal uses the strict consecutive > > > provision of ticket steps to know about ordering, etc. This > is a problem > > > if you have multiple threads - everything is out of order... > > > > > > regards, > > > Bruce. > > > > > > On Sunday 21 September 2003 12:40 am, David Glick wrote: > > > > Hi Davor, > > > > > > > > If you are executing multiple invocations of Babeldoc from > the command > > > > line, each invocation is running is a separate JVM and therefore you > > > > shouldn't have any problems executing the same pipeline > simultaneously > > > > (with the possible exception of the Journal update... Bruce, how is > > > > contention handled in the case of multiple JVM copies of Babeldoc > > > > trying to simultaneously update the Journal?). > > > > > > > > If you are executing multiple invocations in the same JVM, I believe > > > > that this situation is handled via the multi-threading > model Babeldoc > > > > supports. The section on Multithreaded Operation in the > Users Guide is > > > > an excellent source of info for this situation. > > > > > > > > > > > > Hope this helps, > > > > > > > > David > > > > > > > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > > > > Read and respond to this message at: > > > > > https://sourceforge.net/forum/message.php?msg_id=2201154 > > > > > By: dchocky > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a simple > > > > > Document Workflow System (or at least that's what we call > it), as a > > > > > part of my college theses. I've built a custom (RMI)feeder-wrapper > > > > > for Babeldoc. > > > > > > > > > > The application could work ok with this feeder, but I'd like to > > > > > provide an alternative way of feeding documents into the pipeline. > > > > > Here's the question: > > > > > > > > > > Is it possible to start in one process my (or any other) > feeder for > > > > > Babeldoc, and in another process to start a scanner (a mailbox > > > > > scanner) and should I expect any problems or do these > processes work > > > > > independently (concurrent access to journal?,velocity log...)? > > > > > Does it become a problem if both processes are operating > on the same > > > > > pipeline? ...on different pipelines? > > > > > I've tried this and it seems to work fine, but... > > > > > > > > > > > > > > > > > > > > Davor Cokrlic > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > > >_ You are receiving this email because you elected to monitor this > > > > > forum. To stop monitoring this forum, login to SourceForge.net and > > > > > visit: https://sourceforge.net/forum/unmonitor.php?forum_id=190909 > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Welcome to geek heaven. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > Babeldoc-devel mailing list > > > > > Bab...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > |
|
From: Bruce M. <br...@mc...> - 2003-09-21 13:44:24
|
I dont know. On Sunday 21 September 2003 09:19 am, David Glick wrote: > Hi Bruce, > > Does the SQL journal solve this problem? > > David > > On Sunday 21 September 2003 5:43 am, Bruce McDonald wrote: > > David / Davor: > > > > If your are running two instances of babeldoc (two jvms) then all is good > > - the simple journals steps do not get mixed up. The problem arises when > > you are threading, in the same pipeline for the same journal ticket, then > > the ticket steps get mixed. > > > > The issue is that the simple journal uses the strict consecutive > > provision of ticket steps to know about ordering, etc. This is a problem > > if you have multiple threads - everything is out of order... > > > > regards, > > Bruce. > > > > On Sunday 21 September 2003 12:40 am, David Glick wrote: > > > Hi Davor, > > > > > > If you are executing multiple invocations of Babeldoc from the command > > > line, each invocation is running is a separate JVM and therefore you > > > shouldn't have any problems executing the same pipeline simultaneously > > > (with the possible exception of the Journal update... Bruce, how is > > > contention handled in the case of multiple JVM copies of Babeldoc > > > trying to simultaneously update the Journal?). > > > > > > If you are executing multiple invocations in the same JVM, I believe > > > that this situation is handled via the multi-threading model Babeldoc > > > supports. The section on Multithreaded Operation in the Users Guide is > > > an excellent source of info for this situation. > > > > > > > > > Hope this helps, > > > > > > David > > > > > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > > > Read and respond to this message at: > > > > https://sourceforge.net/forum/message.php?msg_id=2201154 > > > > By: dchocky > > > > > > > > Hi! > > > > > > > > > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a simple > > > > Document Workflow System (or at least that's what we call it), as a > > > > part of my college theses. I've built a custom (RMI)feeder-wrapper > > > > for Babeldoc. > > > > > > > > The application could work ok with this feeder, but I'd like to > > > > provide an alternative way of feeding documents into the pipeline. > > > > Here's the question: > > > > > > > > Is it possible to start in one process my (or any other) feeder for > > > > Babeldoc, and in another process to start a scanner (a mailbox > > > > scanner) and should I expect any problems or do these processes work > > > > independently (concurrent access to journal?,velocity log...)? > > > > Does it become a problem if both processes are operating on the same > > > > pipeline? ...on different pipelines? > > > > I've tried this and it seems to work fine, but... > > > > > > > > > > > > > > > > Davor Cokrlic > > > > > > > > > > > > > > > > _____________________________________________________________________ > > > >_ You are receiving this email because you elected to monitor this > > > > forum. To stop monitoring this forum, login to SourceForge.net and > > > > visit: https://sourceforge.net/forum/unmonitor.php?forum_id=190909 > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > Babeldoc-devel mailing list > > > > Bab...@li... > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: David G. <dg...@co...> - 2003-09-21 13:15:27
|
Hi Bruce, Does the SQL journal solve this problem? David On Sunday 21 September 2003 5:43 am, Bruce McDonald wrote: > David / Davor: > > If your are running two instances of babeldoc (two jvms) then all is good - > the simple journals steps do not get mixed up. The problem arises when you > are threading, in the same pipeline for the same journal ticket, then the > ticket steps get mixed. > > The issue is that the simple journal uses the strict consecutive provision > of ticket steps to know about ordering, etc. This is a problem if you have > multiple threads - everything is out of order... > > regards, > Bruce. > > On Sunday 21 September 2003 12:40 am, David Glick wrote: > > Hi Davor, > > > > If you are executing multiple invocations of Babeldoc from the command > > line, each invocation is running is a separate JVM and therefore you > > shouldn't have any problems executing the same pipeline simultaneously > > (with the possible exception of the Journal update... Bruce, how is > > contention handled in the case of multiple JVM copies of Babeldoc trying > > to simultaneously update the Journal?). > > > > If you are executing multiple invocations in the same JVM, I believe that > > this situation is handled via the multi-threading model Babeldoc > > supports. The section on Multithreaded Operation in the Users Guide is an > > excellent source of info for this situation. > > > > > > Hope this helps, > > > > David > > > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > > Read and respond to this message at: > > > https://sourceforge.net/forum/message.php?msg_id=2201154 > > > By: dchocky > > > > > > Hi! > > > > > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a simple > > > Document Workflow System (or at least that's what we call it), as a > > > part of my college theses. I've built a custom (RMI)feeder-wrapper for > > > Babeldoc. > > > > > > The application could work ok with this feeder, but I'd like to provide > > > an alternative way of feeding documents into the pipeline. > > > Here's the question: > > > > > > Is it possible to start in one process my (or any other) feeder for > > > Babeldoc, and in another process to start a scanner (a mailbox scanner) > > > and should I expect any problems or do these processes work > > > independently (concurrent access to journal?,velocity log...)? > > > Does it become a problem if both processes are operating on the same > > > pipeline? ...on different pipelines? > > > I've tried this and it seems to work fine, but... > > > > > > > > > > > > Davor Cokrlic > > > > > > > > > > > > ______________________________________________________________________ > > > You are receiving this email because you elected to monitor this forum. > > > To stop monitoring this forum, login to SourceForge.net and visit: > > > https://sourceforge.net/forum/unmonitor.php?forum_id=190909 > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Babeldoc-devel mailing list > > > Bab...@li... > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel -- David Glick Transmit Consulting, Inc 619-475-4052 dg...@tr... |
|
From: Bruce M. <br...@mc...> - 2003-09-21 12:43:24
|
David / Davor: If your are running two instances of babeldoc (two jvms) then all is good - the simple journals steps do not get mixed up. The problem arises when you are threading, in the same pipeline for the same journal ticket, then the ticket steps get mixed. The issue is that the simple journal uses the strict consecutive provision of ticket steps to know about ordering, etc. This is a problem if you have multiple threads - everything is out of order... regards, Bruce. On Sunday 21 September 2003 12:40 am, David Glick wrote: > Hi Davor, > > If you are executing multiple invocations of Babeldoc from the command > line, each invocation is running is a separate JVM and therefore you > shouldn't have any problems executing the same pipeline simultaneously > (with the possible exception of the Journal update... Bruce, how is > contention handled in the case of multiple JVM copies of Babeldoc trying to > simultaneously update the Journal?). > > If you are executing multiple invocations in the same JVM, I believe that > this situation is handled via the multi-threading model Babeldoc supports. > The section on Multithreaded Operation in the Users Guide is an excellent > source of info for this situation. > > > Hope this helps, > > David > > On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > > Read and respond to this message at: > > https://sourceforge.net/forum/message.php?msg_id=2201154 > > By: dchocky > > > > Hi! > > > > > > > > I'm using Babeldoc (and Xindice XML server) to construct a simple > > Document Workflow System (or at least that's what we call it), as a part > > of my college theses. I've built a custom (RMI)feeder-wrapper for > > Babeldoc. > > > > The application could work ok with this feeder, but I'd like to provide > > an alternative way of feeding documents into the pipeline. > > Here's the question: > > > > Is it possible to start in one process my (or any other) feeder for > > Babeldoc, and in another process to start a scanner (a mailbox scanner) > > and should I expect any problems or do these processes work independently > > (concurrent access to journal?,velocity log...)? > > Does it become a problem if both processes are operating on the same > > pipeline? ...on different pipelines? > > I've tried this and it seems to work fine, but... > > > > > > > > Davor Cokrlic > > > > > > > > ______________________________________________________________________ > > You are receiving this email because you elected to monitor this forum. > > To stop monitoring this forum, login to SourceForge.net and visit: > > https://sourceforge.net/forum/unmonitor.php?forum_id=190909 > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Babeldoc-devel mailing list > > Bab...@li... > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel |
|
From: David G. <dg...@co...> - 2003-09-21 04:35:56
|
Hi Davor, If you are executing multiple invocations of Babeldoc from the command line, each invocation is running is a separate JVM and therefore you shouldn't have any problems executing the same pipeline simultaneously (with the possible exception of the Journal update... Bruce, how is contention handled in the case of multiple JVM copies of Babeldoc trying to simultaneously update the Journal?). If you are executing multiple invocations in the same JVM, I believe that this situation is handled via the multi-threading model Babeldoc supports. The section on Multithreaded Operation in the Users Guide is an excellent source of info for this situation. Hope this helps, David On Saturday 20 September 2003 1:57 am, SourceForge.net wrote: > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=2201154 > By: dchocky > > Hi! > > > > I'm using Babeldoc (and Xindice XML server) to construct a simple Document > Workflow System (or at least that's what we call it), as a part of my > college theses. I've built a custom (RMI)feeder-wrapper for Babeldoc. > > The application could work ok with this feeder, but I'd like to provide > an alternative way of feeding documents into the pipeline. > Here's the question: > > Is it possible to start in one process my (or any other) feeder for > Babeldoc, and in another process to start a scanner (a mailbox scanner) and > should I expect any problems or do these processes work independently > (concurrent access to journal?,velocity log...)? > Does it become a problem if both processes are operating on the same > pipeline? ...on different pipelines? > I've tried this and it seems to work fine, but... > > > > Davor Cokrlic > > > > ______________________________________________________________________ > You are receiving this email because you elected to monitor this forum. > To stop monitoring this forum, login to SourceForge.net and visit: > https://sourceforge.net/forum/unmonitor.php?forum_id=190909 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel -- David Glick Transmit Consulting, Inc 619-475-4052 dg...@tr... |
|
From: SourceForge.net <no...@so...> - 2003-09-20 08:57:30
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2201154 By: dchocky Hi! I'm using Babeldoc (and Xindice XML server) to construct a simple Document Workflow System (or at least that's what we call it), as a part of my college theses. I've built a custom (RMI)feeder-wrapper for Babeldoc. The application could work ok with this feeder, but I'd like to provide an alternative way of feeding documents into the pipeline. Here's the question: Is it possible to start in one process my (or any other) feeder for Babeldoc, and in another process to start a scanner (a mailbox scanner) and should I expect any problems or do these processes work independently (concurrent access to journal?,velocity log...)? Does it become a problem if both processes are operating on the same pipeline? ...on different pipelines? I've tried this and it seems to work fine, but... Davor Cokrlic ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=190909 |
|
From: Bill H. <Bil...@Ac...> - 2003-09-19 20:25:41
|
I think perhaps there some fundamental things I don't understand regarding
setting up babeldoc to run under Tomcat.
The first is that I have a clean install of Tomcat and Babeldoc, everything starts
okay and when I access localhost/babeldoc-console, the browser returns and I
see nothing, however the page is served, and an exception is thrown. Details
are below.
The second is how to pass configuration parameters (e.g. which scanner to
start, how to set up the config files, which pipeline, etc...) I've tried putting the
usual parameters on the catalina command line in various ways, reading the bat
files, etc. but can't figure it out.
I guess these two may be related, as the Tomcat error thrown is trying to
instantiate simple, which I assume is related to pipelines or scanners. I have no
idea what pipeline or scanner it thinks it's running at this point because of the
configuration issue above.
Thanks for any help in getting started.
Bill
Here's the detail on the babeldoc-console issue. The servlet serves,
I see nothing in the browser, and the page source is this:
<frameset cols="100,*">
<frame name="navigation" src="navigation.vm" noresize
frameborder=0>
<frame name="main" src="main.vm" noresize frameborder=0>
</frameset>
The velocity log shows that velocity has correctly started. But I guess that
somehow it isn't processing the .vm files...
In the tomcat console I have this (I've shown the environment in case that will
assist you in assisting me):
<====some relevant environment variables: =====>
D:\Development\Babeldoc\build>set
BABELDOC_HOME=D:\Development\Babeldoc\build
BABELDOC_USER=d:\Development\User
CATALINA_HOME=D:\jakarta-tomcat-4.1.24
CLASSPATH=d:\j2sdk1.4.2\lib\tools.jar
JAVA_HOME=D:\j2sdk1.4.2
Path=C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\jakarta-
ant-1.5.1\bin;
D:\j2sdk1.4.2\bin;d:\Development\Babeldoc\build\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
TEMP=C:\DOCUME~1\wbh\LOCALS~1\Temp
TMP=C:\DOCUME~1\wbh\LOCALS~1\Temp
D:\Development\Babeldoc\build>catalina run
BABELDOC_CMD_LINE_ARGS=run
Using BABELDOC_HOME=D:\Development\Babeldoc\build
Copying over the webapps
D:\Development\Babeldoc\build\lib\babeldoc_soapfeed.war
D:\Development\Babeldoc\build\lib\babeldoc-console.war
D:\Development\Babeldoc\build\lib\babeldoc-httpfeed.war
3 file(s) copied.
D:\Development\Babeldoc\build\lib\babeldoc_web.jar
D:\Development\Babeldoc\build\lib\jaxm-runtime.jar
D:\Development\Babeldoc\build\lib\babeldoc_crypto.jar
D:\Development\Babeldoc\build\lib\xerces.jar
D:\Development\Babeldoc\build\lib\saaj-api.jar
D:\Development\Babeldoc\build\lib\activation.jar
D:\Development\Babeldoc\build\lib\jaxm-api.jar
D:\Development\Babeldoc\build\lib\commons-collections.jar
D:\Development\Babeldoc\build\lib\commons-pool.jar
D:\Development\Babeldoc\build\lib\batik.jar
D:\Development\Babeldoc\build\lib\classes12.jar
D:\Development\Babeldoc\build\lib\saaj-ri.jar
D:\Development\Babeldoc\build\lib\xmlsec.jar
D:\Development\Babeldoc\build\lib\babeldoc_soap.jar
D:\Development\Babeldoc\build\lib\servlet.jar
D:\Development\Babeldoc\build\lib\mail.jar
D:\Development\Babeldoc\build\lib\babeldoc-scanner.jar
D:\Development\Babeldoc\build\lib\fop.jar
D:\Development\Babeldoc\build\lib\xalan.jar
D:\Development\Babeldoc\build\lib\js.jar
D:\Development\Babeldoc\build\lib\avalon-framework.jar
D:\Development\Babeldoc\build\lib\babeldoc_sql.jar
D:\Development\Babeldoc\build\lib\commons-net-1.0.0-dev.jar
D:\Development\Babeldoc\build\lib\babeldoc_conversion.jar
D:\Development\Babeldoc\build\lib\commons-logging.jar
D:\Development\Babeldoc\build\lib\log4j.jar
D:\Development\Babeldoc\build\lib\commons-lang.jar
D:\Development\Babeldoc\build\lib\commons-digester.jar
D:\Development\Babeldoc\build\lib\mm.mysql-2.0.14-bin.jar
D:\Development\Babeldoc\build\lib\ostermiller-utils.jar
D:\Development\Babeldoc\build\lib\xml-apis.jar
D:\Development\Babeldoc\build\lib\babeldoc_core.jar
D:\Development\Babeldoc\build\lib\velocity.jar
D:\Development\Babeldoc\build\lib\JTidy.jar
D:\Development\Babeldoc\build\lib\babeldoc_babelfish.jar
D:\Development\Babeldoc\build\lib\commons-beanutils.jar
D:\Development\Babeldoc\build\lib\commons-dbcp.jar
D:\Development\Babeldoc\build\lib\babeldoc_gui.jar
D:\Development\Babeldoc\build\lib\bsf.jar
D:\Development\Babeldoc\build\lib\dom4j.jar
D:\Development\Babeldoc\build\lib\commons-cli.jar
41 file(s) copied.
Using BABELDOC_USER=d:\Development\User
CLASSPATH=d:\j2sdk1.4.2\lib\tools.jar
Using D:\jakarta-tomcat-4.1.24\bin\catalina run
Using CATALINA_BASE: D:\jakarta-tomcat-4.1.24
Using CATALINA_HOME: D:\jakarta-tomcat-4.1.24
Using CATALINA_TMPDIR: D:\jakarta-tomcat-4.1.24\temp
Using JAVA_HOME: D:\j2sdk1.4.2
Sep 19, 2003 12:43:53 PM org.apache.commons.modeler.Registry loadRegistry
INFO: Loading registry information
Sep 19, 2003 12:43:53 PM org.apache.commons.modeler.Registry getRegistry
INFO: Creating new Registry instance
Sep 19, 2003 12:43:54 PM org.apache.commons.modeler.Registry getServer
INFO: Creating MBeanServer
Starting service Tomcat-Standalone
Apache Tomcat/4.1.24
Sep 19, 2003 12:44:07 PM org.apache.jk.common.ChannelSocket init
INFO: JK2: ajp13 listening on /0.0.0.0:8009
Sep 19, 2003 12:44:17 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/10532 config=D:\jakarta-tomcat-
4.1.24\conf\jk2.pro
perties
Starting service Tomcat-Apache
Apache Tomcat/4.1.24
<===========all ok until I type localhost/babeldoc-console into a browser,
then:=====>
<2003-09-19 12:38:22,671> ERROR [HttpProcessor[80][4]] : Error trying to
insta
tiate: simple
java.lang.NullPointerException
at com.babeldoc.core.user.UserResourceFactory.getInstance(Unknown
Sourc
)
at com.babeldoc.web.main.ConsoleServlet.handleSecurity(Unknown
Source)
at com.babeldoc.web.main.ConsoleServlet.handleRequest(Unknown
Source)
at org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServle
.java:372)
at org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.ja
a:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
ilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
alve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContext
alve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.
ava:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatch
rValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.
ava:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.j
va:376)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
ve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcess
r.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.j
va:1151)
at java.lang.Thread.run(Thread.java:534)
<2003-09-19 12:38:22,671> ERROR [HttpProcessor[80][4]] : Error
java.lang.NullPointerException
at com.babeldoc.web.main.ConsoleServlet.handleSecurity(Unknown
Source)
at com.babeldoc.web.main.ConsoleServlet.handleRequest(Unknown
Source)
at org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServle
.java:372)
at org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.ja
a:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
ilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
alve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContext
alve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.
ava:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatch
rValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.
ava:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.j
va:376)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
ve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcess
r.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.j
va:1151)
at java.lang.Thread.run(Thread.java:534)
<2003-09-19 12:38:22,671> ERROR [HttpProcessor[80][3]] : Error trying to
insta
tiate: simple
java.lang.NullPointerException
at com.babeldoc.core.user.UserResourceFactory.getInstance(Unknown
Sourc
)
at com.babeldoc.web.main.ConsoleServlet.handleSecurity(Unknown
Source)
at com.babeldoc.web.main.ConsoleServlet.handleRequest(Unknown
Source)
at org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServle
.java:372)
at org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.ja
a:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
ilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
alve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContext
alve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.
ava:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatch
rValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.
ava:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.j
va:376)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
ve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcess
r.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.j
va:1151)
at java.lang.Thread.run(Thread.java:534)
<2003-09-19 12:38:22,687> ERROR [HttpProcessor[80][3]] : Error
java.lang.NullPointerException
at com.babeldoc.web.main.ConsoleServlet.handleSecurity(Unknown
Source)
at com.babeldoc.web.main.ConsoleServlet.handleRequest(Unknown
Source)
at org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServle
.java:372)
at org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.ja
a:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
ilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
alve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContext
alve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.
ava:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatch
rValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.
ava:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.j
va:376)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
ve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveConte
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.ja
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcess
r.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.j
va:1151)
at java.lang.Thread.run(Thread.java:534)
--
William B. Harrelson
President
Accordare
13A Medford Street, Arlington, MA 02474
t:781-646-2241 f:781-646-2242
Bil...@Ac...
|
Update of /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user
In directory sc8-pr-cvs1:/tmp/cvs-serv31604/modules/sql/src/com/babeldoc/sql/user
Modified Files:
SqlOrganization.java SqlUser.java SqlUserContext.java
SqlUserFactoryTest.java SqlUserResourceFactoryTest.java
Log Message:
javadoc updates
Index: SqlOrganization.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user/SqlOrganization.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** SqlOrganization.java 15 Aug 2003 00:25:30 -0000 1.5
--- SqlOrganization.java 17 Sep 2003 22:13:21 -0000 1.6
***************
*** 142,148 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param factory DOCUMENT ME!
*/
void setFactory(SqlUserFactory factory) {
--- 142,148 ----
/**
! * set the factory
*
! * @param factory
*/
void setFactory(SqlUserFactory factory) {
***************
*** 151,157 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
SqlUserFactory getFactory() {
--- 151,155 ----
/**
! * @return get the factory
*/
SqlUserFactory getFactory() {
***************
*** 160,166 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param id DOCUMENT ME!
*/
void setId(int id) {
--- 158,164 ----
/**
! * set the id
*
! * @param id
*/
void setId(int id) {
***************
*** 169,175 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
int getId() {
--- 167,171 ----
/**
! * @return get the id
*/
int getId() {
***************
*** 178,184 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param parentId DOCUMENT ME!
*/
void setParentId(int parentId) {
--- 174,180 ----
/**
! * set the parent id
*
! * @param parentId
*/
void setParentId(int parentId) {
***************
*** 187,193 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
int getParentId() {
--- 183,187 ----
/**
! * @return get the parent id
*/
int getParentId() {
Index: SqlUser.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user/SqlUser.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** SqlUser.java 27 Jun 2003 02:05:59 -0000 1.3
--- SqlUser.java 17 Sep 2003 22:13:21 -0000 1.4
***************
*** 127,133 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param userId DOCUMENT ME!
*/
void setUserId(int userId) {
--- 127,133 ----
/**
! * set the user id
*
! * @param userId
*/
void setUserId(int userId) {
***************
*** 136,142 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
int getUserId() {
--- 136,140 ----
/**
! * @return get the user id
*/
int getUserId() {
Index: SqlUserContext.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user/SqlUserContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** SqlUserContext.java 27 Jun 2003 02:05:59 -0000 1.3
--- SqlUserContext.java 17 Sep 2003 22:13:21 -0000 1.4
***************
*** 99,105 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public SqlUserFactory getManager() {
--- 99,103 ----
/**
! * @return get the user factory
*/
public SqlUserFactory getManager() {
***************
*** 108,114 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param orgId DOCUMENT ME!
*/
public void setOrgId(int orgId) {
--- 106,112 ----
/**
! * set the organization id
*
! * @param orgId
*/
public void setOrgId(int orgId) {
***************
*** 117,123 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public int getOrgId() {
--- 115,119 ----
/**
! * @return get the organziation id
*/
public int getOrgId() {
***************
*** 126,132 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param password DOCUMENT ME!
*/
public void setPassword(String password) {
--- 122,128 ----
/**
! * set the password
*
! * @param password
*/
public void setPassword(String password) {
***************
*** 135,141 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public String getPassword() {
--- 131,135 ----
/**
! * @return get the password
*/
public String getPassword() {
***************
*** 144,150 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public IUser getUser() {
--- 138,142 ----
/**
! * @return get the user
*/
public IUser getUser() {
***************
*** 159,165 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param userId DOCUMENT ME!
*/
public void setUserId(int userId) {
--- 151,157 ----
/**
! * set the user id
*
! * @param userId
*/
public void setUserId(int userId) {
***************
*** 168,174 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public int getUserId() {
--- 160,164 ----
/**
! * @return get the user id
*/
public int getUserId() {
***************
*** 177,183 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param userName DOCUMENT ME!
*/
public void setUserName(String userName) {
--- 167,173 ----
/**
! * set the user name
*
! * @param userName
*/
public void setUserName(String userName) {
***************
*** 186,192 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public String getUserName() {
--- 176,180 ----
/**
! * @return get the user name
*/
public String getUserName() {
***************
*** 195,201 ****
/**
! * TODO: DOCUMENT ME!
*
! * @param typeId DOCUMENT ME!
*/
void setTypeId(int typeId) {
--- 183,189 ----
/**
! * set the type id
*
! * @param typeId
*/
void setTypeId(int typeId) {
***************
*** 204,210 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
int getTypeId() {
--- 192,196 ----
/**
! * @return get the type id
*/
int getTypeId() {
Index: SqlUserFactoryTest.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user/SqlUserFactoryTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** SqlUserFactoryTest.java 27 Jun 2003 02:05:59 -0000 1.3
--- SqlUserFactoryTest.java 17 Sep 2003 22:13:21 -0000 1.4
***************
*** 110,116 ****
/**
! * TODO: DOCUMENT ME!
*
! * @return DOCUMENT ME!
*/
public static Test suite() {
--- 110,116 ----
/**
! * Test suite
*
! * @return
*/
public static Test suite() {
***************
*** 360,366 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void setUp() throws Exception {
--- 360,366 ----
/**
! * set up test
*
! * @throws Exception
*/
protected void setUp() throws Exception {
***************
*** 370,376 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void tearDown() throws Exception {
--- 370,376 ----
/**
! * tear down test
*
! * @throws Exception
*/
protected void tearDown() throws Exception {
Index: SqlUserResourceFactoryTest.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/sql/src/com/babeldoc/sql/user/SqlUserResourceFactoryTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** SqlUserResourceFactoryTest.java 27 Jun 2003 02:05:59 -0000 1.3
--- SqlUserResourceFactoryTest.java 17 Sep 2003 22:13:21 -0000 1.4
***************
*** 114,120 ****
/**
! * TODO: DOCUMENT ME!
*
! * @return DOCUMENT ME!
*/
public static Test suite() {
--- 114,120 ----
/**
! * make a test
*
! * @return
*/
public static Test suite() {
***************
*** 189,195 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void setUp() throws Exception {
--- 189,195 ----
/**
! * setup the tests
*
! * @throws Exception
*/
protected void setUp() throws Exception {
***************
*** 200,206 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void tearDown() throws Exception {
--- 200,206 ----
/**
! * teardown the tests
*
! * @throws Exception
*/
protected void tearDown() throws Exception {
|
|
From: <tr...@us...> - 2003-09-17 22:13:32
|
Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker
In directory sc8-pr-cvs1:/tmp/cvs-serv31604/modules/scanner/src/com/babeldoc/scanner/worker
Modified Files:
ExternalApplicationScanner.java
Log Message:
javadoc updates
Index: ExternalApplicationScanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/ExternalApplicationScanner.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** ExternalApplicationScanner.java 17 Sep 2003 21:11:57 -0000 1.7
--- ExternalApplicationScanner.java 17 Sep 2003 22:13:20 -0000 1.8
***************
*** 181,187 ****
/**
! * TODO: DOCUMENT ME!
! *
! * @return DOCUMENT ME!
*/
public Collection getTypeSpecificOptions() {
--- 181,185 ----
/**
! * @return get the config info type specific options
*/
public Collection getTypeSpecificOptions() {
|
|
From: <tr...@us...> - 2003-09-17 22:13:32
|
Update of /cvsroot/babeldoc/babeldoc/modules/soap/src/com/babeldoc/soap/pipeline/command
In directory sc8-pr-cvs1:/tmp/cvs-serv31604/modules/soap/src/com/babeldoc/soap/pipeline/command
Modified Files:
SoapPipelineFeeder.java
Log Message:
javadoc updates
Index: SoapPipelineFeeder.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/soap/src/com/babeldoc/soap/pipeline/command/SoapPipelineFeeder.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** SoapPipelineFeeder.java 7 Aug 2003 08:46:35 -0000 1.11
--- SoapPipelineFeeder.java 17 Sep 2003 22:13:20 -0000 1.12
***************
*** 68,71 ****
--- 68,72 ----
import com.babeldoc.core.I18n;
import com.babeldoc.core.LogService;
+ import com.babeldoc.core.BabeldocCommand;
import com.babeldoc.soap.pipeline.util.SoapHelper;
***************
*** 98,104 ****
* @version 1.0
*/
! public class SoapPipelineFeeder extends com.babeldoc.core.BabeldocCommand {
! /* TODO should these things be configurable? how? */
!
/** constant: the uri */
public static final String URI = "urn:babeldoc";
--- 99,104 ----
* @version 1.0
*/
! public class SoapPipelineFeeder
! extends BabeldocCommand {
/** constant: the uri */
public static final String URI = "urn:babeldoc";
|
|
From: <tr...@us...> - 2003-09-17 22:13:32
|
Update of /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/journal
In directory sc8-pr-cvs1:/tmp/cvs-serv31604/modules/core/src/com/babeldoc/core/journal
Modified Files:
JournalTest.java
Log Message:
javadoc updates
Index: JournalTest.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/core/src/com/babeldoc/core/journal/JournalTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** JournalTest.java 27 Jun 2003 02:19:57 -0000 1.3
--- JournalTest.java 17 Sep 2003 22:13:20 -0000 1.4
***************
*** 112,116 ****
/**
! * TODO: DOCUMENT ME!
*
* @return DOCUMENT ME!
--- 112,116 ----
/**
! * Test suite
*
* @return DOCUMENT ME!
***************
*** 123,129 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
public void testForkTicket() throws Exception {
--- 123,129 ----
/**
! * test forking tickets
*
! * @throws Exception
*/
public void testForkTicket() throws Exception {
***************
*** 133,139 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
public void testGetNewTicket() throws Exception {
--- 133,139 ----
/**
! * test getting new ticket
*
! * @throws Exception
*/
public void testGetNewTicket() throws Exception {
***************
*** 142,148 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
public void testUpdateDocument() throws Exception {
--- 142,148 ----
/**
! * test updating document
*
! * @throws Exception
*/
public void testUpdateDocument() throws Exception {
***************
*** 154,160 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
public void testUpdateStatus() throws Exception {
--- 154,160 ----
/**
! * testimg i[date statis
*
! * @throws Exception
*/
public void testUpdateStatus() throws Exception {
***************
*** 164,170 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void setUp() throws Exception {
--- 164,170 ----
/**
! * Setup the test
*
! * @throws Exception
*/
protected void setUp() throws Exception {
***************
*** 174,180 ****
/**
! * TODO: DOCUMENT ME!
*
! * @throws Exception DOCUMENT ME!
*/
protected void tearDown() throws Exception {
--- 174,180 ----
/**
! * Teardown the test
*
! * @throws Exception
*/
protected void tearDown() throws Exception {
|
|
From: <tr...@us...> - 2003-09-17 22:13:32
|
Update of /cvsroot/babeldoc/babeldoc/modules/soap/src/com/babeldoc/soap/pipeline/servlet
In directory sc8-pr-cvs1:/tmp/cvs-serv31604/modules/soap/src/com/babeldoc/soap/pipeline/servlet
Modified Files:
SoapPipelineFeeder.java
Log Message:
javadoc updates
Index: SoapPipelineFeeder.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/soap/src/com/babeldoc/soap/pipeline/servlet/SoapPipelineFeeder.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** SoapPipelineFeeder.java 27 Jun 2003 00:35:46 -0000 1.7
--- SoapPipelineFeeder.java 17 Sep 2003 22:13:21 -0000 1.8
***************
*** 69,72 ****
--- 69,74 ----
import com.babeldoc.core.journal.JournalException;
import com.babeldoc.core.journal.JournalFactory;
+ import com.babeldoc.core.LogService;
+ import com.babeldoc.core.I18n;
import com.babeldoc.soap.pipeline.util.SoapHelper;
***************
*** 128,132 ****
//debugHeader(request);
String pipeline = getPipeline(request);
! com.babeldoc.core.LogService.getInstance().logDebug(com.babeldoc.core.I18n.get(
"017006", pipeline));
--- 130,134 ----
//debugHeader(request);
String pipeline = getPipeline(request);
! LogService.getInstance().logDebug(com.babeldoc.core.I18n.get(
"017006", pipeline));
***************
*** 167,182 ****
// }
} catch (Exception e) {
! com.babeldoc.core.LogService.getInstance().logError(e);
throw new ServletException("JAXM POST failed " + e.getMessage(), e);
}
} else {
// TODO send SOAPFault
! com.babeldoc.core.LogService.getInstance().logError(com.babeldoc.core.I18n.get(
! "017001"), null);
}
} else {
// TODO send SOAPFault
! com.babeldoc.core.LogService.getInstance().logError(com.babeldoc.core.I18n.get(
! "017003"), null);
}
}
--- 169,182 ----
// }
} catch (Exception e) {
! LogService.getInstance().logError(e);
throw new ServletException("JAXM POST failed " + e.getMessage(), e);
}
} else {
// TODO send SOAPFault
! LogService.getInstance().logError(I18n.get("017001"), null);
}
} else {
// TODO send SOAPFault
! LogService.getInstance().logError(I18n.get("017003"), null);
}
}
|
2 messages has been excluded from this view by a project administrator.
