babeldoc-devel — Babeldoc developer list

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner/worker MailboxScanner.java,1.30,1.31

[<de...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker
In directory sc8-pr-cvs1:/tmp/cvs-serv11953/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker

Modified Files:
	MailboxScanner.java 
Log Message:
Fixed bugs #865417 and #865679
- Throwing exceptions during processing a message will not stop processing other messages
- Binary attachments are now handled properly (you should set binary=true) in scanner config
- Also new config option has been added to MailboxScanner - deleteInvalid which can be used for deleting messages that are not valid (that raise exceptions)
USE THIS OPTION WITH CAUTION since it can be destructive. It can be usefull when you know that valid e-mails does not throw exceptions and you want to delete all other mails


Index: MailboxScanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/MailboxScanner.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -C2 -d -r1.30 -r1.31
*** MailboxScanner.java	4 Dec 2003 00:44:42 -0000	1.30
--- MailboxScanner.java	25 Dec 2003 14:15:50 -0000	1.31
***************
*** 1,70 ****
! /* ====================================================================
!  * The Apache Software License, Version 1.1
!  *
!  * Copyright (c) 2000 The Apache Software Foundation.  All rights
!  * reserved.
!  *
   * Redistribution and use in source and binary forms, with or without
!  * modification, are permitted provided that the following conditions
!  * are met:
!  *
[...1022 lines suppressed...]
  
!     options.add(new ConfigOption(MailboxScanner.FROM_FILTER,
!         IConfigOptionType.STRING, null, true, I18n
!             .get("scanner.MailboxScannerInfo.option.fromFilter")));
  
!     options.add(new ConfigOption(MailboxScanner.TO_FILTER,
!         IConfigOptionType.STRING, null, true, I18n
!             .get("scanner.MailboxScannerInfo.option.toFilter")));
  
!     options.add(new ConfigOption(MailboxScanner.SUBJECT_FILTER,
!         IConfigOptionType.STRING, null, true, I18n
!             .get("scanner.MailboxScannerInfo.option.subjectFilter")));
  
!     options.add(new ConfigOption(MailboxScanner.DELETE,
!         IConfigOptionType.BOOLEAN, "false", true, I18n
!             .get("scanner.MailboxScannerInfo.option.deleteInvalid")));
! 
!     return options;
!   }
  }

[Babeldoc-devel] babeldoc/modules/init/src/com/babeldoc/init Main.java,1.6.4.1,1.6.4.2

[<tr...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init
In directory sc8-pr-cvs1:/tmp/cvs-serv19377/modules/init/src/com/babeldoc/init

Modified Files:
      Tag: V1-2
	Main.java 
Log Message:
updated error scanning directories for the init/main.jar

Index: Main.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init/Main.java,v
retrieving revision 1.6.4.1
retrieving revision 1.6.4.2
diff -C2 -d -r1.6.4.1 -r1.6.4.2
*** Main.java	7 Dec 2003 00:50:50 -0000	1.6.4.1
--- Main.java	24 Dec 2003 21:24:52 -0000	1.6.4.2
***************
*** 79,83 ****
  import java.net.MalformedURLException;
  
- 
  /**
   * Main entry point for babeldoc using a custom class loader to avoid the very
--- 79,82 ----
***************
*** 85,88 ****
--- 84,88 ----
   */
  public class Main {
+ 	
    //  private static ClassLoader loader;
    public static final String BABELDOC_HOME = "babeldoc.home";
***************
*** 262,274 ****
          File file = new File(token);
          if (file.exists() && (
!         		(token.endsWith(DOT_JAR)) ||
!         		(token.endsWith(DOT_ZIP)) ||
!         		(file.isDirectory()) ) ) {
          	//System.out.println("Adding: "+token);
!         	files.add(file);
          } else {
          	//System.out.println("Ignoring  : "+token);
          }
!         }
        return (File[])files.toArray(new File[0]);
      } else {
--- 262,274 ----
          File file = new File(token);
          if (file.exists() && (
!         			(token.endsWith(DOT_JAR)) ||
!         			(token.endsWith(DOT_ZIP)) ||
!         			(file.isDirectory()) ) ) {
          	//System.out.println("Adding: "+token);
!           files.add(file);
          } else {
          	//System.out.println("Ignoring  : "+token);
          }
!       }
        return (File[])files.toArray(new File[0]);
      } else {

[Babeldoc-devel] babeldoc build.properties,1.21,1.21.2.1

[<tr...@us...>]

Update of /cvsroot/babeldoc/babeldoc
In directory sc8-pr-cvs1:/tmp/cvs-serv19377

Modified Files:
      Tag: V1-2
	build.properties 
Log Message:
updated error scanning directories for the init/main.jar

Index: build.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/build.properties,v
retrieving revision 1.21
retrieving revision 1.21.2.1
diff -C2 -d -r1.21 -r1.21.2.1
*** build.properties	16 Nov 2003 18:40:26 -0000	1.21
--- build.properties	24 Dec 2003 21:24:52 -0000	1.21.2.1
***************
*** 9,13 ****
  
  src = ./src
! babeldoc_version = 1.2.0
  config = ./config
  modules = ./modules
--- 9,13 ----
  
  src = ./src
! babeldoc_version = 1.2.1
  config = ./config
  modules = ./modules

[Babeldoc-devel] babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile FlatFileConverter.java,1.2,1.3 LineSegmentData.java,1.1,1.2

[<tr...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile
In directory sc8-pr-cvs1:/tmp/cvs-serv31614

Modified Files:
	FlatFileConverter.java LineSegmentData.java 
Log Message:
Added fixes for bugs: 865405,  865397
and RFE: 865418

Index: FlatFileConverter.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/FlatFileConverter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** FlatFileConverter.java	30 Oct 2003 00:15:56 -0000	1.2
--- FlatFileConverter.java	24 Dec 2003 20:14:14 -0000	1.3
***************
*** 390,398 ****
        int width = lineSegment.width;
        String value = lineSegment.value;
  
!       if ((line.length() > (column + width)) &&
!             line.substring(column, width).equals(value)) {
!         Element segmentElement = handleLineSegmentElement(element, lineSegment);
  
          try {
            handlineLineSegmentElementData(segmentElement, lineSegment, para);
--- 390,400 ----
        int width = lineSegment.width;
        String value = lineSegment.value;
+       String pattern = lineSegment.pattern;
  
!       if ((pattern != null && line.matches(pattern)) || ((width > 0)
!           && (line.length() > (column + width)) &&
!           line.substring(column, column + width).equals(value))) {
  
+         Element segmentElement = handleLineSegmentElement(element, lineSegment);
          try {
            handlineLineSegmentElementData(segmentElement, lineSegment, para);

Index: LineSegmentData.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/LineSegmentData.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** LineSegmentData.java	19 Jul 2003 13:16:47 -0000	1.1
--- LineSegmentData.java	24 Dec 2003 20:14:14 -0000	1.2
***************
*** 85,88 ****
--- 85,89 ----
    public int conversionType;
    public int width;
+   public String pattern;
  
    /**
***************
*** 97,100 ****
--- 98,102 ----
                                      .append("conversionType", conversionType)
                                      .append("value", value)
+                                     .append("pattern", pattern)
                                      .append("startGroup", startGroup)
                                      .append("endGroup", endGroup)

[Babeldoc-devel] babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/digester DigesterConversionUnmarshaller.java,1.3,1.4 InputDocument.java,1.2,1.3 LineSegment.java,1.2,1.3

[<tr...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/digester
In directory sc8-pr-cvs1:/tmp/cvs-serv31614/digester

Modified Files:
	DigesterConversionUnmarshaller.java InputDocument.java 
	LineSegment.java 
Log Message:
Added fixes for bugs: 865405,  865397
and RFE: 865418

Index: DigesterConversionUnmarshaller.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/digester/DigesterConversionUnmarshaller.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** DigesterConversionUnmarshaller.java	16 Sep 2003 05:19:00 -0000	1.3
--- DigesterConversionUnmarshaller.java	24 Dec 2003 20:14:15 -0000	1.4
***************
*** 459,462 ****
--- 459,464 ----
      digester.addCallMethod("conversion/line-segments/segment/end-group-name",
        "setEndGroupName", 0);
+     digester.addCallMethod("conversion/line-segments/segment/segment-pattern",
+       "setSegmentPattern", 0);
  
      // Handle line segment - line fields

Index: InputDocument.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/digester/InputDocument.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** InputDocument.java	30 Oct 2003 00:15:56 -0000	1.2
--- InputDocument.java	24 Dec 2003 20:14:15 -0000	1.3
***************
*** 108,113 ****
     */
    public void setFieldSeparator(String fieldSeparator) {
! //    System.out.println("[InputDocument.setFieldSeparator]: "+fieldSeparator);
!     this.fieldSeparator = fieldSeparator;
    }
  
--- 108,118 ----
     */
    public void setFieldSeparator(String fieldSeparator) {
!     // System.out.println ("[InputDocument.setFieldSeparator]:
!      // "+fieldSeparator);
!     if (fieldSeparator.equals("\\t")) {
!       this.fieldSeparator = "\t";
!     } else {
!       this.fieldSeparator = fieldSeparator;
!     }
    }
  

Index: LineSegment.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/conversion/src/com/babeldoc/conversion/flatfile/digester/LineSegment.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** LineSegment.java	30 Oct 2003 00:15:56 -0000	1.2
--- LineSegment.java	24 Dec 2003 20:14:15 -0000	1.3
***************
*** 82,90 ****
    private String beginGroupName;
    private String endGroupName;
!   private String segmentColumn;
    private String segmentName;
!   private String segmentValue;
!   private String segmentWidth;
! 
    /**
     * setBeginGroupName
--- 82,90 ----
    private String beginGroupName;
    private String endGroupName;
!   private String segmentColumn = "0";
    private String segmentName;
!   private String segmentValue = "";
!   private String segmentWidth = "0";
!   private String segmentPattern;
    /**
     * setBeginGroupName
***************
*** 250,253 ****
--- 250,261 ----
  //    System.out.println("[LineSegment.addLineField]");
      this.lineFields.add(lineField);
+   }
+ 
+   public String getSegmentPattern() {
+     return segmentPattern;
+   }
+ 
+   public void setSegmentPattern(String segmentPattern) {
+     this.segmentPattern = segmentPattern;
    }
  }

[Babeldoc-devel] RE: Configuration change notification...

[McDonald, B. <Bru...@ba...>]

This bounced - I have included the files in a zip archive

-----Original Message-----
From: McDonald, Bruce 
Sent: Tuesday, December 16, 2003 1:49 PM
To: bab...@li...
Subject: Configuration change notification...


All,

I have implemented a set of classes that could form the basis for configuration change notification.  These are:

1.  IConfigChangeListener - Interface which accepts a configuration change notification.  This is implemented by those client classes that are interested in notifications.
2.  ConfigChangeEvent - a simple wrapper for configuration change data.
3.  IConfigChangeNotifier - Interface for those IConfigServices that generate configuration change events.
4.  ConfigChangeNotifier - implementation of 3 for delegation into a Configuration to handle the generation of configuration events.
5.  ConfigService - additions to this class to handle and delegate the IConfigChangeNotifier methods to the contained IConfigServer class.

FW: [Babeldoc-devel] Pipeline cache refreshing

[McDonald, B. <Bru...@ba...>]

Heres the email response to the email that I sent to Mike (foolishly not copying the list)

-----Original Message-----
From: Michael Ansley [mailto:mic...@ze...]
Sent: Thursday, December 11, 2003 4:02 PM
To: McDonald, Bruce
Subject: RE: [Babeldoc-devel] Pipeline cache refreshing


OK, so you are saying that generally, data config clients get their data
on startup, and then wouldn't query for data again until a refresh took
place (thus getting around the "change while processing" problem)?  But,
that behaviour is designed into each individual component, so it could
be changed on a case-by-case basis?

So, we could implement the Listener model, and then check each component
to ensure that it's safe?

Cheers...


MikeA



On Thu, 2003-12-11 at 20:37, McDonald, Bruce wrote:
> Mike,
> 
> You raise valid points, but I would caution you not to try to set policy globally.  The pipeline (for instance) would know to reload its configuration only when no pipelines are running.  This policy is pipeline specific.  Other configuration data clients would be able to react differently to data change messages.
> 
> Bruce.
> 
> -----Original Message-----
> From: Michael Ansley [mailto:mic...@ze...]
> Sent: Thursday, December 11, 2003 1:40 PM
> To: bab...@li...
> Subject: RE: [Babeldoc-devel] Pipeline cache refreshing
> 
> 
> I think that it requires more than that.  First of all, do we want
> pipelines changing while documents are being processed?  If not, then,
> do we version configs?  How?  What is the most basic operation that is
> allowed a consistent set of config data?  All pipelines should present a
> consistent set of config data to any single document.  Once any document
> has started processing, the config data used for processing that
> document should be fixed, in my opinion (I'm open to arguments to the
> contrary, though).  A guess it's a bit like transactioning metadata in a
> relational database.  If somebody does an ALTER TABLE that affects data
> your query is busy with, you don't want it affecting your data (because
> it's likely to be catastrophic).
> 
> So, I'm open to ideas and opinions.
> 
> Cheers...
> 
> 
> MikeA
> 
> 
> 
> On Thu, 2003-12-11 at 14:17, McDonald, Bruce wrote:
> > Yes, 
> > 
> > Do that.
> > 
> > At a more fundamental level, we probably need to implement an listener pattern on the configserver.  The client classes of the configuration data (pipelines, journal, etc, etc) add themselves as data change listeners to the configuration classes thereby being notified when the underlying data changes.  They could register for change notices when the config files changes...
> > 
> > just an idea.
> > 
> > Bruce.
> > 
> > -----Original Message-----
> > From: Michael Ansley [mailto:mic...@ze...]
> > Sent: Wednesday, December 10, 2003 7:22 PM
> > To: bab...@li...
> > Subject: [Babeldoc-devel] Pipeline cache refreshing
> > 
> > 
> > Hi,
> > 
> > I'm back on the trail of config refreshing, and now attacking the
> > pipeline configs.  It seems that PipelineFactory has a method
> > clearCache() and also clearCache(String name), but these methods are not
> > deemed generic to the role of IPipelineFactory.  Can I make them
> > generic?  Or are there implementations of IPipelineFactory for which
> > they do not make sense?
> > 
> > Cheers...
> > 
> > 
> > MikeA
> > 
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Re: Pipeline cache refreshing

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

On the whole, I'm happy with Bruce's line of thought.  I think that it
will be useful to build up a library of "local" configuration management
tools, helping components to manage their own configuration after it has
been retrieved using the existing functions.

Initially, I also thought that the existing configuration classes should
be responsible for the versioning and time-control of the config data,
but I think Bruce's idea works well, as it doesn't force complex config
handling where it is not required.

Cheers...


MikeA



On Sun, 2003-12-14 at 23:51, Bruce McDonald wrote:
> Sherman, All
> 
> Unfortunately I did not respond to the list with my email to Mike, but the 
> gist of what I said was this:  Introduce a listener / notification scheme for 
> the configuration server and the configuration clients.  The configuration 
> clients then can listen for changes to changes in the configuration data.  
> They can choose to update their own caches when it is "correct" for them to 
> do so.  This will mean that the pipeline factory will only flush its caches 
> (and subsequently reload from the changed data) after it has finished 
> processing all pipelines.  The scanner would do something similar.
> 
> The point is that the policy of how the configuration clients react to 
> configuration data changes doesnt (and shouldn't) be set globally - it is up 
> to the configuration client code to react in a fashion that is correct for 
> itself.
> 
> I think that this should cover the situation described by you.
> 
> So here is the rough sequence of events:
> 
> 1.  Configuration client (say, PipelineFactory, registers itself as a 
> configuration data change listener on the "pipeline/config" configuration.
> 2.  When the configuration server (though the configuration implementation) 
> notices that the "pipeline/config" has changed, it fires a DataChange event 
> to all listeners.
> 3.  The PipelineFactory then determines whether it can update its own cache.  
> This is probably done using two threads with a semaphore.  The pipeline 
> processing code grabs the semaphore and only releases it when it has finished 
> processing.  The configuration updater then blocks for the semaphore and when 
> the semaphore is free, it updates the configuration and releases the 
> semaphore.
> 
> Comments?
> 
> Bruce.
> 
> On Sunday 14 December 2003 05:21 pm, Sherman Wood wrote:
> > Ken Geis and I are just getting into this, as part of dynamic deployment of
> > new/changed pipeline definitions, scanners and supporting files ie. XSLs.
> >
> > I think that at the point in time where the pipeline(s) is being
> > reconfigured:
> >
> > * The scanner for the pipeline is stopped from accepting new documents
> > * Documents already in the pipeline finish processing
> > * The reconfiguration occurs: new files deployed etc
> > * A clearCache on the effected pipeline happens
> > * The scanner for the pipeline restarts
> >
> > To Mike's point about the "transactionality" of config data, it seems to me
> > that it is an unnecessary complication to implement the listener pattern to
> > reflect config updates.
> >
> > Cheers,
> >
> > Sherman
> >
> > > Subject: RE: [Babeldoc-devel] Pipeline cache refreshing
> > > From: Michael Ansley <mic...@ze...>
> > > To: bab...@li...
> > > Organization:
> > > Date: 11 Dec 2003 18:39:52 +0000
> > >
> > > I think that it requires more than that.  First of all, do we want
> > > pipelines changing while documents are being processed?  If not, then,
> > > do we version configs?  How?  What is the most basic operation that is
> > > allowed a consistent set of config data?  All pipelines should present a
> > > consistent set of config data to any single document.  Once any document
> > > has started processing, the config data used for processing that
> > > document should be fixed, in my opinion (I'm open to arguments to the
> > > contrary, though).  A guess it's a bit like transactioning metadata in a
> > > relational database.  If somebody does an ALTER TABLE that affects data
> > > your query is busy with, you don't want it affecting your data (because
> > > it's likely to be catastrophic).
> > >
> > > So, I'm open to ideas and opinions.
> > >
> > > Cheers...
> > >
> > >
> > > MikeA
> > >
> > > On Thu, 2003-12-11 at 14:17, McDonald, Bruce wrote:
> > > > Yes,
> > > >
> > > > Do that.
> > > >
> > > > At a more fundamental level, we probably need to implement an listener
> >
> > pattern on the configserver.  The client classes of the configuration data
> > (pipelines, journal, etc, etc) add themselves as data change listeners to
> > the configuration classes thereby being notified when the underlying data
> > changes.  They could register for change notices when the config files
> > changes...
> >
> > > > just an idea.
> > > >
> > > > Bruce.
> > > >
> > > > -----Original Message-----
> > > > From: Michael Ansley [mailto:mic...@ze...]
> > > > Sent: Wednesday, December 10, 2003 7:22 PM
> > > > To: bab...@li...
> > > > Subject: [Babeldoc-devel] Pipeline cache refreshing
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm back on the trail of config refreshing, and now attacking the
> > > > pipeline configs.  It seems that PipelineFactory has a method
> > > > clearCache() and also clearCache(String name), but these methods are
> > > > not deemed generic to the role of IPipelineFactory.  Can I make them
> > > > generic?  Or are there implementations of IPipelineFactory for which
> > > > they do not make sense?
> > > >
> > > > Cheers...
> > > >
> > > >
> > > > MikeA
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Re: Pipeline cache refreshing

[Bruce M. <br...@mc...>]

Sherman, All

Unfortunately I did not respond to the list with my email to Mike, but the 
gist of what I said was this:  Introduce a listener / notification scheme for 
the configuration server and the configuration clients.  The configuration 
clients then can listen for changes to changes in the configuration data.  
They can choose to update their own caches when it is "correct" for them to 
do so.  This will mean that the pipeline factory will only flush its caches 
(and subsequently reload from the changed data) after it has finished 
processing all pipelines.  The scanner would do something similar.

The point is that the policy of how the configuration clients react to 
configuration data changes doesnt (and shouldn't) be set globally - it is up 
to the configuration client code to react in a fashion that is correct for 
itself.

I think that this should cover the situation described by you.

So here is the rough sequence of events:

1.  Configuration client (say, PipelineFactory, registers itself as a 
configuration data change listener on the "pipeline/config" configuration.
2.  When the configuration server (though the configuration implementation) 
notices that the "pipeline/config" has changed, it fires a DataChange event 
to all listeners.
3.  The PipelineFactory then determines whether it can update its own cache.  
This is probably done using two threads with a semaphore.  The pipeline 
processing code grabs the semaphore and only releases it when it has finished 
processing.  The configuration updater then blocks for the semaphore and when 
the semaphore is free, it updates the configuration and releases the 
semaphore.

Comments?

Bruce.

On Sunday 14 December 2003 05:21 pm, Sherman Wood wrote:
> Ken Geis and I are just getting into this, as part of dynamic deployment of
> new/changed pipeline definitions, scanners and supporting files ie. XSLs.
>
> I think that at the point in time where the pipeline(s) is being
> reconfigured:
>
> * The scanner for the pipeline is stopped from accepting new documents
> * Documents already in the pipeline finish processing
> * The reconfiguration occurs: new files deployed etc
> * A clearCache on the effected pipeline happens
> * The scanner for the pipeline restarts
>
> To Mike's point about the "transactionality" of config data, it seems to me
> that it is an unnecessary complication to implement the listener pattern to
> reflect config updates.
>
> Cheers,
>
> Sherman
>
> > Subject: RE: [Babeldoc-devel] Pipeline cache refreshing
> > From: Michael Ansley <mic...@ze...>
> > To: bab...@li...
> > Organization:
> > Date: 11 Dec 2003 18:39:52 +0000
> >
> > I think that it requires more than that.  First of all, do we want
> > pipelines changing while documents are being processed?  If not, then,
> > do we version configs?  How?  What is the most basic operation that is
> > allowed a consistent set of config data?  All pipelines should present a
> > consistent set of config data to any single document.  Once any document
> > has started processing, the config data used for processing that
> > document should be fixed, in my opinion (I'm open to arguments to the
> > contrary, though).  A guess it's a bit like transactioning metadata in a
> > relational database.  If somebody does an ALTER TABLE that affects data
> > your query is busy with, you don't want it affecting your data (because
> > it's likely to be catastrophic).
> >
> > So, I'm open to ideas and opinions.
> >
> > Cheers...
> >
> >
> > MikeA
> >
> > On Thu, 2003-12-11 at 14:17, McDonald, Bruce wrote:
> > > Yes,
> > >
> > > Do that.
> > >
> > > At a more fundamental level, we probably need to implement an listener
>
> pattern on the configserver.  The client classes of the configuration data
> (pipelines, journal, etc, etc) add themselves as data change listeners to
> the configuration classes thereby being notified when the underlying data
> changes.  They could register for change notices when the config files
> changes...
>
> > > just an idea.
> > >
> > > Bruce.
> > >
> > > -----Original Message-----
> > > From: Michael Ansley [mailto:mic...@ze...]
> > > Sent: Wednesday, December 10, 2003 7:22 PM
> > > To: bab...@li...
> > > Subject: [Babeldoc-devel] Pipeline cache refreshing
> > >
> > >
> > > Hi,
> > >
> > > I'm back on the trail of config refreshing, and now attacking the
> > > pipeline configs.  It seems that PipelineFactory has a method
> > > clearCache() and also clearCache(String name), but these methods are
> > > not deemed generic to the role of IPipelineFactory.  Can I make them
> > > generic?  Or are there implementations of IPipelineFactory for which
> > > they do not make sense?
> > >
> > > Cheers...
> > >
> > >
> > > MikeA
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] Re: Pipeline cache refreshing

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

Ken Geis and I are just getting into this, as part of dynamic deployment of
new/changed pipeline definitions, scanners and supporting files ie. XSLs.

I think that at the point in time where the pipeline(s) is being
reconfigured:

* The scanner for the pipeline is stopped from accepting new documents
* Documents already in the pipeline finish processing
* The reconfiguration occurs: new files deployed etc
* A clearCache on the effected pipeline happens
* The scanner for the pipeline restarts

To Mike's point about the "transactionality" of config data, it seems to me
that it is an unnecessary complication to implement the listener pattern to
reflect config updates.

Cheers,

Sherman

> Subject: RE: [Babeldoc-devel] Pipeline cache refreshing
> From: Michael Ansley <mic...@ze...>
> To: bab...@li...
> Organization:
> Date: 11 Dec 2003 18:39:52 +0000
>
> I think that it requires more than that.  First of all, do we want
> pipelines changing while documents are being processed?  If not, then,
> do we version configs?  How?  What is the most basic operation that is
> allowed a consistent set of config data?  All pipelines should present a
> consistent set of config data to any single document.  Once any document
> has started processing, the config data used for processing that
> document should be fixed, in my opinion (I'm open to arguments to the
> contrary, though).  A guess it's a bit like transactioning metadata in a
> relational database.  If somebody does an ALTER TABLE that affects data
> your query is busy with, you don't want it affecting your data (because
> it's likely to be catastrophic).
>
> So, I'm open to ideas and opinions.
>
> Cheers...
>
>
> MikeA
>
>
>
> On Thu, 2003-12-11 at 14:17, McDonald, Bruce wrote:
> > Yes,
> >
> > Do that.
> >
> > At a more fundamental level, we probably need to implement an listener
pattern on the configserver.  The client classes of the configuration data
(pipelines, journal, etc, etc) add themselves as data change listeners to
the configuration classes thereby being notified when the underlying data
changes.  They could register for change notices when the config files
changes...
> >
> > just an idea.
> >
> > Bruce.
> >
> > -----Original Message-----
> > From: Michael Ansley [mailto:mic...@ze...]
> > Sent: Wednesday, December 10, 2003 7:22 PM
> > To: bab...@li...
> > Subject: [Babeldoc-devel] Pipeline cache refreshing
> >
> >
> > Hi,
> >
> > I'm back on the trail of config refreshing, and now attacking the
> > pipeline configs.  It seems that PipelineFactory has a method
> > clearCache() and also clearCache(String name), but these methods are not
> > deemed generic to the role of IPipelineFactory.  Can I make them
> > generic?  Or are there implementations of IPipelineFactory for which
> > they do not make sense?
> >
> > Cheers...
> >
> >
> > MikeA

RE: [Babeldoc-devel] Pipeline cache refreshing

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

I think that it requires more than that.  First of all, do we want
pipelines changing while documents are being processed?  If not, then,
do we version configs?  How?  What is the most basic operation that is
allowed a consistent set of config data?  All pipelines should present a
consistent set of config data to any single document.  Once any document
has started processing, the config data used for processing that
document should be fixed, in my opinion (I'm open to arguments to the
contrary, though).  A guess it's a bit like transactioning metadata in a
relational database.  If somebody does an ALTER TABLE that affects data
your query is busy with, you don't want it affecting your data (because
it's likely to be catastrophic).

So, I'm open to ideas and opinions.

Cheers...


MikeA



On Thu, 2003-12-11 at 14:17, McDonald, Bruce wrote:
> Yes, 
> 
> Do that.
> 
> At a more fundamental level, we probably need to implement an listener pattern on the configserver.  The client classes of the configuration data (pipelines, journal, etc, etc) add themselves as data change listeners to the configuration classes thereby being notified when the underlying data changes.  They could register for change notices when the config files changes...
> 
> just an idea.
> 
> Bruce.
> 
> -----Original Message-----
> From: Michael Ansley [mailto:mic...@ze...]
> Sent: Wednesday, December 10, 2003 7:22 PM
> To: bab...@li...
> Subject: [Babeldoc-devel] Pipeline cache refreshing
> 
> 
> Hi,
> 
> I'm back on the trail of config refreshing, and now attacking the
> pipeline configs.  It seems that PipelineFactory has a method
> clearCache() and also clearCache(String name), but these methods are not
> deemed generic to the role of IPipelineFactory.  Can I make them
> generic?  Or are there implementations of IPipelineFactory for which
> they do not make sense?
> 
> Cheers...
> 
> 
> MikeA
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] Pipeline cache refreshing

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

Hi,

I'm back on the trail of config refreshing, and now attacking the
pipeline configs.  It seems that PipelineFactory has a method
clearCache() and also clearCache(String name), but these methods are not
deemed generic to the role of IPipelineFactory.  Can I make them
generic?  Or are there implementations of IPipelineFactory for which
they do not make sense?

Cheers...


MikeA

Re: [Babeldoc-devel] 1.2 Maintenance branch

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

Yes, you're right, it does need to be done on a periodic basis, so that
we have controlled tag points for each merge.

Bruce, this needs to be taken into account at each release point.  I
think that the policy should be that each point release of 1.2 must be
merged, and any outstanding issues in the maintenance branch should be
merged at the 1.3 milestone releases.  Is this feasible?

Cheers...


MikeA


On Wed, 2003-12-10 at 09:57, Hans Benedict wrote:
> On 2 Dec 2003, Michael Ansley wrote:
> 
> > Please make sure that if you fix and commit something in the 1.2 branch
> > that somebody merges the changes to the HEAD.  Otherwise we'll get
> > regression problems.  If you're not sure, let me know.
> 
> Do we have a policy about who is when performing these merges? Propably it
> is a good idea to do this just before the next release in the HEAD branch?
> 
> Regards,
> Hans
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] JTidyPipelineStage broken?

[Hans B. <ben...@ch...>]

Hi,

sort of answering my own mail...

I have now found a way to fill those Properties in JTidyPipelineStage, but
though it seems to work for me, I am not sure, whether reading the values
from the ConfigOptions directly and not via the getOptionList method,
causes any trouble.

Any comments?

Thanks,
Hans

-------------
revision 1.5:
-------------
  protected Properties getConfigProperties() {
    String[] optionKeys =
       (String[]) getInfo().getOptions().toArray(new String[0]);
    com.babeldoc.core.NameValuePair[] options =
                       this.getOptionList(optionKeys);
    Properties configProperties = new Properties();

    for (int i = 0; i < options.length; i++) {
      configProperties.put(options[i].getName(), options[i].getValue());
    }

    return configProperties;
  }

--------------
my workaround:
--------------
  protected Properties getConfigProperties() {
    Properties configProperties = new Properties();

    for (Iterator it=getInfo().getOptions().iterator();it.hasNext();) {
        ConfigOption opt =  (ConfigOption)it.next();
        if (opt.getValue()!=null) {
            configProperties.put(opt.getName(), opt.getValue());
        }
    }

    return configProperties;
  }


On Thu, 4 Dec 2003, Hans Benedict wrote:

> Hi to all,
>
> I am trying to use JTidyPipelineStage the first time since 1.0.2, but it
> throws the following exception:
>
> -------------
> java.lang.ArrayStoreException
> 	at
> java.util.AbstractCollection.toArray(AbstractCollection.java:174)
> 	at
> com.babeldoc.core.pipeline.stage.JTidyPipelineStage.getConfigProperties(JTidyPipelineStage.java:336)
> 	at
> com.babeldoc.core.pipeline.stage.JTidyPipelineStage.process(JTidyPipelineStage.java:291)
> ------------
>
> I assume that casting the ConfigOptions from getOptions() to Strings in
> line 337
> ---
>     String[] optionKeys = (String[]) getInfo().getOptions().toArray(new String[0]);
> ---
> causes the problem, but at the moment I have no idea what to do instead
>
> Any suggestions?
>
> Regards,
>          Hans
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] 1.2 Maintenance branch

[Hans B. <ben...@ch...>]

On 2 Dec 2003, Michael Ansley wrote:

> Please make sure that if you fix and commit something in the 1.2 branch
> that somebody merges the changes to the HEAD.  Otherwise we'll get
> regression problems.  If you're not sure, let me know.

Do we have a policy about who is when performing these merges? Propably it
is a good idea to do this just before the next release in the HEAD branch?

Regards,
Hans

[Babeldoc-devel] babeldoc/modules/scanner/src/com/babeldoc/scanner/worker MailboxScanner.java,1.29,1.29.4.1

[<hbe...@us...>]

Update of /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker
In directory sc8-pr-cvs1:/tmp/cvs-serv27200/modules/scanner/src/com/babeldoc/scanner/worker

Modified Files:
      Tag: V1-2
	MailboxScanner.java 
Log Message:
fixed a bug introduced by myself: if an attachment has a charset parameter in it's content-type, this should be used as the encoding when reading the inputstream

Index: MailboxScanner.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/scanner/src/com/babeldoc/scanner/worker/MailboxScanner.java,v
retrieving revision 1.29
retrieving revision 1.29.4.1
diff -C2 -d -r1.29 -r1.29.4.1
*** MailboxScanner.java	13 Oct 2003 07:24:39 -0000	1.29
--- MailboxScanner.java	10 Dec 2003 09:48:34 -0000	1.29.4.1
***************
*** 74,77 ****
--- 74,78 ----
  import java.util.Properties;
  
+ import javax.activation.MimeType;
  import javax.mail.Address;
  import javax.mail.BodyPart;
***************
*** 304,309 ****
  	private StringBuffer getMailContent(Part part) throws Exception {
  		// Code donated by Hans Benedict.
! 		BufferedReader reader =
! 			new BufferedReader(new InputStreamReader(part.getInputStream()));
  		StringBuffer result = new StringBuffer();
  		String line;
--- 305,311 ----
  	private StringBuffer getMailContent(Part part) throws Exception {
  		// Code donated by Hans Benedict.
!         MimeType type = new MimeType(part.getContentType());
!         BufferedReader reader = new BufferedReader(new InputStreamReader(
!               part.getInputStream(),type.getParameter("charset")));
  		StringBuffer result = new StringBuffer();
  		String line;

[Babeldoc-devel] babeldoc/modules/init/src/com/babeldoc/init Main.java,1.6,1.6.4.1

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

Update of /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init
In directory sc8-pr-cvs1:/tmp/cvs-serv9636/modules/init/src/com/babeldoc/init

Modified Files:
      Tag: V1-2
	Main.java 
Log Message:
Fixed an issue where directories on the classpath were not included in getClasspathFiles(), only zip and jar files.

Sent in by Walt Teh-Ming Yao <wal...@as...>


Index: Main.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init/Main.java,v
retrieving revision 1.6
retrieving revision 1.6.4.1
diff -C2 -d -r1.6 -r1.6.4.1
*** Main.java	25 Sep 2003 22:11:30 -0000	1.6
--- Main.java	7 Dec 2003 00:50:50 -0000	1.6.4.1
***************
*** 261,273 ****
          String token = st.nextToken();
          File file = new File(token);
!         if(file.exists()&&
!             (token.endsWith(DOT_JAR)||
!             token.endsWith(DOT_ZIP))) {
! //          System.out.println("Adding: "+token);
!           files.add(file);
          } else {
! //          System.out.println("Ignoring  : "+token);
          }
-       }
        return (File[])files.toArray(new File[0]);
      } else {
--- 261,274 ----
          String token = st.nextToken();
          File file = new File(token);
!         if (file.exists() && (
!         		(token.endsWith(DOT_JAR)) ||
!         		(token.endsWith(DOT_ZIP)) ||
!         		(file.isDirectory()) ) ) {
!         	//System.out.println("Adding: "+token);
!         	files.add(file);
          } else {
!         	//System.out.println("Ignoring  : "+token);
!         }
          }
        return (File[])files.toArray(new File[0]);
      } else {

[Babeldoc-devel] babeldoc/modules/init/src/com/babeldoc/init Main.java,1.6,1.7

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

Update of /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init
In directory sc8-pr-cvs1:/tmp/cvs-serv851/modules/init/src/com/babeldoc/init

Modified Files:
	Main.java 
Log Message:
Fixed an issue where directories on the classpath were not included in getClasspathFiles(), only zip and jar files.

Sent in by Walt Teh-Ming Yao <wal...@as...>

Index: Main.java
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/modules/init/src/com/babeldoc/init/Main.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** Main.java	25 Sep 2003 22:11:30 -0000	1.6
--- Main.java	6 Dec 2003 23:43:40 -0000	1.7
***************
*** 79,83 ****
  import java.net.MalformedURLException;
  
- 
  /**
   * Main entry point for babeldoc using a custom class loader to avoid the very
--- 79,82 ----
***************
*** 85,88 ****
--- 84,88 ----
   */
  public class Main {
+ 	
    //  private static ClassLoader loader;
    public static final String BABELDOC_HOME = "babeldoc.home";
***************
*** 261,271 ****
          String token = st.nextToken();
          File file = new File(token);
!         if(file.exists()&&
!             (token.endsWith(DOT_JAR)||
!             token.endsWith(DOT_ZIP))) {
! //          System.out.println("Adding: "+token);
            files.add(file);
          } else {
! //          System.out.println("Ignoring  : "+token);
          }
        }
--- 261,272 ----
          String token = st.nextToken();
          File file = new File(token);
!         if (file.exists() && (
!         			(token.endsWith(DOT_JAR)) ||
!         			(token.endsWith(DOT_ZIP)) ||
!         			(file.isDirectory()) ) ) {
!         	//System.out.println("Adding: "+token);
            files.add(file);
          } else {
!         	//System.out.println("Ignoring  : "+token);
          }
        }

Re: [Babeldoc-devel] FIX: Directories in classpath ignored in 1.2.0

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

Mike,
if you have tested it and if it really solves a
problem then please apply this patch. I am pretty
bussy these days (altough I have returned to Belgrade)
and I don't beleive I will be in the office next week.


Dejan

--- Michael Ansley <mic...@ze...> wrote:
> Anybody reviewed this?  Can I add it to the 1.2
> maintenance?
> 
> On Fri, 2003-12-05 at 08:50, Walt Teh-Ming Yao
> wrote:
> > Hi,
> > 
> > The latest stable release of Babeldoc (1.2.0)
> seems unable to handle
> > directories specified through the $CLASSPATH
> environment variable
> > properly.  The command line interface
> (bin/babeldoc) ignores any
> > directory given at $CLASSPATH.  This means none
> the examples under
> > examples/ could run as described in the user
> guide.
> > 
> > I've attached a very simple patch to allow
> directories in the $CLASSPATH
> > in case if you also regard this as a bug.  Any
> comment will be welcome.
> > 
> > Thanks.
> > 
> > -- Walt
> > 
> > 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?  SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
>
https://lists.sourceforge.net/lists/listinfo/babeldoc-devel


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [Babeldoc-devel] FIX: Directories in classpath ignored in 1.2.0

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

Anybody reviewed this?  Can I add it to the 1.2 maintenance?

On Fri, 2003-12-05 at 08:50, Walt Teh-Ming Yao wrote:
> Hi,
> 
> The latest stable release of Babeldoc (1.2.0) seems unable to handle
> directories specified through the $CLASSPATH environment variable
> properly.  The command line interface (bin/babeldoc) ignores any
> directory given at $CLASSPATH.  This means none the examples under
> examples/ could run as described in the user guide.
> 
> I've attached a very simple patch to allow directories in the $CLASSPATH
> in case if you also regard this as a bug.  Any comment will be welcome.
> 
> Thanks.
> 
> -- Walt
> 
> 

[Babeldoc-devel] babeldoc build.properties,1.21,1.22 build.xml,1.16,1.17

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

Update of /cvsroot/babeldoc/babeldoc
In directory sc8-pr-cvs1:/tmp/cvs-serv2931

Modified Files:
	build.properties build.xml 
Log Message:
Forgot to merge from TEMP_MIKEA

Index: build.properties
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/build.properties,v
retrieving revision 1.21
retrieving revision 1.22
diff -C2 -d -r1.21 -r1.22
*** build.properties	16 Nov 2003 18:40:26 -0000	1.21
--- build.properties	6 Dec 2003 00:04:55 -0000	1.22
***************
*** 9,13 ****
  
  src = ./src
! babeldoc_version = 1.2.0
  config = ./config
  modules = ./modules
--- 9,13 ----
  
  src = ./src
! babeldoc_version = 1.3.0_DEV
  config = ./config
  modules = ./modules
***************
*** 22,26 ****
  
  build.compiler=modern
! compile.debug=off
  compile.deprecation=on
  
--- 22,26 ----
  
  build.compiler=modern
! compile.debug=on
  compile.deprecation=on
  

Index: build.xml
===================================================================
RCS file: /cvsroot/babeldoc/babeldoc/build.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** build.xml	4 Sep 2003 03:16:53 -0000	1.16
--- build.xml	6 Dec 2003 00:04:56 -0000	1.17
***************
*** 226,228 ****
--- 226,288 ----
      <moduleRunner target="format" modules="${babeldoc_modules}"/>
    </target>
+   
+   <!--
+   jboss target - create jboss sar (and eventually jar, for EJB stuff) file
+   -->
+   <target
+   	name="jboss"
+   	depends="build">
+   	<echo message="Building JBoss service archive"/>
+   	<mkdir dir="build/babeldoc-service.sar"/>
+   	<mkdir dir="build/babeldoc-service.sar/META-INF"/>
+   	<copy todir="build/babeldoc-service.sar/META-INF">
+   		<fileset dir="modules/scanner/config">
+   			<include name="jboss-service.xml"/>
+   		</fileset>
+ 	</copy>
+   	<copy todir="build/babeldoc-service.sar">
+   		<fileset dir="build/lib">
+   			<include name="activation.jar"/>
+   			<include name="avalon-framework.jar"/>
+   			<include name="babeldoc_babelfish.jar"/>
+   			<include name="babeldoc_conversion.jar"/>
+   			<include name="babeldoc_core.jar"/>
+   			<include name="babeldoc_crypto.jar"/>
+   			<include name="babeldoc_init.jar"/>
+   			<include name="babeldoc_jfreereports.jar"/>
+   			<include name="babeldoc-scanner.jar"/>
+   			<include name="babeldoc_sql.jar"/>
+   			<include name="babeldoc_xslfo.jar"/>
+   			<include name="batik.jar"/>
+   			<include name="bsf.jar"/>
+   			<include name="classes12.jar"/>
+   			<include name="commons-beanutils.jar"/>
+   			<include name="commons-cli.jar"/>
+   			<include name="commons-collections.jar"/>
+   			<include name="commons-dbcp.jar"/>
+   			<include name="commons-digester.jar"/>
+   			<include name="commons-discovery.jar"/>
+   			<include name="commons-httpclient.jar"/>
+   			<include name="commons-lang.jar"/>
+   			<include name="commons-logging.jar"/>
+   			<include name="commons-net.jar"/>
+   			<include name="commons-pool.jar"/>
+   			<include name="concurrent.jar"/>
+   			<include name="csv19.jar"/>
+   			<include name="dom4j-full.jar"/>
+   			<include name="jcommon-0.8.5.jar"/>
+   			<include name="jfreereport-0.8.4_4-all.jar"/>
+   			<include name="poi.jar"/>
+   			<include name="velocity.jar"/>
+   			<include name="xml-apis.jar"/>
+   			<include name="xmlsec.jar"/>
+   		</fileset>
+   	</copy>
+   	<jar destfile="build/lib/babeldoc-service.sar"
+   		basedir="build/babeldoc-service.sar">
+ 			<manifest>
+ 				<attribute name="Built-By" value="${user.name}"/>
+ 			</manifest>
+   	</jar>
+   </target>
  </project>

[Babeldoc-devel] modules/jabber build.properties,1.1,1.2 build.xml,1.1,1.2

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

Update of /cvsroot/babeldoc/modules/jabber
In directory sc8-pr-cvs1:/tmp/cvs-serv31567/jabber

Modified Files:
	build.properties build.xml 
Log Message:
Cleaned up to compile

Index: build.properties
===================================================================
RCS file: /cvsroot/babeldoc/modules/jabber/build.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** build.properties	9 Oct 2003 14:03:56 -0000	1.1
--- build.properties	5 Dec 2003 23:40:34 -0000	1.2
***************
*** 1,7 ****
! Module=soap
! Depends=core web
! Jarfile=babeldoc_soap.jar
! ModuleClass=com.babeldoc.soap.module.SoapModule
  
! web_soapfeed_warfile=babeldoc_soapfeed.war
  
--- 1,7 ----
! Module=jabber
! Depends=core
! Jarfile=babeldoc_jabber.jar
! ModuleClass=com.babeldoc.jabber.module.XmppWriterModule
  
! babeldoc_home=../../Babeldoc/build
  

Index: build.xml
===================================================================
RCS file: /cvsroot/babeldoc/modules/jabber/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** build.xml	9 Oct 2003 14:03:57 -0000	1.1
--- build.xml	5 Dec 2003 23:40:34 -0000	1.2
***************
*** 1,10 ****
! <project name="soap" basedir="." default="setup">
  	<property file="build.properties"/>
  
  	<property name="module_name" value="babeldoc_${Module}"/>
! 	<property name="module_path" value="${build}"/>
! 
  	<target
! 		name="setup"/>
  
  	<target
--- 1,18 ----
! <project name="jabber" basedir="." default="build">
  	<property file="build.properties"/>
  
  	<property name="module_name" value="babeldoc_${Module}"/>
! 	<property name="module_path" value="./build"/>
! 	<property name="base_dir" value="${basedir}"/>
! 	<property name="babeldoc_home" value="${babeldoc_home}"/>
! 	
  	<target
! 		name="setup">
! 		<mkdir dir="./build"/>
! 		<mkdir dir="./build/lib"/>
! 		<mkdir dir="./build/examples"/>
! 		<mkdir dir="./build/readme"/>
! 		<mkdir dir="./build/support"/>
! 	</target>
  
  	<target
***************
*** 30,33 ****
--- 38,44 ----
  				  <include name="*"/>
  			  </fileset>
+ 				<fileset dir="${babeldoc_home}/lib">
+ 				  <include name="*"/>
+ 			  </fileset>
  			  <pathelement location="${base_dir}/support/ant/lib/junit.jar"/>
  		  </classpath>
***************
*** 50,54 ****
  		<jar 
  			jarfile="${base_dir}/build/lib/${Jarfile}"
! 			basedir="${module_path}">
  			<manifest>
  				<attribute name="Built-By" value="${user.name}"/>
--- 61,66 ----
  		<jar 
  			jarfile="${base_dir}/build/lib/${Jarfile}"
! 			basedir="${module_path}"
! 			excludes="**/${Jarfile}">
  			<manifest>
  				<attribute name="Built-By" value="${user.name}"/>
***************
*** 60,79 ****
  	    </manifest>
  		</jar>
- 
- 		<!--
- 		Make the soap servlet
- 		-->
- 		<mkdir dir="build/soapfeed/"/>
- 		<copy toDir="build/soapfeed/">
- 			<fileset dir="servlet/soapfeed"/>
- 		</copy>
- 		<copy toDir="build/soapfeed/WEB-INF">
- 			<fileset dir="build">
- 				<include name="com/**"/>
- 			</fileset>
- 		</copy>
- 		<jar
- 			jarfile="${base_dir}/build/lib/${web_soapfeed_warfile}"
- 			basedir="build/soapfeed"/>
  
  		<copy toDir="${base_dir}/build">
--- 72,75 ----

[Babeldoc-devel] modules/jabber/config/service query.properties,1.1,1.2

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

Update of /cvsroot/babeldoc/modules/jabber/config/service
In directory sc8-pr-cvs1:/tmp/cvs-serv31567/jabber/config/service

Modified Files:
	query.properties 
Log Message:
Cleaned up to compile

Index: query.properties
===================================================================
RCS file: /cvsroot/babeldoc/modules/jabber/config/service/query.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** query.properties	9 Oct 2003 14:03:57 -0000	1.1
--- query.properties	5 Dec 2003 23:40:34 -0000	1.2
***************
*** 1,2 ****
! PipelineStage.SoapWriter=com.babeldoc.soap.pipeline.stage.SoapWriterPipelineStage
  
--- 1,2 ----
! PipelineStage.XmppWriter=com.babeldoc.jabber.pipeline.stage.XmppWriterPipelineStage
  

[Babeldoc-devel] modules/jabber/services com.babeldoc.core.module.BabeldocModule,1.1,1.2

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

Update of /cvsroot/babeldoc/modules/jabber/services
In directory sc8-pr-cvs1:/tmp/cvs-serv31567/jabber/services

Modified Files:
	com.babeldoc.core.module.BabeldocModule 
Log Message:
Cleaned up to compile

Index: com.babeldoc.core.module.BabeldocModule
===================================================================
RCS file: /cvsroot/babeldoc/modules/jabber/services/com.babeldoc.core.module.BabeldocModule,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** com.babeldoc.core.module.BabeldocModule	9 Oct 2003 14:03:58 -0000	1.1
--- com.babeldoc.core.module.BabeldocModule	5 Dec 2003 23:40:34 -0000	1.2
***************
*** 1 ****
! com.babeldoc.soap.module.SoapModule
--- 1,2 ----
! com.babeldoc.jabber.module.XmppWriterModule
! 

[Babeldoc-devel] modules/jabber/config/i18n messages.properties,1.1,1.2

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

Update of /cvsroot/babeldoc/modules/jabber/config/i18n
In directory sc8-pr-cvs1:/tmp/cvs-serv31567/jabber/config/i18n

Modified Files:
	messages.properties 
Log Message:
Cleaned up to compile

Index: messages.properties
===================================================================
RCS file: /cvsroot/babeldoc/modules/jabber/config/i18n/messages.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** messages.properties	9 Oct 2003 14:03:57 -0000	1.1
--- messages.properties	5 Dec 2003 23:40:34 -0000	1.2
***************
*** 1,18 ****
- soap.001=Feed the document to the soap pipeline
- soap.002=Sending SOAP Message
- soap.003=Waiting for response....
- soap.004=HTTP POST was successful. \n
- soap.005=No host:port parameter
- soap.006=No file parameter
- soap.007=<host:port> Server address and port number
-  
- soap.100=Send the document to a soap service
- soap.101=URL for the SOAP service
- soap.102=SOAP action
- soap.103=URL for the SOAP service
- soap.104=Error sending soap message
- soap.105=Error processing SOAP response
- soap.106=Return SOAP service response as an attribute
- soap.107=Post soap document with authentication
- soap.108=User id for authentication
- soap.109=Password for authentication
--- 0 ----